Interrupt Requests (IRQs) are a mechanism that allows the various devices and software that make up a computer to jump the processing queue in order to have tasks of a predetermined “higher” priority to be executed “out of turn”. BIOS services are accessed using software interrupts, which are similar to the hardware interrupts (usually generated by devices external to the CPU) except that they are generated inside the CPU by programs.
Interrupt Request (IRQ) Management
Both hardware interrupts such as those generated by I/O devices like the keyboard and mouse and software interrupts such as those generated by system software when accessing BIOS services all need to be prioritized, queued, executed and managed. Originally this was done by the CPU.
Software interrupts also make it possible for system software (DOS or the operating system), applications and other software to directly access one another via BIOS routines without having to know where the target application resides in memory.
In order to improve overall system efficiency engineers decided to create a dedicated Interrupt Request controller rather than have the CPU spend processing cycles on such a relatively simple task as I/O device interrupt request management (IRQ prioritization and queuing) and associated data transfers.
Interrupt Vector Table
Normally, to call a software routine you need to know its address (location) in memory. However; with interrupt requests a table called an interrupt vector table is created and this is used to bypass the need to explicitly know the correct address in memory. Now every time the system is booted, the BIOS puts addresses representing where its routines are located for each interrupt that it is been configured to respond to.
So whenever DOS, the operating system or other applications want to use a BIOS routine, it generates a software interrupt. The system processes the interrupt, looks up the value in the interrupt vector table and then automatically jumps directly to the appropriate BIOS routine. Modern operating systems and applications as well as DOS can also directly use this interrupt vector table.
Intel 8259 Interrupt Controller
From early on in the evolution of the PC the standard for an interrupt controller is the Intel 8259 interrupt controller. The Intel 8259 Interrupt Controller has 8 input lines (numbered IRQ0 through IRQ7) that take requests from any one of 8 different devices that are connected to it. The controller then passes the request on to the CPU informing it of which device issued the request (which device triggered the request).
Originally only one device was attached to each interrupt line. Over time as more I/O devices started to be attached to the PC the need arose for more Interrupt Request channels to become available and so a second dedicated Intel 8259 interrupt controller was added to PCs.
Cascading Interrupt Controllers
To ensure compatibility with older PCs and existing hardware the IBM AT design team didn't want to change any of the currently existing IRQ lines that were functioning as the interrupt request highway to the CPU. Thus the decision was made to cascade the two interrupt controllers together.
The first interrupt controller still has 8 inputs and a single output going to the CPU. The second controller has the same design, but it takes 8 new inputs thereby doubling the number of interrupts.
The second interrupt controller feeds its output into input line IRQ2 of the first controller which then sends the signals to the CPU. Figure 1 below shows a logical depiction of this controller cascading arrangement. Thus; if any of the second interrupt controller's inputs become active, the output from the second interrupt controller will trigger IRQ2 on the first controller (the big red arrow in Fig.1 below), which then signals the CPU.
Because IRQ2 was now being used to cascade the second interrupt controller motherboard designers had to change the wiring on the motherboard so that any devices which would normally have used this IRQ channel (IRQ2) were sent over to IRQ9 which is on the second interrupt request controller. In Fig 1 above device 2 is the solid red box on the right labelled DEVICE2 and as you can see it triggers IRQ9 located on the second interrupt controller.
You will also see that in Table 1 Default IRQ Allocation - By IRQ Number that IRQ2 has N/A as its priority this is because IRQ2 is used as the cascade IRQ for the second controller and is therefore unavailable for assignment to any other device.
This concept of cascading is important as system designers have reused it many times in different formats as a solution for adding additional controllers of a wide variety of types to PCs. For example; when a second DMA controller was added, designers cascaded the first DMA controller to the second DMA controller (the new one).
