🚀 go-pugleaf

In article <7952@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes:
>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. 
>
>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.
>
>>   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
From this and previous postings I get the impression than one is comparing
apples and oranges.
I think that comparing code size should be done on code that is generated
with the same operating system, probably unix.
If that is the case than the 386 compiler does not use the segment registers
in the user code. All memory references will be 32 bits references.
The compiler we have for the 386 on unix is from AT&T unix V release 3.1
It does not use the segment registers, that leaves 8 registers. From
these registers 3 are used for the c register declarations ( 4 in 3.2 ).
For the motorola the compiler can hold ten register declarations.
This make a big diffrence in code size and execution speed.

So before more comparisons are made lets do it in the same operating
environment and not compare code generated under MSDOS with code generated
under UNIX.

-- 
#  Peter Brouwer,                     ##
#  Philips TDS, Dept SSP-V2           ## voice +31 55 432523
#  P.O. Box 245                       ## UUCP address ..!mcvax!philapd!pb
#  7300 AE Apeldoorn, The Netherlands ## Internet pb@idca.tds.philips.nl