Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!ames!orville!fouts
From: fouts@orville.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <738@ames.UUCP>
Date: Fri, 13-Mar-87 11:03:00 EST
Article-I.D.: ames.738
Posted: Fri Mar 13 11:03:00 1987
Date-Received: Sat, 14-Mar-87 10:55:34 EST
References: <3810013@nucsrl.UUCP>
Sender: usenet@ames.UUCP
Reply-To: fouts@orville.UUCP (Marty Fouts)
Organization: NASA Ames Research Center, Mountain View, CA
Lines: 28

In article <3810013@nucsrl.UUCP> ram@nucsrl.UUCP (Raman Renu) writes:

>     Any predictions?  Do we really need 64 bit processing power?

Dusting off my crystal ball, I come to the following conclusion:

It depends.

As things currently stand, much of what is done with a computer is
"naturally" done with smaller word sizes;  bytes for character
processing, 16 bit integers for many things, 32 bit for others and 32
bit floating point data is often adequate.  32 bit address spaces will
probably be adequate for five or six years.

64 bit systems buy you more floating point precision at the cost of
complexity in nearly everything else.  If the memory addressable unit
is also 64 bits, then partial word computations become relitively more
expansive, because of the need to shift and mask.  If the memory
addressable unit is 32, 16, or 8 bits, than subword swapping can
become a local problem, address alignment complexity creeps in, and
memory reference operations can become more expensive.

Given a lack of preceived need which would drive a requirement for 64
bit systems, I would suspect most designers will concentrate on
building 32 bit systems which are better than current systems by some
metric such as speed, power consumption, or chip count.

Marty