EECS 470Exceptions and Interrupts

University of MichiganSlides developed by Jielun Tan, Mark Brehob, Ron Dreslinski

1

A long long time (a couple lectures) ago● We went over precise state● Which, by the way, you should understand pretty well now● But let’s have a quick recap anyways

2

3

4

5

6

A long long time (a couple lectures) ago● We have only applied this situation to a branch misprediction, though● A branch is an microarchitectural exception, invisible to the programmer● This is a well defined event, because we’ve expected and prepared for all possible scenarios● What happens when it’s not a well defined event - an actual exception?

7

Exceptions● An exception is an anomalous event that requires special processing, often disrupting the

normal flow of program execution● Unlike branch mispredictions, exceptions are visible to software and need to be handled in

software○ This process transfers the control from the program to something else○ This something is usually called the exception handler○ The process of transferring control is often called trapping

8

Exceptions Examples● Floating point divide by zero

○ Welp● Page fault

○ Trap to the OS and let the OS load in the page● Misaligned access

○ Let software perform two or more separate accesses instead - trap-and-emulate● Illegal instruction

○ Crash and burn● System call● Whenever you encounter a blue screen of death (BSoD), often it’s because the CPU cannot

recover from a single or multiple nested exceptions○ Although Intel won’t ever admit that

9

Exception Handling● Unlike branch mispredictions, what happens when exception occurs is extremely ISA

dependent○ Different ISAs track different things, resolve things slightly different

● However, the general concepts are similar

10

Exception Handling● Let’s recall the case of branch misprediction

○ We know what happened in the pipeline■ Mispredicted a branch

○ We know where it happened in the pipeline■ Squash everything after the branch, roll back serially or via checkpoints to the

branch○ We know where to go afterwards

■ Take the branch● Likewise, we introduce three concepts: cause, exception PC and trap vector

○ These are often associated with machine specific registers, commonly known as control registers

11

Exception Handling● Cause: what caused the exception?

○ All the examples we listed before, and many more● Exception PC: which instruction caused the exception?

○ Set up a return point, for example:■ page fault, load the page in, return and re-execute the same instruction■ Misaligned memory accesses, let the handler do accesses properly and return to

the next instruction■ Crash and burn, leave a trace for people to figure out what went wrong

● Trap vector: where to go next?○ This is where execution continues○ There are different ways to find out where to go

12

Exception Handling ● Trap vector in essence is the address of the trap handler(s)● Directed/Vectorless*

○ a single register containing an address○ sets the PC to that address upon taking an exception○ software handles the rest

● Vectored/Autovectored* ○ a table of addresses, offsets from a base address○ hardware directed based on the cause

● Polling ○ go around and ask each unit/device/peripheral what happened

● Most architectures support a combination/all of these

*Terminologies may differ based on the platform, be aware that these can have overlapping names

13

Exception Handling● Let’s revisit this case, what happens after we squash and roll back the pipeline?

14

Exception Handling1. Record the PC of the mulf instruction in a register, let’s call it the epc2. Record the cause of the exception in register called cause

a. Let’s just say it’s a floating point overflow3. Jump to the trap vector

a. Start the trap handler routinei. What will the handler do?

15

Exception Handling

● How exceptions are handled are ultimately determined by whoever writes the handler● Sometimes there are standards to follow when encountering certain things● In our case, the IEEE 754 standard offers a list of operations permitted in the subroutine

○ Round to nearest carries all overflow to ∞ with the sign of the intermediate result○ Round toward 0 carries all overflows to the largest representable finite number with the

sign of the intermediate result.○ Round toward -∞ carries positive overflows to the largest representable finite

number and negative overflows to -∞.○ Round toward ∞ carries negative overflows to the most negative representable

finite number and positive overflows to ∞.● We can pick any one of these options in the exception handler, or all of them

16

x86 floating point status register

Exception Handling● OS has a list of things to do when handling an exception

○ Take a look at the linux trap handler● Machine designers can add in their flavors

○ Trap-and-emulate certain instructions that aren’t implemented in hardware■ Intel whips out new instruction every generation, how do they keep their machines

backwards compatible?● Users can have their own exception handlers

○ Remember the try catch blocks in C++?

17

Exception Handling● So cool, the exception handler can deal with all those problems, right?● There’s a small problem

○ In many cases, an exception is an unexpected event○ Calling the exception handler is just like calling another function○ Remember either a caller/callee save needs to happen when there’s a function call

■ Push the registers that will modified in the new function onto the stack● Not necessarily all registers need to be saved

■ Restore them from the stack once the function finishes■ What if you can’t use the same stack?

18

System Call● A system call is typical instruction that generates an exception

○ In Linux x86, it’s int $0x80○ Later x64 had a dedicated instruction called syscall○ In arm64, svc #0○ In RISC-V, there’s ecall, mcall, scall, ucall…

● Why would you just want an instruction that just generates an exception and does nothing else?

● If we simply want go to the exception handler, why don’t we just branch to the exception handler? Furthermore, why do we even need to go the exception handler in the first place?

19

System Call● Let’s say you wrote a program that needs to use dynamic memory, so you call malloc()

○ malloc() calls sbrk() which traps to the trap handler, but why?● Remember, your program isn’t the only one running on the machine

○ What if you hog up all the memory?● Trapping lets the user hand over control to the environment, in this case the OS● When the user program traps, a context switch happens

20

Context● A context is a state of the process

○ Saving the context is much like taking a snapshot of the program○ When saving a context, all the registers are saved along with the current PC

● The benefit of saving context? ○ You may leave and re-enter the user program without it ever knowing, and more

importantly, without it allowing■ The program can now be preempted

○ To resume, simply restore all registers and the PC○ This is called a context switch

● Context switching an expensive procedure○ You are pushing a lot into memory!○ Some ISAs use hardware routines instead

● But it happens every time the program traps○ Why bother? Again, why not just branch?

21

Privileges● Back to our example of malloc(), we want some way to control how much memory a single

user program can get, so no one can hog up all the memory● The OS ultimately determines how much memory a program can get

○ malloc() can return NULL if there’s enough memory■ Rather, if the OS isn’t allowing more memory to be used

○ What prevents the user program from bypassing the OS?● The OS is actually protected by hardware privileges

22

Privileges● Most commercial ISAs have different privilege levels● Each privilege level has its own set of control registers

○ i.e. epc, cause, trap vector○ Trap handling are redirected based on the current privilege

● There is always status register that indicates the current privilege level○ With that comes with different kinds of memory protection

● The higher privilege level, the more access to hardware○ User programs tend to have the lowest privilege

● Desktop OSes don’t even run at the highest privilege level○ In x86, there’s ring -1 and more○ In RISC-V, the kernel runs in supervisor mode instead

23

Preemption● We’ve covered the of case sharing memory, in which the user program asks the OS for more

memory● What about sharing CPUs?

○ In most scenarios, there are more programs running than cores● We know that the OS can preempt a program with a context switch● How does the OS know when to preempt?

○ When there’s a timer interrupt!

24

Interrupts● In essence, an interrupt is an asynchronous exception

○ Interrupts are not controlled by the user program, but rather external sources■ External, such as serial buses, GPIOs, etc■ System timer■ Software interrupts

○ Interrupts, when taken, will cause the processor to trap, just like an exception■ The processor can choose when to take them

● Ideally you want to take it as soon as possible● There’s always an interrupt pending control register, indicating what kinds of interrupts are

pending at each privilege level

25

26

Timers

CPU

SoftwareHardware

InternalExternal

Input

System BusesAHB/APB

ldr (read)str (write)ISA

USART DAC/ADCInternal &ExternalMemory

GPIO/INT

Output

Interr

upt

Compa

re

Captur

e I2C SPIUART ADC

DAC

CAssembly

Machine Code

Interrupts

interrupts

EMC

SVC#

fault

traps &exceptions

INT#

Interrupts● Let’s revisit this case again

27

Interrupts● Now assume that in this cycle, the interrupt pending control register asserts a pending

interrupt● When to take and how to take interrupt is implementation dependent

○ In the simplest case, tag all incoming instructions as “interrupting instructions”○ When the oldest “interrupt instruction” is at the head of the ROB, pretend that as an

exception and trap■ Squash the younger instructions, good ole precise state■ Save the PC of the excepting instruction in the epc register■ Save the cause, which in this case is an interrupt came■ Jump to the trap vector■ Note that the ROB is empty at this point

28

Interrupt Handling● There’s a slight with what we just did…

○ The interrupt pending bit is still high…■ Usually the pending bit is controlled by external sources, which means we can’t

arbitrarily clear it■ The interrupt source will clear it once we’ve serviced its request

● As long as the pending bit is high, all incoming instructions are tagged as “interrupting instructions”

○ Which means the pipeline is trapping on the trap handler code back and forth

29

Interrupt Handling● Most ISAs have one or more status registers that contain ... the current status

○ In x86, the FLAGS register○ In arm, there are multiple○ In RISC-V, mstatus

● Within the current status, there exists the global interrupt enable bit for each privilege level● Typically, global interrupt at the current privilege level is disabled upon trapping

○ Otherwise we’d be looping forever○ There also more granular interrupt enable bits in other control registers, so the trap

handler can still re-enable them

30

Return from Trap● Once the trap handler has done its job, we need to return from the trap handler

○ Assuming we don’t need to take any additional measures or crash and burn● Before we return, we have to restore the user context● To where do we return? The epc register will tell us

○ In some cases, we return to the epc and re-execute the instruction, i.e. page fault○ In other cases, we return to the next instruction

31

Return from Trap● There’s always some special instruction to jump using the epc value

○ Regular jump instructions can’t access control registers○ In x86, iret○ In RISC-V, mret, sret, uret

● Along with it, restore the previous interrupt status○ Re-enable global interrupt if previously enabled○ Go back to the previous privilege level if necessary

32

Terminology● Different places like to have different names● Sometimes interrupts are classified as exceptions, sometimes vice versa● Just be careful with these...

33

34