Read the original article here.

---

Understanding Interrupt Handlers (ISRs): A Key Component in Building a Computer from Scratch

When building a computer system, one of the fundamental challenges is allowing the CPU to react to events happening in the outside world or within the system itself without constantly checking every single device. This is where interrupts and their associated interrupt handlers come into play. They provide a mechanism for hardware and software to signal the CPU asynchronously, demanding immediate attention and allowing the CPU to pause its current task to address a high-priority condition.

Interrupt Handler (or Interrupt Service Routine - ISR): A special block of code associated with a specific interrupt condition. This code is executed by the CPU when the corresponding interrupt occurs.

In essence, the interrupt handler is the CPU's designated "emergency response team" for a particular type of event.

What Triggers an Interrupt Handler?

Interrupt handlers can be initiated by various sources, broadly categorized as:

1. Hardware Interrupts: Signals originating from physical devices (like a keyboard, mouse, disk controller, timer chip, network card) or internal CPU events (like a power failure notification).
2. Software Interrupts: Instructions explicitly executed by a running program to trigger an interrupt mechanism.
3. Software Exceptions: CPU-detected conditions arising from executing an instruction, such as attempting to divide by zero, accessing invalid memory, or executing an illegal instruction. While often handled similarly to interrupts, they are synchronous to the offending instruction, not asynchronous events.

The Fundamental Difference: Hardware vs. Software Interrupts

Understanding the distinction between hardware and software interrupts is crucial when designing and building a system:

• Hardware Interrupts:

  • Trigger: Generated by electrical signals or low-level digital logic protocols from peripheral devices or the CPU itself.
  • Dispatch: Traditionally dispatched via a hard-coded table of interrupt vectors. The interrupt signal causes the CPU to look up the address of the corresponding handler in this table (the Interrupt Vector Table - IVT) and jump to that address.
  • Synchronicity: Asynchronous. They can occur at any time, interrupting the normal flow of execution, independent of the instruction currently being executed.
  • Execution Context: Often involve automatic transitions to a different, typically higher, privilege level (like kernel or supervisor mode) and may use a separate stack provided for interrupt handling.
  • Primary Use: Handling real-time device events, I/O completion, timer ticks, and other external conditions requiring prompt attention.

• Software Interrupts:

  • Trigger: Initiated by a specific CPU instruction (e.g., INT on x86 processors).
  • Dispatch: Synchronous. They occur precisely when the interrupt instruction is executed. While they might use the same vector table mechanism as hardware interrupts on some architectures, they are often implemented at the operating system level as a form of callback function invoked by the interrupt instruction.
  • Synchronicity: Synchronous. The interrupt occurs as a direct result of executing the instruction.
  • Execution Context: May also involve a privilege level transition, particularly when used for system calls.
  • Primary Use: Implementing system calls (requests from user programs to the operating system kernel for privileged operations) or providing a standardized way for software components to communicate or signal conditions.

Interrupt Vector Table (IVT): A data structure, typically residing at a fixed memory location, containing the memory addresses of the interrupt handlers (ISRs) for various interrupt types or sources. When an interrupt occurs, the CPU uses the interrupt's vector number (an index) to find the address of the corresponding ISR in this table and then transfers control to that address.

The Role of the Interrupt Handler Code

The core function of an interrupt handler is to service the condition that caused the interrupt and then return control to the interrupted program. What "servicing" entails depends entirely on the interrupt source:

• Device Handling: For a keyboard interrupt, the handler reads the key code from the keyboard controller's data register and copies it into a buffer in memory. For a mouse, it reads the position data. For a disk drive completion, it might update status flags or transfer a block of data.
• System Calls: For a software interrupt triggering a system call, the handler examines parameters passed by the calling program (often in CPU registers) and executes the requested operating system service (like opening a file or allocating memory).
• Timer Interrupts: A timer interrupt handler might increment a system clock counter and trigger the operating system's scheduler to decide which process runs next.

Interrupt handlers are the low-level counterparts of event handlers in higher-level programming (like GUI events). However, their execution environment is highly constrained, making them uniquely challenging to write and debug.

Execution Context and Privilege Levels

When an interrupt occurs, the CPU must switch from the current task to execute the interrupt handler. This switch involves saving the state (context) of the interrupted task (registers, program counter, flags) so it can be resumed later.

In modern systems with privilege levels (like user mode and kernel mode), hardware interrupts often automatically force the CPU into the highest privilege level upon entering the handler.

Privilege Level: A mode of operation for the CPU that defines the set of instructions and resources (like memory areas or hardware registers) that the currently executing code is allowed to access. Higher privilege levels (e.g., kernel/supervisor mode) have more access than lower levels (e.g., user mode). Interrupt handlers often execute at a high privilege level to interact directly with hardware.

This elevated privilege is necessary because interrupt handlers frequently need to access hardware registers of peripheral devices to acknowledge the interrupt, read/write data, or configure the device.

For performance reasons, in many operating systems, the initial part of a hardware interrupt handler runs using the memory context (e.g., the memory mappings defined by the Memory Management Unit) of the interrupted process. While the privilege level is elevated, the memory layout might still be tied to the user process that was running. This can be subtle, as the handler has no inherent connection to that specific process; it merely "borrowed" its execution time and memory context.

Stack Space Considerations

The stack is a vital area of memory used for storing local variables, function call parameters, and return addresses. Interrupt handlers, being pieces of code that are "called" asynchronously, also need stack space. How this stack is managed is a critical design decision, especially in resource-constrained or complex systems.

Stack: A region of memory used by a program to store temporary data, such as function local variables, return addresses for function calls, and parameters passed between functions. Data is added (pushed) and removed (popped) in a Last-In, First-Out (LIFO) manner.

Stack Overflow: A condition that occurs when a program attempts to use more space on the call stack than has been allocated, leading to it writing data into adjacent memory regions.

Consider these scenarios when building a system:

1. Simple Microcontrollers (No MMU, No Protection):

   • Often, the interrupt handler uses the same stack as the interrupted program.
   • Stacks might be of a fixed, small size due to limited memory.
   • Nested Interrupts (a higher-priority interrupt occurring while a lower-priority one is being handled) consume additional stack space from the same pool.
   • Danger: It's easy to exceed the allocated stack space (stack overflow). On these simple chips, this often goes undetected by hardware. If the overflow writes into another writable memory area, the system might appear to work for a while, only to fail later due to the corrupted data. If it writes into read-only memory or an invalid address, the failure might happen immediately within the handler, which is paradoxically easier to debug.
   • Mitigation (Manual): Programmers must carefully calculate the worst-case stack usage for all possible interrupt handlers and application tasks combined to ensure the stack is large enough.
   • Debugging Aid: A sentinel stack guard can be implemented. This involves placing a known, fixed value just beyond the end of the allocated stack. A watchdog mechanism can periodically check if this value has been overwritten, indicating a stack overflow has occurred relatively recently.

2. Multitasking Systems (with MMU):

   • Each thread or process typically has its own stack.
   • The Memory Management Unit (MMU) can be configured to detect stack overflows. If a stack operation attempts to write beyond the allocated stack region, the MMU can trigger a hardware fault (like a page fault), which the OS can catch. This might lead to a process crash (useful for debugging) or, in sophisticated systems, trigger a mechanism to automatically extend the stack space.
   • Memory resources are usually more abundant, allowing for larger, more generous stack allocations.

3. Systems with a Special System Stack:

   • Some CPU architectures and operating systems provide a dedicated stack specifically for interrupt handling.
   • When an interrupt occurs, the hardware automatically switches to this system stack before executing the handler.
   • Advantage: This simplifies stack management significantly. The stack for each user thread/process no longer needs to be large enough to accommodate the worst-case scenario of nested interrupts occurring while that specific thread is running. Only the system stack needs to be sized for worst-case interrupt nesting.
   • Historically, even relatively simple CPUs like the 8-bit Motorola 6809 (from 1978) offered separate system and user stack pointers, demonstrating the long-recognized value of this approach.

Choosing the stack management strategy is a critical design decision when building your CPU architecture and operating system layer.

Constraints: Time, Concurrency, and Debugging

Interrupt handlers operate under severe constraints that make them notoriously difficult to write correctly:

• Time Constraints: Handlers should be as brief as possible. This is because:
  • Often, during critical sections of interrupt processing (like acknowledging the hardware source), other interrupts might be temporarily masked (disabled) by the CPU. Prolonged masking can lead to missed events or increased latency for other devices.
  • Long-running handlers increase jitter – the variation in the timing of scheduled tasks or other interrupts. This is particularly problematic in real-time systems that require predictable response times.
• Concurrency Issues:
  • In systems with multiple CPU cores, multiple interrupts (even of the same type) could potentially be handled simultaneously by different cores, leading to reentrancy issues if the handler code or the data it accesses is not designed to be safely executed concurrently.
  • With hardware DMA (Direct Memory Access) engines, a peripheral device can access memory directly without CPU intervention. If an interrupt handler is also accessing that same memory region (or control registers related to the DMA), careful synchronization is needed to avoid data corruption.

    Reentrancy: A property of code that allows it to be safely interrupted during its execution and then called again (re-entered) by another task or interrupt handler without causing data corruption or unexpected behavior. Interrupt handlers must be reentrant if higher-priority interrupts can occur or if they can be run concurrently on multiple cores. Direct Memory Access (DMA): A feature of computer systems that allows certain hardware subsystems (like disk controllers, network cards) to access system memory independently of the central processing unit (CPU). This is typically used for high-speed data transfer operations.

• Debugging Difficulty: The asynchronous nature of interrupts makes bugs notoriously hard to reproduce. An error might only occur under specific, rare timing interactions between the interrupt and the interrupted code, or between multiple interrupts. Standard debugging techniques (like setting breakpoints) can significantly alter the timing and mask the problem. This demands specialized skills and tools.

Managing Interrupts: Flags and Quenching

A critical part of writing an interrupt handler involves managing interrupt flags and acknowledging the source.

When an interrupt occurs, the CPU typically handles the initial entry into the handler, often automatically disabling further interrupts (at least globally, or for equal/lower priorities) to prevent immediate preemption during the initial state saving.

Inside the handler, a common sequence is:

1. Save Minimal Context: Store necessary CPU registers that the handler will modify.
2. Acknowledge Source / Quench: This is paramount. The handler must interact with the hardware device that triggered the interrupt to clear the interrupt pending status in the device's control registers. This tells the device (and the interrupt controller) that the interrupt has been recognized. If this step is missed, the device will often keep the interrupt line asserted, causing the interrupt to trigger again the moment interrupts are re-enabled upon exiting the handler, leading to an infinite loop or system crash.

   Quenching (Interrupt Acknowledgment): The process by which an interrupt handler interacts with the interrupting hardware device (typically by writing to a specific register) to clear the interrupt condition flag within the device. This signals to the interrupt controller and the device itself that the interrupt has been serviced and prevents the same interrupt from immediately re-triggering the handler.

3. Re-enable Higher Priority Interrupts (Optional but common): If the system supports nested interrupts and interrupt priorities, the handler might re-enable interrupts above its own priority level relatively early, minimizing the time those higher-priority interrupts are blocked. Global interrupt re-enable is often delayed until more critical work or quenching is done.
4. Perform Service Task: Do the necessary work (read data, update status, etc.).
5. Restore Context: Restore the CPU registers saved in step 1.
6. Return: Execute a special instruction (like IRET or RETFIE) that restores the saved program counter and flags (including the interrupt enable flag, if applicable) and returns control to the interrupted code.

Exiting the handler correctly, ensuring interrupts are in the proper state (masked/unmasked) and the source is quenched, is critical. Errors here can lead to subtle, intermittent bugs that are difficult to diagnose and can halt the system.

Modern Technique: Divided Handlers (Front-half/Back-half)

To address the constraints on interrupt handlers (especially the need to be fast and avoid blocking), modern operating systems and complex embedded systems often divide the work into two parts:

1. First-Level Interrupt Handler (FLIH): Also known as the hard interrupt handler or fast interrupt handler.

   • This is the code that runs immediately upon the interrupt occurring.
   • It executes in a highly restricted context (often with interrupts masked, potentially using a special interrupt stack).
   • Its primary job is to do the absolute minimum necessary to service the hardware quickly:
     • Acknowledge (quench) the interrupt source in the hardware.
     • Save any critical, time-sensitive data from the hardware (e.g., emptying a small data buffer before it overflows).
     • Schedule the "back-half" processing to happen later.
   • It must complete very quickly to minimize interrupt latency and the duration of interrupt masking.
   • An FLIH that re-enables its own interrupt level before completing is called reentrant; this is generally avoided as it can lead to stack overflows if the same interrupt re-triggers repeatedly.

2. Second-Level Interrupt Handler (SLIH): Also known as the soft interrupt handler or slow interrupt handler. In Windows, a similar concept is called a Deferred Procedure Call (DPC). In Linux, FLIHs are sometimes called the "upper half," and SLIHs the "lower half" or "bottom half."

   • This is the code that performs the bulk of the interrupt-related processing.
   • It is scheduled for execution by the FLIH, typically at a lower priority than the FLIH itself.
   • It runs in a less constrained environment, often in the context of a dedicated kernel thread or a pool of worker threads.
   • It can take longer to execute, can perform operations that might block (like waiting for memory allocation or other resources), and has access to the full range of operating system services.
   • Its job is to complete the logical operation of the interrupt, such as processing the data read by the FLIH, waking up a waiting process, or performing complex error handling.

The division between FLIH and SLIH allows the system to achieve low interrupt latency (by doing the time-critical work in the FLIH) while deferring the longer, more complex processing to a more suitable execution context where it won't block other interrupts.

Conclusion

Interrupt handlers are a cornerstone of modern computer architecture, enabling responsiveness and efficient device interaction. When building a computer system from scratch, understanding how interrupts are triggered, how the CPU finds and executes the handler, the constraints under which handlers operate (especially concerning stack usage, time, and concurrency), and techniques like quenching and divided handlers is absolutely essential. Mastering the "art" of writing correct, efficient, and robust interrupt handlers is a challenging but rewarding part of low-level system programming.

---