Exceptions and Interrputs

1. CS 321 – Introduction to Computer Architecture and Machine-Level Programming Barry Britt, Systems Analyst II Department of Computer Science Iowa State University Exceptions and Interrputs

2. Who am I? • Systems Administrator for 8 years • Bachelors in CS, 2002 • Bachelors in Music, 2002 • Masters in CS, 2007 • Work: • Computer technician in industry for 3 years. • Research support for 3 years. • University support for 5 years.

3. Definition • An exception, or interrupt, is an unexpected event that changes the normal flow of instruction execution (excluding branches and jumps). • Exceptions can have both internal and external causes. • Interrupts have only external causes.

4. NOTE • Some authors do not distinguish between interrupts and exceptions and will use the term interrupt for both types of events. One decent rule of thumb: • Exceptions generally handle events intrinsic to a program (think Java try-catch blocks). • Interrupts handle user or device requests.

5. Examples

6. Further Examples • Imagine your cell phone ringing • The phone causes an interrupt. • The phone ring-tone is like a “signal” • When you acknowledge the interrupt, a hardware “signal” is stopped. • The ringtone and the caller ID can give you about where the call originates. • Answering the phone is “servicing” or “handling” the interrupt.

7. Control Flow • The most challenging part of processor design is implementing the interrupt and exception handlers. • Interrupts must be acknowledged: • Interrupt source • Interrupt priority level • Interrupt security • Both hardware AND software are required to handle exceptions.

8. Handling an Exception (High-Level) Requirements • A mechanism to indicate an exception. • A mechanism to specify the nature of the exception. • A mechanism to specify the requested service. • A mechanism to specify the priority of the exception. • A mechanism to inform the requester that the exception is being handled. • A mechanism to restore normal activity after handling the exception.

9. Implementations • Implementations are different for different computers. • MIPS: • Part of the CPU (coprocessor 0) records information needed to handle interrupts and exceptions. • This is kept in 32-bit registers that are NOT part of the general register set. Access requires special or privileged instructions.

10. Registers

11. Implementation, cont. • Exception is in the Cause register. • Contains a field which indicates the reason for the exception. This field is used to determine which handler to execute. • To execute, • Save program state • update the Next-Instruction to the first address of the exception handler, and execute. • After execution, restore program state

12. Implementation, cont. • Vectored interrupts: • A table that exists within the hardware. • Table can be indexed by exception type • Pseudocode???

13. Pseudocode • class HandleError: Program program = new Program(); Exception exceptionToHandle = new Exception(); Main: program.getCurrentlyRunningProgram(); exceptionToHandle = program.getException(); Handler handler = new Handler(exceptionToHandle); handler.saveProgramState(program); handler.HandleException(); program = handler.restoreProgramState();

14. Exception Handlers • An exception handler is a software routine invoked to handle exceptions when they occur. • Even though this is a software routine, hardware actions are required to successfully deal with exceptions!

15. Required Actions for Handlers • Save execution state of currently running process • Clear interrupts • Handle the interrupt • Restore execution state of program • Increment the process' program counter and hand control back to interrupted process.

16. Critical Thinking Questions • Why do we clear the interrupt before executing the interrupt handler?

17. Critical Thinking Questions • Why do we clear the interrupt before executing the interrupt handler? • If we don't clear the interrupt, the next program to execute will experience the same interrupt request and try to handle an invalid interrupt. • This would effectively deadlock the system.

18. Critical Thinking Questions • Why do we increment the program counter of the process before handing off execution back to the interrupted process?

19. Critical Thinking Questions • Why do we increment the program counter of the process before handing off execution back to the interrupted process? • Otherwise, the process would execute the same interrupted statement as before, preventing further program execution.

20. MIPS Instructions • Mfc0 -> move from coprocessor 0 • Mtc0 -> move to coprocessor 0 • Lwc0 -> load word to register of coprocessor 0 • Swc0 -> store word from register of coprocessor 0

21. MIPS Instructions, cont. • Mfc0 $k0, $13 #move cause into register $k0Mfc0 $k1, $14 #move EPC into register $k1Addi $k1, $k1, 4 #Do not re-execute exception instr................rfe #Restore the interrupt statejr $k1 #Transfer control to the original proc