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)