Pipelining: Basic and Intermediate Concepts - Computer Architecture: A Quantitative Approach - page 664

FIGURE C.32 Exceptions that may occur in the MIPS pipeline . Exceptions raised from in-
struction or data memory access account for six out of eight cases.
This pair of instructions can cause a data page fault and an arithmetic exception at the same
time, since the LD is in the MEM stage while the DADD is in the EX stage. This case can be handled
by dealing with only the data page fault and then restarting the execution. The second excep-
tion will reoccur (but not the first, if the software is correct), and when the second exception
occurs it can be handled independently.
In reality, the situation is not as straightforward as this simple example. Exceptions may oc-
cur out of order; that is, an instruction may cause an exception before an earlier instruction
causes one. Consider again the above sequence of instructions, LD followed by DADD . The LD can
get a data page fault, seen when the instruction is in MEM, and the DADD can get an instruction
page fault, seen when the DADD instruction is in IF. The instruction page fault will actually occur
first, even though it is caused by a later instruction!
Since we are implementing precise exceptions, the pipeline is required to handle the excep-
tion caused by the LD instruction first. To explain how this works, let's call the instruction in the
position of the LD instruction i , and the instruction in the position of the DADD instruction i + 1.
The pipeline cannot simply handle an exception when it occurs in time, since that will lead to
exceptions occurring out of the unpipelined order. Instead, the hardware posts all exceptions
caused by a given instruction in a status vector associated with that instruction. The exception
status vector is carried along as the instruction goes down the pipeline. Once an exception in-
dication is set in the exception status vector, any control signal that may cause a data value to
be writen is turned of (this includes both register writes and memory writes). Because a store
can cause an exception during MEM, the hardware must be prepared to prevent the store from
completing if it raises an exception.
When an instruction enters WB (or is about to leave MEM), the exception status vector is
checked. If any exceptions are posted, they are handled in the order in which they would occur
in time on an unpipelined processor—the exception corresponding to the earliest instruction
(and usually the earliest pipe stage for that instruction) is handled first. This guarantees that
all exceptions will be seen on instruction i before any are seen on i + 1. Of course, any action
taken in earlier pipe stages on behalf of instruction i may be invalid, but since writes to the
register file and memory were disabled, no state could have been changed. As we will see in
Section C.5 , maintaining this precise model for FP operations is much harder.
In the next subsection we describe problems that arise in implementing exceptions in the
pipelines of processors with more powerful, longer-running instructions.