pyramid architectural restraints

[Henry Spencer]

Kenneth Reek contends, in part:

	Architectures that require aligning multi-byte quantities on
	particular boundaries sound to me like they were designed by an
	engineer who was interested in simplifying his own task at the
	expense of the software designers who will use the machine.

Simple hardware wins on more counts than just making life easier for
lazy engineers.  It is simpler and cheaper to build, simpler for the
software to run (comparing an 11/44 to the nightmare complexity of the
VAX i/o structure, for example, tells you why 4.2BSD is so bloated),
more reliable, easier to fix when it breaks, etc etc.

Don't forget that magic word "cheaper".  It has become fashionable
to say "software costs totally dominate hardware costs", but most
people forget to add "...unless you can't afford the hardware in the
first place".  Hardware and software money don't usually come out of
the same pot, and the people who make decisions about such things are
not necessarily as enlightened as we are.  And once again, don't forget
the example of the VAX:  sure, it looks like a nice machine, but it's
grossly overpriced for its market now.  This is despite massive use of
[semi-]custom ICs on the more recent VAXen -- and you would not believe
what a disaster that is for production and maintenance!  (There is an
awful lot to be said for using standard parts, which means restricting
yourself to things that can be built economically with them.)  I have
heard, from reliable sources, that if/when the successor to the VAX
emerges, the biggest difference will be that it will be much simpler.

	Allowing non-aligned data to be accessed with a performance
	penalty is only a little less short-sighted.  When designing a
	computer, anything that makes the job of writing software easier
	will be justified in the marketplace, especially the oem marketplace.

If you can show me a way to eliminate alignment constraints without a
speed penalty, WITHOUT adding large amounts of hardware (which I could
use better to make the aligned version faster), I'd love to hear about
it.  It's hard.

	Given the current comparison of hardware costs to software
	(i.e. people) costs, a more expensive cpu that is easier to
	program will be vastly cheaper in the long run.

See my first comments for some reasons why the software will be easier
if the hardware is simpler.

But actually, most of this is beside the [original] point.  We are not
talking about some decision which makes life a lot harder for the poor
software jockey.  We are talking about a decision which requires more
memory to get equivalent performance.  There is a perfectly straight-
forward hardware-vs-hardware tradeoff here:  is it cheaper to build
a machine that doesn't care about alignment, or to just stack more
memory on a machine that does care?  I would give long odds that the
latter approach wins, even just on initial cost.  When you think about
things like reliability and maintenance, it wins big.

I agree that this doesn't help the poor people who have made a big
investment in data structures that assume no alignment constraints.
These people have made a mistake, period:  they have imbedded a major
machine-dependent assumption in software that obviously should have
been portable.  The merits of the assumption are debatable; what is
not debatable is that it shouldn't have been wired in so deeply!
They have asked whether they should spend 10 man-months recoding to
imbed the opposite assumption, i.e. alignment constraints.  I think
they should spend however much time it takes to eliminate such
deeply-wired-in assumptions completely.  Or they will surely be bitten
by something like this again some day.  (Case in point:  does the code
assume that a long int is 32 bits?  Might be a mistake if they ever
want to move it to an Amdahl Unix -- and the big Amdahls are supposed
to be pretty good Unix machines if you need lots of crunch.)

[I can just hear N netnews readers firing up their afterburners to
accuse me of being a degenerate anti-software hardware hacker...
I'm a software specialist, degree in Computer Science (specifically,
compilers), experience mostly in software.  But I know a good deal
about how hardware works and about the practical aspects of building
it, and have personal experience with some of the problems.]
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry