🚀 go-pugleaf

In article <205@bbxeng.UUCP> scott@bbxeng.UUCP (Scott-Engineering) writes:
>I guess this is where I'm having a problem.  What if the instruction
>involved address increment/decrement modes?  Restarting the instruction
>might not give the exact same result unless the results of auto-inc/dec
>were not placed into the affected registers until the instruction completes.

Sorry, I should have stated explicitly the strong requirement that is
placed on the OS:

	The user program must not be able to notice that anything
	happened (except in second-order ways, such as the time of
	day jumping ahead).

Notice I said the OS. That's because the hardware doesn't necessarily
do it all. It is fine if the processor merely leaves enough
information so that the OS can sort things out. For instance, on the
old PDP-11/45, there were special registers, which recorded whether
the interrupted instruction had autoincremented any registers, and if
so, which ones. First, the OS would copy the user's register set to
some convenient place in memory. Then, using this special
information, the OS would undo any incrementation. Later, the values
in memory would be reloaded, and the offending instruction would be
restarted. The instruction would "see" the same values that it saw
the previous time.

Alternatively, the hardware can have "shadow registers". At the
beginning of each instruction, they are made equal to the normal
registers. If the instruction faults, then simply store the shadow to
memory, instead of storing the "foreground" register set to memory.
This nicely avoids the undo problem, and replaces it with lots and
lots of silicon. Or, as you suggested, the register updates can be
postponed until the end of the instruction. On most machines this
would be simpler but slower.

-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science