🚀 go-pugleaf

In article <1989May20.223228.2456@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
(discussion: should 68000's and 68010's have 16-bit ints or 32-bit ints?)

>On the 68000 and 68010, there was no consensus on this, and both choices
>were found in operational compilers.  32-bit ints are generally better,
>and the common operations were present, but some of the less common ones
>(e.g. multiply) weren't, and most everything took an efficiency hit from
>32-bit data on a 16-bit bus.  The width of int is supposed to be "the most
>natural width", but for the 680[01]0 that could go either way, depending
>on the implementor's prejudices.

Henry, why do you say that 32-bit ints are "generally better" on
68000's and 68010's?  Seems to me the only reason someone would
consider such an unnatural thing is that there is so much sloppy code
around that assumes that ints are the same size as pointers.  Choosing
32-bit ints on a 68010 causes poorer performance and larger code.  It
takes cycles to fetch all those 32-bit values and memory to store
them.  While multiplies aren't all that common, the applications that
do generate them take big performance hits when library calls are
needed instead of single instructions.  With the 16-bit-int choice,
32-bit integers can be obtained where required by declaring variables
"long".  There isn't any way to get the more compact, efficient 16-bit
int operations if your compiler makes the (IMnotsoHO) wrong choice.

The most common values of integer variables are "0" and "1".  Why drag
those extra bytes everywhere?

I'm obviously in the minority on this.  I want to junk our old HP64000
development system, and all the newer emulator/cross-compiler products
want to do 32-bit ints for 68000's.  Grr.
-- 
-- Joe Buck	jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck