Read Appendix C.4
Exceptions
The book uses the word
exception to mean anything that interrupts the normal sequence of instruction execution.
Here are some examples:
- I/O device request (from external device)
- OS service request
- trace instruction
- breakpoint
- integer arithmetic overflow
- floating point arithmetic anomaly
- page fault
- misaligned memory access
- memory protection violation
- undefined or illegal opcode
- hardware malfunction
- power failure
Classification of exceptions
- synchronous vs. asynchronous:
- synchronous: occurs in the same place every time the program is executed
- asynchronous: usually caused by an external device
- user requested vs. coerced
- user requested: e.g. OS system call or breakpoint
- coerced: caused by hardware device not under direct control of the program
- user maskable vs. nonmaskable
- within vs. between instructions
- within: usually synchronous, prevent instruction completion
- between: usually caused by external devices
- resume vs. terminate
- resume: must resume the program after handling exception, e.g.page fault
- terminate: always terminate, e.g. undefined instruction
Some examples:
- I/O device request: asynchronous, coerced, nonmaskable, between, resume
- system call: synchronous, user request, nonmaskable, between, resume
- integer overflow: synchronous, coerced, user maskable, within, resume
- memory protection violation: synchronous, coerced, nonmaskable, within, terminate
Stopping and restarting
The most difficult exceptions to handle are those that occur within
instructions and must be restartable: e.g. page fault
- force a trap instruction into the pipeline on the next IF
- A trap instruction hands control over to the OS
- Until the trap executes, turn off all writes for the faulting instruction and all that come after
- Do this by inhibiting the clocking of the memory and the register file.
- The OS saves the PC of the faulting instruction so it can be restarted later.
- For the 5-stage pipeline:
- state changes (other than the PC) occur only in MEM and WB
- exceptions cannot be caused by WB
- if an instruction causes an exception, later instructions can not have already changed the state
- For delayed branches, just saving the PC is not sufficient: need to save 2 values.
Precise and imprecise exceptions
Precise: instruction before the faulting exception can be completed and those after can be restarted from scratch.
Imprecise: not precise
Imprecise exceptions occur with long pipelines and with non-RISC instructions.
Examples:
-
For some floating point operations, the exception is not handled until after the result has been written.
What if one of the source registers is the same as the destination register?
- Consider:
| LD | IF | ID | EX | MEM | WB |
| DADD | | IF | ID | EX | MEM | WB |
The LD can have a page fault in MEM but the DADD can have a page fault in IF, before the page fault of LD.
Solution: not handle the exception when it occurs, but when the instruction completes (inhibiting any state change)
MIPS 5-stage Pipeline Exceptions
| pipeline stage | Exceptions |
| IF | page fault, misaligned memory access, memory protection violation |
| ID | undefined or illegal opcode |
| EX | arithmetic exception |
| MEM | page fault, misaligned memory access, memory protection violation |
| WB | none |