Download Exceptions - Lecture Notes - Computer Architecture | ECEN 4243 and more Study notes Computer Architecture and Organization in PDF only on Docsity!
Exceptions
Exceptions, interrupts and faults arise from infrequent (several thousand clocks or more between occurrences) situations that require a quick response from the processor. The processor responds by stopping normal instruction flow and a special routine starts exe- cuting that can respond to the situation causing the exception. These special routines are called exception handlers or interrupt service routines.
Usually, there are a small set of control lines on the processor which can cause exceptions, interrupts and faults. Historically, hardware designers used different names depending on where the control lines came from.
- Exception - from processor hardware, e.g., ALU overflow (this is what you do with the ALU V output!), etc.
- Interrupt - from external (to processor) hardware
- Fault - from the memory system, e.g. page fault
- Trap - software instruction that causes execution of exception handlers and interrupt service routines
Unfortunately, hardware manufacturers have not used these terms consistently (except for trap). We will use exceptions as a general term that refers to them all.
Most exceptions require that the processor state must be preserved so that the original pro- gram may be restarted after the exception is handled (interrupt is serviced).
Exceptions like external interrupts and traps are easy to handle because they do not require canceling an instruction already in the pipeline. Just change the PC register to point to the beginning of the exception handler routine while saving the old PC so that normal pro- gram flow can be restored later (very similar to the JAL instruction). The PC is the only part of the machine state that needs to be saved by the hardware. It is the responsibility of the exception handler software to save and restore any general purpose registers it uses using normal LOAD and STORE instructions.
Exceptions such as ALU overflow or memory system faults are trickier. Since the instruc- tion cannot finish, the processor pipeline cannot continue in a normal fashion. There are two (at least) alternatives for preserving the processor pipeline state:
- Save a “snap shot” of the entire processor pipeline (saves all internal processor pipeline registers except register file). This greatly increases the complexity of the processor hardware. Since interrupts do not occur very often (once every million instructions or so), it does not make sense in a RISC design to do this.
- Flush the pipeline. The instruction causing the exception and all instructions after it (behind it in the pipeline) are turned into NOPs. Allow instructions before it (ahead of it in the pipeline) to finish. Save only the address of the instruction causing the excep- tion and restart the instruction after the exception is handled. This approach is usually taken in modern RISC designs. See fig. 6.42, p. 428 and fig. 6.43, p. 430 for MIPS example.
Saving the processor state is more difficult when delayed branch instructions are in the instruction set. Suppose the following instructions are somewhere in the pipeline.
BEQ R7,R8,somewhere LW R1, whatever(R2)
If the branch is a 1 cycle delayed branch, the LW instruction is always executed. If the LW causes a memory exception, it is re-executed later by starting with the PC at its address. Unfortunately, the instruction after the LW depends on whether the branch was to be taken or not. In this case, it is necessary to save the address of the instruction causing the exception (the LW in this case) and the address of the next instruction (the address determined by the delayed branch).
In general, when there are n delay slots in a delayed branch, it will be necessary to save n +1 PCs.
Precise Exceptions. Since several instructions may be in the processor pipeline at one time, exceptions can occur in a different order in a pipelined processor running the same code as an unpipelined processor. Unpipelined processors execute one instruction at a time. Thus, the exceptions caused by an instruction must occur before any caused by other instructions following it. A pipelined machine that has this same behavior is said to have precise exceptions.
Precise exceptions make it much easier to restart the program instruction stream after an exception has occurred. With precise exceptions, all that is necessary is to save the PC or PCs as outlined previously and exceptions caused by later instructions will occur in order.
With imprecise exceptions, the exception handler may cause unexpected changes in condi- tions governing exceptions in other instructions. For example, consider two sequential load instructions.
LW R1, location LW R2, location
If both instructions cause page faults and the exceptions are handled in the wrong order, the second instruction could read from the incorrect page in main memory. This is why designs that support virtual memory usually have precise exceptions. The alternative to precise exceptions is to save more information about the machine state so that exception handlers have enough information not to interfere with each other.
interrupts are pending (not answered yet) or active (already running). An example of how this might be done for 8 levels of interrupts is shown below.
The active or pending interrupts are coded into 8-bits of the status register. The current interrupt level is provided as the output of a priority encoder which is a relatively simple logic circuit. Thus, all interrupt levels that require service set bits in the status register. The highest level interrupt passes through the priority encoder and determines the current interrupt level. When exception handlers or interrupt service routines are finished, the bit for the current interrupt level is reset in the status register and the next highest interrupt level routine starts running.
Return from Exception (RFE). A special instruction is needed at the end of an exception handler that resets the current interrupt bit in the status reg and restores the PC (or PCs). The MIPS has the RFE instruction to do this. A problem is that the bit does not get reset and the PC restored until RFE executes. This means that resetting the exception does not take effect until the RFE instruction is in the EX stage of the pipeline. Two other instruc- tions (even more in superpipelined versions of the MIPS) are now in the pipeline. These instructions must be turned into NOPs by the hardware.
Alternatively, one could adopt the convention that the RFE instruction should always be followed by NOP’s. (Optimizing compiler can enforce this)
Interrupt Vectors. When an exception or interrupt occurs, the processor needs to have the beginning address of the exception handler or interrupt service routine to put into the PC.
Usually there are only a limited number of different interrupt levels, but there may be tens or hundreds of different exceptions. Therefore, there are usually many different excep- tions assigned to the same interrupt level. This requires the interrupting device to provide additional information (the interrupt vector) that identifies which exception is occurring.
bit for each
interrupt level
to indicate
active or pend-
ing
priority encoder
IL
status register
The interrupt vectors must be translated into the address of the exception handler. A typi- cal example of the translation is shown below.
Note: the memory page must be unswappable or else a page fault might cause a page fault and so on forever.
vector (from interrupting device)
Interrupt Base
Register
ISR addr’s
stored here
unswappable
memory page
addr bus
data bus
to PC
