Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <5995@pt.cs.cmu.edu> Date: 28 Aug 89 22:47:30 GMT References: <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> <205@bbxeng.UUCP> Organization: Carnegie-Mellon University, CS/RI Lines: 36 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