🚀 go-pugleaf

So far, people have brought up two hardware solutions:

 - 1. The CPU can just do it.
 - 2. The CPU can complain (interrupt) when someone tries to do it.

No one has mentioned the third alternative.

Let me begin by saying that I don't know if IBM PC/RTs still use the
third method.  When I used the RT (before it was announced) this method
was, ahem, a design feature, obeying, ahem, RISC principles.

The third method was quit simple: screw up.

An unaligned fetch implies two memory fetches. The ROMP chip would do
the low-order one, obtain the low-order bits, and put them in the
low-order part of the target register. The high-order part of the
register would be unchanged.

Someone out there in Netland may be saying that it's OK: the compiler
can just get everything right. Well, we were writing a compiler, and we
didn't get it right, always, at first. It turns out that un-alignedness
is a property that is preserved: add 4 to an unaligned pointer, and it
still is. It also turned out that this could creep in through lots of
little ratholes.

Let me explain to you about the statistics of data. If only the low
order part of a register is changed, there is a high likelihood that
the high order part is still OK. This is because it was probably zero
before, and it probably still should be zero. Alternatively, the
register held a pointer, and its next value was a pointer to a nearby
place.

The upshot is that the compiler could generate bad code, which would
run fine. Test programs would appear to be perfect - until you tried to
have 256 inputs, or linked them with 64KB of library routines, or
whatever else it took to cross that lurking threshold. Then the program
would pick up bizarre behavior that was hard to backtrack.

I don't know who invented this RISC feature, but I had strong feelings
about him at the time.
-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science
--