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

Instruction Set Complications
No MIPS instruction has more than one result, and our MIPS pipeline writes that result only
at the end of an instruction's execution. When an instruction is guaranteed to complete, it is
called commited . In the MIPS integer pipeline, all instructions are commited when they reach
the end of the MEM stage (or beginning of WB) and no instruction updates the state before
that stage. Thus, precise exceptions are straightforward. Some processors have instructions
that change the state in the middle of the instruction execution, before the instruction and its
predecessors are guaranteed to complete. For example, autoincrement addressing modes in
the IA-32 architecture cause the update of registers in the middle of an instruction execution.
In such a case, if the instruction is aborted because of an exception, it will leave the processor
state altered. Although we know which instruction caused the exception, without additional
hardware support the exception will be imprecise because the instruction will be half inished.
Restarting the instruction stream after such an imprecise exception is difficult. Alternatively,
we could avoid updating the state before the instruction commits, but this may be difficult or
costly, since there may be dependences on the updated state: Consider a VAX instruction that
autoincrements the same register multiple times. Thus, to maintain a precise exception model,
most processors with such instructions have the ability to back out any state changes made
before the instruction is commited. If an exception occurs, the processor uses this ability to
reset the state of the processor to its value before the interrupted instruction started. In the
next section, we will see that a more powerful MIPS floating-point pipeline can introduce sim-
ilar problems, and Section C.7 introduces techniques that substantially complicate exception
handling.
A related source of difficulties arises from instructions that update memory state during
execution, such as the string copy operations on the VAX or IBM 360 (see Appendix K). To
make it possible to interrupt and restart these instructions, the instructions are defined to use
the general-purpose registers as working registers. Thus, the state of the partially completed
instruction is always in the registers, which are saved on an exception and restored after the
exception, allowing the instruction to continue. In the VAX an additional bit of state records
when an instruction has started updating the memory state, so that when the pipeline is restar-
ted the CPU knows whether to restart the instruction from the beginning or from the middle
of the instruction. The IA-32 string instructions also use the registers as working storage, so
that saving and restoring the registers saves and restores the state of such instructions.
A different set of difficulties arises from odd bits of state that may create additional pipeline
hazards or may require extra hardware to save and restore. Condition codes are a good ex-
ample of this. Many processors set the condition codes implicitly as part of the instruction.
This approach has advantages, since condition codes decouple the evaluation of the condition
from the actual branch. However, implicitly set condition codes can cause difficulties in
scheduling any pipeline delays between seting the condition code and the branch, since most
instructions set the condition code and cannot be used in the delay slots between the condition
evaluation and the branch.
Additionally, in processors with condition codes, the processor must decide when the
branch condition is fixed. This involves finding out when the condition code has been set for
the last time before the branch. In most processors with implicitly set condition codes, this is
done by delaying the branch condition evaluation until all previous instructions have had a
chance to set the condition code.
Of course, architectures with explicitly set condition codes allow the delay between condi-
tion test and the branch to be scheduled; however, pipeline control must still track the last in-
struction that sets the condition code to know when the branch condition is decided. In effect,