🚀 go-pugleaf

Thanks to everyone who replied to my question on whether there was an
advantage to using short ints (16 bits) where 32 really were not required.
These replies answer quite nicely:


From: <ubc-cs!uunet!microsoft!donh>

> In a 32-bit code segment (default is to use 32-bit registers) there is
> actually a performance *penalty* for using 16-bit ints.  Processing
> the operand size override adds about one clock per instruction.  In a
> 32-bit C program you would want to use shorts only when you have to
> match existing data structures in size, or when you are desparate for
> data space.

-- 

From van-bc!ubc-cs!uunet!sco!seanf Sat Jan 14 04:44:00 1989

> Use 32-bit ints.  The 80386 does everything in 32-bit chunks, for the most
> part, and C will have subscripts converted to an int (32-bit) anyway.
 
--

From van-bc!ubc-cs!uunet!vrdxhq!drew Sat Jan 14 04:44:05 1989

>     The most important thing to remember when doing operations on 32-bit
> objects is long-word alignment.  Remember that if a 32-bit object rests
> on a word boundary, but not a long-word boundary, it still takes 2 reads
> to get the object.  Many compilers (including our Ada compiler) do not
> automatically do this for you.  When using 16-bit objects, you are virtually
> guaranteed 1-read access to the object, as virtually all compilers start
> objects on even boundaries.
>
>     The actual performance difference will depend upon optimization/hardware
> (code hoisting in loops, register variables, data caches, etc) available
> in your situation, so it is not a simple issue.

-- 
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Frank I. Reiter             \ /    UUCP:    {uunet,ubc-cs}!van-bc!rsoft!frank
Langley, British Columbia   / \     BBS:    Mind Link @ (604)533-2312
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*