pyramid architectural restraints

[Guy Harris]

> We currently have a pyramid 90x which I am evaluating in my copious spare
> time.  It's configured with 4m main, and ~900m disk.  We do not have
> data cache installed yet.  So far, a great deal of fun has been had, but
> the 90x faults on non-long-aligned 32-bit memory operations.  Any comments,
> questions, opinions, etc, would be of interest.  Especially regarding the
> above item.  Also, I am interested in exchanging benchmark stats (vs
> 780, 750).  Lastly, I am curious about up-and-coming architectures (exp.
> DEC) with the above constraint.

The Motorola M68000 CPU chips (MC68000 and MC68010, at least) fault on non-word-
aligned 16-bit or 32-bit memory operations.  The 360 would also fault on non-
long-aligned 32-bit operations or non-(half)word-aligned 16-bit operations;
the 370 (and 360/85) wouldn't, *but* would run slower if the operand wasn't
properly aligned.  I believe the same is true on the VAX; i.e., you can put
things off the right boundary, but you pay for it.  Since C puts things on the
right boundary, and since you're better off putting them there in a lot of
cases even on machines which permit you to do otherwise, I presume Pyramid
figured it wasn't worth the trouble to permit unaligned operands.  I suspect
it'll be a cold day in June before any VAXen refuse to support unaligned
operands (compatibility and all that), but I suspect any other machines
DEC is working on (like some RISC project supposedly being cooked up) may not
feel any obligation to support them.

I can't speak for most other VAX-class superminis (such as the Ridge 32), but
there *is* at least one other 32-bit supermini which requires proper alignment;
the CCI Power 6/32.  (It's not announced yet, but it's *very* fast.  Keep
your eyes peeled.  - unpaid commercial announcement)  When we ported UNET
to our 6/32, we did get bit by that one but it was simple to fix.  (The code
was using an "short *" to point into a buffer and either casting or assigning
that pointer to "long *" and pulling a 32-bit quantity out of that buffer.
It probably never failed on other machines because most of them are 16-bit
or 16/32 bit machines and only require 16-bit alignment, or are 32-bit
machines but don't require any alignment.)  I suspect we took the same tack;
namely, C puts things on the right boundary, and there's no guarantee that
unaligned operands work on all machines, so portable code won't assume that
they do - so there's no point in putting effort into supporting unaligned
operands.

Consider that lots of machines read the contents of a memory buffer register
onto some internal 32-bit data bus; if the operand is aligned, you need not
monkey with it, but if it's unaligned you have to fetch the next longword,
combine the two longwords, shift it by the appropriate number of bytes, and
pull out the appropriate 32 bits and put them onto the appropriate data
bus.  If you don't really need all this fanciness, why bother?

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy