Chapter 12 -- Exception Handling
EXCEPTION HANDLERS
------------------
The trouble with programmed I/O is that it both wastes CPU
resources and it has potential for "incorrect" operation.
What we really want:
(Since most I/O devices are slow), have I/O devices signal
the CPU when they have a change in status.
The I/O devices tell the CPU that they are "ready."
In order to do this we need:
Hardware (wires) from devices to the CPU.
A way for special software to be invoked when the a device
signals on the wire.
The modern solution bundles the software to deal with
these signals (interrupts) and other situations into
an EXCEPTION HANDLER. (Effectively part of the OS.)
EXCEPTIONS
----------
1. interrupts
--initiated outside the instruction stream
--arrive asynchronously (at no specific time)
examples:
I/O device status change
I/O device error condition
thermal override shutdown
internal error detection
when should the interrupt be dealt with?
as soon as possible
2. traps
--occur due to something in instruction stream
--arrive synchronously (while instruction is executing)
good test: if program was re-run, the trap would
occur in precisely the same place in the code.
examples:
unaligned address error
arithmetic overflow
syscall
when should the trap be dealt with?
right now! The user program cannot continue until
whatever caused the trap is dealt with.
exception handling
------------------
the mechanism for dealing with exceptions is simple; its
implementation can get complex. The implementation varies
among computers (manufactures).
situation: a user program is running (executing), and
a device generates an interrupt request.
mechanism to respond:
the hardware temporarily "suspends" the user
program, and instead runs code called
an EXCEPTION HANDLER. After the handler
is finished doing whatever it needs to,
the hardware returns control to the user program.
limitations of exception handler:
since it is being invoked (potentially) in the middle
of a user program, the handler must take extra care
not to change the state of the user program.
-- it can't change register values
-- it can't change the stack
So, how can it do anything at all?
The key to this answer is that any portion of the
state that it does change, it must also restore
before returning to the user program.
The handler often uses the system stack to temporarily
store register values.
WHEN to handle an interrupt -- 2 possiblilities:
1. right now! Note that this could be in the middle of
an instruction. In order to do this, the hardware
must be able to know where the instruction is in
its execution and be able to "take up where it left off"
This is very difficult to do.
But, it has been done in simpler forms on a few machines.
Example: arbitrary memory to memory copy
2. wait until the currently executing instruction finishes,
then handle. THIS IS THE METHOD OF CHOICE.
The instruction fetch/execute cycle must be expanded to
1. handle pending interrupts
2. instruction fetch
3. PC update
4. decode
5. operand load
6. operation
7. store results
some terms
----------
interrupt request -- the activation of hardware somewhere that
signals the initial request for an interrupt.
pending interrupt -- an interrupt that hasn't been handled yet,
but needs to be
kernel-- the exception handler
In most minds, when people think of a kernel, they think
of critical portions of an operating system. The exception
handler IS a critical portion of an operating system!
handler -- the code of the exception handler.
MIPS exception handling mechanism
---------------------------------
hardware does the following:
1. sets state giving cause of exception
Cause register -- coprocessor C0, register 13
32 bit register, bits 6..2 (5 bits) specify the type
of the exception, called the ExcCode.
Page 316 (text) gives the mapping of encodings to causes
examples:
00000 (0) Interrupt
00100 (4) load from an illegal address
01000 (8) syscall instruction
01100 (12) arithmetic overflow
2. changes to kernel mode, saving the previous mode
in a hardware stack (3 levels deep)
The mode is saved in the Status register.
coprocessor C0, register 12
defined in the processor's architecture are 2 modes,
user -- the mode that user programs run under.
certain instructions are not available
kernel -- the operating system mode. Allows the OS
to retain control over "vital" system aspects.
All instructions are available.
3. disables further interrupts
4. saves current PC
coprocessor C0, register 14, called Exception Program counter.
Gives return address in user program. Where to return to
when done handling the exception.
5. jumps to hardwired address 0x8000 0080.
This is where the exception handler code is.
Then, the code within the exception handler is run.
It does the following:
1. save some registers (on system stack).
The handler needs to use registers too! It may not
change (clobber) register contents of the user program.
So, it saves them (on stack or in memory).
2. Figure out exception type. (in ExcCode)
mfc0 $k0, $13 # get Cause register
andi $k0, $k0, 0x3c # Mask out all but ExcCode
3. use ExcCode in combination with a JUMP TABLE to jump to
the correct location within the exception handler.
4. handle the exception (whatever it is!)
5. restore registers saved in (1).
6. atomically:
(as if done in 1 step, not 3)
restore previous kernel/user mode (from Status register)
reenable interrupts
jump back to user program (using EPC)
about Jump Tables
-----------------
A clever mechanism for doing something like a CASE (SWITCH) statement.
A jump to one of many locations.
keep a table of addresses (case1, case2, and case3):
JumpTable: .word case0
.word case1
.word case2
sll $8, $8, 2 # case number shifted left 2 bits
# (need a word offset into table, not byte)
lw $9, JumpTable($8) # load address into $9
jr $9 # jump to address contained in $9
.
.
.
case0: #code for case0 here
.
.
.
case1: #code for case1 here
.
.
.
case2: #code for case2 here
(Note that the cases don't have to go in any specific order.)
Addressing mode: label($rb)
Effective address is gotten by label + ($rb)
label doesn't fit into 16 bit displacement field of load/store
instruction.
MAL->TAL synthesis of this must be something like:
la $1, label
add $1, $1, $rb
then use 0($1) as addressing mode in load/store instruction.
some advanced topics
--------------------
PRIORITIES
problem: Multiple interrupt requests can arrive simultaneously.
Which one should get handled first?
possible solutions:
FCFS -- the first one to arrive gets handled first.
difficulty 1) This might allow a malicious/recalcitrant
device or program to gain control of the processor.
difficulty 2) There must be hardware that maintains
an ordering of pending exceptions.
prioritize all exceptions -- the one with the highest priority
gets handled first. This is a common method for solving
the problem.
Priorities for various exceptions are assigned either by
the manufacturer, or by a system manager through software.
The priorities are normally set when a machine is
booted (the OS is started up).
difficulty 1) Exceptions with the same priority must
still be handled in some order. Example of same priority
exceptions might be all keyboard interrupts. Consider
a machine with many terminals hooked up.
The instruction fetch/execute cycle becomes:
1. any interrupts with a higher priority than whatever
is currently running pending?
2. fetch
3. decode
4. operands
5. operation
6. result
NOTE: This implies that there is some hardware
notion of the priority for whatever is running
(user program, keyboard interrupts, clock interrupt, etc.)
What should get given the highest priority?
clock? power failure? thermal shutdown? arithmetic overflow?
keyboard? I/O device ready?
priorities are a matter of which is most urgent,
and therefore cannot wait, and how long it takes
to process the interrupt.
-- clock is urgent, and takes little processing,
maybe only a variable increment.
-- power failure is very urgent, but takes a lot
or processing, because the machine will be stopped.
-- overflow is urgent to the program which caused it,
because it cannot continue.
-- keyboard is urgent because we don't want to lose
a second key press before the first is handled.
(story of what can happen if interrupt priorities set wrong)
REENTRANT EXCEPTION HANDLERS
The best solution combines priorities with an exception handler
that can itself be interrupted. There are many details to
get right to make this possible.
The instruction fetch/execute cycle remains the same. At
the beginning of EVERY instruction (even those within
the exception handler), a check is made if there are
pending interrupts. Only those with higher priorities
than whatever is currently running will be processed.
The exception handler must be modified so that it can
be interrupted. Its own state must be saved (safely).
Within the handler:
1. disable interrupts momentarily in order to save
important state that cannot get clobbered.
(EPC, current priority level, maybe registers
$26 and $27).
Question: where do these things get saved?
2. re-enable interrupts for higher priorities than
current level.
If the priority level checking is done in hardware,
then all interrupts can be re-enabled.
3. This invocation of the exception handler eventually
finishes.
The instruction fetch/execute cycle must be expanded to
1. handle pending interrupts
2. instruction fetch
3. PC update
4. decode
5. operand load
6. operation
7. store results