From: abell@netcom.com (Steven T. Abell)
Subject: 64-bit CPUs (was DEC's alpha is "way fast")
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 12 Nov 1992 23:51:51 GMT

Regarding the speed increase due to a 64-bit CPU,
cs4w+@andrew.cmu.edu (Charles William Swiger) writes:
> abell@netcom.com (Steven T. Abell) writes:
>> Someone will have to explain this one to me, because:
>> 
>> 1) Not that many programs use floating point;

>Arguable, but even so, a 64-bit processor does 64-bit integer ops, as
>well.  Right now, most programs don't need 64 bits for representing
>either integers or pointers, because 32 bits has provided more than
>sufficient addressing space and numerical representation space.

Actually, I'm working on an app right now that could use 64-bit integers,
but I'm willing to bet that it's one of *very few* such apps I'll
ever write or use.

>However, there are definitely times when having some extra room is
>really nice.  For example, in languages that have typing infomation
>associated with every object, having 64 bits to play with makes it
>somewhat easier to write fast ops.  Examples would be LISP, SML, and
>others.  Currently, most implementations use 24 bits for addressing, and
>8 bits for typing, limiting the data space to 4MB or so.  The elisp
>found under GNU Emacs is a classic example of this.

*Danger, Will Robinson! Danger!* Remember the flap about 32-bit cleanness
in the Mac world? Tricks like this sometimes pay off, but often have
regrettable consequences later. Also, most CPUs give you precious little
help in working with composite operands. I used to design calculators
for HP; their current calc CPU has 64-bit registers with lots of subfields
that make it easy to do this kind of stuff. But the mainstream CPUs I've
seen don't support such tricks. I'm not saying composite operands are bad,
anymore than I think self-modifying code is bad, but you have to remember
that there are usually good reasons not to use techniques like this.

>> 2) Bus interfaces are usually designed such that a big ALU and a wide bus
>>    is useless in string operations, where alignment restrictions can't
>>    be applied;

>Partially true.  The standard 'char' is 8 bits, and on a char-by-char
>basis, 32- & 64- bit processors tie.  However, a 64-bit processor can do
>string moves and compares close to twice as fast as a 32-bit, other
>things being equal.

No, they can't, in general. Please note that my comment is phrased in
terms of bus interfaces. Try doing a *general* full-width string move
where you often have unaligned data. i86s do it at a substantially higher
cost for unaligned data; 68Ks will do the aligned cases only, and *crash*
on the unaligned cases. There is *no way* to correct this problem short of
8-bit comparisons. Without a bus interface that none of the vendors seems
to want to develop, even a 16-bit CPU is no better than an 8-bit machine
for these problems.
  
>> 3) Portability constraints decrease the utility of a big ALU and a wide bus
>>    in struct operations, where alignment restrictions *are* applied.

>It's true that a 64-bit processor will be happier using wider alignment
>than a 32-bit, but so what?  How does this affect portability?  (It does
>affect inter-system compatibility for raw data files, but that's not a
>huge concern.)

I think lots of people will disagree about the level of concern. Also,
we're talking about whether a 64-bit machine is really faster than a
32-bitter. Due to alignment problems and the C specification, object
(struct) comparisons, for example, can only use all of the ALU when
the struct fields are fortuitously packed. Faster? Usually, but not by
any kind of factor of 2.

You've raised some good points, but I think some of those points are
bumps in a minefield. For most apps, a 64-bit CPU is a waste of silicon.

Steve abell@netcom.com
Newsgroups: comp.sys.next.advocacy