1 / 44

COMP201 Computer Systems Exceptions and Interrupts

COMP201 Computer Systems Exceptions and Interrupts. Outline Part1. Why have exceptions? What are exceptions and interrupts? The exception handler Device support for interrupts. Polled I/O. loop: Get device status Test status If not ready go to loop

abie
Télécharger la présentation

COMP201 Computer Systems Exceptions and Interrupts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMP201 Computer SystemsExceptions and Interrupts

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

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

  4. 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. Also… • What should happen if an error occurs during program execution? • Divide-by-zero • Overflow • Illegal instruction • Memory access error

  6. 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. Schematic Design

  8. Interrupt Pins

  9. An exception occurs Exception Example Main Program Exception Handler

  10. 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. 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. 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. 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. 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. 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. 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. Outline -Part 2 • Program Structure • WRAMP Exception Sources • WRAMP Special Registers • WRAMP Special Instructions • WRAMP Exception Operations • Device Interrupt Control

  18. 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. 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. REX Interrupt Sources

  21. Interrupt Pins

  22. 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. 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. CPU Control Register 31 11 4 3 2 1 0 KU Undefined IntMask IE OKU OIE IRQ7 … IRQ0 Interrupt Mask Bits Kernel/User Mode (KU) Old Kernel/User Mode (OKU) Interrupt Enable (IE) Old Interrupt Enable (OIE)

  25. CPU Control Register (eg.) eg. We wish to setup the CPU to allow only IRQ1… … # 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 …

  26. 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. Exception Vector Register (eg.) eg. We wish to setup the CPU to go to our handler when an exception occurs… … # 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

  28. 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. Exception Status Register 31 15 12 11 4 0 Undefined HW Ints Undef Arithmetic Breakpoint Software Exceptions Syscall GPF IRQ7 … IRQ0 Hardware Interrupts

  30. Exception Status Register (eg.) eg. Decide whether the exception was caused by IRQ1. 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 …

  31. 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. 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. Return from exception (eg.) eg. Return to the main program after an exception. handle_interrupt: # Handle our interrupt … # Acknowledge the interrupt … # Return to the main program rfe

  34. 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. 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. 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. 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. 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. $cctrl on exception KU IE OKU OIE 0 1

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

  41. 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. 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. Example – The Timer eg. Setup the timer to generate an interrupt every 10s. … # 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) …

  44. 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

More Related