Interrupts Explained

Analogy categoryAnalogies

Interrupts, Exceptions, and Traps

An interrupt is an asynchronous signal that diverts the CPU from its current instruction stream to a handler routine, then resumes where it left off. Hardware interrupts (like a keyboard keypress or a timer tick) arrive from external devices and are asynchronous to the instruction stream; software interrupts are deliberately triggered by an INT instruction; and exceptions are synchronous conditions raised by the CPU itself during instruction execution, such as a divide-by-zero (#DE) or a page fault (#PF). Exceptions are further split into faults (which report the faulting instruction's address so it can be retried, like a page fault after the OS fixes the mapping), traps (which report the address after the instruction, like a breakpoint #BP), and aborts (unrecoverable severe errors like a double fault).

🏏

Cricket analogy: It is like the difference between a scheduled drinks break called at a fixed over count (a timer interrupt), an umpire stopping play because of a no-ball called mid-delivery (a synchronous exception), and a captain calling for DRS voluntarily (a software interrupt).

The Interrupt Descriptor Table

The Interrupt Descriptor Table (IDT) is a kernel-managed array of up to 256 gate descriptors, each mapping an interrupt vector number to a handler address, a target code segment, and a privilege level. Vectors 0–31 are reserved by Intel for CPU exceptions (0 is #DE divide error, 6 is #UD invalid opcode, 13 is #GP general protection fault, 14 is #PF page fault), while vectors 32 and above are available for hardware IRQs and OS-defined software interrupts. The LIDT instruction loads the base address and limit of the IDT into the CPU's IDTR register, and this table must be set up correctly during early boot before any interrupt can be safely handled — an unhandled or missing entry for a raised vector triggers a double fault, and if that too is unhandled, a fatal triple fault that resets the machine.

🏏

Cricket analogy: It is like a fixed 256-entry substitute-call sheet where the first 32 slots are permanently reserved league-wide for standard incidents (injury, rain, bad light) and the rest are open for each ground's own local signals, and a signal with no matching entry causes the match to be abandoned entirely.

Masking Interrupts and the PIC/APIC

The CLI and STI instructions clear and set the interrupt flag (IF) in RFLAGS, controlling whether maskable hardware interrupts can preempt the current code; non-maskable interrupts (NMI, vector 2) and CPU exceptions ignore IF entirely because they signal conditions too critical to defer. On real hardware, IRQ lines from devices are routed either through the legacy 8259 Programmable Interrupt Controller (PIC), which handles only 15 lines through primary/secondary chaining, or the modern Advanced Programmable Interrupt Controller (APIC), which supports far more interrupt sources, per-CPU local APICs for multicore interrupt distribution, and interrupt priority levels — nearly all contemporary x86 systems configure and use the APIC instead of the legacy PIC once the OS boots past its BIOS-compatibility stage.

🏏

Cricket analogy: It is like a captain briefly telling the twelfth man 'no substitutions right now' during a tense final over (CLI masking maskable interrupts) while an actual medical emergency (an NMI) would still stop play regardless of that instruction.

nasm

; Minimal x86 interrupt service routine stub (protected-mode style)
; Registers an IDT entry vector 0x21 (keyboard IRQ1 remapped) and
; demonstrates the standard save/handle/restore/iret pattern.

isr_keyboard:
    pushad                 ; save all general-purpose registers
    cld                     ; ensure string ops go forward, per calling convention

    in al, 0x60             ; read the scancode from the keyboard controller
    call handle_scancode     ; C-callable handler, receives scancode in eax by convention

    mov al, 0x20             ; EOI (end of interrupt) command
    out 0x20, al              ; acknowledge the interrupt on the PIC

    popad                    ; restore all general-purpose registers
    iret                      ; return from interrupt: pops EIP, CS, EFLAGS

IRET (or IRETQ in 64-bit long mode) differs from a plain RET because it restores not just the instruction pointer but also the code segment and RFLAGS, including the interrupt flag — this is what safely re-enables interrupts that were implicitly disabled while the handler ran, without requiring an explicit STI.

Forgetting to send an End-Of-Interrupt (EOI) signal to the PIC or APIC after handling a hardware interrupt leaves that interrupt line effectively masked from the controller's point of view — the device can fire again, but the controller will never deliver a second interrupt for it until EOI is acknowledged, causing input or timer events to silently stop.

Interrupts are asynchronous (hardware), exceptions are synchronous (CPU-detected), and software interrupts are deliberate INT instructions.
Exceptions subdivide into faults (retryable, address of faulting instruction), traps (address after instruction), and aborts (unrecoverable).
The IDT maps 256 vector numbers to handler addresses; vectors 0-31 are reserved by Intel for CPU exceptions.
LIDT loads the IDT base/limit into IDTR; a missing handler for a raised vector can cascade into a double or triple fault.
CLI/STI toggle the IF flag to mask/unmask maskable hardware interrupts; NMIs and exceptions ignore IF.
The legacy 8259 PIC handles 15 IRQ lines; the modern APIC scales to many more sources and multicore systems.
IRET restores RIP, CS, and RFLAGS together, correctly re-enabling interrupts after a handler completes.