How hardware interrupts work at the binary level
An interrupt is a hardware signal that tells the CPU to pause what it is doing and handle something urgent instead. It is the digital equivalent of tapping someone on the shoulder while they are deep in thought. Without interrupts, your CPU would have to constantly poll every device — a huge waste of cycles. In this article, I break down the binary-level mechanics: the signal voltages, the priority encoding logic, the interrupt vector table, and the context switching sequence.
An IRQ line is a dedicated electrical signal wire between a device and the interrupt controller. Interrupt signaling uses standard logic levels: asserted (active) means the voltage goes high (logic 1) or low (logic 0, depending on active-high or active-low convention), and deasserted means the voltage returns to the opposite level.
There are two conventions I regularly encounter: level-triggered (the IRQ line stays asserted until the CPU responds, safer but can cause spurious re-interrupts) and edge-triggered (the interrupt is signaled by a voltage transition, which can miss pulses if two interrupts arrive too close together). The original IBM PC used edge-triggered IRQs on the 8259A PIC — a design flaw where two devices sharing the same IRQ line could lose interrupts.
The 8259 Programmable Interrupt Controller is the classic example of interrupt priority encoding. When multiple interrupts arrive simultaneously, the controller uses a priority encoder — a binary circuit that selects the highest-priority request. Each priority level has a binary vector number. If IRQ0 is asserted, the encoder outputs vector 0 regardless of other inputs; if only IRQ1 is asserted, it outputs vector 1, and so on.
The priority encoder is implemented with a simple cascade of AND-OR gates where each stage blocks lower-priority signals when a higher-priority one is active. This is the same circuit pattern used in keyboard encoders and bus arbiters — a fundamental building block in digital logic design.
Once the interrupt controller selects which interrupt to service, it tells the CPU the interrupt vector — a binary number (0–255) that the CPU uses as an index into the Interrupt Descriptor Table (IDT). The IDT is stored in memory starting at a base address specified in the CPU's IDT register (IDTR).
For example, if the IDT base is 0xFFFFF000, vector 0 (divide error) points to offset 0xFFFFF000 + 0*16 = 0xFFFFF000, vector 32 (IRQ0, timer) points to 0xFFFFF000 + 32*16 = 0xFFFFF200, and so on. Each entry is typically 8 or 16 bytes containing the handler address, privilege level, and presence flags. The CPU reads the handler address and jumps to it within nanoseconds.
The x86 architecture supports 256 interrupt vectors (0 through 255). The first 32 (0–31) are reserved for CPU exceptions and are hardwired by Intel. These include vector 0 (divide error, binary 00000000), vector 3 (breakpoint, 00000011), vector 13 (general protection fault, 00001101), and vector 14 (page fault, 00001110).
Vectors 32–255 (binary 00100000 through 11111111) are available for hardware interrupts via the PIC or APIC. The master PIC typically maps IRQ0–IRQ7 to vectors 32–39, and the slave PIC maps IRQ8–IRQ15 to vectors 40–47. Each vector corresponds to a specific interrupt handler address stored in the IDT.
When the CPU accepts an interrupt, it must save the current program's state. The hardware performs this automatically: it finishes the current instruction (instructions are atomic with respect to interrupts), pushes the return address (PC) onto the stack, pushes the flags/status register, reads the handler address from the IDT, and jumps to the handler.
The ISR then saves any additional registers it will use (via PUSH instructions), services the device, restores the registers (POP), and executes IRET, which pops the saved flags and return address. A hardware context switch typically takes 10–30 clock cycles. Total interrupt latency can be as low as 50–100 nanoseconds in a well-tuned system.
Hardware interrupts are generated by external devices: the timer chip asserting IRQ0 every millisecond for the system tick, the network card asserting an IRQ when a packet arrives, the keyboard controller when a key is pressed, or the disk controller when a read completes.
Software interrupts are triggered by the CPU executing a special instruction like INT (x86) or SVC (ARM). Uses include system calls (user-mode programs invoking OS services via INT 0x80 or SYSCALL), exceptions (divide-by-zero, page fault, invalid opcode), and breakpoints (INT 3 for debugging). Both types use the same IDT — the only difference is the source.
What happens when a higher-priority interrupt arrives while servicing a lower-priority one? In nested interrupt handling, the CPU saves the current ISR state and services the new one, then resumes. The CPU has an Interrupt Flag (IF) that, when cleared, causes the CPU to ignore all maskable interrupts. Non-maskable interrupts (NMIs) bypass this flag.
Modern interrupt controllers also support priority-based masking: the OS sets a "current priority level," and any interrupt below this level is held pending. The priority level is stored as a binary number in the controller's control register. I've used this extensively in real-time embedded systems where a missed timer tick from a lower-priority interrupt could cause control loop instability.
Understanding binary interrupt signals is crucial for anyone working with low-level systems programming, embedded development, or performance analysis. Every keystroke, network packet, and mouse movement your computer handles goes through this exact interrupt mechanism. When you use our binary decoder or any binary to text converter, remember that the keyboard interrupt that delivered those keystrokes traveled through this exact priority encoding and vector table lookup pathway.
Open the Binary Code Decoder in a new tab and enter some binary patterns to see the results instantly. All conversions happen in your browser — no data is sent to any server.