Editing Interrupt (section)

==Types==
[[File:2 types of interrupts in operating system.jpg|thumb]]
Interrupt signals may be issued in response to [[computer hardware|hardware]] or [[software]] events. These are classified as '''hardware interrupts''' or '''software interrupts''', respectively. For any particular processor, the number of interrupt types is limited by the architecture.
<!-- IRQ lines do not exist in all architectures. -->

===Hardware interrupts===
A hardware interrupt is a condition related to the state of the hardware that may be signaled by an external hardware device, e.g., an [[interrupt request]] (IRQ) line on a PC, or detected by devices embedded in processor logic (e.g., the CPU timer in IBM System/370), to communicate that the device needs attention from the [[operating system]] (OS)<ref>{{cite web|url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Reference_Guide/chap-Realtime_Reference_Guide-Hardware_interrupts.html |title=Hardware interrupts |access-date=2014-02-09}}</ref> or, if there is no OS, from the [[bare metal]] program running on the CPU. Such external devices may be part of the computer (e.g., [[disk controller]]) or they may be external [[peripheral]]s. For example, pressing a [[Keyboard (computing)|keyboard]] key or moving a [[Mouse (computing)|mouse]] plugged into a [[PS/2 port]] triggers hardware interrupts that cause the processor to read the keystroke or mouse position.

Hardware interrupts can arrive [[asynchronous communication|asynchronous]]ly with respect to the processor clock, and at any time during instruction execution. Consequently, all incoming hardware interrupt signals are conditioned by synchronizing them to the processor clock, and acted upon only at instruction execution boundaries.

In many systems, each device is associated with a particular IRQ signal. This makes it possible to quickly determine which hardware device is requesting service, and to expedite servicing of that device.

On some older systems, such as the 1964 [[CDC 3600]],<ref>{{cite book
 |     title = Control Data 3600 Computer System Reference Manual
 |        id = 60021300
 |   section = Interrupt Instructions
 |      pages = 4–6
 |      date = July 1964
 |       url = http://bitsavers.org/pdf/cdc/3x00/48bit/3600/60021300E_3600_SysRef_Sep64.pdf
 | publisher = Control Data Corporation
 }}
</ref> all interrupts went to the same location, and the OS used a specialized instruction to determine the highest-priority outstanding unmasked interrupt. On contemporary systems, there is generally a distinct interrupt routine for each type of interrupt (or for each interrupt source), often implemented as one or more [[interrupt vector table]]s.

====Masking====
To ''mask'' an interrupt is to disable it, so it is deferred{{efn|Typically, interrupt events associated with I/O remain pending until the interrupt is enabled or explicitly cleared, e.g., by the '''Test Pending Interruption''' ('''TPI''') instruction of [[IBM System/370-XA]] and later.}} or ignored{{efn|E.g., when program mask bits on the [[IBM System/360]] are 0 (disabled), the corresponding overflow and significance events do not result in a pending interrupt.}} by the processor, while to ''unmask'' an interrupt is to enable it.<ref>{{cite book|first=Ying|last=Bai|year=2017|page=21|publisher=CRC Press|url=https://books.google.com/books?id=TDENDgAAQBAJ&pg=PA21|title=Microcontroller Engineering with MSP432: Fundamentals and Applications|isbn=978-1-4987-7298-3|lccn=2016020120|quote=In Cortex-M4 system, the interrupts and exceptions have the following properties: ... Generally, a single bit in a mask register is used to mask (disable) or unmask (enable) certain interrupt/exceptions to occur}}</ref>

Processors typically have an internal ''interrupt mask'' register,{{efn|The mask register may be a single register or multiple registers, e.g., bits in the [[Program status word|PSW]] and other bits in [[control register]]s.}} which allows selective enabling<ref name=":0" /> (and disabling) of hardware interrupts. Each interrupt signal is associated with a bit in the mask register. On some systems, the interrupt is enabled when the bit is set, and disabled when the bit is clear. On others, the reverse is true, and a set bit disables the interrupt. When the interrupt is disabled, the associated interrupt signal may be ignored by the processor, or it may remain pending. Signals which are affected by the mask are called ''maskable interrupts''.

Some interrupt signals are not affected by the interrupt mask and therefore cannot be disabled; these are called ''[[non-maskable interrupt]]s'' (NMIs). These indicate high-priority events which cannot be ignored under any circumstances, such as the timeout signal from a [[watchdog timer]]. With regard to [[SPARC]], the Non-Maskable Interrupt (NMI), despite having the highest priority among interrupts, can be prevented from occurring through the use of an interrupt mask.<ref>{{cite web |url=https://docs.rtems.org/releases/rtems-4.11.2/cpu-supplement/sparc.html#interrupt-levels |title=Interrupt Levels |access-date=2023-11-17}}</ref>

====Missing interrupts====
One failure mode is when the hardware does not generate the expected interrupt for a change in state, causing the operating system to wait indefinitely. Depending on the details, the failure might affect only a single process or might have global impact. Some operating systems have code specifically to deal with this.

As an example, IBM [[OS/360 and successors|Operating System/360]] (OS/360) relies on a not-ready to ready device-end interrupt when a tape has been mounted on a tape drive, and will not read the tape label until that interrupt occurs or is simulated. IBM added code in OS/360 so that the VARY ONLINE command will simulate a device end interrupt on the target device.

====Spurious interrupts====
A ''spurious interrupt'' is a hardware interrupt for which no source can be found.  The term "phantom interrupt" or "ghost interrupt" may also be used to describe this phenomenon.  Spurious interrupts tend to be a problem with a [[wired-OR]] interrupt circuit attached to a level-sensitive processor input.  Such interrupts may be difficult to identify when a system misbehaves.

In a wired-OR circuit, [[parasitic capacitance]] charging/discharging through the interrupt line's bias resistor will cause a small delay before the processor recognizes that the interrupt source has been cleared.  If the interrupting device is cleared too late in the interrupt service routine (ISR), there will not be enough time for the interrupt circuit to return to the quiescent state before the current instance of the ISR terminates.  The result is the processor will think another interrupt is pending, since the voltage at its interrupt request input will be not high or low enough to establish an unambiguous internal logic 1 or logic 0.  The apparent interrupt will have no identifiable source, hence the "spurious" moniker.

A spurious interrupt may also be the result of electrical [[glitch|anomalies]] due to faulty circuit design, high [[electrical interference|noise]] levels, [[crosstalk]], timing issues, or more rarely, [[Erratum#CPU logic|device errata]].<ref name="RT_concepts">{{cite book |last1=Li |first1=Qing |last2=Yao |first2=Caroline |title=Real-Time Concepts for Embedded Systems |date=2003 |publisher=CRC Press |isbn=1482280825 |page=163}}</ref>

A spurious interrupt may result in system deadlock or other undefined operation if the ISR does not account for the possibility of such an interrupt occurring.  As spurious interrupts are mostly a problem with wired-OR interrupt circuits, good programming practice in such systems is for the ISR to check all interrupt sources for activity and take no action (other than possibly logging the event) if none of the sources is interrupting.

===Software interrupts===
A software interrupt is requested by the processor itself upon executing particular instructions or when certain conditions are met. Every software interrupt signal is associated with a particular interrupt handler.

A software interrupt may be intentionally caused by executing a special [[instruction (computer science)|instruction]] which, by design, invokes an interrupt when executed.{{efn|See [[INT (x86 instruction)]]}} Such instructions function similarly to [[subroutine call]]s and are used for a variety of purposes, such as requesting operating system services and interacting with [[device driver]]s (e.g., to read or write storage media). Software interrupts may also be triggered by program execution errors or by the [[virtual memory]] system.

Typically, the operating system [[Kernel (operating system)|kernel]] will catch and handle such interrupts. Some interrupts are handled transparently to the program - for example, the normal resolution of a [[page fault]] is to make the required page accessible in physical memory. But in other cases such as a [[segmentation fault]] the operating system executes a process callback. On [[Unix-like]] [[operating system]]s this involves sending a [[Signal (IPC)|signal]] such as [[SIGSEGV]], [[SIGBUS]], [[SIGILL]] or [[SIGFPE]], which may either call a signal handler or execute a default action (terminating the program). On Windows the callback is made using [[Structured Exception Handling]] with an exception code such as STATUS_ACCESS_VIOLATION or STATUS_INTEGER_DIVIDE_BY_ZERO.<ref>{{cite web |title=Hardware exceptions |url=https://docs.microsoft.com/en-us/cpp/cpp/hardware-exceptions?view=msvc-170 |website=docs.microsoft.com |language=en-us |date=3 August 2021}}</ref>

In a kernel [[process (computing)|process]], it is often the case that some types of software interrupts are not supposed to happen. If they occur nonetheless, an [[Crash (computing)#Operating system crashes|operating system crash]] may result.

===Terminology===
{{Further|Exception handling#Definition}}

The terms ''interrupt'', ''trap'', ''exception'', ''fault'', and ''abort'' are used to distinguish types of interrupts, although "there is no clear consensus as to the exact meaning of these terms".<ref name="Hyde_1996">{{cite book |last1=Hyde |first1=Randall |chapter-url=https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |access-date=22 December 2021|date=1996|title=The Art Of Assembly Language Programming |chapter=Chapter Seventeen: Interrupts, Traps and Exceptions (Part 1) |quote=The concept of an interrupt is something that has expanded in scope over the years. The 80x86 family has only added to the confusion surrounding interrupts by introducing the int (software interrupt) instruction. Indeed different manufacturers have used terms like exceptions faults aborts traps and interrupts to describe the phenomena this chapter discusses. Unfortunately there is no clear consensus as to the exact meaning of these terms. Different authors adopt different terms to their own use.}}</ref> The term ''trap'' may refer to any interrupt, to any software interrupt, to any synchronous software interrupt, or only to interrupts caused by instructions with ''trap'' in their names. In some usages, the term ''trap'' refers specifically to a [[breakpoint]] intended to initiate a [[context switch]] to a [[profiler (computer science)|monitor program]] or [[debugger]].<ref name="Jargon_2003"/> It may also refer to a synchronous interrupt caused by an exceptional condition (e.g., [[division by zero]], [[segmentation fault|invalid memory access]], [[illegal opcode]]),<ref name="Hyde_1996"/> although the term ''exception'' is more common for this.

[[x86]] divides interrupts into (hardware) ''interrupts'' and software ''exceptions'', and identifies three types of exceptions: faults, traps, and aborts.<ref name=Intel1/><ref name=Bryant>{{cite book |last1=Bryant |first1=Randal E. |last2=O’Hallaron |first2=David R. |title=Computer systems: a programmer's perspective |date=2016 |location=Harlow |isbn=978-1-292-10176-7 |edition=Third, Global |chapter=8.1.2 Classes of exceptions |publisher=Pearson}}</ref> (Hardware) interrupts are interrupts triggered asynchronously by an I/O device, and allow the program to be restarted with no loss of continuity.<ref name="Intel1">{{cite web |title=Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 1: Basic Architecture |url=https://www.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-software-developers-manual-volume-1-basic-architecture.html |access-date=22 December 2021 |pages=6–12 Vol. 1}}</ref> A fault is restartable as well but is tied to the synchronous execution of an instruction - the return address points to the faulting instruction. A trap is similar to a fault except that the return address points to the instruction to be executed after the trapping instruction;<ref name=Intel3/> one prominent use is to implement [[system call]]s.<ref name=Bryant/> An abort is used for severe errors, such as hardware errors and illegal values in system tables, and often{{efn|Some operating systems can recover from severe errors, e.g., paging in a page from a paging file after an uncorrectable ECC error in an unaltered page.}} does not allow a restart of the program.<ref name=Intel3>{{cite web |title=Intel® 64 and IA-32 architectures software developer's manual volume 3A: System programming guide, part 1 |url=https://www.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-volume-3a-system-programming-guide-part-1.html |access-date=22 December 2021 |page=6-5 Vol. 3A}}</ref>

[[ARM architecture family|Arm]] uses the term ''exception'' to refer to all types of interrupts,<ref>{{cite web |title=Exception Handling |url=https://developer.arm.com/documentation/den0013/d/Exception-Handling?lang=en |website=developer.arm.com |publisher=ARM Cortex-A Series Programmer's Guide for ARMv7-A |access-date=21 January 2022}}</ref> and divides exceptions into (hardware) ''interrupts'', ''aborts'', ''reset'', and exception-generating instructions. Aborts correspond to x86 exceptions and may be prefetch aborts (failed instruction fetches) or data aborts (failed data accesses), and may be synchronous or asynchronous. Asynchronous aborts may be precise or imprecise. MMU aborts (page faults) are synchronous.<ref name="ARM">{{cite web |title=Types of exception |url=https://developer.arm.com/documentation/den0013/d/Exception-Handling/Types-of-exception?lang=en |website=developer.arm.com |publisher=ARM Cortex-A Series Programmer's Guide for ARMv7-A |access-date=22 December 2021}}</ref>

[[RISC-V]] uses interrupt as the overall term as well as for the external subset; internal interrupts are called exceptions.