Interrupt handler

In computer systems programming, an interrupt handler, also known as an interrupt service routine (ISR), is a special block of code associated with a specific interrupt condition. Interrupt handlers are initiated by hardware interrupts, software interrupt instructions, or software exceptions, and are used for implementing device drivers or transitions between protected modes of operation, such as system calls. The traditional form of interrupt handler is the hardware interrupt handler. Hardware interrupts arise from an electrical trigger. The specifics of how an interrupt is handled depends on the hardware, but generally the CPU pauses execution of its current task, saves current program counter (and often flags) to the stack, and updates its program counter to the address of the routine that is responsible for servicing the interrupt. The interrupt service routine must then save any registers it may change. In general, hardware interrupts and their handlers are used to handle high-priority conditions that require the interruption of the current code the processor is executing. It is convenient for software to be able to trigger the same mechanism: a software interrupt. Rather than using a hard-coded interrupt dispatch table at the hardware level, software interrupts are often implemented at the operating system level as a form of callback function.…

In computer systems programming, an interrupt handler, also known as an interrupt service routine (ISR), is a special block of code associated with a specific interrupt condition. Interrupt handlers are initiated by hardware interrupts, software interrupt instructions, or software exceptions, and are used for implementing device drivers or transitions between protected modes of operation, such as system calls. The traditional form of interrupt handler is the hardware interrupt handler. Hardware interrupts arise from an electrical trigger. The specifics of how an interrupt is handled depends on the hardware, but generally the CPU pauses execution of its current task, saves current program counter (and often flags) to the stack, and updates its program counter to the address of the routine that is responsible for servicing the interrupt. The interrupt service routine must then save any registers it may change. In general, hardware interrupts and their handlers are used to handle high-priority conditions that require the interruption of the current code the processor is executing. It is convenient for software to be able to trigger the same mechanism: a software interrupt. Rather than using a hard-coded interrupt dispatch table at the hardware level, software interrupts are often implemented at the operating system level as a form of callback function. Interrupt handlers have a multitude of functions, which vary based on what triggered the interrupt and the speed at which the interrupt handler completes its task. For example, pressing a key on a computer keyboard, or moving the mouse, triggers interrupts that call interrupt handlers which read the key, or the mouse's position, and copy the associated information into the computer's memory. An interrupt handler is a low-level counterpart of event handlers. However, interrupt handlers have an unusual execution context, many harsh constraints in time and space, and their intrinsically asynchronous nature makes them notoriously difficult to debug by standard practice (reproducible test cases generally don't exist), thus demanding a specialized skillset—an important subset of system programming—of software engineers who engage at the hardware interrupt layer. == Stack space considerations== In a low-level microcontroller, the chip might lack protection modes or lack a memory management unit (MMU). In these chips, the execution context of an interrupt handler will be essentially the same as the interrupted program, which typically runs on a small stack of fixed size (memory resources have traditionally been extremely scant at the low end). Nested interrupts are often provided, which exacerbates stack usage. A primary constraint on the interrupt handler in this programming endeavour is to not exceed the available stack in the worst-case condition, requiring the programmer to reason globally about the stack space requirement of every implemented interrupt handler and application task. When allocated stack space is exceeded (a condition known as a stack overflow), this is not normally detected in hardware by chips of this class. If the stack is exceeded into another writable memory area, the handler will typically work as expected, but the application will fail later (sometimes much later) due to the handler's side effect of memory corruption. If the stack is exceeded into a non-writable (or protected) memory area, the failure will usually occur inside the handler itself (generally the easier case to later debug). In the writable case, one can implement a sentinel stack guard—a fixed value right beyond the end of the legal stack whose value can be overwritten, but never will be if the system operates correctly. It is common to regularly observe corruption of the stack guard with some kind of watch dog mechanism. This will catch the majority of stack overflow conditions at a point in time close to the offending operation. In a multitasking system, each thread of execution will typically have its own stack. If no special system stack is provided for interrupts, interrupts will consume stack space from whatever thread of execution is interrupted. These designs usually contain an MMU, and the user stacks are usually configured such that stack overflow is trapped by the MMU, either as a system error (for debugging) or to remap memory to extend the space available. Memory resources at this level of microcontroller are typically far less constrained, so that stacks can be allocated with a generous safety margin. In systems supporting high thread counts, it is better if the hardware interrupt mechanism switches the stack to a special system stack, so that none of the thread stacks need account for worst-case nested interrupt usage. Tiny CPUs as far back as the 8-bit Motorola 6809 from 1978 have provided separate system and user stack pointers.

Text derived from https://en.wikipedia.org/w/index.php?oldid=1367008534 under CC BY-SA 4.0; modifications have been made.