Implementation of Precise Interrupts in Pipelined Processors
SIGARCH 1985
In Summary
This is Smith/Pleszkun’s seminal paper on precise interrupts. At the time, most computer microarchitectures implemented a linear pipeline without aggressive out-of-order execution. Some high performance microarchitectures were out-of-order, but did not implement precise exceptions or precise interrupts, which complicated software development, complicated software debug, made it difficult to resume execution after exceptions/interrupts, etc.
Smith and Pleszkun suggest five solutions to the problem of imprecise interrupts:
- Results Shift Register
- RSR + ROB
- RSR + ROB w/ forwarding
- RSR + History Buffer
- RSR + ROB + Future File
Takeaways
Some of the out-of-order architectures the paper discusses seem comical in retrospect. The idea that you could save pipeline state on an exception and then restore the dynamic state is crazy, seems bug-prone, and doesn’t actually solve most of the problems with imprecise interrupts (except the inability to resume).
The paper describes a Result Shift Register, which by itself is a sort of precursor to the ROB. The RSR is essentially a table of issued instructions, with rows inserted at issue. A row is inserted at the position corresponding to the instructions functional unit latency. Rows are shifted down one-per-clock, with row 0 being written back every clock. To implement precise interrupts, rows cannot insert if there is a valid instruction already in the targeted row or any higher rows. This is obviously bad for performance relative to a ROB since it causes newer, faster instructions to wait until they’re guaranteed to complete after older, slower instructions, even if there is no dependency between the two.
The paper’s description of a ROB with forwarding network is as concise a description as I’ve seen.
The paper’s description of a History Buffer is interesting. Basically, the history buffer is a data structure that augments the RSR, allowing RSR to implement out-of-order completion, but maintaining the overwritten state so that state can later be “rolled back” to a prior known state when an exception occurs.
The paper’s description of a Future File is less interesting to me. The Future File is essentially a speculative RF that is written out-of-order; the ROB writes a separate Architectural File in-order. The AF outputs are only used on exceptions.
The paper says that the three most sophisticated solutions (ROB w/ forwarding, History Buffer, Future File) all perform similarly well.
