How Early Computers Invented Interrupts to End Wasteful Polling

Background and the Polling Problem

In the early 1960s, developers of batch processing systems had to interact with slow external devices such as tape drives and printers. While a tape read took about 100 ms and a printer line over 600 ms, the CPU ran orders of magnitude faster. To wait for a device, programs repeatedly queried its status, as shown in the following polling loop:

int poll_count = 0;
// Polling wait for printer ready
while (1) {
    poll_count++;
    if (check_printer_status() == PRINTER_READY) {
        send_to_printer(print_data);
        break;
    }
}

This busy‑waiting wastes CPU cycles because the loop cannot exit until the device signals readiness.

Inspiration from IBM 704 Overflow Flag

The IBM 704 introduced an overflow flag (OV) that the hardware set when arithmetic operations overflowed. Programmers could test this flag and branch to error‑handling code, eliminating the need for manual checks in every instruction.

ADD MQ        // AC = AC + MQ, may overflow
TOV ERROR    // If OV == 1, jump to ERROR handler
TRA CONTINUE // Otherwise continue

ERROR:
    // error handling code
CONTINUE:
    // normal execution continues

This idea suggested that the CPU itself could detect exceptional conditions and automatically transfer control to predefined handlers.

From Software Exceptions to Hardware Interrupts

Applying the same principle to I/O, the design proposes that external devices should be able to notify the CPU when they are ready, just as software exceptions do. The resulting mechanism consists of four steps:

Hardware connection: devices are wired to the CPU via dedicated signal lines.

Signal trigger: a device changes voltage level when it becomes ready.

CPU response: the CPU detects the signal and jumps to the appropriate handler.

Task resume: after handling, execution returns to the interrupted program.

This eliminates continuous polling and forms the basis of the interrupt mechanism.

Interrupt Types and Vector Table

Interrupts are classified into hardware (e.g., printer, disk, timer, keyboard) and software (e.g., divide‑by‑zero, page fault, system call). The following enumeration defines these types:

// Interrupt type definition
typedef enum {
    // Hardware interrupts
    INT_PRINTER = 0,   // printer
    INT_DISK = 1,      // disk
    INT_TIMER = 2,     // timer
    INT_KEYBOARD = 3,  // keyboard

    // Software interrupts
    INT_DIVIDE_BY_ZERO = 4, // divide‑by‑zero
    INT_PAGE_FAULT = 5,     // page fault
    INT_SYSTEM_CALL = 6,    // system call

    MAX_INTERRUPT_TYPE = 7
} InterruptType;

Interrupt handling functions are stored in an interrupt vector table, which maps each interrupt type to a handler address and an enable flag:

// Interrupt handler type
typedef void (*InterruptHandler)(void);

// Vector table structure
typedef struct {
    InterruptHandler handlers[MAX_INTERRUPT_TYPE];
    bool enabled[MAX_INTERRUPT_TYPE]; // enable state
} InterruptVectorTable;

When an interrupt occurs, the CPU uses the interrupt number as an index into this table and invokes the corresponding handler:

void handle_interrupt(InterruptVectorTable* ivt, InterruptType type) {
    // ...
    ivt->handlers[type]();
    // ...
}

Conclusion

By allowing devices to generate interrupt signals, the CPU can focus on normal instruction execution and only divert attention when necessary, dramatically reducing wasted cycles and laying the foundation for modern operating‑system interrupt handling.