|
11.035 bytes |
Service Hints & Tips |
Document ID: SSCT-3JMGK2 |
CrossBrand - Interrupts Explained
Applicable to: World-Wide
Interrupts are fundamental to the operation of a personal computer; many system crashes are caused somewhere along the line by a lost or spurious interrupt. This article explains what interrupts are, and how problems can arise. To keep it simple we have covered only Real Mode (that is, DOS) operation and have concentrated on hardware interrupts.
There are several classes of interrupt - these will be described later - but every interrupt has an interrupt number associated with it. The following happens when an interrupt occurs:
1. The currently executing instruction completes.
2. The CPU saves the next instruction's address and its status flags in a save area (the 'stack').
3. The CPU locates and calls in the code written to handle this particular interrupt. It does this using a list of addresses called the Interrupt Vector Table, which starts at address 0 in memory. The handler address for interrupt 0 is at location 0, the handler address for interrupt 1 is at location 4, and so on for all 256 possible interrupts.
All this happens automatically - it's a feature of Intel processors. Once the interrupt handler has performed whatever action was necessary it issues an IRET instruction, which restores the saved flags and instruction pointer so that the interrupted program can continue from where it left off.
Three types of interrupt can occur: Software, Exception and Hardware.
- Software Interrupts
A software interrupt occurs when a program executes an INT instruction; this will have been coded explicitly by the programmer in an Assembler program, or generated by a Compiler in a high-level language program. INT instructions are normally used to call BIOS or DOS services. You can think of software interrupts as an Application Program Interface
- Exception Interrupts
Sometimes, something goes wrong during the execution of an instruction. One example is a 'divide-by-zero' error during a DIVIDE instruction. Another exception arises when the CPU encounters an invalid instruction (this often happens when a 'wild branch' is taken).
Many more exceptions are possible in Protect mode; a typical one arises when a program attempts to access storage which doesn't belong to it. This will give an interrupt exception 13, which appears as a Trap D (13 decimal) under OS/2 or an EMM386 error #13 under DOS.
The operating system may be able to handle the exception interrupt in some cases (by ending the program, for example). Exception codes are a design feature of the Intel processor, not the Operating System or application.
- Hardware Interrupts
These are generated by events external to the CPU. There are two types: maskable and non-maskable. Each is communicated by a dedicated pin (INTR and NMI respectively) on the CPU chip.
The NMI pin is wired to critical components on the system board and is triggered if a serious fault, such as a parity or channel check, occurs. NMI causes an interrupt code 2 and the NMI handler (either in BIOS or the Operating System) will normally halt the system after issuing an explanatory message.
Maskable interrupt lines (IRQs) on the system bus are NOT wired directly to the CPU's INTR pin. Instead, a separate Interrupt Controller chip (an Intel 8259A or equivalent) is used. We'll start by describing how the PC and XT worked, and then AT-bus and subsequent systems, which addanother layer of complexity.
PCs and XTs
The 8259A chip supports eight input lines; it can thus handle up to eight separately interrupting devices. The lines are given Interrupt Request (IRQ) numbers, which are NOT the same as interrupt codes already discussed; the difference (and similarity) causes most of the confusion in discussing interrupts.
IRQs are numbered 0 to 7. Some are used by system-board devices (the system timer connects to IRQ0, the keyboard controller to IRQ1) and others are wired to the PC bus for use by adapters (for example, IRQs 2,3,5).
When a device (adapter or system board - the 8259A doesn't know or care) needs to communicate with the CPU (usually because its buffer has just filled or emptied) it triggers its interrupt line to the 8259A. This in turn signals the INTR pin on the CPU, and at the same time it transfers the interrupt value to the CPU using special data-bus cycles. Now here's where confusion arises; the 8259A adds an offset - usually 8 - to the IRQ index number before transferring the interrupt number
(The offset is necessary to avoid a clash with interrupt values allocated to exceptions.) So an IRQ0 actually causes an interrupt 8; an IRQ1 causes an interrupt 9; and so on, up to IRQ7 which causes an interrupt 15 (x'0F').
Clearly, the designers of the PC and XT had to reserve interrupts 8 through x'0F' for hardware use, but subsequent interrupts were allocated to INT instructions and various BIOS calls. INT x'10' happens to be the call to BIOS video services. This wasn't a problem in the early days of the PC and XT; there weren't that many adapters around, and few users needed to install more than a couple. Interrupt conflicts rarely arose or were easily avoided.
PC-ATs
However, the PC market expanded rapidly, and when the PC-AT was being designed it became a requirement to support more adapters concurrently. Although interrupt sharing was architecturally possible it wasn't implemented on most adapters, so the obvious solution was to provide more, separate IRQ lines.
Unfortunately, there were no interrupt controller chips available that supported more than eight devices, and Intel processors only provide one INTR pin, so can only talk to one 8259A.
The solution was to add another 8259A (supporting IRQs 8 to 15) and wire the second 8259A to the first one, then the first one to the CPU. So if (for example) an adapter triggers the IRQ10 line on the system bus, the second (slave) 8259A tells the master 8259A, which in turn interrupts the CPU. This technique is called a cascade.
But how could the slave 8259A connect to the master when all its IRQ inputs were already allocated to system devices and the PC bus? The answer was to 'steal' the IRQ2 line from the PC bus and give it, instead, to the slave controller.
However, many adapters (for example, Token-Ring and 3270) use IRQ2, so how could they continue to work on the PC-AT? The explanation is that the line designated 'IRQ2' on the AT bus actually goes to the second 8259A and is 'really' IRQ9 as far as the CPU is concerned. How this actually works is explained below.
Another problem was that (as already mentioned)interrupts x'10' upwards had already been allocated to BIOS calls, so the interrupt vector couldn't be 'IRQ+8' for the new IRQ lines. Finally, a device driver written to support an IRQ2 adapter would still expect to be called via interrupt x'0A' (IRQ2+8).
The first available interrupt block on the PC-AT was at x'70', so the interrupt number allocated to IRQ8 is x'70'; IRQ9 is interrupt x'71'; and so on. Clearly, special handling is needed for an adapter that 'thinks' it is using IRQ2. (Remember, a 'real' IRQ2 never actually happens!)
So this is how an adapter IRQ2 is handled on a PC-AT architecture system:
1. During system initialisation, a device-driver or TSR written to handle an IRQ2 adapter is loaded. If it is an 'old' driver it will hook the interrupt x'0A' vector (IRQ2 + 8) to point to its interrupt handler routine.
(Later, AT-aware drivers may hook interrupt x'71' directly.)
2. An adapter requiring service toggles the AT-bus line labelled 'IRQ2'.
3. This causes the slave interrupt controller to signal the master interrupt controller because it has 'seen' an IRQ9.
4. The master interrupt controller 'sees' an interrupt and signals the CPU's INTR pin, but doesn't transfer an interrupt value because it knows that this is a cascaded interrupt.
5. At the same time, the slave controller transfers the interrupt value 71 (IRQ8=index 0; IRQ9=index 1, and so on, plus its offset of x'70'). Thus, as far as the CPU is concerned, a physical hardware interrupt x'71' has just occurred.
6. The CPU saves its pointer and flags, then jumps to the interrupt x'71' handler via its Interrupt Vector Table entry.
7. The interrupt x'71' handler (part of BIOS) resets the slave controller and issues an INT x'0A' instruction.
8. The INT x'0A' instruction causes the adapter interrupt handler that hooked it (Step 1) to be invoked. This performs whatever action was required by the adapter then returns (to the interrupt x'71' handler).
9. The Interrupt x'71' handler returns to the originally executing program.
Finally, one more possible cause of confusion and system problems. IRQ9 is also used directly by some video adapters and video subsystems to signal a vertical retrace interval. (This enables applications to update the video buffer during flyback to avoid 'snow'). It is therefore vital to disable this interrupt if an adapter is using IRQ2; this can often be done via a jumper. This is quite a common cause of Token-Ring or other communications adapter problems.
|
Search Keywords |
Interrupts | |
|
Hint Category |
General Information | |
|
Date Created |
09-08-95 | |
|
Last Updated |
11-08-98 | |
|
Revision Date |
10-08-99 | |
|
Brand |
Cross Brand | |
|
Product Family |
Various | |
|
Machine Type |
Various | |
|
Model |
Various | |
|
TypeModel |
| |
|
Retain Tip (if applicable) |
| |
|
Reverse Doclinks |