Interrupt: Difference between revisions

Line 1:

{{Short description|Signal to a computer processor emitted by hardware or software}}

{{About|computer interrupts conceptually|interrupts on the PC architecture|Interrupt request (PC architecture)|other uses|Interruption (disambiguation){{!}}Interruption}}

~~{{More citations needed|date=February 2014}}~~

[[File:Interrupt.svg|thumb|350 px|Taxonomy of a simple interrupt]]

Line 75:

Line 74:

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 |access-date=21 January 2022 |archive-date=22 December 2021 |archive-url=https://web.archive.org/web/20211222210302/https://docs.microsoft.com/en-us/cpp/cpp/hardware-exceptions?view=msvc-170 |url-status=live }}</ref>

Typically, the operating system [[Kernel (operating system)|kernel]] will catch and handle software 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 |access-date=21 January 2022 |archive-date=22 December 2021 |archive-url=https://web.archive.org/web/20211222210302/https://docs.microsoft.com/en-us/cpp/cpp/hardware-exceptions?view=msvc-170 |url-status=live }}</ref> Intentional software interrupts for [[system call]]s result in calls to routines in the kernel to perform the function requested by the system call.

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.

Line 86:

Line 85:

[[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>

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

Line 151:

Line 150:

==System implementation==

~~{{POV section|talk=NPOV - PC centric|date=January 2022}}~~

Interrupts may be fully handled in hardware by the CPU, or may be handled by both the CPU and another component such as a [[programmable interrupt controller]] or a [[southbridge (computing)|southbridge]].

Line 159:

Line 157:

In [[system on a chip|systems on a chip]] (SoC) implementations, interrupts come from different blocks of the chip and are usually aggregated in an interrupt controller attached to one or several processors (in a multi-core system).<ref>{{Citation |last=Yiu |first=Joseph |title=CHAPTER 2 - Overview of the Cortex-M3 |date=2010-01-01 |url=https://www.sciencedirect.com/science/article/pii/B9781856179638000053 |work=The Definitive Guide to the ARM Cortex-M3 (Second Edition) |pages=11–24 |editor-last=Yiu |editor-first=Joseph |access-date=2023-10-11 |place=Oxford |publisher=Newnes |doi=10.1016/b978-1-85617-963-8.00005-3 |isbn=978-1-85617-963-8|url-access=subscription }}</ref>

===Shared ~~IRQs~~===

===Shared interrupt lines===

~~{{POV section|date=December 2021}}~~

Multiple devices may share an edge-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven it settles to its inactive state, which is the default state of it. Devices signal an interrupt by briefly driving the line to its non-default state, and let the line float (do not actively drive it) when not signaling an interrupt. This type of connection is also referred to as [[open collector]]. The line then carries all the pulses generated by all the devices. (This is analogous to the [[pull cord]] on some buses and trolleys that any passenger can pull to signal the driver that they are requesting a stop.) However, interrupt pulses from different devices may merge if they occur close in time. To avoid losing interrupts the CPU must trigger on the trailing edge of the pulse (e.g. the rising edge if the line is pulled up and driven low). After detecting an interrupt the CPU must check all the devices for service requirements.

Line 258:

Line 255:

Hardware timers are often used to generate periodic interrupts. In some applications, such interrupts are counted by the interrupt handler to keep track of absolute or elapsed time, or used by the OS task [[Scheduling (computing)|scheduler]] to manage execution of running [[process (computing)|processes]], or both. Periodic interrupts are also commonly used to invoke sampling from input devices such as [[analog-to-digital converter]]s, [[incremental encoder interface]]s, and [[GPIO]] inputs, and to program output devices such as [[digital-to-analog converter]]s, [[motor controller]]s, [[multiplexed display]]s, and GPIO outputs.

{{anchor|Disk interrupt}}A disk interrupt signals the completion of a data transfer from or to the disk peripheral; this may cause a process to run which is waiting to read or write. A power-off interrupt predicts imminent loss of power, allowing the computer to perform an orderly shut-down while there still remains enough power to do so. Keyboard interrupts typically cause [[keystrokes]] to be buffered so as to implement [[typeahead]].

{{anchor|Disk interrupt}}A disk interrupt signals the completion of a data transfer from or to the disk peripheral; this may cause a process to run which is waiting to read or write. A power-off interrupt predicts imminent loss of power, allowing the computer to perform an orderly shut-down while there still remains enough power to do so. Keyboard interrupts typically cause [[Typing|keystrokes]] to be buffered so as to implement [[typeahead]].

Interrupts are sometimes used to emulate instructions which are unimplemented on some computers in a product family.<ref>{{cite book

Line 306:

Line 303:

*[http://stanislavs.org/helppc/int_table.html IBM PC Interrupt Table]

*[https://web.archive.org/web/20120313195304/http://ugweb.cs.ualberta.ca/~c296/Arduino-UofA/ConcreteComputing/section/interrupts.htm University of Alberta CMPUT 296 Concrete Computing Notes on Interrupts], archived from the original on March 13, 2012

*[https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 Arduino Pin change Interrupts] - Article by Adityapratap Singh

*[https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 Arduino Pin change Interrupts] {{Webarchive|url=https://web.archive.org/web/20230131163438/https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 |date=2023-01-31 }} - Article by Adityapratap Singh

@@ Line 1: / Line 1: @@
 {{Short description|Signal to a computer processor emitted by hardware or software}}
 {{About|computer interrupts conceptually|interrupts on the PC architecture|Interrupt request (PC architecture)|other uses|Interruption (disambiguation){{!}}Interruption}}
-{{More citations needed|date=February 2014}}
 {{OS}}
 [[File:Interrupt.svg|thumb|350 px|Taxonomy of a simple interrupt]]
@@ Line 75: / Line 74: @@
 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 |access-date=21 January 2022 |archive-date=22 December 2021 |archive-url=https://web.archive.org/web/20211222210302/https://docs.microsoft.com/en-us/cpp/cpp/hardware-exceptions?view=msvc-170 |url-status=live }}</ref>
+Typically, the operating system [[Kernel (operating system)|kernel]] will catch and handle software 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 |access-date=21 January 2022 |archive-date=22 December 2021 |archive-url=https://web.archive.org/web/20211222210302/https://docs.microsoft.com/en-us/cpp/cpp/hardware-exceptions?view=msvc-170 |url-status=live }}</ref> Intentional software interrupts for [[system call]]s result in calls to routines in the kernel to perform the function requested by the system call.
 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.
@@ Line 86: / Line 85: @@
 [[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>
+[[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.
@@ Line 151: / Line 150: @@
 ==System implementation==
-{{POV section|talk=NPOV - PC centric|date=January 2022}}
 Interrupts may be fully handled in hardware by the CPU, or may be handled by both the CPU and another component such as a [[programmable interrupt controller]] or a [[southbridge (computing)|southbridge]].
@@ Line 159: / Line 157: @@
 In [[system on a chip|systems on a chip]] (SoC) implementations, interrupts come from different blocks of the chip and are usually aggregated in an interrupt controller attached to one or several processors (in a multi-core system).<ref>{{Citation |last=Yiu |first=Joseph |title=CHAPTER 2 - Overview of the Cortex-M3 |date=2010-01-01 |url=https://www.sciencedirect.com/science/article/pii/B9781856179638000053 |work=The Definitive Guide to the ARM Cortex-M3 (Second Edition) |pages=11–24 |editor-last=Yiu |editor-first=Joseph |access-date=2023-10-11 |place=Oxford |publisher=Newnes |doi=10.1016/b978-1-85617-963-8.00005-3 |isbn=978-1-85617-963-8|url-access=subscription }}</ref>
-===Shared IRQs===
+===Shared interrupt lines===
-{{POV section|date=December 2021}}
 Multiple devices may share an edge-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven it settles to its inactive state, which is the default state of it. Devices signal an interrupt by briefly driving the line to its non-default state, and let the line float (do not actively drive it) when not signaling an interrupt. This type of connection is also referred to as [[open collector]]. The line then carries all the pulses generated by all the devices. (This is analogous to the [[pull cord]] on some buses and trolleys that any passenger can pull to signal the driver that they are requesting a stop.) However, interrupt pulses from different devices may merge if they occur close in time. To avoid losing interrupts the CPU must trigger on the trailing edge of the pulse (e.g. the rising edge if the line is pulled up and driven low). After detecting an interrupt the CPU must check all the devices for service requirements.
@@ Line 258: / Line 255: @@
 Hardware timers are often used to generate periodic interrupts. In some applications, such interrupts are counted by the interrupt handler to keep track of absolute or elapsed time, or used by the OS task [[Scheduling (computing)|scheduler]] to manage execution of running [[process (computing)|processes]], or both. Periodic interrupts are also commonly used to invoke sampling from input devices such as [[analog-to-digital converter]]s, [[incremental encoder interface]]s, and [[GPIO]] inputs, and to program output devices such as [[digital-to-analog converter]]s, [[motor controller]]s, [[multiplexed display]]s, and GPIO outputs.
-{{anchor|Disk interrupt}}A disk interrupt signals the completion of a data transfer from or to the disk peripheral; this may cause a process to run which is waiting to read or write. A power-off interrupt predicts imminent loss of power, allowing the computer to perform an orderly shut-down while there still remains enough power to do so. Keyboard interrupts typically cause [[keystrokes]] to be buffered so as to implement [[typeahead]].
+{{anchor|Disk interrupt}}A disk interrupt signals the completion of a data transfer from or to the disk peripheral; this may cause a process to run which is waiting to read or write. A power-off interrupt predicts imminent loss of power, allowing the computer to perform an orderly shut-down while there still remains enough power to do so. Keyboard interrupts typically cause [[Typing|keystrokes]] to be buffered so as to implement [[typeahead]].
 Interrupts are sometimes used to emulate instructions which are unimplemented on some computers in a product family.<ref>{{cite book
@@ Line 306: / Line 303: @@
 *[http://stanislavs.org/helppc/int_table.html IBM PC Interrupt Table]
 *[https://web.archive.org/web/20120313195304/http://ugweb.cs.ualberta.ca/~c296/Arduino-UofA/ConcreteComputing/section/interrupts.htm University of Alberta CMPUT 296 Concrete Computing Notes on Interrupts], archived from the original on March 13, 2012
-*[https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 Arduino Pin change Interrupts] - Article by Adityapratap Singh
+*[https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 Arduino Pin change Interrupts] {{Webarchive|url=https://web.archive.org/web/20230131163438/https://www.inspiringtechweb.in/p/arduino-pin-change-interrupts.html?m=1 |date=2023-01-31 }} - Article by Adityapratap Singh
 {{Operating system|state=collapsed}}

Interrupt: Difference between revisions

Navigation menu

Search