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: 17 Nov 92 08:22:58 GMT
Article-I.D.: andrew.Mf2HW2G00iUz83GxNz
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.next.advocacy: 17-Nov-92 Re: 64-bit CPUs
(was DEC's .. by Steven T. Abell@netcom.c 
> 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.

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

The most difficult case...ugh.  If you can make a minimal set of
alignment assumptions, then clearly a simple algorithm will work.  These
restrictions will hold for dealing with structs, but the most general
case with strings is difficult.  You may well have a point here; I'll
have to think about this one a bit.

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

Auto-increment mode ala the PDP-11?  It's no surprise that this works
well; the C string definition was designed with auto-increment
addressing in mind.  Using a different string definition (pascal,
perhaps? [ie, requiring that each string has an initial length byte])
makes auto-increment much less useful.  Pascal strings (or substrings)
can require to be aligned so that the simpler algorithm can be used. 
Agreed, this is a restriction, but there are environments where it's
better not to be able to arbitrarily mangle pointers.

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

You refer to passing structs on the stack *by value*, I assume?  You can
do it by making sure that the holes are zero-filled and that the struct
is correctly aligned in the stack.

BTW, I'm very wary of passing structs by value and not reference;
remember the incredible hassle on the Sun SPARC's because gcc and Sun's
cc didn't agree on how to do this?  That's been fixed, but it was a big
mess for a while because Sun didn't have a bug-free C compiler and gcc
was incompatible with Sun's shared libraries.  In general, IMHO, there
is no real reason to pass structs on the stack; either do it by
reference, or pass individual data values as needed.  You're not going
to lose that much performance.

-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]
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA