🚀 go-pugleaf

in article <13699@steinmetz.ge.com>, davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) says:
>   Someone posted an opinion that images on the 68040 will be smaller
> than the 80386. I didn't think this sounded right, so I made a few

For programs with less than 64K of data and 64K of text, the
generated 8086 code is more compact than 68000 code. This is because
a) it's using 16-bit pointers, and b) all those one-byte opcodes.

On the other hand, for programs with more than 64K of data (and, to
some extent, programs with more than 64K of text), the 68000 is 
more efficient, because it doesn't have to be loading those damned
segment registers all the time.

It's probably a tossup as to whether the 80386 vs. 68040 comparison
will continue that trend. I suspect that for small codes, the 80386
will continue having more compact object code. But once the need for
32-bit segments occurs, the 80386 and 680xx are likely to be about the
same as far as code density goes. 

>   I checked the size of image files compiled from the same source on
> Xenix/386 v2.3.1 and SunOS 3.4 (on a 3/280 if anyone cares). I noted

A possible flaw: I seem to recall that SunOS's old compilers, at
least, were based on the PCC. The PCC isn't exactly the world's most
sophisticated compiler. The code it produces is, to put it charitably,
merely adequate. On the other hand, I suspect that the Xenix compiler
has been much tweaked by Microsoft's compiler experts....

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //  ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849     |
| \X/           Newsflash: DP director fired for buying IBM!                |