🚀 go-pugleaf

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.

>+bet you didn't time how long BC++ took to compile the same program compared
>+to BC++ did you now?), the RTL in Gcc 2.1 is _REAL_ slow. To prove my

>The slowness here is not due to 'I/O' but the method used for the
>RTL vs. what B- does.

Possibly, so what are the different methodologies used? They are still both
ANSI C standard libraries, so there cant be too much difference. Anywayu,
my point was that using the STANDARD ANSI C I/O routine is SLOW under GCC.
Surely this means the I/O routines are slow?

>Where does the DJGPP 'libc.a' equivalent come from? The biggest
>problem with the usual stdio functions on DOS is the wyrdness of
>handling the CRLF to LF translation so that such things as 'gets'
>works as expected on 'UN*X'. Raw 'read' binary I/O functions are simple DOS
>function calls and work equally as fast in either setting.

I assume that DJ either used the GNU C library, or at least wrote on
himself. I seem to remember that it was very similar to the GNU C lib, but
had been modified extensively.

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_?

>There is a 'generic' gas-doc file which I've seen on
>'prep.ai.mit.edu' where the released gas is. The assembler is one
>thing I won't try to defend, only to say that it is in the 'UN*X'
>tradtion which is "we don't need no stinking assembler". However, it
>is possible to embed asm statements in the 'C' code via the 'asm'
>compiler 'pseudo' function.

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

+------------------------------------------+-------------------------------+
| Kendall Bennett,                         | Internet:                     |
| Advanced Computer Graphics Centre,       | kjb@godzilla.cgl.citri.edu.au |
| Royal Melbourne Institute of Technology, | rcskb@minyos.xx.rmit.oz.au    |
| Victoria, AUSTRALIA.                     |                               | 
+------------------------------------------+-------------------------------+
| CoSysop (Bossman), PC Connection Australia:               +61 3 688 0909 |
+--------------------------------------------------------------------------+