Hardware Interrupts

Polled I/O

One of the oldest forms of handling asynchronous input requirements was by means of a technique called "polling". "Asynchronous" means not at specific time intervals, and, in this case, basically means not at a time controllable by the computer system's processor or by a program within the computer system.

• Polling Cycle

  - A program being performed by the processor causes the processor to "loop through" all of its asynchronous devices and for each device output a signal asking if the device had any input it needed to send to the main processor; the specific device would either respond negatively or would respond positively and then transmit the actual input data.

• Problems with Polled IO

  - The major problem with polled I/O is that the main processor may not get around to checking a particular device while its input data value is still valid or present; if the input is a key from a keyboard terminal, the user may have taken his/her finger off the key and may have even pressed the next key before the processor is able to check for input. If for any polled device, its input value can only be guaranteed to remain valid of a certain period of time (say one-hundredth of a second), then the processor must complete its loop and get back to checking this device in less than one-hundredth of a second; the time required to complete the loop depends upon the number of devices on the loop and the non-determinable number of devices which will request I/O during the same loop process. Furthermore, the time the processor spends performing this "polling loop" is time that is not available for other useful processing (note that most of the time spent in polling is spent checking with devices that have nothing to input).

The Interrupt Concept

An alternative is to make the device responsible for letting the main processor know when it has some I/O requirement.

• "Excuse Me!"

  - The device acts somewhat like a rude guest at a party, interrupting the main processor whenever it needs I/O attention, without regard for whether or not the processor is currently busy.

• "Process My Needs"

  - Having obtained the main processor's attention, the device needs to identify its specific processing requirement. This normally begins with a declaration of who the device is. (Again, imagine the rude guest who having got the host's attention, begins a conversation with "Do you know who I am? I'm the Assistant to the Understudy for the Ambassador for the Proposed Conditional Diplomatic Mission to The Canary Islands, and I want more champagne.")

• "Continue With What You Were Doing"

  - Once the main processor has completed providing service to this device, it is free to resume whatever it was doing when the interruption occurred.

Processor Requirements for Interrupt Processing

• Getting the Signal

  - An electronic signal must be provided to the processor indicating the need to handle an interrupt request. This signal is normally only recognized at the end of the instruction cycle loop (after the current instruction has been processed, but before the next instruction is "fetched" from memory).

• Saving Current Status

  - Before an interrupt can be serviced, the processor must save its current status. Servicing an interrupt is like performing a subroutine call; one of the most critical pieces of information that must be saved is therefore, the value of the Program Counter (i.e. the location of the next instruction to be performed after servicing of the interrupt is complete). Processing an interrupt request involves performing a series of instructions for that request; this tends to modify the contents of flags and registers, so the flags and any registers that might be changed also need to be saved somewhere.

• Determining Who Signaled and What To Do About It

  - Once critical registers, etc. have been saved the processor needs to check which device sent the interrupt request (this may involve some I/O operations) and then it must determine where to find the necessary instructions needed to service that specific I/O request (typically handled using a "dispatch table" which contains interrupt device numbers and the addresses of service subroutines for each interrupt number).

• Returning To Original Activity

  - As a final step in each service routine, all original flag and register values, including the Program Counter, must be restored to their original values as they were just before the interrupt occurred.

Example: IBM PC Interrupt Processing

• Signal

  - Each device is assigned an IRQ (Interrupt ReQuest) number. When a device requires I/O attention it sends a signal on a dedicated line to an Interrupt Controller Chip (which line the signal comes in on determines its IRQ number). The Interrupt Controller Chip passes this value on to the main processor to be recognized as soon as the current instruction has been completed.

• The Stack

  - The IBM PC processor family uses two 16-bit registers in a variation of the base/offset addressing technique for a Program Counter; it also uses a 16-bit register as a collection for its flags. The 4 bytes for the "Program Counter" and the 2 bytes for the Flags are all save in an area of memory called the "stack". The last byte stored on the stack is pointed to by a special register called the "Stack Pointer". The stack "grows" backwards in memory, so as the result of an interrupt, the value in the Stack Pointer is reduced by 6, as the 6 bytes just noted are stored in stack memory space.

• Interrupt Service Vectors

  - Still operating at the hardware level, the IRQ number is used to retrieve two 16-bit addresses from 4 bytes of a table in memory; these addresses are automatically loaded into the "Program Counter" registers mentioned earlier. This table of addresses always starts in memory at address 0. The 4-byte address for any specific IRQ number is always found starting in memory at an address which is 4 times the IRQ number. There are a maximum of 256 (100h) interrupt vectors, numbered from 0 to 255 (00 to FFh), so the Interrupt Vector Table occupies the first 1024 (400h) bytes of memory. The routines pointed to by these "vector" addresses are part of the operating system.

• Interrupt Disabling

  - Some interrupts are so time critical or have some portions that are so time critical, that they must not be interrupted even by other interrupt requests. When an interrupt request is serviced, the hardware automatically turns off a flag thus blocking further interrupts from being recognized by the processor (i.e. other interrupts are "disabled"). Once the critical activities have been performed, the service routines execute an instruction which sets this flag, "enabling" other interrupts to occur.

• Interrupt Processing

  - The actual interrupt processing is fairly simple. I/O operations are performed for the specific device and I/O data control information is updated.

• Returning

  - Each service routine ends by restoring any general purpose registers that were used by the routine and the restoring the Flag and "Program Counter" registers so that on the next instruction control returns to wherever it was when the interrupt occurred.