Control is hardest part of the design
Hardest part of control is interrupts
Interrupts are events other than branches or jumps that change the
normal flow of instruction execution
Internal/External to the CPU
An exception is an unexpected event from within the processor;
e.g., arithmetic overflow
An interrupt is an unexpected event from outside the processor;
MIPS convention: exception means any unexpected change in control flow,
without distinguishing internal or external;
use the term interrupt only when the event is externally caused.
I/O device request - External Interrupt
Invoke OS from user program - Internal Exception
Arithmetic overflow - Internal Exception
Using an undefined instruction - Internal Exception
Hardware malfunctions - Either Exception or Interrupt
How are Exceptions Handled?
Machine must save the address of the offending instruction in the EPC
(exception program counter)
Then transfer control to the OS at some specified address
OS performs some action in response, then terminates or returns using
2 types of exceptions in our current implementation:
undefined instruction and an arithmetic overflow
Which Event caused the Exception?
Option 1 (used by MIPS): a Cause register contains reason
Option 2 Vectored interrupts: address determines cause - addresses
loaded from a table
Additions to MIPS ISA to support Exceptions
EPC-a 32-bit register used to hold the address of the affected instruction.
Cause-a register used to record the cause of the exception. In the
MIPS architecture this register is 32 bits, though some bits are currently
unused. Assume that the low-order bit of this register encodes the two
possible exception sources mentioned above: undefined instruction=0 and
2 control signals to write EPC and Cause
Be able to write exception address into PC -change mux to allow fixed
address to be fed into the PC
May have to undo PC = PC + 4, since want EPC to point to offending
instruction (not its successor); PC = PC - 4
How Control Detects Exceptions
Undefined Instruction-detected when no next state is defined from state
1 for the op value.
Handle this exception by defining the next state value for all op values
other than lw, sw, 0 (R-type), jmp, beq, and ori as new state 12.
Shown symbolically using "other" to indicate that the op field does
not match any of the opcodes that label arcs out of state 1.
Arithmetic overflow- A a signal called Overflow is provided as an output
from the ALU. This signal is used in the modified finite state machine
to specify an additional possible next state for state 7
Note: Challenge in designing control of a real machine is to handle
different interactions between instructions and other exception-causing
events such that control logic remains small and fast.
Extra States to Handle Exceptions
What happens to the Instruction that caused the exception?
Some problems could occur in the way the exceptions are handled.
For example, in the case of arithmetic overflow, the instruction causing
the overflow completes writing its result, because the overflow branch
is in the state when the write completes.
However, the architecture may define the instruction as having no effect
if the instruction causes an exception; MIPS specifies this.
Certain classes of exceptions also prevent the instruction from changing
the machine state (e.g. page fault).
This aspect of handling exceptions becomes complex and potentially
A CPU where every instruction can be restarted if it causes an exception
is called restartable.
As we get pipelined CPUs that support page faults on memory accesses
which means that the instruction cannot complete AND you must be able to
restart the program at exactly the instruction with the exception, it gets