My students and I are confused about the way that traps are handled in SPARC implementations with multi-cycle, unpipelined FP operations.
Page 288 of Hennessy and Patterson reads:
----------------
A third technique in use is to allow the interrupts to become somewhat imprecise, but keep enough information so that trap-handling routines can create a precise sequence for the interrupt. This means knowing what operations were in the pipeline and their PCs. Then, after handling a trap, the software finishes any instructions that precede the latest instruction completed, and the sequence can restart. Consider the following worst-case code sequence:
Instruction-1 --- A long running instruction that eventually interrupts
execution
Instruction-2,...,Instruction-(n-1) --- a series of instructions that are
not completed
Instruction-n --- an instructionthat is finished.
Given the PCs of all of the instructions in the pipeline and the interrupt return PC, the software can find the state of instruction-1 and instruction-n. Since instruction-n has completed, we will want to restart execution at instruction-(n+1). After handling the interrupt, the software must simulate the execution of instruction-1 ... instruction-(n-1). Then we can return from the interrupt and restart at instruction n+1.
-------------------
I can't find anything in the SPARC arch. ref. that says anything different. Here is our problem. If you only save the instructions and PCs of uncompleted operations, then how do you get the input operands to re-execute them. For example if instruction-2 requires r7, but instruction-n (that has completed) overwrites r7 then how can I restart instruction 2?
It would seem that a history buffer of some type containing register values is still required.
Is there anyone who has a more intimate understanding of this problem that can correct our interpretation of the facts or confirm that saving the PC's and instructions is not enough?
