From: cs4w+@andrew.cmu.edu (Charles William Swiger)
Newsgroups: comp.sys.next.advocacy
Subject: Re: 64-bit CPUs (was DEC's alpha is "way fast")
Date: 16 Nov 92 13:48:23 GMT
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.next.advocacy: 14-Nov-92 Re: 64-bit CPUs
(was DEC's .. by Steven T. Abell@netcom.c 
> No, they aren't 32-bit clean. They contain extra information that prevents
> their use as machine pointers without added manipulation. For example, some
> lisps bury garbage-collection status in the upper ends of their pointers.
> As I said earlier, this isn't necessarily bad, but it's something to be
> avoided. Some CPUs provide subregisters or bitfield extraction instructions
> that can help with this; such features seem contrary to the nature of RISC.

We're using the term "32-bit clean" in slightly different contexts here.
 Your description above is absolutely correct, but I would still regard
emacs, LISP, et al to be 32-bit clean if the program itself (the
executable code) is 32-bit clean.  The programs are free to create data
structures (using things like typed pointers, etc) that cannot represent
32-bit objects.  It's a tolerable solution to the typing problem.

> [ munch ]
> We're sort of both right:
>  
> On a 32-bit CISC, the realignment method you're talking about moves 2 bytes
> in three instructions, which is a net loss to byte movement; a 64-bit CISC
> moves 4 bytes in 3 instructions, a net gain, but not by all that much.
> On a RISC, this method requires 5 instructions per transfer, with 2 bytes
> moved through 32 bits, 4 bytes through 64, as opposed to 4 instructions per
> byte for byte movement.

You're thinking too hard about this.  Assuming that you want to optimize
memory block moves or comparisions, at the cost of a little added space,
simply have strings have a CPU-word size NULL area so that you can do a
test for zero with it for the end-of-string.  You can do a move or
compare with a trivial algorithm; this algorithm will be twice as fast
on a 64- than  32- bit processor.  (Assuming the 64-bit CPU instructions
take the same amount of time as the 32-bit CPU instructions.)  You can
save this space if you know ahead of time how bit the strings are and
special case at the end if the string lengths aren't an even multiple of
the CPU size.

> The method actually uses rotation, not masking.

Ummm...yes.  

> In other words, nobody would do this on a CISC, but anybody would on a
> RISC.  I'm still used to thinking about CISCs. My apologies.

CISC vesus RISC doesn't matter here, I think.

>>Read Scott's description and substitute "object (struct)" for "string".
>>A 64-bit CPU is on the order of twice as fast as a 32-bit CPU for doing
>>these operations.  However, when you need to actually deal with the
>>contents of the string itself, any CPU that's at least as wide as the
>>character size will run at the same speed.
>  
> I'm willing to soften my stance on struct ops, but the normal inheritance
> architecture leaves holes in aligned structs that have to be masked out,
> which will palpably decrease throughput in struct compares.

You can use calloc() rather than malloc() to allocate space for
structures, so the holes created by alignment restrictions will be
zero-filled.  No performance loss involved.

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