Difference between revisions of "Interrupt"

From Computer History Wiki
Jump to: navigation, search
m (Avoid redirs)
m (External links: +History and Overview of Interrupts)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
An '''interrupt''' is an asynchronous (i.e. it happens at an unpredictable time) diversion of the program execution in the [[Central Processing Unit|CPU]]. Interrupts are usually caused by things like a device signalling that it needs attention, but it could be almost anything: a clock ticking, or some sort of problem in the execution of a program (e.g. a divide by zero).
+
An '''interrupt''' is an [[asynchronous]] (i.e. it happens at an un-predictable time) diversion of the [[program]] execution in the [[Central Processing Unit|CPU]]. Interrupts are usually caused by things like a device signalling that it needs attention, but it could be almost anything: a clock ticking, or some sort of problem in the execution of a program (e.g. a divide by zero).
  
To 'service' the interrupt, the state of the [[CPU]] at the time of the interrupt (e.g. the [[Program Counter]]) is saved, and the CPU then proceeds to an '''interrupt handler''' - code to deal with the interrupt. The code in the handler often saves additional state - e.g. register contents; the more state that is saved automatically, the more expensive every interrupt becomes, so generally the minimum necessary state is saved automatically, and the handler can save more, if need be.
+
To 'service' the interrupt, the state of the CPU at the time of the interrupt (e.g. the [[Program Counter]]) is saved, and the CPU then proceeds to an '''interrupt handler''' - code to deal with the interrupt.
 +
 
 +
The code in the handler often saves additional state - e.g. the contents of other [[register]]s; the more state that is saved automatically, the more expensive every interrupt becomes, so generally the minimum necessary state is saved automatically, and the handler can save more, if need be.
  
 
Once the interrupt handler has finished dealing with the interrupt, it performs a 'return from interrupt', which restores the saved prior state of the CPU, and the computation which was interrupted resumes where it was when the interrupt happened.
 
Once the interrupt handler has finished dealing with the interrupt, it performs a 'return from interrupt', which restores the saved prior state of the CPU, and the computation which was interrupted resumes where it was when the interrupt happened.
Line 8: Line 10:
  
 
The CPU's priority may usually be set explicitly (by the program), but it is also typically raised as part of the servicing of an interrupt, so that no further interrupts at that priority level may he serviced until the handling of the current interrupt is complete. This prevents the interrupt handler from becoming confused by being restarted before the handling of the current interrupt is completed.
 
The CPU's priority may usually be set explicitly (by the program), but it is also typically raised as part of the servicing of an interrupt, so that no further interrupts at that priority level may he serviced until the handling of the current interrupt is complete. This prevents the interrupt handler from becoming confused by being restarted before the handling of the current interrupt is completed.
 +
 +
==Eternal links==
 +
 +
* [https://people.cs.clemson.edu/~mark/interrupts.html History and Overview of Interrupts and Interrupt Systems]
 +
 +
[[Category: CPU Basics]]

Latest revision as of 13:17, 3 February 2022

An interrupt is an asynchronous (i.e. it happens at an un-predictable time) diversion of the program execution in the CPU. Interrupts are usually caused by things like a device signalling that it needs attention, but it could be almost anything: a clock ticking, or some sort of problem in the execution of a program (e.g. a divide by zero).

To 'service' the interrupt, the state of the CPU at the time of the interrupt (e.g. the Program Counter) is saved, and the CPU then proceeds to an interrupt handler - code to deal with the interrupt.

The code in the handler often saves additional state - e.g. the contents of other registers; the more state that is saved automatically, the more expensive every interrupt becomes, so generally the minimum necessary state is saved automatically, and the handler can save more, if need be.

Once the interrupt handler has finished dealing with the interrupt, it performs a 'return from interrupt', which restores the saved prior state of the CPU, and the computation which was interrupted resumes where it was when the interrupt happened.

In many systems, interrupts are assigned to priority levels, and the CPU also has a priority level, and interrupt requests with a priority level less than the CPU's current priority level are ignored until the CPU's priority is lowered below that of the requested interrupt.

The CPU's priority may usually be set explicitly (by the program), but it is also typically raised as part of the servicing of an interrupt, so that no further interrupts at that priority level may he serviced until the handling of the current interrupt is complete. This prevents the interrupt handler from becoming confused by being restarted before the handling of the current interrupt is completed.

Eternal links