Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!killer!elg From: elg@killer.Dallas.TX.US (Eric Green) Newsgroups: comp.arch Subject: Re: 80486 vs. 68040 code size Message-ID: <7952@killer.Dallas.TX.US> Date: 29 Apr 89 16:18:49 GMT References: <13699@steinmetz.ge.com> Organization: The Unix(R) Connection, Dallas, Texas Lines: 32 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! |