The book uses "exception" as a general term for all interrupts ...
... in these notes interrupt is used as the general term ...
... and a narrower definition is used for exception.
The definitions of trap, interrupt, and exception given here ...
... are not explicitly provided in the text ...
... but are widely used.
Operating system "takes over" computer ...
... attends to whatever caused the interrupt ...
... and (most of the time) resumes interrupted program.
Interrupt Terminology
The OS program that "takes over" in response to interrupt.
Privileged Mode
A state in which the CPU controller and memory system ...
... do not restrict instructions that can be executed ...
... or memory that can be accessed.
Processor switches into privileged mode in response to interrupt ...
... and out of privileged mode when resuming the program.
Interrupts and Pipeline Design
... because it's hard to stop a pipeline in the middle of something ...
... and have it resume again later ...
... as if nothing happened.
Sort of a subroutine call to OS.
Something went wrong, triggered by an executing instruction.
Exception has both a general and this specific meaning.
Something is trying to get the computer's attention.
Interrupt has both a general and this specific meaning.
Initiated by a special trap instruction in user code.
Trap causes branch to OS code and a switch to privileged mode ...
... in which there are fewer restrictions on access to memory and I/O.
Typically used for I/O, memory allocation, etc.
That "something" is usually caused by an instruction, for example:
In response to an exception ...
... OS either fixes problem and re-tries instruction ...
... or terminates program.
Exceptions frequently occur in the middle of an instruction ...
... which has to be re-started when the program resumes.
... which typically needs routine attention.
For example,
... while all instructions following the last are abandoned.
... with the instruction following last.
... while instructions following the last must have no effect at all ...
... even though they may have already started when the interrupt occurred.
These abandoned instructions will be executed after the handler completes.
Abandoning Instructions
When the handler finishes and the program resumes ...
... it must be as though the abandoned instructions never even started.
So ...
... they cannot write registers ...
... they cannot write memory ...
... or set any kind of condition codes ...
... unless ...
... the state change can be un-done.
... because they change state in the last two stages (MEM & WB).
To abandon an instruction in the IF, ID, or EX stages ...
... the opcode is replaced with a NOP ...
... or any control bits that initiate a memory or register write ...
... are set to perform no action.
An instruction in WB cannot easily be abandoned ...
... because the following instruction, in MEM, ...
... would already be changing state.
Fortunately, there's never a need to abandon an instruction in WB ...
... although an already-abandoned instruction can enter WB.
An instruction in MEM cannot be abandoned ...
... unless the memory operation fails ...
... which, luckily, is the only reason to abandon the instruction.
... handler may have to ...
... determine which instructions finished ...
... and which were in progress.
... an interrupted instruction can resume in the middle.
No problem.
No problem again.
In a system having precise exceptions:
... and it's not always a good choice.
In a system without precise exceptions:
Precise exceptions are necessary for some instructions ...
... and expensive for others.
They are necessary for instructions ...
... such as memory loads and stores.
For other instructions they are a convenience ...
... for example FP instructions ...
... that can write error values instead of numbers ...
... if they don't complete.
In many systems precise exceptions are optional for floating point ...
... but always provided for other instructions.
| David M. Koppelman - koppel@ee.lsu.edu | Modified 2 Mar 1997 19:16 (1:16 UTC) |