Home

CPSC 418: Interrupts: Precise/Imprecise

A machine has precise interrupts if, when an interrupt or exception occurrs, the microprocessor state is exactly as if the CPU had executed to the instruction causing the exception and then stopped.

In contrast, imprecise interrupts allow an inconsistent state: for example some register may hold values resulting from instructions that follow the instruction that caused the exception.

A few excerpts from the DEC Alpha Architecture manual:

Exceptions:

something goes wrong with the execution of an instruction

Fault: "an exception condition that occurs during [the processing of] an instruction and leaves the registers and memory in a consistent state" so that after fixing the fault, the instruction can be re-executed
For example: when a page fault occurs, the desired page must be brought into memory. Once that has happened, the instruction can be re-executed and things will work as they should.
Arithmetic trap: For example: divide by zero.
Unlike faults, arithmetic traps usually cannot be fixed up to allow the program to continue. Arithmetic traps are a sign that something is wrong in the user's program.
Synchronous trap: For example: data mis-alignment (e.g. access quad-word on a byte-boundary), breakpoint, illegal instruction, illegal operand.
Synchronous traps can result in aborting the program (data mis-alignment w/o any O/S routine to do data-alignment, illegal instruction, illegal operand) or entering a debugger (breakpoint) or an O/S routine.

Interrupts

an event external to the currently running program

In the Alpha:

arithmetic traps	imprecise
faults	semi-precise
interrupts	precise
synchronous traps	precise

After a fault or interrupt program execution must be able to continue, because there wasn't any problem with the user's code. However, it may be possible to leave the CPU in a state in which program execution can continue, but where the register file and other state-holding devices do not make it appear that the program executed up to a particular instruction and then stopped. For example, if we saved the entire set of architectural and physical registers in HO-17, we could restore them and continue execution, yet the state of the architectural registers and physical registers do not represent a precise location in the program.

Arithmetic traps usually mean that the user's program has errors in it and so, if you are going to kill the program, there is no need to make sure that the state is consistent. To fix the error, the user will likely run the program under a debugger, which will use synchronous traps (breakpoints) to single-step through the execution of the program.

Home

Suggestion Box

Last modified: 01 Apr 96