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

cs4w+@andrew.cmu.edu (Charles William Swiger) writes:
>abell@netcom.com (Steven T. Abell) writes:
>> [ 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.

There's something I'm not sure is coming through here. We're talking about
string movement from an arbitrary not-necessarily-aligned address to an
arbitrary not-necessarily-aligned address. The bus interfaces on the CPUs
I've seen do non-aligned multibyte reads and writes either at a high cost
or not at all. The algorithms to do string movement in multibyte chunks are
*non-trivial*, that is, not "pick it up here and put it down there", which
will *crash* a 68K. If we are (unbeknownst to me) discussing machines that
will do arbitrary no-additional-cost reads and writes, this discussion
might as well be about apples and oranges.

>> The method actually uses rotation, not masking.

>Ummm...yes.  

If we are really agreeing on this, I'd like to see your code, preferably
in assembler. Maybe I'll learn something. Maybe you will. Test it on a
string of length 32, moving from an address ending in 1 to an address ending
in 2.

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

The lack of autoincrement on a RISC makes other economies worth attempting.
You *need* a 64-bit CPU to make these fancy string movers worthwhile on a
68K-like machine. On a smaller CPU, the fancy method is *slower* than
byte-by-byte.

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

What if your struct is on the stack? K&R recommend against simple-minded
block comparison of structs for just this reason. If you want to specify
no structs on the stack, there's a performance loss right there.

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