1 ece 371 microprocessors chapter 8 interrupts herbert g. mayer, psu status 11/3/2015 for use at...
DESCRIPTION
3 Introduction During execution of a piece of software, numerous unexpected events can happen A user may enter a character on a keyboard that needs to be read The power, supplying the computer system, may suddenly end The given time slice granted to a process in a time-sharing system may run its course, the running process is suspended temporarily; it has not completed, needs future processor time The CPU intends to execute the target of a branch at instruction pc, yet that code is not residentTRANSCRIPT
1
ECE 371Microprocessors
Chapter 8Interrupts
Herbert G. Mayer, PSUStatus 11/3/2015
For use at CCUT Fall 2015
2
Syllabus
Introduction Interrupt Definition Reorder Buffer Priorities Reentrant vs. Recursive Appendix Bibliography
3
Introduction During execution of a piece of software,
numerous unexpected events can happen A user may enter a character on a keyboard
that needs to be read The power, supplying the computer system,
may suddenly end The given time slice granted to a process
in a time-sharing system may run its course, the running process is suspended temporarily; it has not completed, needs future processor time
The CPU intends to execute the target of a branch at instruction pc, yet that code is not resident
4
Introduction During a floating-point divide operation,
the denominator is found to be 0.0, causing a result that is not representable
Two numbers are multiplied, yet the mathematical product exceeds the numeric capacity of the machine to store that value
Elements of an array are added up, yet the next addition exceeds the numeric capability of the machine
The target address of some branch instruction lies outside the code range of the current program
The object code for an x86 CPU executes an INT instruction, asking for support, parameterized in some machine register
5
Introduction There are numerous causes, why the regular flow of
execution is changed; regular execution means an execution order of SW by the HW, as if no unusual event happened
Some of these events are unpredictable; such as power outage; those cause an interrupt and are resolved by the interrupt handler, AKA interrupt service routine (ISR)
Other events are unfortunate, but are anticipated; e.g. the overflow of the numeric value during a floating-point add operation; this event causes an exception; such exceptions are anticipated, and are not true interrupts
Yet other events are directly programmed, e.g. a request to the OS for some system function. Those events are completely predictable. For example, the INT call on x86, or the request to read a character from an input device. Despite the name these are not true interrupts
6
Introduction During a floating-point divide operation,
the denominator is found to be 0.0, causing a result that is not representable
Two numbers are multiplied, yet the mathematical product exceeds the capacity of the machine to store that value
Elements of an array are summed up, yet the next addition exceeds the numeric capability of the machine
The target address of some branch instruction lies outside the range of the current program
The object code for an x86 CPU executes an INT instruction, asking for support, parameterized in some machine register
7
IntroductionResponding to Exceptional conditions: via interrupt,
exception, or a system call; picture from Wikipedia
8
Interrupt Definition Definition: Program interrupt is a transparent, non-
scheduled change in execution flow with specific cause outside the program, treated by an interrupt handler, ending up at the original program again
Is unpredictable: Programmer does not know that, when, why, where, how long interrupt happens
Is unexpected: Programmer does not know when interrupt happens, or whether it happens; it is asynchronous
Cannot be pinpointed (i.e. coded) by location: Programmer does not know where such an interrupt happens
Cause is only known once interrupt happens; is passed to ISR by HW, yet the SW program (i.e. process) does not know a-priori that it will happen
Cause can be some external event like power-outage, or time-slice consumption (timer interrupt), numeric error
9
Interrupt Requirements After handling the interrupt, regular SW
execution continues at the place of code right after the interrupt location
Challenge: if interrupt happens during execution of very long instruction, say move of a large portion of memory by a byte-move instruction!
The challenge is caused by the requirement of handling an interrupt swiftly, more swiftly than the time needed for some long machine instructions!
Interrupt handled in a way that the program never knows it was interrupted: must be completely transparent
10
Interrupt Requirements Responding to an interrupt has to be fast; after
all, the cause may be some catastrophic event, such as power outrage! And in such a case data need to be saved, i.e. the complete program status, so processor may resume execution later
It will not be known that an interrupt has happened, except that execution ends up slower than expected; slower than if the interrupt had not happened
Summary: the SW does not see that, why, when, how often, how long, where in the code an interrupt has happed; it is not a programmed event
Note: x86 INT instruction is not an interrupt! Though it is named a “software interrupt” instruction; is it totally predictable, locatable!
System calls and exceptions are not truly interrupts!
11
Interrupt: Final Definition
A system interrupt is an asynchronous change of execution flow, caused by an external event Interrupted SW completes execution transparently, as if the event never had happened System SW, named interrupt handler (ISR), responds to the interrupt
12
Interrupt: Final Definition
Exceptions, such as a floating-point overflow, are similar to interrupts, yet are tied to specific instructions, not external events System calls are completely predictable, like other calls, and have little in common with interrupts or exceptions see for example the x86 INT instruction.
13
Reorder Buffer On a pipelined architecture there exist at any
moment numerous instructions pci, i = 1..n in various stages of partial completion; n being the pipeline depth
When an interrupt happens, and the cause of the interrupt is attributable to instruction pci, all instructions before pci must complete, and none of the instructions after pci may complete, until the interrupt is handled
If the cause is not attributable to one of pci instructions, a decision inside pci, i = 1..n is made
For an exception, the cause is always attributable to one of the pci instructions
14
Reorder Buffer When a genuine interrupt happens, the
HW decides, at which of the various pci instructions the cut-off is to be made
So that all operations before pci complete, and all started instructions after pci get flushed to be restarted later
On a non-pipelined architecture this is easy to determine
Contemporary architectures are pipelined, even super-pipelined
15
Reorder BufferWhen an interrupt happens at moment in time 6,
what should happen with instructions i7 and i8?
Instruct. 1 2 3 4 5 6 7 8 9 10 11 12 13 timei8 if de op1 op2 exec wbi7 if de op1 op2 exec wbi6 if de op1 op2 exec wbi5 if de op1 op2 exec wbi4 if de op1 op2 exec wbi3 if de op1 op2 exec wbi2 If de op1 op2 exec wbi1 if de op1 op2 exec wb
Retire ? ? i1 ? i2 ? i3 ? i4 ? i5 ? i6 ? i7 ? i8
6 CPI from here: 1 clock per new instruction retirement, CPI = 1
Horizontal: time, units of cycles. Vertical: consecutive instructions
16
Reorder Buffer
The µP executes a reorder buffer to sort the yet to be completed vs. the to be restarted instructions
Reordering requires sorting (by numbering) instructions in progress; in progress means instructions started, but not yet retired
Though instructions have been decomposed into smaller internal HW entities, via numbering they can be reconstructed after handling the interrupt and ordered in original positions to satisfy the sequencing restriction
17
Reservation
Stationsand
ReorderBuffer
From Shen and Lipasti
18
Priorities When an exception occurs, such as a zero-
divide, the time to respond is uncritical; i.e. waiting a few microseconds more, even milliseconds, causes no new problem
Some exceptions are sometimes ignored, such as integer overflow on some Unix operating systems
When an interrupt occurs, the handler must decide, how and with which speed to react!
For example, new data may have arrived at some input port, are available for limited, defined duration, to be consumed by HW or else being lost
19
Priorities Moreover, an interrupt may happen while
some other interrupt is being handled Therefore, interrupts need priorities to
sort out, which action to perform first, and which other can be postponed
To limit the time of postponement, interrupt handling must always be swift
Some interrupts are so critical (high priority) that their handling cannot tolerate further interruptions
Hence it must be possible on a system to disable further interrupts
After handing, interrupts are again enabled
20
Interrupt Handler (ISR) Causes for interrupts are plentiful How does the ISR decide, which action
to take? Each type of interrupt is assigned
its own number, that number can be used as an index into a table of service routines; more accurately, a table of addresses of service routines; AKA branch table
Thus the data structure for selecting the ISR is uniform, the handling is fast, costing one added branch in addition to saving the machine state
21
Interrupt Handler (ISR)Table of addresses of individual handlers
for a specific processor, the ARM
22
Return from Interrupt Similar to the call-return mechanism, a
completed ISR must return execution --after handling an interrupt-- to the instruction after the last one that was interrupted but completed
Since an interrupt has to be transparent, the complete state of the machine is recreated at the point of return from saved information, similar to call-return
Hence more than just the return address is saved by the ISR; the whole processor state is saved and then restored
On some processors (e.g. ARM) the ISR has its own stack, different from the program stack
23
Reentrant vs. Recursive The code of an ISR does not need to be
recursive There is no need for the interrupt handler to
call itself, directly or indirectly However, the ISR must be written in a way
that it may be called before having completed the current interrupt!
Yet the flow of control is that of a single process, not multiple parallel processes
Interrupting the ISR must be allowed, since some sudden higher priority interrupt may have to be handled before the current one completes
This dictates reentrant, single-threaded code
24
Reentrant vs. Recursive
ISR 3
user code
int. 1
ISR 2ISR 1
int. 2
ISR 1
int. 3
ISR 2Enable interrupts & return & restore
return & restorereturn & restore
user code
disable interrupts
Reentrant code may not communicate via globals; interrupting ISR will save and restore the program state each time; certain high-priority interrupts may disable further interrupts; handling must be fast; to share data: use semaphores for exclusivity
25
Reentrant vs. Recursive It is straight-forward to design recursive
source code in a high-level language Recursion is enabled by the type of object
code generated; generally the compiler’s responsibility
And by executing on a run-time stack, with each incarnation of a recursive function having its own activation record, AKA stack frame (own locals, own formals, own return address)
Reentrant code must adhere to coding restrictions
E.g. not to communicate via global objects But reentrant code does (generally) not call
itself, either directly or indirectly
26
Appendix:Some Definitions
27
DefinitionsDefinitionsException An exception e is an event caused by an
irregular or faulty operation of a running program p. It is p itself that causes the e
Similar to an interrupt, e causes the HW –or some special system SW– to respond, to correct the situation where possible, or else to report the cause, location, and circumstance of e
Some exceptions are ignored, for example integer overflow on Unix systems, but the resulting arithmetic results generally look wrong
Location and reason for an e are clearly identifiable by the instruction that caused it
28
DefinitionsDefinitionsInterrupt An interrupt i is a transparent change in
the normal flow of operation of SW SW does not know, when, why, where, how
often or how long such an i happens The cause of i is outside the interrupted
SW A special piece of system SW called the
interrupt service routine (ISR) handles i and ensures that execution continues normally, once the interrupt has been completed
29
DefinitionsDefinitionsMachine-Check Error A Machine-Check Error (MCE) is a
catastrophic event, detectable by the HW that causes the system to end the regular path of execution
For example, a processor may get too hot, or the clock for a specific CPU may run too fast for continued, reliable operation
Result of an MCE is usually an end to further operation; a good MCE handler provides information about the cause and location before the machine shuts down
30
DefinitionsDefinitionsRecursive Code A piece of SW is recursive, if it
is partly defined in simpler versions of itself
This implies that SW may call itself directly or indirectly, yet continues to make progress
For SW to be recursive it also needs to be reentrant
31
DefinitionsDefinitionsReentrant Code SW is reentrant, if it can be called again
before completing the current execution path To write reentrant code, communication via
globals should be excluded; sharing global information requires protection via semaphores
Wiki: a procedure is reentrant if it can be interrupted in the middle of its execution and safely be called again ("re-entered") before its previous invocations complete. The interruption could be caused by an internal action such as a jump or call, or by an external actions. Once the reentered invocation completes, the previous invocations will resume correct execution
32
DefinitionsDefinitionsSystem Call A system call is a programmed
(visible in the source program) request for system services. The location is visible, as the service requires an explicit request via an instruction
For example, on the x86 architecture, the INT instruction is such a special request for service
33
Bibliography
1. Shen, John Paul, and Mikko H. Lipasti: Modern Processor Design, Fundamentals of Superscalar Processors, McGraw Hill, ©2005
2. https://en.wikipedia.org/wiki/Reentrancy_(computing)