In this chapter we'll examine the use of interrupts on the 8088 microprocessor. You have used interrupts in earlier chapters in a cookbook fashion: the DOS function call, INT 21H, for ex-ample. Here we'll discuss how interrupts work and how the 8088 and MS-DOS make use of them. (There is an excellent, if technical, discussion of interrupt structure on pages 8-30 through 8-42 of Rector's and Alexy's The 8086 Book, published by Osborne/McGraw-Hill.) In the next two chapters, we'll continue with the subject of interrupts, focusing on the Pc.
Why
Interrupts?First of all, let's discuss what an interrupt is. We all are well-acquainted with many types of interruptions: the telephone ringing, the smoke alarm going off, a young child wanting our attention. However, in a computer system, interrupts are pos-itively advantageous.
The computer is always connected to a variety of other devices. Some of them are clearly separate-disk drives, moderns, other microprocessors-and some less so-internal clocks and timers, for example. For a computer to handle input and output properly, it has to be prepared for information from all of these devices at any time. There are only two ways for the 8088 to find out what's happening with these external devices.
1. The computer can routinely take time off from its various tasks to poll all the attached devices. In other words, the 8088 checks the appropriate input/output ports to see if anything is happening.
2. The devices let the computer know when something happens.
As you can imagine, this second alternative makes more sense. That way, the computer is spared having to spend a substantial amount of time checking all the attached
peripherals. This second method is the interrupt technique. In 189
11
Overview of Interrupts
short, whenever some external device has something to tell the microprocessor, it interrupts it. The keyboard, for example, interrupts the microprocessor whenever a key is struck.
The 8088 has a much more powerful system of interrupts than most eight-bit microprocessors. Each interrupt on the 8088 has a priority level, from interrupt 0 (the highest) to 255 (the lowest). Whenever the 8088 gets two interrupts at the same time, the lower-numbered interrupt is handled first.
Software Interrupts
In general, external interrupts (interrupts from peripherals) won't concern you. Software interrupts (interrupts requested by your own program as part of the normal program flow) are of more concern to the programmer. The interrupt number then becomes not a measure of an interrupt's priority, since you can call only one interrupt at a time, but rather a conven-ient index with which to access specific interrupt routines.
These software interrupts are designed to give the programmer access to all the power of DOS and BIOS.
Basically, using software interrupts is similar to CALling the system routines. However, using the INT command lets you call a routine without knowing where it is. You simply use the INT command in your program and let the computer fig-ure out where the requested routine is located.
The idea of something interrupting itself is most peculiar.
In fact, as you can imagine, the rationale behind these soft-ware interrupts is entirely different from the reason for the hardware interrupts discussed above. Why not simply have your program CALL any DOS or BIOS routines it needs to use? There are a few convincing reasons for using interrupts:
1. Simplicity. Putting INT lOR in your program is obviously preferable to, for example, CALL FOOO:ODOB: It takes fewer bytes of program memory (two versus five), and it is considerably easier to remember.
2. Portability. A portable program is one that will run without modification on a variety of different machines. For ex-ample, most machine language programs written on the IBM PC will run on the PCjr, even though the crucial routines in DOS and BIOS are in different places. A CALL FOOO:ODOB on one machine, for example, is a CALL FOOO:F065 on another. Portable programs thus always use 190
II
• II
II
where the appropriate routines are located.How Interrupts Work
No matter whether an interrupt is a software interrupt or a hardware interrupt, the basic mechanism used to handle them is the same. There are three ways for the computer to know which interrupt you want. The number can be specified by an external device requesting an interrupt, by the program itself (as in INT 21H), or the number can be implicit in the software command.
Once the computer knows which interrupt number is be-ing requested, it locates the interrupt-handlbe-ing routine (also know as the interrupt service routine). The first 1024 bytes of memory (OOOOOH to 003FFH) are given over to storing the starting addresses of each interrupt routine in segment:offset form. (Thus, 256 interrupt vectors, each four bytes long, add up to 1024 or one K.) It is possible to modify these vectors so that they point to your routines rather than the computer's, but doing so is a rather advanced technique.
Now the computer knows where the subroutine is located.
It pushes three words onto the stack: the 16-bit flags register, the current code segment (CS), and the current instruction pointer (IP). Next it loads the appropriate segment offset value from the interrupt vector area. At this point the interrupt rou-tine is given control. As you can see, this is much like a far CALL (such as the CALL FOOO:ODOB mentioned above). The only difference is that the flags register is also saved on the stack. We'll discuss why in a moment.
At this point, CS:IP holds the start address of the inter-rupt routine; the routine begins to execute. When the interinter-rupt routine is finished, it executes an IRET instruction (Interrupt execution by an external interrupt and then to resume exactly where it left off. For example, the clock-updating routine,
191
11
Overview of Interrupts
II
II
which is called 18.2 times each second by one of the PC's
II
timers, saves and then restores all the registers that it modi-fies. (Imagine the registers in your program changing 18.2
times a second!)
II
For those interrupt routines that are called only with soft-ware interrupts (and that covers most routines), certain
reg-isters are not saved. These are the regreg-isters that are used to
II
pass parameters. For example, the AX register is very rarely saved by any of the common interrupts; some interrupts, like the absolute disk read and write routines (INT 25H and 26H), alter all but the segment registers. Since these routines are al-ways called predictably from within program code, you don't have to worry about registers changing randomly. If you need to save registers, simply place PUSH instructions before the interrupt call, and POP instructions after it.
Interrupt Control Opcodes
We've already discussed the primary interrupt commands, INT and IRET. INT allows you to call any of the 256 interrupt routines simply by specifying
INT number
where number ranges from 0 to 255. IRET (Interrupt RETurn) is the instruction used to return from an interrupt. You'll have no need to use IRET yourself until you're an advanced pro-grammer, but you'll need to be able to recognize it to under-stand interrupt routine program listings, such as those in BIOS.
There are, as we've briefly mentioned, two other interrupt generating opcodes. The first of these is INT 3. In appearance this is the same as the INT number form above, but in fact the
INT 3 command is only one byte, as opposed to the standard
II
two-byte INT instruction. INT 3 is used by DEBUG to set breakpoints, and will be discussed in more detail below.
The second specialized interrupt command is INTO. This
II
command (INTerrupt on Overflow) is a conditional interrupt.
Normally, a program that deals with signed math needs to
have a way to handle overflow. If INTO is placed after a math
II
operation, it will execute an INT 4 if the overflow flag is set.
This interrupt opcode, like INT 3, is only one byte. As a rule,
you won't be needing to use this interrupt. Generating an
II
interrupt on overflow i~ a slight case of overkill for the
begin-192