Boundary alignment: Ken Reek responds (LONG!)

[Henry Spencer]

Dave Martindale has addressed some of Ken Reek's comments; here's
some more rebuttal...

   > Simple hardware wins on more counts than just making life easier for
   > lazy engineers.  It is simpler and cheaper to build, ..., more reliable,
   > easier to fix when it breaks, etc etc.
   
   Yes, simple hardware is easier to design, easier to fix, and all of the rest.
   But it is a lot less useful.  How simple should it be?  An abacus is pretty
   simple, for example.

The whole point of the RISC notion is that the hardware can be made
dramatically simpler *without* losing anything important.  You haven't
demonstrated that "aligned" machines lose anything important -- the
inability to run unportable software is hardly significant, or the RISC
would be doomed by its inability to run VMS.

   > (omitted from above) 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)
   
   You are confusing implementation with interface.  The functions you choose to
   implement do not determine the interface between the hardware and the soft-
   ware; consider the many different ways that different machines support I/O.
   On the Vax, it is the complexity of the interface that causes the problems,
   not underlying implementation.

Complexity of implementation usually rears its ugly head in the
interface as well.  Even things like caches and unaligned-operand
features do show up, if you think about it carefully.  Ask someone who's
written operating-system memory-management code what he thinks of
unaligned operands that can straddle page boundaries.  No, unaligned
operands are *not* free of software complexities, although the extra
complexity they introduce is at least localized.

   > 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.
   
   Then enlighten them!  If you buy a machine on which software development is
   difficult only because that machine is cheaper, you're not making a very
   good decision.  It's up to those who know about such things to educate those
   that "make the decisions" about the false economy of choosing a machine based
   only on price.

I don't know about you, but my software development would not be one cent
cheaper on an unaligned machine.  (My current machine, a PDP11, is aligned.)
Clean, portable software has no problem with such a machine.

   > 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.)
   
   Are you suggesting that it would have been better to build Vaxen from
   7400 series logic?  I think not.

Read that last parenthesized sentence again -- the point is not that
you should use standard parts even for jobs that they can't do, but that
you should restrict your jobs to things that standard parts *can* do.
It actually is possible to implement a VAX in 7400's -- what do you think
the 780 is made of? -- it's just hard and expensive.

   > 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.
   
   That's the interface again, not necessarily the implementation.

See earlier for comments on the visibility of implementation complexities.

   > 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.
   
   Page 200 of the Vax Hardware Handbook describes how it is done with a cache
   on the 780.  The same can be (is!) done with data, using a larger cache to
   compensate for the less sequential nature of data accesses.

Please read your Vax Hardware Handbook more carefully.  The same is *not*
done with data, unless the data item fortuitously happens to fall within
an 8-byte-aligned doubleword.  A data item that straddles an 8-byte boundary
in memory will take two fetches, i.e. a speed penalty.  Nor is the presence
of the cache an "out":  caches cost hardware.  Lots.  The VAX has already
paid this particular price for other reasons -- stupid memory-system
interface design -- but this doesn't make the cache free.  Well-designed
machines in this speed range don't need caches at all.

   > 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.
   
   Good point.  However, for programs that dynamically allocate space, the size
   of the largest problem that can be handled is determined by how efficiently
   you use that space.  For ANY given memory size, the program that more
   efficiently uses the space can handle larger problems.
   
   Of greater concern, though, is where all that data resides when the program
   is not actually running.  Can you add additional disk space to hold all of
   the wasted space in your data structures as cheaply as you can add main
   memory?  I would be upset if I had to buy another drive because all of my
   existing ones were full of data that was 25% wasted space.  Sure, you can
   pack them on disk and unpack them when you read them, but you are then
   trading away execution efficiency.

You have not refuted my point at all.  Granted that adding memory (be it
main memory or disk) costs money, it's still cheaper and simpler than
adding unaligned-operand hardware.

   > 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.  
   
   This is my whole point -- alignment should NOT be machine dependent.

There is an anecdote attributed to Abraham Lincoln.  He asked a riddle:
"If you call a dog's tail a leg, how many legs does a dog have?".  The
correct answer is:  "Four.  Calling the tail a leg doesn't make it one."
The fact is, alignment *IS* machine dependent, and all the wishing in
the world won't change it.  To quote Dave Martindale:

   .......................... You make software which is portable by making
   it independent of the details of the implementations of a wide variety
   of machines, not by arguing that a certain class of those machines should
   not be allowed to exist.

-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry