2. a hardware interrupt occurs during execution of an instruction while the trace bit is set
(the trace exception has priority)
When multiple exceptions occur simultaneously, the CPU enters the exception processing state
for the exception with the highest priority first. It completes the exception processing and then,
immediately, without executing any of the instructions for this handler, the CPU reenters the
exception processing state for the exception with the lower priority level. Once it has obtained
the vector number, it fetches the address of the exception handler for this exception and places it
in the CS and IP registers. Then it executes this handler. Once this routine completes, control
returns to the handler for the exception with the higher priority level. This process seems
counter-intuitive at first glance. You would expect the CPU to execute the handler for the higher
priority exception first. An examination of the second example above (the trace/interrupt
example) shows that scheme just outlined is the right way to handle this situation. If the CPU
executed the trace routine first, you would end up tracing the first instruction of the interrupt
handler, instead of the next instruction of the user program. A programmer using the debugger
(the most common use of the trace exception) would certainly be surprised to see a "foreign"
instruction that has nothing to do with his or her program.
Processing and Handling Interrupts
Although we will need to fill in details later, the following steps will give you a broad overview
of what happens when the CPU recognizes and processes an interrupt. Notice that these steps
include the normal exception processing state, but also include other actions that are not part of
the exception processing state.
1. The CPU saves state (the FLAGS register or SR and the return address)
2. The CPU (Motorola) or interrupt controller (Intel) disables interrupts of the same or
lower priority
3. The CPU clears the trace bit of the SR or FLAGS register (on the Motorola processor, SR
also contains a "mode" bit which the CPU sets to 1. This sets the processor operation to
supervisor mode to allow execution of "privileged" instructions, not available in normal
or user mode)
4. The CPU obtains the vector number for the interrupt, retrieves the address of the interrupt
service routine from the exception vector and places this address in the IP, thus
transferring control to the interrupt handler. At this point, we return to normal execution
state.
5. The handler identifies and services the condition that caused the device to request an
interrupt. The execution of the service routine will include the following (the programmer
of the handler must write code to perform these tasks):
a. Optionally disable interrupts. In some situations, a particular service routine must
be able to perform at least part of its task without interruption, in which case it would set
the interrupt mask or IMR to disable all interrupts.
b. Save scratch registers.
c. Identify the condition that caused the interrupt. A single device often generates
interrupts for various different reasons. For example, either moving a mouse or pressing
one of its buttons will cause it to generate an interrupt. Similarly, the interface for a
modem may generate an interrupt either when its buffer for incoming data is full or when
it has transmitted all the data in its buffer for outgoing data and is ready to have the buffer