Hardware Reference
In-Depth Information
Interrupts
are changes in the flow of control caused not by the running pro-
gram, but by something else, usually related to I/O. For example, a program may
instruct the disk to start transferring information, and set the disk up to provide an
interrupt as soon as the transfer is finished. Like the trap, the interrupt stops the
running program and transfers control to an interrupt handler, which performs
some appropriate action. When finished, the interrupt handler returns control to
the interrupted program. It must restart the interrupted process in exactly the same
state that it was in when the interrupt occurred, which means restoring all the inter-
nal registers to their preinterrupt state.
The essential difference between traps and interrupts is this:
traps
are syn-
chronous with the program and
interrupts
are asynchronous. If the program is
rerun a million times with the same input, the traps will reoccur in the same place
each time but the interrupts may vary, depending, for example, on precisely when a
person at a terminal hits carriage return. The reason for the reproducibility of traps
and irreproducibility of interrupts is that traps are caused directly by the program
and interrupts are, at best, indirectly caused by the program.
To see how interrupts really work, let us consider a common example: a com-
puter wants to output a line of characters to a terminal. The system software first
collects all the characters to be written to the terminal together in a buffer, ini-
tializes a global variable
ptr
, to point to the start of the buffer, and sets a second
global variable
count
equal to the number of characters to be output. Then it
checks to see if the terminal is ready and if so, outputs the first character (e.g.,
using registers like those of Fig. 5-30). Having started the I/O, the CPU is then
free to run another program or do something else.
In due course of time, the character is displayed on the screen. The interrupt
can now begin. In simplified form, the steps are as follows.
HARDWARE ACTIONS
1. The device controller asserts an interrupt line on the system bus to
start the interrupt sequence.
2. As soon as the CPU is prepared to handle the interrupt, it asserts an
interrupt acknowledge signal on the bus.
3. When the device controller sees that its interrupt signal has been
acknowledged, it puts a small integer on the data lines to identify it-
self. This number is called the
interrupt vector
.
4. The CPU removes the interrupt vector from the bus and saves it tem-
porarily.
5. Then the CPU pushes the program counter and
PSW
onto the stack.
