8. 8.2 What are Exceptions? EE 457 Unit 8 Exceptions What Happens When Things Go Wrong Exceptions are rare events triggered by the hardware and forcing the processor to execute a software handler Similar to conditional branches/subroutine calls Utilize the hardware already in place for branches Flush pipeline Fetch from entry point of software exceptions handler 8.3 8.4 Exception Processing Exception Examples Exception = Asynchronous (non-programmed) control transfer Synchronous system call/trap Must save PC of offending, program state, and any information needed to return afterwards Restore upon return Example Stage Action I/O Device Interrupt A peripheral device requires action from the CPU (Interrupt I/O Driven) Operating System Calls ( Traps ) [e.g. File Open] Trap causes processor to enter kernel mode Take ASAP User Program System Exception Handler Return from exception Instruction Tracing and Breakpoints When TRAP Bit is set all s cause exceptions Particular s are flagged for exceptions (debugging) Arithmetic Exceptions Overflowor Divide-by- ID EX
8.5 8.6 Exception Examples 2 System Calls/Traps Example Stage Action Page Faults Virtual memory access fault(no Page Table entry resident in memory) Misaligned Memory Address Address is not multiple of operand size Memory Protection Violations Address is out of bounds; RWX violation Undefined Instructions Decode unit does not recognize opcode or other fields Could be useful to extend the set Hardware failure Unrecoverable hardware error is detected; execution is compromised Power Failure Powerhas fallen below a threshold; Trap to software to save as much state as possible Abort Process Abort Process (Why not abort) Take ASAP Take ASAP A controlled-method for user application calling OS services Switches processor to kernel mode where certain privileges are enabled that we would not want normal user apps to access x86 System Call (old DOS OS call) IN AH, H INT 2H // getchar() PSW Processor Status Word Instruction Tracing and Breakpoint Single-stepping & Breakpoint in x86 TF Trap Flag 8.7 8.8 Exception Processing Save necessary state to be able to restart the process Save of offending Call an appropriate to deal with the error / interrupt / syscall Handler identifies cause of exception and handles it May need to save more state Restore state and return to offending application (or kill it if recovery is impossible) MIPS Coprocessor Registers Status Register Enables and disables the handling of exceptions/interrupts Controls user/kernel processor modes Kernel mode allows access to certain regions of the address space and execution of certain s Register: Indicates which exception/interrupt occurred Register Indicates the address of the causing the exception This is also the we should return to after handling the exception Coprocessor registers can be accessed via the mtc and mfc s mfc $gpr,$c_reg # R[gpr] = C[c_reg] mtc $gpr,$c_reg # C[c_reg] = R[gpr]
8.9 8. Status Register Register Register 2 in coprocessor Bit definitions IM[7:] Interrupt Mask = Ignore interrupt / = Allow interrupt UM User Mode = User mode / = Kernel mode ERL/EXL = Exception/Error Level = Already handling exception or error / = Normal exec. If either bit is processor is also said to be in kernel mode IE = Interrupt Enable = Allow unmasked interrupts / = Ignore all interrupts Register 3 in coprocessor Bit definitions BD Branch Delay The offending was in the branch delay slot points at the branch but it was +4 that caused the exception PI[7:] Pending Interrupt = Interrupt Requested / = No interrupt requested Exception Code Indicates cause of exception (see table) Code Interrupt(HW) 4, 5 Load(4), Store (5) Address Error 6, 7 Instruc. (6), Data (7) Bus Error 8 Syscall 9 Breakpoint Reserved Instruc. CoProc. Unusable 2 Arith. Overflow 3 Trap 5 Floating Point Status Register 3 5 8 4 2 IM7 IM6 IM5 IM4 IM3 IM2 IM IM UM ERL EXL IE Register 3 5 8 7 6 2 BD PI7 PI6 PI5 PI4 PI3 PI2 PI PI Exception Code 8. 8.2 Register Exception PC holds the address of the offending Can be used along with register to find and correct some error conditions used to return from exception handler and back to execution point in original code (unless handling the error means having the OS kill the process) Operation: PC = Problem of Calling a Handler We can t use explicit jal s to call exception handlers since we don t _.text MAIN: jr $ra Many s could cause an error condition. Or a hardware event like a keyboard press could occur at any point in the code. = Exception PC 3 Address of that generated the exception
8.3 8.4 Solution for Calling a Handler Handler Calling Methods Since we don t know when an exception will occur there must be a preset location where an exception handler should be defined or some way of telling the processor in advance where our exception handlers will be located Method : for master handler Early MIPS architecture defines that the exception handler should be located at x8_8. Code there should then examine CAUSE register and then call appropriate handler routine Method 2: (usually for interrupts) Each interrupt handler at a different address based on interrupt number (a.k.a. vector) (INT @ x82, INT2 @ x83) Method 3: Table in memory holding start address of exception handlers (i.e. overflow exception handler pointer at x4, FP exception handler pointer at x8, etc.) Kernel Exception Handler User Method xffffffff x88 x8 x Kernel INT n Hand. INT 2 Hand. INT Hand. Exception Handler User Method 2 xffffffff x8??? x83 x82 x88 x8 x Kernel INT 2 Hand. Handler INT Hand. addr x3 addr x2 addr x User Method 3 xffffffff x3 x x2 x8 x 8.5 8.6 Exceptions Why are Exceptions So Important? Two conditions: Synchronized with an A particular caused the exception Not an interrupt or some kind of failure Must resume execution after handler Restart the causing the exception after exception handler returns Not an exception that will cause the process to abort Not difficult in a processor executing one at a time Very difficult in architectures in which multiple execute concurrently (i.e. our 5-stage pipeline) Exceptions are part of the ISA (Instruction Set Architecture) specification Any implementation of an ISA must comply with its Exception model exception handling constrains what the architecture can do Exceptions are rare yet we must functionally support them If we did not have to comply to the exception model architects would have a lot more freedom in their design When designing micro-architectures for the common case, exceptions must always be in the back of your mind!
8.7 8.8 Exceptions in the 5-Stage Pipeline To support precise exceptions in the 5-stage pipeline we must Identify the pipeline stage and causing the exceptions Any stage can trigger an exception (except for the stage) Identify the cause of the exception Save the process state at the faulting Including registers, PC, and cause Usually done by software exception handler Complete the execution of s preceding the faulting Flush following the faulting plus the faulting Transfer control to exception handler 8_8 2 PC PCWrite 4 + I-Cache. IRWrite Reset Instruction Register rs rt Exception in EX stage 5 5 HDU IF.Flush Control Reg. # Reg. 2 # Write Reg. # Write Data Stall data data 2 Register File Sign Extend 6 32 rs rt rd FLUSH EX.RegWrite EX.RegDst Branch Sh. Left 2 2 3 2 ALUSelB 3 ALUSelA = Forwarding Unit + Ex Mem Pipeline Stage Register ALUSrc Save =PC+4 of offending Record Add 3 rd input of x8_8 to PCSrcMux (start address of exception handler) ALU Res. RegDst Mem Pipeline Stage Register D-Cache Mem & MemWrite Pipeline Stage Register MemToReg Use many of the same mechanisms as conditional branches. 8.9 8.2 Exception Handling Complexities More Complex Complexities? When the arithmetic exception is triggered in EX, we must flush, and and start fetching from x8_8 Note that the handler s software must have access to CAUSE and registers to figure out what to do Realize though exceptions may occur in all but the stage 4 possible values of Software needs to know which value is the actual cause and Depending on the stage where the exception occurs, we have to flush different stages Muxes What happens if multiple exceptions occur in the same cycle from different s in different stages Should take the exception in Program/process order = Order if only were executed at a time (= Fetch order) Thus oldest is the one _ into the pipeline There is no point in dealing with all exceptions, just the oldest one Let software deal with the oldest and then restart if later were going to generate an exception, then they will again upon restart and we can handle it then Cycle n We can start handling illegal exception. What could happen on cycle n+? But it gets worse!!! I-Fetch TLB miss / Page Fault Illegal Instruction SW address computation LW TLB miss Page hit (no exception)
8.2 8.22 More Complex Complexities? Simplify the Process Remember we must complete preceding the faulting Remember we are supposed to handle in program order (not temporal order) Cycle n+ I-Fetch TLB miss / Page Fault Illegal Instruction LW It is not practical to take an exception in the cycle when it happens Multiple exceptions in the same cycle It is complex to take exception in various pipeline stages since we have to take them in program order and not temporal order Instead, we will just tag an in the pipeline if it causes and exception (recording the cause and ) Turn the offending into a NOOP (bubble) Let the s continue to flow down the pipeline and handle the offending s execution in the stage The cause and status info is carried down the pipe via stage registers Exception remains until it reaches the stage Exceptions are then processed into the stage Muxes Actual & Register Handling in Stage Handling in stage helps deal with temporal vs. program order issues 4: LW $,($8) 44: AND $2,$2,$5 CC CC2 CC3 CC4 CC5 CC6 CC7 CC8 8.23 Simplified Processing exceptions are now taken in along with other HW interrupts Faulting s carry their cause and values through the pipeline stage registers Only one set of and CAUSE registers in the stage When an flagged as faulting reaches the stage Flush IF, ID, EX, MEM Make sure that if a SW is in MEM stage that it is not allowed to write Load the handler address in the PC Make sure & are software-readable (movable to GPR s) 8.24 48: OR $3,$6,$2 52: ADD $4,$2,$2 This is a general approach to dealing with exceptions in the processor: Wait until the faulting exits the machine to trigger the handling procedure