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

able. They are treated as exceptions, however, because the same mechanisms that are used
to save and restore the state are used for these user-requested events. Because the only
function of an instruction that triggers this exception is to cause the exception, user-reques-
ted exceptions can always be handled after the instruction has completed. Coerced excep-
tions are caused by some hardware event that is not under the control of the user program.
Coerced exceptions are harder to implement because they are not predictable.
3. User maskable versus user nonmaskable —If an event can be masked or disabled by a user
task, it is user maskable . This mask simply controls whether the hardware responds to the
exception or not.
4. Within versus between instructions —This classification depends on whether the event pre-
vents instruction completion by occurring in the middle of execution—no mater how
short—or whether it is recognized between instructions. Exceptions that occur within in-
structions are usually synchronous, since the instruction triggers the exception. It's harder
to implement exceptions that occur within instructions than those between instructions,
since the instruction must be stopped and restarted. Asynchronous exceptions that occur
within instructions arise from catastrophic situations (e.g., hardware malfunction) and al-
ways cause program termination.
5. Resume versus terminate —If the program's execution always stops after the interrupt, it is a
terminating event. If the program's execution continues after the interrupt, it is a resuming
event. It is easier to implement exceptions that terminate execution, since the CPU need not
be able to restart execution of the same program after handling the exception.
Figure C.31 classifies the examples from Figure C.30 according to these five categories.
The difficult task is implementing interrupts occurring within instructions where the instruc-
tion must be resumed. Implementing such exceptions requires that another program must
be invoked to save the state of the executing program, correct the cause of the exception,
and then restore the state of the program before the instruction that caused the exception
can be tried again. This process must be effectively invisible to the executing program. If a
pipeline provides the ability for the processor to handle the exception, save the state, and re-
start without affecting the execution of the program, the pipeline or processor is said to be re-
startable . While early supercomputers and microprocessors often lacked this property, almost
all processors today support it, at least for the integer pipeline, because it is needed to imple-
ment virtual memory (see Chapter 2 ) .