From: cs4w+@andrew.cmu.edu (Charles William Swiger)
Newsgroups: comp.sys.next.advocacy
Subject: Re: DEC's alpha is "way fast" according to WSJournal
Date: 12 Nov 92 06:29:57 GMT
Article-I.D.: andrew.Qf0cO5m00WBO02KJ5a
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.next.advocacy: 12-Nov-92 Re: DEC's alpha
is "way fas.. by Steven T. Abell@netcom.c 

> 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.

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.

> 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.  Also note that there is a growing tendancy towards
moving to larger characters in order to deal with foreign language needs.
  
> 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.)

> Don't flame, just enlighten, please.

But, isn't flame enlightening?  ;-)

But for all of the above, I agree with you to some extent.  The
transition between a 16-bit and a 32-bit processor was a major leap in
system capability.  The Macintosh was the first major machine to make
the transition way back when, and their OS was able to make assumptions
about the hardware that made it substantially more functional than the
MS-DOS 2.x (maybe 3.x) environment of IBM's of that time.  IBM-PC
operating systems are still trying to catch up: witness the troubles
that OS/2 has had gaining acceptance.  (NT is still vaporware to me, and
MS-Windows is a bad joke.)

I don't see a major revolution occurring with the transition between
32-bit and 64-bit processors because the computer industry really hasn't
max'ed out the possibilities of 32-bit machines yet.  (How many people
do you know have complained that their machines can only address 4 gigs
at a time?  Anyone ever seen a machine with more than 4 gigs?  Cray
YMP's in your local supercomputing center, perhaps, but not machines
intended for the consumer market.)

-Chuck

+------------------------------------------+ "Foosh.  Aaughh!!"
| Charles William Swiger -- CMU...crunch!  | "Foosh.  Aauuggghh!!"
| AMS & normal mail: cs4w+@andrew.cmu.edu  | "Cold spray deodorant...."
| NeXTmail: chuck@mon.slip.andrew.cmu.edu  |
+------------------------------------------+   -- Opus, Bloom County [RIP]
Newsgroups: comp.sys.next.advocacy