🚀 go-pugleaf

In article <Bz2rKn.ByF@cantua.canterbury.ac.nz> deanaj@elec.canterbury.ac.nz (A. J. Dean) writes:
>Mike Newberry (newberry@aquarius.as.arizona.edu) wrote:
>: >you are using, etc. PC C compilers seem to be generally pretty useless, even
>: >if they do optimise they often still leave massive room for improvement in
>: >the assembly. Sparc compilers seem to get it together much more. But if you
>: 
>: It depends greatly upon the PC compiler.  Watcom C/386 and Metaware High C
>: produce good code, as one can tell by disassembling the object module and
>: inspecting the assembly code.  The 16 bit compilers all have troubles
>: because of the 16 bit address space and the fact that the 287 compatible
>: code they produce has no sin, cos, arcsin, and arccos instructions--they
>: don't exist on the 87 and 287.  They so exist on higher processors.
>
>No doubt, they are getting _much_ better. A lot of it seems to be to do with
>the way arguments and data is passed into functions - quite slow on a 80x86,
>but I suppose like the lack of sin, cos etc there is some minimum amount of
>mess you just have to put up with.  Also something I don't immediately
>appreciate while looking wild-eyed at some ultimately 'stupid' compiler
>output, is that it did have to be compiled, and every departure from the
>line by line approach leaves a little more room availble for something to
>come unstuck. Someone has to write the compiler after all. Though I still
>rekon I could do it better!...
>
>Antony.

One point you brought up that I forgot to mention about the Watcom C/386
compiler is that it can pass and retrieve arguments using registers instead
of pushing and popping the stack as per the original C standard.  That does
save some time when your code calls a function inside a tight loop.  The
Watcom C/386 compiler is an industrial strength package that one doesn't find
all that often in the PC world. I understand that Metaware's compiler is
of similar caliber but I can't speak from experience with it.
.