1. COMP201 Computer Systems Exceptions and Interrupts

2. COMP201 Outline Part1 Why have exceptions? What are exceptions and interrupts? The exception handler Device support for interrupts

3. COMP201 Polled I/O loop: Get device status Test status If not ready go to loop Send more data to device

4. COMP201 Problems with Polled I/O Polled I/O is often inefficient. CPU time is wasted waiting for things like:  A character to be received  A character to be sent  A certain time to elapse  A switch to be flicked It would be better if programs could be notified when one of these things happen.

5. COMP201 Also… What should happen if an error occurs during program execution?  Divide-by-zero  Overflow  Illegal instruction  Memory access error

6. COMP201 Exceptions Modern processors solve these problems by way of ‘Exceptions’ Exceptions are like subroutine calls, except they are not explicitly initiated by the program. The class of exceptions that are caused by things external to the processor are known as ‘Interrupts’ When an exception occurs then the CPU jumps to a piece of code called an ‘Exception Routine’ or ‘Exception Handler’

7. COMP201 Schematic Design

8. COMP201 Interrupt Pins

9. COMP201 Exception Example Exception Handler Main Program An exception occurs

10. COMP201 The Exception Handler The exception handler must:  Determine what caused the exception.  Deal with the exception that has occurred. Maybe read a character that has arrived. Maybe print an divide-by-zero error message.  Return to the point at which the exception occurred.

11. COMP201 The Exception Handler… The exception handler should have no effect on the main program (except for delaying it for a short time).  The exception routine must return to the point where the main program was interrupted.  The exception routine must restore all registers used by the main program to the same values they held when the exception occurred.  The exception routine should be kept as short as possible so as to have as little impact as possible on the main program.

12. COMP201 CPU Support for Exceptions Automatic jump to exception handler routine when exception occurs Ability to jump back to return point at end of exception routine Control ability to notice (enable) or ignore (disable) interrupts  Protected mode for exception handler

13. COMP201 Device Support For Interrupts Many I/O devices support interrupts. Interrupts can be enabled/disabled at the device.  By writing to a register in the I/O device. When an interrupt occurs the device sends a signal to the CPU. A part of handling the interrupt is telling the device we’ve seen it.  This is known as acknowledging the interrupt.  This is normally done by writing to a register in the I/O device.

14. COMP201 Device Support For Interrupts… Some devices can generate interrupts for more than one reason.  Eg. Serial Port Character received Character sent We may need to be able to tell which of these events caused the interrupt. This can be discovered by looking at registers in the device.

15. COMP201 Summary (Part 1) Exceptions solve inefficiency of polled I/O and can handle error conditions Interrupts (hardware) are externally generated exceptions. Software exceptions are internally generated Interrupts allow the CPU to respond to external events.

16. COMP201 Summary - cont. When an exception occurs during program operation, control is transferred to an ‘exception handler’. The exception handler routine deals with the excetption (interrupt) and returns without affecting the running program CPUs and I/O devices have special features to control Exceptions

17. COMP201 Outline -Part 2 Program Structure WRAMP Exception Sources WRAMP Special Registers WRAMP Special Instructions WRAMP Exception Operations Device Interrupt Control

18. COMP201 Example program structure main: # Setup interrupts. … loop: # Main program loop. … j loop handler: # Check which exception occurred. # If it is the one we want then we # jump to handle_interrupt. # Otherwise we jump to the system # exception handler. handle_interrupt: # Do our handler stuff. # Acknowledge the interrupt. # Return from the exception.

19. COMP201 Exceptions and WRAMP The WRAMP processor supports eight interrupt sources (IRQ0 – IRQ7).  On the REX board these are connected to the I/O devices (Timer, Parallel Interface, Serial Ports) WRAMP allows four possible software exception sources:  Arithmetic Exception (divide-by-zero, overflow)  General Protection Fault Exception (illegal instruction, memory access fault)  System Call Exception (syscall instruction)  Breakpoint Exception (break instruction)

20. COMP201 REX Interrupt Sources IRQ0Unused IRQ1User Interrupt Button IRQ2Timer Interrupt IRQ3Parallel Interrupt IRQ4Serial Port 1 Interrupt IRQ5Serial Port 2 Interrupt IRQ6Unused IRQ7Unused

21. COMP201 Interrupt Pins

22. COMP201 Exceptions and WRAMP How does the WRAMP ISA provide for exceptions?  Four special registers: $cctrl – CPU control register $evec - Exception vector register $estat – Exception status register $ear - Exception address register  Special instructions, including… movsg - Move special register to general movgs - Move general register to special rfe - Return from exception

23. COMP201 CPU Control Register In the WRAMP architecture the interrupts (IRQ0 – IRQ7), can be enabled and disabled on a global basis as well as individually. Software exceptions cannot be disabled. This is done through the CPU control register ( $cctrl ).

24. COMP201 CPU Control Register 310123411 IRQ7 … IRQ0 Interrupt Mask Bits Interrupt Enable (IE) Old Interrupt Enable (OIE) Kernel/User Mode (KU) Old Kernel/User Mode (OKU) KU OKU IE OIE IntMaskUndefined

25. COMP201 CPU Control Register (eg.) … # Get the CPU control register movsg $2, $cctrl # Mask (disable) all interrupts andi $2, $2, 0x000f # Enable IRQ1 and IE (Global interrupt enable) ori $2, $2, 0x22 # Put the CPU control register back movgs $cctrl, $2 … eg. We wish to setup the CPU to allow only IRQ1…

26. COMP201 Exception Vector Register The processor needs to know where to jump when an exception occurs. The Exception Vector Register ( $evec ) holds the address to jump to. By changing this register we can tell the processor where our exception handler is.

27. COMP201 Exception Vector Register (eg.) … # Get the exception vector register movsg $2, $evec # Save it sw $2, old_vector($0) # Get the address of our handler la $2, handler # And copy it back into the $evec register movgs $evec, $2 … old_vector:.word 0 eg. We wish to setup the CPU to go to our handler when an exception occurs…

28. COMP201 Exception Status Register When an exception has occurred we need to be able to tell what caused it.  Timer interrupt?  Serial port interrupt?  Divide-by-zero exception? When an interrupt occurs this information is available in the Exception Status Register ( $estat ). We use this to decide whether to handle the exception ourselves, or jump to the system exception handler.

29. COMP201 Exception Status Register 310411 IRQ7 … IRQ0 Hardware Interrupts HW IntsUndefined 1512 Undef Software Exceptions Arithmetic Breakpoint Syscall GPF

30. COMP201 Exception Status Register (eg.) handler: # Get the exception status register movsg $1, $estat # Check for any other exceptions than # the one we want (IRQ1) andi $1, $1, 0xffd0 # If no other exceptions have occurred then # we branch to our handler. beqz $1, handle_interrupt # Otherwise we must jump to the system # exception handler. lw $1, old_vector($0) jr $1 handle_interrupt: # Handle our interrupt … eg. Decide whether the exception was caused by IRQ1.

31. COMP201 Exception Address Register When an exception occurs we need to know where the program was up to. When we have handled the exception we can pick up where we left-off. The address of the instruction that was about to be executed when the exception occurred is stored in the Exception Address Register ( $ear ). When an rfe instruction is executed the CPU returns to the address that is stored in $ear.

32. COMP201 Movsg/movgs These instructions allow us to access the special registers.  Movsg copies the contents of a special register into a general purpose register: eg. movsg $2, $cctrl  Movgs copies the contents of a general purpose register into a special register. eg. movgs $cctrl, $2

33. COMP201 Return from exception (eg.) handle_interrupt: # Handle our interrupt … # Acknowledge the interrupt … # Return to the main program rfe eg. Return to the main program after an exception.

34. COMP201 Setting up WRAMP interrupts What needs to happen to allow a particular interrupt to occur?  Interrupts must be turned on (IE = ‘1’)  The particular interrupt we want must be unmasked (corresponding bit in IntMask = ‘1’).  The device that we want to generate the interrupt may need to be setup.

35. COMP201 What happens on an interrupt?  The CPU checks if interrupts are enabled (IE = ‘1’)  The CPU checks if that particular interrupt is enabled (in IntMask)  The address of the next instruction is saved to $ear.  Bits in $estat are set to indicate which exception(s) occurred.  The IE and KU bits in $cctrl are copied into the OIE and OKU bits respectively.  Interrupts are disabled and the CPU is set to kernel mode (IE = ‘0’, KU = ‘1’).  The CPU jumps to the address stored in $evec.

36. COMP201 But… What would happen if we got another exception while inside our exception handler?  The address stored in $ear would be overwritten.  We could not get back to where we came from. We must ensure that no exceptions occur when in the handler.

37. COMP201 How? To prevent software exceptions we can write our handler code very carefully (no overflow, or divide-by-zero). To ensure no hardware interrupts affect this, the WRAMP CPU automatically turns off the Interrupt Enable bit in $cctrl when an exception occurs. Any interrupts that occur while IE = ‘0’ are held off until interrupts are turned back on.

38. COMP201 What happens on an ‘rfe’?  The OIE and OKU bits in $cctrl are copied back into the IE and KU bits.  The CPU returns to the address stored in $ear.

39. COMP201 $cctrl on exception OIE IE OKU KU 1 0

40. COMP201 $cctrl on ‘rfe’ OIE IE OKU KU

41. COMP201 Interrupts and Devices How do devices support interrupts?  Interrupts are signaled to the CPU through a wire (known as the Interrupt Request or IRQ line).  A way to enable/disable the interrupt is provided. Often through a control register in the device.  A way to acknowledge the interrupt is provided.

42. COMP201 Device Initialisation Before a device will generate interrupts for us we must set it up. This normally involves writing to it’s control register. We must also ensure that any previous interrupts are acknowledged.

43. COMP201 Example – The Timer … # Acknowledge any outstanding interrupts sw $0, 0x72003($0) # Put our count value into the timer load reg addi $11, $0, 24000 sw $11, 0x72001($0) # Enable the timer and set auto-restart mode addi $11, $0, 0x3 sw $11, 0x72000($0) … eg. Setup the timer to generate an interrupt every 10s.

44. COMP201 Summary Part-2 Exception Handlers may be chained. Chaining exception handlers allows new handlers to be added. WRAMP supports eight Interrupts and four Software Exceptions. WRAMP has four special registers and three special instructions Interrupts are disabled in the exception handler automatically