The routi ne that processes an interru pt (called an interrupt handler ) needs to do a number of things.

Transcription

1 Interrupt handlers The routi ne that processes an interru pt (called an interrupt handler ) needs to do a number of things. First, since the interr up t may have occurred anywhere in the main code, including the middle of a calculation, any of the generalpur pos e registers may have impor ta nt, unsaved values. Since you can't know ahead of time which registers contain importa nt values, all general- purpose registers changed by the interrup t handler must be saved on entry and restored on exit. (Don't try to use registers that the main program isn't using: the main program might be using all of them, and your routine has to be general enough to work in all cases.) The interru pt handler may have been invoked for a number of reasons. (On MIPS, the sam e routine is called not only for interru pt s, but also for synchrono us event s such as arithm et ic overflow and unaligned loads / s t or e s. Collectively, these are called exceptions, and so a better term for the handler would be "exception handler".) The exception handler thus needs to deter mi ne the cause of the exception, and jump to the relevant subroutine that will handle it. Now, the interr up t needs to be serviced. For instance, if it was a receiver (keyboar d) interr up t, then the next keypress is read from the Receiver Data Register. When the interru pt handler is due to return, the interru pt e d program needs to have its state (i.e., registers) restore d, and then be resumed at the point it was stopped. The address of this instruction was saved by the machi ne when the interr up t occurre d, so it is sim ply a matter of getting this address, and jumpi ng back to it.

2 MIPS To make interr upt s work, you'll need to know a few more features of the MIPS architect ure. Section 2.1 of the SPIM manual has a few paragrap hs on Coprocess or 0 and interru p t handling, but you may find the following sections more up- to- date and informative. Coprocess or 0 MIPS com put er s contain not only the main process or (CPU), but also at least one coprocessor (see Figure 2 in the SPIM manual ). Interrup t s and exceptions are managed by Coprocessor 0, which also handles the mem ory subsyste m. (Coprocess or 1, if present, does floating- point com p u t ati o n s.) Normal user- level code doesn't access Coprocesso r 0, but interrupt - aware code has to use it. Coprocessor 0 has several registers which control interrup t s and exceptions. Register 12, the Status Register, is a read- write register which cont rols whether interrup t s are allowed to happen, and if so, which ones. Register 13, the Cause Register, is a mostly read- only register whose value is set by the system when an interru pt or exception occurs. It specifies what kind of interr upt or exception just happened. Register 14 is Exception Program Counter (EPC). When an interrup t or exception occurs, the address of the currently running instruction is copied from the Program Counter to EPC. This is the addres s that your interru pt handler jumps back to when it finishes Registers 9 and 11, Timer Count and Timer Compare. In SPIM, the timer is sim ulat ed with two more coprocess or registers: Count ($9), whose value is continuou sly incremen te d by the hardwar e, and Compare ($11), whose value can be set. When Count and Compare are equal, an interr upt is raised, at Cause register bit 15. To schedul e a timer interru pt, the exception handler has to load Count, add a fixed amount called the time slice (quantu m), and

3 store this value into Compare. The smaller the time slice, the greater the frequency of timer interrupts. To access these registers, you'll need to know two new MIPS instructions. mfc0 (Move From Coprocessor 0) moves a value from a coprocessor 0 register to a general- purpose register: mfc0 $t5, $13 # Copy Cause register value to $t5. mtc0 (Move To Coprocessor 0) moves a value from a generalpurpose register to a coprocessor 0 register: mtc0 $v0, $12 # Copy $v0's value to Status register. If you want to modify a value in a coprocessor 0 register, you need to move the register's value to a general- purpose register with mfc0, modify the value there, and move the changed value back with mtc0.

4 Enabling interrupts Enabling interrupts requires doing three things: 1. Turn on the Interru pt Enable bit at Bit 0 of the Status Register. This bit is the global on/off control for interrupts. 2. Also in the Status Register, turn on the Interru pt Mask bits corresponding to the Receiver (bit 11), Transmitter (bit 10) and Timer (bit 15). These bits permit the CPU to respond to interrupts generated by the keyboard, display and timer. 3. Turn on the Interru pt Enable bit in the Receiver Control Register (0xFFFF0000). This bit tells the receiver hardware (keyboar d) that it should generate interrupts when keypresses occur. Now an interru pt will be generated when the user presses a key, and the exception handler will automatically be jumped to. Later, when your program is ready to write to the termi nal, you'll want to turn off the Receiver Control Register Interru pt Enable bit and turn on the corresponding bit in the Transmitter Control Register (at 0xFFFF0008). Writing an interrupt handler When an interr upt occurs, the following things are done autom atically by the hardware: 1. The Exception Level bit (bit 1) in the Status Register is turned on. While this bit is 1, no further interru pt s can occur. This is essential, because we don't want the interr up t handler to be itself interrupted. 2. The Cause register is set to indicate the cause of the interru pt (see Dispatching an interrupt below).

5 3. The EPC register is set to the current value in the Program Counter. This is the addres s in the main code where you will be resumi ng after handling the interrupt. 4. The Program Counter is set to 0x This addres s (0x ) is where you need to put your exception han dler. Do this with the.ktext (kernel text) and.kdata (kernel data) directives. here..kdata # Put any data structures required by the interrupt handler.ktext 0x # Exception handler begins here. Dispatching an interrupt When the exception handler begins, it needs to first find out what caused the exception. This can be achieved by examining the Cause Register from coprocessor 0. The Exception Code (bits 6-2) describes what caused the trap; if the Exception Code value is zero, then an interrup t has occurred. But which interrup t? The Interrup t Pending bits in the Cause Register indicate which devices need servicing; bit 11 will be on if the receiver has data to be read, bit 10 will be on if the transmitter is ready for another character and bit 15 will be on if the timer has raise an interrupt. Registers Your interrup t handler must save any general- purpose registers that it is going to use (to be restored at return). But to do so requires you to modify at least one register first (try it and see; reme m ber that somet hi ng like sw $t0, saved_t0 expands to two machine instructions using $at). This situation is resolved by forbiddi ng user program s from using two general- purpose register s, $k0 and $k1 (The k stands for kernel, which an exception handler is part of). Your interr upt handler is allowed to use $k0 and $k1 without having to save or restore their values. This allows you just enough leeway to start saving registers, as well as making returning from the interrupt handler possible.

6 Note that your exception handler (and main program) is probably also using the $at register, which is used silently by the assem bler in the expansion of certain pseudoinstructions; for example: # Expansion of "blt $t3, $t4, foo". slt $at, $t3, $t4 bne $at, $zero, foo To save $at, you will need to stage its value to a tempor ary location before saving it to mem ory, since the act of executing a sw instruction destroys $at as a side- effect. Any mention of $at must be bracketed by. set noat and.set at or the compiler will complain: # Allow direct references to $at # (and forbid its use in pseudoinstructions)..set noat # Copy $at to a temporarily safe place. move $k1, $at # Reserve $at for pseudoinstruction expansions again..set at # Save value to memory (side effect: this changes $at!). sw $k1, saved_at # Now save the other registers used by the interrupt handler. Simply do this in reverse to restore $at at the end of the interr upt handler. Spend a bit of time on your register - saving code when you write your interru pt handler, because it is tricky to get right, and getting it wrong can lead to subtle inter mit te nt failures. For instance, since $at is so delicate, it makes sense to save it first and restore it last. Returning from an interrupt When your interr up t handler is ready to retur n, it must restore the interru pt e d progra m' s state first. Most of this is done when your handler restores saved general- purp o se registers. The final step s are to resto re the Status register and to jum p back to the user program. These are done with the eret instruction: # eret effectively does this, all at once: # mfc0 $k0, $12 # Get status register. # li $k1, 0xFFFFFFFD # and $k0, $k0, $k1 # Clear Exception Level bit (bit 1) # mtc0 $k0, $12 # to allow interrupts again. # mfc0 $k0, $14 # Get address to jump back to (EPC). # jr $k0 # Jump back to that address.

7 eret