Exception Handling
Background
Operating System:
 Multiprogramming: multiple programs concurrently run, sharing
computer resources.
 In a time-sharing system users all have the illusion of a dedicated
machine, where the system swaps rapidly between users.
 Process model: a process (or task) consists of a program in execution.
This includes the information about the state of the program.
 Ready-Running-Waiting model of Processes
 Kernel (Supervisor) Mode vs. User Mode
o The interrupt handler routine must operate in kernel mode,
switching back to user mode when done. User programs
cannot themselves explicitly call the interrupt handler.
o The interrupt handler can use registers 26 & 27 ($k0 and $k1)
without having to worry about saving them.
Classes of Exceptions
Interrupt: appears to the program as if a parameterless procedure has been
inserted, with no results returned. Sometimes referred to as an “asynchronous
procedure call.”
E.g.
 I/O device is now ready (avoids busy-waiting)
 Timer interrupt (certain amount of time per process in a timesharing
system); also cron jobs
Trap: Caused by the running program itself. This is synchronous, since running
the program again would again cause the same problem at the same line of
code.
E.g.
 I/O request (e.g. getc() waits for a character to be typed), blocking
until it is.
 Division by zero
 Overflow
The Trap Handler
When an interrupt occurs, in PCSpim the trap handler is called (see Appendix E
of Britton text).
When a procedure is called using jal, the address is supplied. In the case of an
exception, the system must supply the address, which is fixed at
0x8000 0080
The PC is loaded with this value, and execution resumes at that instruction.
A “normal” subroutine call using jal also has the effect of saving the return
address (the next address to be executed, which is the address of the jal + 4) in
$ra, register 31. The trap handler can’t use $ra for this, since it would
overwrite the $ra value needed by the code generating the interrupt.
Additionally, the trap handler can’t depend on $sp being usable.
Coprocessor 0 Register Description (see following diagram):
There are 16 registers in Coprocessor 0. We will only concern ourselves with a
few of them.
SR – Register 12, the Status Register
The status register consists of mostly writable control fields. Fields
determine the CPU privilege level, which interrupt pins are enabled, and
other CPU modes.
Cause – Register 13
This represents what caused the exception or interrupt
EPC – Register 14, the Exception Program Counter.
This stores where to restart after the exception.
BadVaddr – Register 8
The program address that cuased the last address-related exception. This
is set by address (memory management) errors of all kinds.
There is one instruction for reading and one for writing to Coprocessor 0
registers:
mfc0 $k0, $13
# Move from Coprocessor 0 register 13
# (the cause register) into $k0
mtc0 $0, $12
# Move value 0 into Coprocessor 0 register 12
# (the status register)
Architecture for Interrupts
Diagram of CPU, Memory, and Coprocessors 0 and 1, from Hennessey and Paterson Appendix A
Sample Trap Handler (From Britton text Appendix E)
To understand example, you need to know about:
.kdata <addr>
Subsequent data items are stored in the kernel data segment. If the optional
argument addr is present, subsequent items are stored starting at address addr.
.ktext <addr>
Subsequent items are put in the kernel text segment. If the optional argument
addr is present, subseequent items are stored starting at address addr.
.set noat and .set at
The first directive prevents SPIM from complaining about subsequent
instructions that use register $at. The second directive reenables the warning.
Since pseudoinstructions expand into code that uses register $at, programmers
must be very careful about leaving values in this register.