What Are Interrupts?

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.

For 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.

That is an interrupt in action:

1. The background process runs.
2. A keyboard press triggers an interrupt , pausing the background process.
3. The CPU processes the keypress and displays the letter.
4. The CPU resumes the background process at the exact point where it was stopped.

Types of Interrupts (Hardware vs. Software)

Interrupts fall into two main categories: Hardware Interrupts and Software Interrupts.

• Hardware Interrupts: Your machine contains various physical devices, including the keyboard, mouse, storage drive, and Network Interface Card (NIC). When one of these hardware components requests CPU attention, it raises a hardware interrupt.
• Software Interrupts: When an interrupt is triggered by software (such as your OS or a user program), it is a software interrupt.

Software interrupts further break down into two subcategories:

• Normal Software Interrupts: Issued when a user program makes asystem call to request OS services.
• Exceptions: Triggered automatically by runtime errors or exceptional CPU conditions, such as adivide-by-zero error.

Interrupt Mechanism: Legacy Systems vs. Modern Systems

Modern systems rely on an APIC (Advanced Programmable Interrupt Controller) and MSI (Message Signaled Interrupts).

In 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.

The structural difference between a PIC and an APIC is straightforward:

• APIC is a modern, scalable version of the PIC. It handles significantly more interrupts and supportsmulti-core processors .

How 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?

• Legacy Systems (Physical Lines): Dedicated physical lines connected each hardware slot directly to the interrupt controller. Because of these dedicated traces, motherboard slots required additional pins beyond the standard system bus.
• Modern Systems (MSI): There are no dedicated interrupt lines running from hardware slots to the PIC. Instead, devices use the standard system bus. When a hardware device needs to trigger an interrupt, it sends a data packet (amessage ) to a specific memory address. The interrupt controller reads this message and triggers the interrupt for that device.

The fundamental architecture shifted:

• In legacy systems, a hardware device triggered the interrupt over a dedicated physical wire.
• In modern systems, a hardware device notifies the interrupt controller by writing a message to memory.

How to Enable Hardware Interrupts

Since 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.

The 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.

• The Master PIC handles IRQ0 through IRQ7.
• The IRQ2 line on the Master PIC connects directly to theSlave PIC .
• The Slave PIC handles IRQ8 through IRQ15.

Connecting IRQ2 to the Slave PIC yields 15 usable hardware interrupt lines (16 total lines minus the 1 line used for cascading).

When an interrupt occurs on lines IRQ8 through IRQ15:

1. The Slave PIC catches the interrupt and cascades it to theMaster PIC .
2. The Master PIC pulls itsIRQ2 pin high to inform the CPU.
3. The CPU needs to identify the specific interrupt vector so it can execute the correct handler.
4. The CPU transfers data bus control to the Master PIC .
5. Control is handed to the Slave PIC , which writes the exact interrupt number onto the data bus for the CPU to read.

Interrupt Descriptor Tables (IDT)

An 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.

In the x86 architecture, the IDT contains up to 256 entries. This allows you to configure up to 256 distinct interrupt handlers.

Structure of Each Table Entry

Each entry in the table contains the following fields:

typedef struct{
    unsigned short int offset_0;
    unsigned short int selector;
    unsigned char ist;
    unsigned char type_attribute;
    unsigned short int offest_1;
    unsigned int offset_2;
    unsigned int ignore;
} __attribute__ ((packed)) idt_desc_entry_t;

• offsets : These split fields combine to form the full memory address of the interrupt handler function.offset_0 holds the lower 16 bits,offset_1 holds bits 16–31, andoffset_2 holds the upper 32 bits.
• selector: A segment selector referencing theGlobal Descriptor Table (GDT) . It identifies the memory segment containing the handler function. While modern 64-bit OS design rarely uses segmentation, x86 architecture still requires setting this field.
• ist (Interrupt Stack Table): An offset into the Interrupt Stack Table. It provides a dedicated memory stack used during interrupt handling. When the field is set to 0, the CPU switches stack if it is coming from Ring 3 to Ring 0 and stays in the same stack if it already in Ring 0. If it is set to something else, it has to switch stack in any case. If you’re not familiar with Kernel-User isolation (Ring 0 — Ring 3). You can forget the last few sentences until that blog comes out. For now, just know that I’ve set it to 0.
• ignore: 2 bytes of reserved padding at the end of each entry. This field is unused.
• type_attribute: A bitmask containing flags that dictate the descriptor’s characteristics.

                                                                Bit position
                                                                inside the
  7     6       5       4       3       2       1       0   <-- Flags byte
+---+-------+-------+-----------------------------------+
| P |  DPL  |   0   | Gate Type                         |
+---+-------+-------+-----------------------------------+
| 1 | 2-bit | 1-bit |            4-bit                  |   <-- Size

• Gate Type: Defines the behavior upon triggering. For example, anInterrupt Gate (0b1110

  )** automatically disables subsequent interrupts until the current handler finishes. ATrap Gate (**0b1111 *)* does not disable subsequent interrupts while dealing with the current one.

• DPL (Descriptor Privilege Level): Specifies the CPU privilege level required to invoke the vector. Setting this to Ring 3 (0b11 ) allows user-space programs to trigger the interrupt via theINT instruction (e.g., for system calls).
• P (Present Bit): Indicates whether the descriptor is active. Must be set to1 for the vector to be valid.

The LIDT Register

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 {
    unsigned short int limit;
    unsigned long long offset;
} __attribute__ ((packed)) idtr_t;

• offset: The memory address where the IDT array starts. Since it is declared as an array, it is always contiguous in memory.
• limit: The maximum byte length of the table minus 1 (sizeof(IDT) - 1 ).

My Implementation

When an interrupt fires, the CPU hardware automatically pushes state data onto the stack before beginning interrupt handling:

• Stack Segment (SS)
• Stack Pointer (RSP)
• RFLAGS (represents the CPU state at any given point)
• Code Segment (CS)
• Instruction Pointer (RIP)

After this hardware push, whatever happens next is handled entirely by your custom code.

I 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.

Saving Context

Suppose a process is executing on the CPU. While running, the process uses the memory stack and stores temporary data inside CPU general-purpose registers.

Now 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.

To resolve this, we push all general-purpose CPU registers onto the stack. This process is context saving.

Along 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.

The C Handlers

Once 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.

When 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:

%macro SAVE_CONTEXT 0
    push rax
    push rbx
    push rcx
    push rdx
    push rsi
    push rdi
    push rbp
    push r8
    push r9
    push r10
    push r11
    push r12
    push r13
    push r14
    push r15
%endmacro

And here’s the structure of trapframe:

typedef struct trap_frame_t {
    // general purpose registers used by any running process
    uint64_t r15;
    uint64_t r14;
    uint64_t r13;
    uint64_t r12;
    uint64_t r11;
    uint64_t r10;
    uint64_t r9;
    uint64_t r8;
    uint64_t rbp;
    uint64_t rdi;
    uint64_t rsi;
    uint64_t rdx;
    uint64_t rcx;
    uint64_t rbx;
    uint64_t rax;
    uint64_t interrupt_no; // which interrupt triggerd switch
    uint64_t error_code;
    // these are pushed automatically by cpu
    uint64_t rip; //instruction pointer
    uint64_t cs; // code segment
    uint64_t r_flags; // cpu flags
    uint64_t rsp; // stack pointer
    uint64_t ss; // stack segment
} __attribute__((packed)) trap_frame_t;

Restoring Context

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.

%macro RESTORE_CONTEXT 0
    pop r15
    pop r14
    pop r13
    pop r12
    pop r11
    pop r10
    pop r9
    pop r8
    pop rbp
    pop rdi
    pop rsi
    pop rdx
    pop rcx
    pop rbx
    pop rax
%endmacro

The Problem with My Initial Code

In my code, I have registered specific assembly functions as interrupt handlers. However, these were not final handlers; they are placeholders.

%macro ISR_NO_ERR 1
global isr%1
isr%1:
    push 0                  ; Push dummy error code
    push %1                 ; Push interrupt number
    jmp isr_common_stub     ; Jump to the heavy lifting
%endmacro
%macro ISR_ERR 1
global isr%1
isr%1:
    ; Error code is already on stack!
    push %1                 ; Push interrupt number
    jmp isr_common_stub
%endmacro
ISR_NO_ERR 6   ; Invalid Opcode Exception
ISR_ERR    13   ; General protection fault
ISR_ERR    14   ; Page Fault
ISR_NO_ERR 32   ; IRQ0 (Timer) - This is the big one for scheduling!
ISR_NO_ERR 33   ; IRQ1 (Keyboard)
ISR_NO_ERR 128 ; System call
ISR_NO_ERR 43 ; E1000 network card
isr_common_stub:
    ; 1. Save all General Purpose Registers
    SAVE_CONTEXT
    ; 2. Prepare for C Function Call (System V AMD64 ABI)
    ; The first argument (RDI) must contain the pointer to our struct.
    ; RSP points to the top of the stack, which IS the start of our TrapFrame.
    mov rdi, rsp
    ; 3. Call the C Handler
    ; void isr_handler(TrapFrame* frame);
    call isr_handler
    ; 4. Restore Context
    ; If the scheduler switched tasks, RSP will be different now!
    RESTORE_CONTEXT
    ; 5. Cleanup Error Code and Int No
    ; We pushed 2 uint64_t values (16 bytes) manually before SAVE_CONTEXT.
    ; We need to remove them so RSP points to the return address (RIP).
    add rsp, 16 
    ; 6. Return from Interrupt
    ; Pops RIP, CS, RFLAGS, RSP, SS automatically.
    iretq

Why were these placeholders necessary?

When 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.

Every placeholder function performed identical tasks:

1. Pushed its specific interrupt number and error code ( a dummy 0 in case it was not present).
2. Jump to the isr_common_stub function.

The isr_common_stub function then:

1. Performed context saving.
2. Called the common C handler.
3. Performed context restoration.
4. Made the iretq call to signify end of interrupt handling and pop all the data that was pushed to the stack by the CPU automatically.

Suppose 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.

Now, 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.

The Solution

With the knowledge gained from this project, a cleaner architecture emerges.

The assembly placeholders served two functions: capturing the interrupt number and managing register context.

However, 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.

Thanks 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!