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