Interrupts: Objectives
Interrupts: Objectives
Interrupts
Objectives
• To describe the interrupt mechanism of the Pentium;
• To explain software and hardware interrupts;
• To discuss DOS and BIOS interrupt services to interact with I/O devices such as the
keyboard;
• To illustrate how user-defined interrupt handlers are written;
• To discuss how single-stepping is implemented in the Pentium;
• To describe the interrupt mechanism of PowerPC and MIPS processors.
Interrupts, like procedures, can be used to alter a program’s flow of control to a procedure called
the interrupt service routine or handler. For most of this chapter, we focus on Pentium interrupts.
Unlike procedures, which can be invoked by the call instruction, interrupt service routines
can be invoked either in software (called software interrupts), or by hardware (called hardware
interrupts). Interrupts are introduced in the first section. Section 20.2 discusses a taxonomy
of Pentium interrupts. The interrupt invocation mechanism of the Pentium is described in Sec-
tion 20.3.
Both DOS and BIOS provide several software interrupt service routines. Software interrupts
are introduced in Section 20.4. This section also discusses the keyboard services of DOS and
BIOS. Section 20.5 discusses exceptions. Exceptions are like interrupts, except that they are
caused by an event within the processor such as an attempt to divide by zero.
Hardware interrupts are introduced in Section 20.6. Hardware interrupts deal with interrupt
requests from the I/O devices. We use the keyboard to illustrate how interrupt handlers are
written in Pentium-based systems. We briefly discuss the interrupt mechanisms of PowerPC
and MIPS processors in Sections 20.7 and 20.8. The last section summarizes the chapter.
825
826 Chapter 20 Interrupts
20.1 Introduction
The interrupt is a mechanism by which a program’s flow of control can be altered. We have
seen two other mechanisms that do the same: procedures and jumps. Jumps provide a one-way
transfer of control, and procedures provide a mechanism to return control to the point of calling
when the called procedure is completed.
Interrupts provide a mechanism similar to that of a procedure call. Causing an interrupt
transfers control to a procedure, which is referred to as an interrupt service routine. An interrupt
service routine is commonly called an interrupt handler. When the interrupt handler execution
is done, the original program resumes execution as if it were not interrupted. This behavior is
analogous to a procedure call. There are, however, some basic differences between procedures
and interrupts that make interrupts almost indispensable.
One of the main differences is that interrupts can be initiated by both software and hardware.
In contrast, procedures are purely software-initiated. The fact that interrupts can be initiated by
hardware is the principal factor behind the power of the interrupt mechanism. This capability
gives us an efficient way by which external devices (outside the CPU) can get the attention of
the CPU.
Software-initiated interrupts—called simply software interrupts—are caused by executing
a processor instruction. In the Pentium, software interrupts are caused by executing the int
instruction. PowerPC and MIPS processors also have an instruction to generate interrupts. The
PowerPC uses the system call (sc) instruction to cause interrupts. The MIPS processor also
uses the system call (syscall) instruction for software interrupts. In fact, in Chapter 15, we
used this instruction to invoke the SPIM simulator I/O services.
Thus, software interrupts, like procedure calls, are anticipated or planned events. For exam-
ple, when you are expecting a response from the user (e.g., Y or N), you can initiate an interrupt
to read a character from the keyboard. What if an unexpected situation arises that requires the
immediate attention of the CPU? For example, you have written a program to display the first
90 Fibonacci numbers on the screen. While running the program, however, you have realized
that your program never terminates because of a simple programming mistake (e.g., you forgot
to increment the index variable controlling the loop). Obviously, you want to abort the program
and return control to the operating system. As you know, in most cases this can be done by
ctrl-break. For this example, ctrl-break certainly works. The important point is that
this is not an anticipated event, so it cannot be programmed into the code. Strictly speaking,
we can include code to handle all possible events, or at least most likely events, but such an
alternative makes the program very inefficient.
The interrupt mechanism provides an efficient way to handle unanticipated events. Refer-
ring to the previous example, the ctrl-break could cause an interrupt to draw the atten-
tion of the CPU away from the user program. The interrupt service routine associated with
ctrl-break can terminate the program and return control to the operating system.
We see two terms in this chapter: interrupts and exceptions. Interrupts were originally
proposed as a way to handle unanticipated events such as requests for service from I/O devices.
Later, the same mechanism was extended to handle internal events such as arithmetic overflow