Interrupts, Traps, System calls, and Exceptions

• Interrupts - signals raised by hardware external to the MP

that needs a response (help) from the MP
 Caused by hardware
 Can happen at any time
 Regardless of what instruction(s) the MP is executing

• Traps - signals caused by execution of instructions

 Caused by software
 Lifetime of an interrupt...

• External hardware signals request

• CPU
 Checks if interrupt can be taken

 Jumps to interrupt handler

 Executes handler

 Returns to interrupted task

 Interrupt Signal
• Signals from the hardware
 When I/O devices need attention from the MP they let the
MP know by signaling it
• I/O chip pin for this purpose is attached to an input pin of
the MP This signal tells the MP that
serial chip needs service

Serial
Port

MP

Network
Interface Interrupt reqest pins
This signal tells the MP that network chip needs service
 Interrupts
• Signals from the hardware
 When I/O devices need attention from the MP they let the MP
know by signaling it

 Devices that drive serial ports

When a character arrives from the serial port
Signals the MP with an interrupt to get the MP to take the character from
where it is stored in the device
When the serial device has transmitted a character and is ready to send
another, it signals the MP so that the next characters are sent to the device
 Network interfaces, etc.
When data arrives on the network, the network signals the MP so that it
will take the data from the network device buffer
When sending, the network signals the MP when it is ready to send
additional data
 Interrupts
• Is there an alternative to interrupts when communicating
with peripheral devices? Any advantages, disadvantages?

• are interrupts really the fastest way of communication

with peripheral devices? can an interrupt based system
route 50000 packets/second if network device interrupts
on every packet received?
 Interrupt Request (IRQ)

• MP input pin to which device interrupt pins are attached

• Lets the MP know when some chip in the circuit wants
attention

• When an IRQ is asserted

 MP stops doing what it was doing (executing instructions)
 New stack frame created
Saves the next address on the stack
Like a return address when a CALL instruction is executed
However the `CALL’ is done automatically
 Jumps to an interrupt routine
Interrupt handler
Interrupt service routine (ISR)
 When an IRQ is asserted

• An IRQ can happen during ANY instruction

• MP completes execution of the instruction that is executing
 All of the instructions currently in the pipeline

• Interrupt handler
 Subprogram
 Instructions that handle specific hardware signals
 Does some cleanup also
Turn on interrupts if they were turned off
 Reset interrupt-detection hardware

 Very short, very fast set of instructions

Interrupt Routines

Task Code Interrupt Routine

... push AR4 //return address

addi3 R2 R3 R2 addi 1h SP // - save it on stack
subi3 R1 R2 R1 ...
subi3 R4 R1 R4 //read char from hw into R1
... //Store R1 value into memory
...
//Reset serial port hw
//Reset interrupt hardware
...
pop AR4
subi 1h SP
bu AR4 //may be special return
 Interrupt Routines

• Notice: Interrupt can occur between any two instructions

 CALL instruction: compiler knows what code came before
and after the call
 Compiler can write code to save/restore registers used in
the callee
• The compiler (when generating code for interrupt handler)
 Or assembly programmer
 Does not know when interrupts will occur
 Therefore ALL registers used by the interrupt handler must
be saved and restored to ensure register preservation
AKA saving the context
 Disabling Interrupts

• Every system allows interrupts to be disabled in some way

 Devices can be told not to interrupt
 MP can be told to ignore interrupts
 In addition, the MP can ignore some subset of interrupts
Certain interrupts are ignored, others are not
• Commonly individual interrupts can be disabled
• If an interrupt occurs while turned off, the MP remembers
 Deferred, not really disabled
Disabling Interrupts

• Nonmaskable interrupt
 An interrupt that cannot be turned off ever
 Used for exceptional circumstances
Beyond the normal range of ordinary processing
Catastrophic event
Power failure

 Question: How do you reset Mars Rover if gets stuck in an

infinite loop?
 Interrupt Priorities

• Each interrupt request signal (IRQ) can be assigned a

priority
• Programs can set the lowest priority it is willing to accept
 By setting this priority higher, a program effectively
disables all interrupts below this priority
 Most systems use prioritized interrupts and allow individual
interrupts to be turned off

• When multiple IRQs are raised at the same time

 MP invokes the handler of each according to (highest)
priority
 Example: Priorities in RM 7000

• MIPS RM 7000: High performance- RISC

• 13 interrupts:
 10 external
 1 timer
 2 software

• 16 interrupt levels

• All interrupts can be software prioritized.

Interrupt Handlers

• Commonly, a table is used

 Holds addresses of interrupt handler routines
Interrupt vectors
 Called an interrupt vector table
 Indexed by a unique number assigned to each interrupt
 Never changes - implemented with the system
 Location
Known/fixed location
Variable location w/ known mechanism for telling the MP where it is
• When an IRQ is raised
 MP looks up the interrupt handler in the table
 Uses the address to jump to
 Example: RM 7000 Interrupt Vectors

• Interrupt Vectors are at a fixed address.

If exception is an interrupt and IV bit in CAUSE register is set
vector = 0x200 + (IPL * SPACING )
else
vector = 0x180
endif
If BEV is set
PC = vector + 0xbfc0 0000
else
PC = vector + 0x8000 0000
endif
 Example: 80386 Interrupt Vectors

• Interrupt descriptor table can reside anywhere

• CPU uses IDT Limit and IDT base registers for interrupt
vector lookup.
Figure taken from Intel 80386 Programmer’s Reference
 Interrupt Nesting

• When an interrupt occurs while an interrupt handler is

executing
 For some systems, this is the default behavior

 When priorities are used - only a higher priority interrupt can

interrupt the handler
If a lower priority IRQ is raised, the current handler completes before
the low-priority IRQ is handled

 For others, special instructions are inserted into interrupt

routines to indicate that such behavior can occur
For this case, all interrupts are automatically disabled whenever an
interrupt handler is invoked
 Unless the instructions are present which re-enables interrupts
 Example: Exception Nesting in RM 7000

• Little help from hardware

 moves PC to EPC
 sets status, cause registers etc.

• Software
 k0 and k1 registers are interrupts only
 Interrupt stack: exclusive for nested interrupts
 Question: What is the maximum depth of interrupt stack?
 Example: Exception Nesting in 80386

• Hardware knows where stack is

 pushes EIP, flags and code segment to stack
 sets status, cause registers etc.

• Even supports “interrupt tasks”

 Hardware invokes tasks from interrupts
 Saves entire context -similar to task switch
 Hardware scheduler controls execution
 Separate address space
Figure taken from Intel 80386 Programmer’s Reference
 Shared Data Problem

• Very little can be done in the interrupt handler

 To ensure that interrupts are handled quickly
 To ensure that control returns to the task code ASAP

• Interrupt routine must tell task code to do followup

processing
 To enable this, the interrupt routine and the task code
communicate using shared variables.
 Shared Data Problem

• Interrupt routine must tell task code to do followup

processing
 Via shared memory (variables)
Used for communication between handler and task code
Shared

 However, shared data is a well-known, difficult problem

Handlers-tasks
Across tasks
Across threads

 Because two+ entities are interleaved - and each can

modify the same data!
Nuclear Reactor Monitoring System
• Monitors two temperatures that must always be equal
 Code monitors these temperatures
 Raises alarm if they are ever unequal
static int iTemperatures[2];
void interrupt vReadTemperatures () {
iTemperatures[0] = //read value from hardware
iTemperatures[1] = //read value from hardware
}
void main() {
int iTemp0, iTemp1;
while(TRUE) {
iTemp0 = iTemperatures[0]; Interrupt can occur
iTemp1 = iTemperatures[1]; between any
if (iTemp0 != iTemp1) { two instructions!
//set off alarm!
}
}
}
Nuclear Reactor Monitoring System
• Monitors two temperatures that must always be equal
 Code monitors these temperatures
 Raises alarm if they are ever unequal
static int iTemperatures[2];
void interrupt vReadTemperatures () {
iTemperatures[0] = //read value from hardware
iTemperatures[1] = //read value from hardware
} Problem!
void main() {
int iTemp0, iTemp1;
while(TRUE) {
iTemp0 = iTemperatures[0]; Interrupt can occur
iTemp1 = iTemperatures[1]; between any
if (iTemp0 != iTemp1) { two instructions!
//set off alarm!
}
}
}
Nuclear Reactor Monitoring System
• Monitors two temperatures that must always be equal
 Code monitors these temperatures
 Raises alarm if they are ever unequal
static int iTemperatures[2];
void interrupt vReadTemperatures () {
iTemperatures[0] = //read value from hardware
iTemperatures[1] = //read value from hardware
}

void main() {
while(TRUE) {
if (iTemperatures[0] != iTemperatures[1]) { Interrupt can occur
//set off alarm! between any
} two instructions!
}
}
Nuclear Reactor Monitoring System
static int iTemperatures[2];
void interrupt vReadTemperatures () {
iTemperatures[0] = //read value from hardware
iTemperatures[1] = //read value from hardware
}

void main() {
while(TRUE) {
if (iTemperatures[0] != iTemperatures[1]) { Interrupt can occur
//set off alarm! between any
} two instructions!
}
}
PUSH AR3
LDIU SP, AR3
L11 LDIU @2E2h, R0 Problem!
CMPI @2E3h, R0
BZ L11
// code in if part of the branch (executed when not taken)
BU L11
 Shared Data Problem

• Difficult because
 They don’t happen every time the code runs
In the previous example, the interrupt could happen at other points
in main’s execution and doesn’t cause a problem
 Events (interrupts) happen in different orders at different
times
Non-deterministic (not necessarily repeatable)

• Possible solution
 Disable interrupts whenever the task code uses shared data
Disabling IRQs to Solve the Shared Data Pbm

static int iTemperatures[2];

void interrupt vReadTemperatures () {
iTemperatures[0] = //read value from hardware
iTemperatures[1] = //read value from hardware
}
void main() {
int iTemp0, iTemp1;
while(TRUE) {
disable();
iTemp0 = iTemperatures[0];
iTemp1 = iTemperatures[1];
enable();
if (iTemp0 != iTemp1) {
//set off alarm!
}
}
}
 Atomic Code

• Shared-data problem
 Task code and interrupt routine share data
 Task code uses the data in a way that is not atomic
 Solution: Disable interrupts for task code that uses data
 Atomic code: Code that cannot be interrupted
• Critical section: set of instructions that must be atomic
for correct execution
• Atomic code
 Code that cannot be interrupted by anything that might
modify the data being used
 Allows specific interrupts to be disabled as needed
And other left enabled
More Examples
static int iSeconds, iMinutes, iHours;
void interrupt vUpdateTime() { • Hardware timer
if (++iSeconds >= 60) { asserts an IRQ
iSeconds = 0; each second
if (++iMinutes >= 60) {
iMinutes = 0;
 Invoking
if (++iHours >= 24) { vUpdateTime
iHours = 0; }  Where is the
}
}
problem?
// update the HW as needed
}

long lSecondsSinceMidnight() {
return(
(((iHours*60)+iMinutes)*60)+iSeconds);
}
More Examples
static int iSeconds, iMinutes, iHours;
void interrupt vUpdateTime() { • Hardware timer
if (++iSeconds >= 60) {
iSeconds = 0;
asserts an IRQ
if (++iMinutes >= 60) { each second
iMinutes = 0;  Invoking
if (++iHours >= 24) {
iHours = 0; }
vUpdateTime
}  Is this a
} solution?
// update the HW as needed
}

long lSecondsSinceMidnight() {
disable();
return(
(((iHours*60)+iMinutes)*60)+iSeconds;
enable();
}
More Examples
static int iSeconds, iMinutes, iHours;
void interrupt vUpdateTime() { • Hardware timer
if (++iSeconds >= 60) { asserts an IRQ
iSeconds = 0; each second
if (++iMinutes >= 60) {
iMinutes = 0;
 Invoking
if (++iHours >= 24) { vUpdateTime
iHours = 0; }  Is this a
}
}
solution?
// update the HW as needed
}

long lSecondsSinceMidnight() {
disable();
long retn =
(((iHours*60)+iMinutes)*60)+iSeconds;
enable();
return retn;
}
More Examples
• Hardware timer asserts an
static int iSeconds, iMinutes, iHours; IRQ each second
void interrupt vUpdateTime() {
if (++iSeconds >= 60) {
 Invoking vUpdateTime
iSeconds = 0;  Is this a solution?
if (++iMinutes >= 60) {  What happens if
iMinutes = 0; lSecondsSinceMidnight() is
if (++iHours >= 24) { called from within a critical
iHours = 0; } section?:
} disable();
} ...
// update the HW as needed lSecondsSinceMidnight();
} ...
enable();
long lSecondsSinceMidnight() {
disable();  Check before disabling
long retn = Disadvantages?
(((iHours*60)+iMinutes)*60)+iSeconds;
enable();
return retn;
}
 Interrupt Latency

• Interrupts are a tool for getting better response from our

systems

• Response is commonly the performance metric used for

embedded systems
 Interrupt Latency

• MP response time (to interrupts)

• Consists of (per interrupt):
 Longest period of time (this/all) interrupts are disabled
 Execution time for any interrupt routine that has higher
priority than the currently executing one
 Context switching overhead by the MP
Time to sense the IRQ, complete the currently executing
instruction(s), build stack frame and invoke handler
 Execution time of the current interrupt routine to the point
that counts as a “response”

• Reducing response time

 Short handlers, short disable time
 Interrupt Latency Example

• Task code disable time

 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• Interprocessor interrupt
 Another processor causes an IRQ
System must respond in 650 s
Handler requires 300 s

• Worst case wait response time for interprocessor IRQ

 Handler routine (300 s)
 Longest periods interrupts are disabled (250 s)
 550 s - meets the response requirement
 Interrupt Latency Example

• Task code disable time

 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• Interprocessor interrupt
 Another processor causes an IRQ
System must respond in 650 s
Handler requires 300 s
• Network device
 Interrupt routine takes 150 s
• Worst case wait response time for interprocessor IRQ?
 Will interprocessor interrupt deadline be met?
• Can you improve on this?
 Interrupt Latency Example

• Task code disable time

 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• Interprocessor interrupt
 Another processor causes an IRQ
System must respond in 650 s
Handler requires 300 s
• Network device
 Interrupt routine takes 150 s
• Worst case wait response time for interprocessor IRQ?700
 Will interprocessor interrupt deadline be met?no
• Can you improve on this? Make network dev. Lower prty.
 Interrupt Latency Example
• Task code disable time
 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• Interprocessor interrupt
 Another processor causes an IRQ
System must respond in 650 s
Handler requires 350 s
• Network device
 Interrupt routine takes 100 s
 Lower priority than interprocessor interrupt
• Worst case wait response time
 For the interprocessor IRQ?
 For the network device?
 Interrupt Latency Example
• Task code disable time
 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• Interprocessor interrupt
 Another processor causes an IRQ
System must respond in 650 s
Handler requires 350 s
• Network device
 Interrupt routine takes 100 s
 Lower priority than interprocessor interrupt
• Worst case wait response time
 For the interprocessor IRQ? 600
 For the network device? 700
Interrupt Latency Example

• Task code disable time

 125 s to read temp values (shared with temp. hw)
 250 s to read time value (shared with timer interrupt)
• What happens if two disable periods happen back to back?
 Interrupt Latency

• Disabling interrupts
 Doing it often, decreases your reponse time
• Some systems (real-time) makes guarantees about
response time
 As you design the system you must ensure that such
guarantees (real-time or not) are met
• For some codes, you can avoid disabling interrupts
 Via careful coding
 To decrease interrupt latency
 Makes code fragile
 Difficult to ensure that you’ve got it right
 Volatile Variables

• Most compilers assume that a value in memory never

changes unless the program changes it
 Uses this assumption to perform optimization
 However, interrupts can modify shared data
Invalidating this assumption
 Holding memory values in registers is a problem

• An alternate solution to disabling interrupts is to identify

single piece of data that is shared with interrupt routines
 Make sure that the compiler performs NO optimizations on
instructions that use the data
All reads and writes are executed even if they seem redundant
 Force a memory read each time the variable is used
 Volatile Variables
Memory
int flag = 500;
foo() { 0x1002 500
... =&flag
while (flag != 10) {…;}
Raise_alarm();
...
}

O LDIU 1002h, AR4

LDIU 1002h, AR4 P
... ...
T
L11 ... I LDIU *AR4, R7
CMPI 10h, *AR4 M L11 ...
BEQ L11 I CMPI 10h, R7
CALL &Raise_alarm Z BEQ L11
... E CALL &Raise_alarm
...
 Volatile Variables
Memory
int flag = 500;
foo() { 0x1002 10
...
while (flag != 10) {…;}
Raise_alarm();
...
}

O LDIU 1002h, AR4

LDIU 1002h, AR4 P
... ...
T
L11 ... I LDIU *AR4, R7
CMPI 10h, *AR4 M L11 ...
BEQ L11 I CMPI 10h, R7
CALL &Raise_alarm Z BEQ L11
... E CALL &Raise_alarm
...
 Volatile Variables
Memory
volatile int flag = 500;
foo() { 0x1002 10
...
while (flag != 10) {…;}
Raise_alarm();
...
}

LDIU 1002h, AR4 LDIU 1002h, AR4

... ...
L11 ... LDIU *AR4, R7
CMPI 10h, *AR4 L11 ...
BEQ L11 CMPI 10h, R7
CALL &Raise_alarm BEQ L11
... CALL &Raise_alarm
...
 Volatile Variables

• Many compilers support the use of the keyword volatile

 Identifies variables as those that are shared
 Tells the compiler to NOT store the variable value in a
register
 Ensures that the value is the most recent
There is no problem of inconsistency between a register and
memory location that both refer to the same variable

• If compiler doesn’t support volatile and you don’t want to

disable interrupts
 Hand modify the assembly
 Turn off optimizations
Interrupts Overview
• The most important aspect to embedded system design
• Enable designers to split work - modularity
 Background work (tasks performed while waiting for
interrupts)
Unaware of foreground work
 Foreground work (tasks that respond to interrupts)

• They can be
 Precise - the system knows the exact cause and how to
respond
 Imprecise - catastrophic event; abort
 Asynchronous and synchronous (to MP clock)…
 Interrupts, Traps, and Exceptions
• Interrupt - a raised CPU signal
 External - raised by an external event
 Internal - generated by on-chip peripherals
 Can happen any time -- asynchronous interrupts
• Trap - software interrupt (synchronous interrupts)
 Mechanism that changes control flow
 Bridge to supervisor mode (system calls)
 Requires additional data to be communicated
Parameters, type of request
Return values (status)
• Exception - unprogrammed control transfer
 General term for synchronous interrupts
 On some machines these include internal async interrupts
 Interrupts, Traps, and Exceptions
• External Interrupts - a raised CPU signal
 Asynchronous to program execution
 May be handled between instructions
 Simply suspend and resume user program
• Traps (and exceptions)
 Exceptional conditions (overflow)
 Invalid instruction
 Faults (non-resident page in memory)
 Internal hardware error
 Synchronous to program execution
 Condition must be remedied by the handler
 Restarting After a Synchronous Interrupt

• Restart - start the instruction over

 May require many instructions to be restarted to ensure that
the state of the machine is as it was
• Continuation - set up the processor and start at the point
(midstream) that the fault occurred
 Process state is so complete that restart is not necessary
 A second processor handles the interrupt so the first
processor can simply continue where it left off
 Traps - Implementing System Calls
• Operating System
 Special program that runs in priviledged mode and has
access to all of the resources and devices
 Manages and protects user programs as well as resources
Via keeping user programs from directly accessing resources
Uses a separate using a user mode for all non-OS related activities
 Presents virtual resources to each user
Abstractions of resources are easier to use
 filesvs. disk sectors
 Virtual memory vs physical memory

• Traps are OS requests by user-space programs for service

(access to resources)
 Begins at the handler
Traps in the TMS320Cx
• TMS320Cx system calls
 Put index of system call start instruction into register IR0
 Trap 2
 Branch to main trap handler
 Find address (given index in IR0) of the right system call
In the interrupt vector table
 Jump there to continue execution