Hardware Interrupt Generation and Acknowledgement - Part 1

On the next couple pages we are going to talk about what happens at the hardware level when a device is in need of service. Remember these things all are done by hardware (unless otherwise specified) - there is no software involved yet. Remember also that this information varies according to the architecture. The description below, though, is representative of most systems.

Now - let's look at what happens when a device needs service. An example of a device in need of service might be a keyboard controller immediately after a key has been pressed. The controller receives the key press from the beyboard and would now like to pass it along to the CPU.

• When a device needs service, it requests service from the CPU by placing a signal on the "interrupt request" BUS line. If the CPU is allowing interrupts, it checks the status of that line in between every instruction it executes.
• If it finds that line active (that there is a device needing service), it acknowledges the interrupt by sending a signal down another line (the interrupt acknowledge line).
• The devide that generated the interrupt, on receipt of the acknowledgement, now sends an interrupt vector address over another set of BUS lines back to the CPU.

So - what has happened so far is that a device decided it needed service, so it told the CPU. The CPU then gave the device the go-ahead to send back some information (the interrupt vector address) that it will need to process the interrupt.

So - what happens next?

• The vector address returned by the device uniquely identifies that device. The vector addresses returned by the devices are predetermined and known by the O/S in advance. The way it is used is as an index into a table (called the interrupt vector table) which holds the interrupt vector for that device (more on what the interrupt vector is and does later).

As an aside, what happens if more than 1 device generates an interrupt at the same time?

Well, the interrupt acknowledge line is one of those BUS lines that are discontinuous (as opposed to the interrupt request line which is continuous). So - say two devices (or more) raise a signal on the interrupt request line at the same time. The CPU sends back an interrupt acknowledge signal. The first device on the (physically nearest the CPU on the BUS) notices the line go high.

• If it has an interrupt pending then it grabs the acknowledgement and does not pass it along. It then sends back the interrupt vector address. Other interrupting devices will have to wait for the next go-around.
• If the first device had not generated an interrupt, then it simply passes it along to the next device. This continues until the acknowledge signal finally makes it to the first interrupting device.

Notice, then, that the physical arrangement of the devices on the BUS actually determines the priority with which devices will be responded to in the case of concurrent interrupts. This is the case for the PDP-11, but not for all architectures.

80x86 Interrupt Processing in General

On PC's, interrupts are processed by an interrupt controller chip: the Intel 8259A. Modern PC's use two of these chips hooked in serial. Each controller has 8 interrupt lines (IRQ0 - IRQ7).

• The highest priority request is recognized and processed.
• Higher priority interrupts are recognized during lower priority interrupts.

When an interrupt is serviced, the device sends an interrupt type code nn back to the CPU. The absolute address of the ISR is 0:4*nn.

The two interrupt controllers are connected in a Master-Slave relationship. Controller 1 has IRQ's 0 through 7, while Controller 2 has IRQ's 8 through 15.

Specific devices and locations on the 8259A are as follows:

• IRQ0 is the system timer
• IRQ1 is the keyboard
• IRQ2 is the connection to the second controller
• IRQ3 is serial port 2
• IRQ4 is serial port 1
• IRQ6 is the floppy disk
• IRQ7 is the parallel port 1
• IRQ8 is the realtime clock
• IRQ12 is the mouse (but not always, depends on the mouse, etc)
• IRQ13 is the numeric coprocessor

The default priority ordering is 0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7.

The IRQ to which a device is connected (programmed to use) determines its priority and thus, there is no mechanism to store a PS with the PC in the interrupt vector table.