Upload
harriet-nash
View
231
Download
3
Tags:
Embed Size (px)
Citation preview
COMP201 Computer SystemsExceptions and Interrupts
COMP201
Outline Part1
Why have exceptions? What are exceptions and interrupts? The exception handler Device support for interrupts
COMP201
Polled I/O
loop: Get device status
Test status
If not ready go to loop
Send more data to device
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.
COMP201
Also…
What should happen if an error occurs during program execution? Divide-by-zero Overflow Illegal instruction Memory access error
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’
COMP201
Schematic Design
COMP201
Interrupt Pins
COMP201
Exception Example
Exception Handler
Main Program
An exception occurs
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.
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.
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
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.
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.
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.
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
COMP201
Outline -Part 2
Program Structure WRAMP Exception Sources WRAMP Special Registers WRAMP Special Instructions WRAMP Exception Operations Device Interrupt Control
COMP201
Example program structure
main: # Setup interrupts. …loop: # Main program loop. … j loophandler: # 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.
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)
COMP201
REX Interrupt Sources
IRQ0
Unused
IRQ1
User Interrupt Button
IRQ2
Timer Interrupt
IRQ3
Parallel Interrupt
IRQ4
Serial Port 1 Interrupt
IRQ5
Serial Port 2 Interrupt
IRQ6
Unused
IRQ7
Unused
COMP201
Interrupt Pins
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
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).
COMP201
CPU Control Register
31 0123411
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
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…
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.
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…
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.
COMP201
Exception Status Register
31 0411
IRQ7…IRQ0
HardwareInterrupts
HW IntsUndefined
15 12
Undef
SoftwareExceptions
ArithmeticBreakpointSyscallGPF
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.
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.
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
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.
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.
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.
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.
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.
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.
COMP201
$cctrl on exception
OIE
IE
OKU
KU
1 0
COMP201
$cctrl on ‘rfe’
OIE
IE
OKU
KU
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.
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.
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.
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