🚀 go-pugleaf

In article <kjb.706245348@godzilla.cgl.citri.edu.au> kjb@cgl.rmit.oz.au (Kendall Bennett) writes:
+jclark@sdcc3.ucsd.edu (John Clark) writes:
+
+>+The Borland C++ runtime library has been carefully tuned to run efficiently
+>+on an 8086 based system (if you dont believe me, check the source code). It
+>+is very fast. Gcc 2.1's runtime library has been written to be portable, so
+
+>But then why do you have to use the B- runtime library? Because B-
+>doesn't impliment 32 bit ops, but does them as subroutines..
+
+Your not making any sense here.

I think of 'runtime' libraries as those routines which the code
uses to implement language operations which are not implemented by
the hardware, as in the usual 64 bit operations of 'long long', or
common to modern 'C's structure assignment. I think of the 'libc.a'
functions as that, or 'read/write/open/close' etc. as I/O libraries.


+Hmm. Translating CR/LF to LF's. The whole point of the program I wrote
+was to do just this, so would it be pretty silly to read the file in
+text format? Naturally I was reading 20k chunks (like I said) in 'raw'
+binary format - admittedly I was using fread and fwrite for ANSI
+compatability, but they should still be fast as they ARE 'raw' binary
+read routines right? So tell me how you came to the conclusion that
+RAW binary reads would be equally fast under both settings? Have you
+even bother to test this _hypothesis_?

Since I haven't used a PC in over 2 years, I haven't tested
anything. My conjectures are based on my experience with Turbo-C and
Microsoft C. Both of which required the use of the 'O_BINARY' open
option flag to get 'raw-io' on DOS files. In those days I was forced
to use MASM to implement truely direct 'raw-io' if I wanted no delay
or other problems. (I was also using my own multi-tasking executive
on top of DOS and so had to protect 'DOS' call from 're-entrancy'
problems.

The T-C and M-C 'f...' file functions had even more layers than the
primative 'read/write' functions.

+Oh come now. The embedded assembler statements must STILL be BSD style
+assembler, and look exactly like the standalon .s files...


With the 'asm' construct one can emit such code as:(using a 68k like
assmebly code, since I don't have a PC to test authoritatively a PC
example, nor do I have my hand DOS tech ref. to know which AX, BX,
DX, CX, DS, ES, et al to set up to emit a DOS call).

Raw_read( fd, buf, length )
{
	asm( "movel %0,d0" :: "m" (fd) );
	asm( "movel %0,d1" :: "m" (buf) );
	asm( "movel %0,d2" :: "m" (length) );

	asm( "trap #15" );
}


Clearly this circumvents any 'ANSI' functions, but does IO
directly, if the DOS gnu CC doesn't boil down to an equivalent in the
DOS environment, then it isn't going to be effecient.

I'm almost about to dig around in the PC just to test this out. But
I have a number of things to do so I won't be able to get to it
until sometime in July or so.
-- 

John Clark
jclark@ucsd.edu