Interrupts and Exceptions
Interrupts and exceptions divert the processor from its current work to handle an event, then restore it precisely afterward.
Two Kinds of Diversion
A processor mostly executes instructions in sequence, but it must also respond to events. An interrupt is asynchronous, raised by external hardware such as a timer or a device that has finished a transfer. An exception is synchronous, caused by the currently executing instruction: a divide by zero, a page fault, an illegal instruction, or a deliberate system call.
The Handling Sequence
When an interrupt or exception is recognized, the processor saves enough state to resume later (at least the program counter and status flags), looks up the address of the appropriate handler in a vector table, and jumps there. The handler services the event and then executes a return-from-interrupt instruction that restores the saved state and resumes the interrupted program as if nothing happened.
- Save program counter and processor status
- Vector to the handler via an interrupt vector table
- Run the handler, then restore state and resume
Precise Exceptions
For a clean recovery the processor must present a precise state: all instructions before the faulting one have completed, none after it have taken effect, and the faulting instruction is clearly identified. In out-of-order processors this is nontrivial, and it is exactly what the reorder buffer and in-order retirement guarantee. Precise exceptions make page faults and debugging tractable.
Priorities and Masking
Multiple interrupts can be pending at once. A priority scheme, often backed by a priority encoder in the interrupt controller, decides which to service first, and lower-priority interrupts can be temporarily masked so a critical handler runs uninterrupted. Non-maskable interrupts exist for events too important to defer, such as imminent power loss or a hardware fault. Careful interrupt design keeps latency low, which matters in any real-time control system.