Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ncr-sd!stubbs
From: stubbs@ncr-sd.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <1483@ncr-sd.SanDiego.NCR.COM>
Date: Fri, 3-Apr-87 14:39:09 EST
Article-I.D.: ncr-sd.1483
Posted: Fri Apr  3 14:39:09 1987
Date-Received: Sun, 5-Apr-87 03:37:51 EST
Reply-To: stubbs@ncr-sd.UUCP (0000-Jan Stubbs)
Organization: NCR Corporation, Rancho Bernardo
Lines: 30

In article <5954@amdahl.UUCP> chuck@amdahl.UUCP (Charles Simmons) writes:
>16 bits is clearly not sufficient for most things people do.  Consider
>
>hundred thousand dollars a year.  It would be nice, when generating
>reports describing where the money came from and where it went, to
>store these figures as fixed point numbers.  But they certainly won't
>fit in 16 bit integers.
>

Integer size and field size need not be restricted by hardware word
size. My NCR 9800 has up to 256 byte integer arithmetic (add sub, etc.)
implemented in one machine instruction. Of course since it is
a 32 bit word machine this takes multiple cycles, but firmware
does the work. 

Maybe the real concern is performance. The unit
of memory access is selected based on many factors, including
average instruction size, register size, address size, average
data operand size, and today, how many pins you can fit 
on your chip package. Integer size is only one (important)
factor. Another important factor is what all the support
hardware uses, and today 32 bits is in, and will be
for a long long time.


Jan Stubbs    ....sdcsvax!ncr-sd!stubbs
619 485-3052
NCR Corporation
16550 W. Bernardo Drive MS4010
San Diego, CA. 92127