Interrupts are easily one of my favorite topics. They came pretty early in my low-level development journey. The concept was so fascinating that it kept me driven to explore deeper systems programming concepts.
\nSince I started my coding journey with Android app development, I was already familiar with event listeners like onClick(). However, I never stopped to think about how they worked under the hood. Interrupts took me down to the lower layers where that underlying mechanism becomes clear. Take one more step down, and you land directly at the hardware and electronics layer.
The word literally means “to stop something while it is happening.” The technical concept is identical. While the CPU is executing instructions, a specific condition occurs. The CPU immediately stops its current work to handle that situation.
\nFor example, consider a single-core CPU executing one process at a time. Suppose the process currently running is doing background OS utility work. At that exact moment, you press a key on your keyboard. Do you want the OS to display that letter on your text editor immediately? Or do you want to wait for the background task to finish first? We all know the answer.
\nThat is an interrupt in action:
\nInterrupts fall into two main categories: Hardware Interrupts and Software Interrupts.
\nSoftware interrupts further break down into two subcategories:
\nModern systems rely on an APIC (Advanced Programmable Interrupt Controller) and MSI (Message Signaled Interrupts).
\nIn my own OS implementation, I built support for the older PIC (Programmable Interrupt Controller). The PIC relies on physical wire connections linked to every hardware slot (such as PCI or PCIe slots) on the motherboard.
\nThe structural difference between a PIC and an APIC is straightforward:
\nHow does MSI differ from physical lines connected to PCI slots? In modern systems, if hardware needs CPU attention, how does it notify the CPU without a dedicated wire?
\nThe fundamental architecture shifted:
\nSince my project uses the PIC (Programmable Interrupt Controller), I will focus on its operation here. The PIC acts as a gatekeeper for hardware interrupts reaching the CPU. Physical connections from hardware devices feed into the PIC, which then routes them to the processor.
\nThe number of physical lines on a PIC dictates how many devices it can support. Early PICs had only 8 interrupt lines (IRQ0 to IRQ7). Engineers quickly ran out of lines, leading to a clever workaround: cascading two PIC chips in a Master-Slave architecture.
\nConnecting IRQ2 to the Slave PIC yields 15 usable hardware interrupt lines (16 total lines minus the 1 line used for cascading).
\nWhen an interrupt occurs on lines IRQ8 through IRQ15:
\nAn Interrupt Descriptor Table (IDT) is an array of descriptor structures defining interrupt gates. Each entry follows a rigid, hardware-defined format. Entries contain the target handler’s memory address, required privilege levels, and execution characteristics.
\nIn the x86 architecture, the IDT contains up to 256 entries. This allows you to configure up to 256 distinct interrupt handlers.
\nEach entry in the table contains the following fields:
\ntypedef struct{\n unsigned short int offset_0;\n unsigned short int selector;\n unsigned char ist;\n unsigned char type_attribute;\n unsigned short int offest_1;\n unsigned int offset_2;\n unsigned int ignore;\n} __attribute__ ((packed)) idt_desc_entry_t; Bit position\n inside the\n 7 6 5 4 3 2 1 0 <-- Flags byte\n+---+-------+-------+-----------------------------------+\n| P | DPL | 0 | Gate Type |\n+---+-------+-------+-----------------------------------+\n| 1 | 2-bit | 1-bit | 4-bit | <-- SizeGate Type: Defines the behavior upon triggering. For example, anInterrupt Gate (0b1110
)** automatically disables subsequent interrupts until the current handler finishes. ATrap Gate (**0b1111\n*)* does not disable subsequent interrupts while dealing with the current one.
0b11 ) allows user-space programs to trigger the interrupt via theINT instruction (e.g., for system calls).1 for the vector to be valid.The IDT resides in main memory. The CPU tracks its location using a dedicated register called IDTR (Interrupt Descriptor Table Register). x86 provides a special assembly instruction — LIDT (Load Interrupt Descriptor Table)—to load this table pointer into the register.
However, the address loaded into the IDTR does not point directly to the table array. Instead, it holds a pointer to a pseudo-descriptor structure describing the table:
typedef struct {\n unsigned short int limit;\n unsigned long long offset;\n} __attribute__ ((packed)) idtr_t;sizeof(IDT) - 1 ).When an interrupt fires, the CPU hardware automatically pushes state data onto the stack before beginning interrupt handling:
\nAfter this hardware push, whatever happens next is handled entirely by your custom code.
\nI divided my interrupt handling process into three distinct steps: Context Saving, Interrupt Handling, and Context Restoring. This architecture uses a mix of Assembly and *C* because C cannot perform low-level register manipulation directly.
\nSuppose a process is executing on the CPU. While running, the process uses the memory stack and stores temporary data inside CPU general-purpose registers.
\nNow an interrupt occurs. The CPU pauses current execution and jumps to handle the interrupt. The handler requires CPU registers and stack space to do its work. Once handling completes, the CPU registers and stack would no longer match the state they were in when the interrupt occurred.
\nTo resolve this, we push all general-purpose CPU registers onto the stack. This process is context saving.
\nAlong with the registers, my assembly code pushes an error code (for exception interrupts like Divide by Zero) and the interrupt vector number onto the stack. This allows the C handler to identify which interrupt is currently active.
\nOnce context is saved on the stack, the assembly wrapper calls a common C interrupt handler. This dispatcher evaluates the vector number and calls specific driver routines.
\nWhen calling the common C interrupt handler, the assembly stub passes the current Stack Pointer value (RSP) as an argument. The C code receives this address as a pointer to a trapframe structure representing saved context.
Because the x86 stack grows downward (from higher memory to lower memory), the structure of the trapframe in C must be the exact inverse of the order in which elements were pushed onto the stack.
Here’s the assembly code that does the context saving:
\n%macro SAVE_CONTEXT 0\n push rax\n push rbx\n push rcx\n push rdx\n push rsi\n push rdi\n push rbp\n push r8\n push r9\n push r10\n push r11\n push r12\n push r13\n push r14\n push r15\n%endmacroAnd here’s the structure of trapframe:
typedef struct trap_frame_t {\n // general purpose registers used by any running process\n uint64_t r15;\n uint64_t r14;\n uint64_t r13;\n uint64_t r12;\n uint64_t r11;\n uint64_t r10;\n uint64_t r9;\n uint64_t r8;\n uint64_t rbp;\n uint64_t rdi;\n uint64_t rsi;\n uint64_t rdx;\n uint64_t rcx;\n uint64_t rbx;\n uint64_t rax;\n uint64_t interrupt_no; // which interrupt triggerd switch\n uint64_t error_code;\n // these are pushed automatically by cpu\n uint64_t rip; //instruction pointer\n uint64_t cs; // code segment\n uint64_t r_flags; // cpu flags\n uint64_t rsp; // stack pointer\n uint64_t ss; // stack segment\n} __attribute__((packed)) trap_frame_t;Context restoring pops the saved register values from the stack back into the CPU registers. When the interrupted process resumes, it finds all registers exactly as it left them.
\n%macro RESTORE_CONTEXT 0\n pop r15\n pop r14\n pop r13\n pop r12\n pop r11\n pop r10\n pop r9\n pop r8\n pop rbp\n pop rdi\n pop rsi\n pop rdx\n pop rcx\n pop rbx\n pop rax\n%endmacroIn my code, I have registered specific assembly functions as interrupt handlers. However, these were not final handlers; they are placeholders.
\n%macro ISR_NO_ERR 1\nglobal isr%1\nisr%1:\n push 0 ; Push dummy error code\n push %1 ; Push interrupt number\n jmp isr_common_stub ; Jump to the heavy lifting\n%endmacro\n%macro ISR_ERR 1\nglobal isr%1\nisr%1:\n ; Error code is already on stack!\n push %1 ; Push interrupt number\n jmp isr_common_stub\n%endmacro\nISR_NO_ERR 6 ; Invalid Opcode Exception\nISR_ERR 13 ; General protection fault\nISR_ERR 14 ; Page Fault\nISR_NO_ERR 32 ; IRQ0 (Timer) - This is the big one for scheduling!\nISR_NO_ERR 33 ; IRQ1 (Keyboard)\nISR_NO_ERR 128 ; System call\nISR_NO_ERR 43 ; E1000 network card\nisr_common_stub:\n ; 1. Save all General Purpose Registers\n SAVE_CONTEXT\n ; 2. Prepare for C Function Call (System V AMD64 ABI)\n ; The first argument (RDI) must contain the pointer to our struct.\n ; RSP points to the top of the stack, which IS the start of our TrapFrame.\n mov rdi, rsp\n ; 3. Call the C Handler\n ; void isr_handler(TrapFrame* frame);\n call isr_handler\n ; 4. Restore Context\n ; If the scheduler switched tasks, RSP will be different now!\n RESTORE_CONTEXT\n ; 5. Cleanup Error Code and Int No\n ; We pushed 2 uint64_t values (16 bytes) manually before SAVE_CONTEXT.\n ; We need to remove them so RSP points to the return address (RIP).\n add rsp, 16 \n ; 6. Return from Interrupt\n ; Pops RIP, CS, RFLAGS, RSP, SS automatically.\n iretqWhy were these placeholders necessary?
\nWhen an interrupt fires, the CPU does not pass the interrupt vector number directly to your code. The placeholders existed solely to push a unique interrupt number onto the stack before jumping to the common C handler.
\nEvery placeholder function performed identical tasks:
\nThe isr_common_stub function then:
\nSuppose an timer interrupt triggers, the function that will be called is isr32 which was set as the handler and generated by the assembly macro. This function then pushes the interrupt number to the stack, does context saving, then calls the C common interrupt handler and then restores context. isr6 does the same thing and so does isr14. Do you see the problem here, every function is doing the same thing except for what interrupt number they’re pushing on to the stack and yet you have a separate one for each and every one of it.
\nNow, while it still serves the purpose and it works perfectly. I find it just too much unnecessary. What can I say? I never built an OS before this. I was supposed to do naive and somewhat stupid things.
\nWith the knowledge gained from this project, a cleaner architecture emerges.
\nThe assembly placeholders served two functions: capturing the interrupt number and managing register context.
\nHowever, the CPU already knows which handler entry was invoked. Instead of duplicating wrapper code across 256 separate assembly labels, context saving and restoring can be consolidated into central helper functions (save_context and restore_context).
Every interrupt handler that is declared and implemented just calls two functions — save_context() in the start of it and restore_context() at the end of it. With this we, completely eliminate the need of those placeholders and the need of any comman C handler. If it every happens that you need to find the interrupt number, you already have the IDT as an array in your code, just traverse it.
\nThanks for reading till so far. I hope it was worth the time. If you would like to see my whole code here’s the github link to that. You can also follow me on Linkedin and *X* as well. And I know this one came after a very huge break. But now I hope to be regular with this series. So, Keep in touch!
","headings":[{"level":1,"text":"Building a 64-Bit OS — Chapter 3: Interrupt Descriptor Tables (The magic behind a working keyboard)","id":"building-a-64-bit-os-chapter-3-interrupt-descriptor-tables-the-m"},{"level":2,"text":"Interrupts","id":"interrupts"},{"level":2,"text":"What Are Interrupts?","id":"what-are-interrupts"},{"level":2,"text":"Types of Interrupts (Hardware vs. Software)","id":"types-of-interrupts-hardware-vs-software"},{"level":2,"text":"Interrupt Mechanism: Legacy Systems vs. Modern Systems","id":"interrupt-mechanism-legacy-systems-vs-modern-systems"},{"level":2,"text":"How to Enable Hardware Interrupts","id":"how-to-enable-hardware-interrupts"},{"level":2,"text":"Interrupt Descriptor Tables (IDT)","id":"interrupt-descriptor-tables-idt"},{"level":2,"text":"Structure of Each Table Entry","id":"structure-of-each-table-entry"},{"level":2,"text":"The LIDT Register","id":"the-lidt-register"},{"level":2,"text":"My Implementation","id":"my-implementation"},{"level":2,"text":"Saving Context","id":"saving-context"},{"level":2,"text":"The C Handlers","id":"the-c-handlers"},{"level":2,"text":"Restoring Context","id":"restoring-context"},{"level":2,"text":"The Problem with My Initial Code","id":"the-problem-with-my-initial-code"},{"level":2,"text":"The Solution","id":"the-solution"}]}}