
The PowerPC Core
MOTOROLA
MPC823 USER’S MANUAL
6-7
CORE
6
6.3.3 Interrupts
The core interrupts can be generated when an exception occurs. An exception results when
certain instructions are executed or an asynchronous external event occurs. There are five
exception sources in the MPC823:
External interrupt request
Certain memory access conditions (protection faults and bus error)
Internal errors, such as an attempt to execute an unimplemented opcode or
floating-point arithmetic overflow
Trap instructions
Internal exceptions (breakpoints and debug counter’s expiration)
Interrupt handling is transparent to user mode code and uses the same mechanism to
handle all types of exceptions. When a user mode instruction experiences an exception, the
machine is placed into privileged state and control is transferred to a software exception
handler routine located at some offset within a memory-based vector table. Each interrupt
generated in the machine transfers control to a different address in the vector table. For
more information on initializing the base address of the vector table, refer to
Table 6-6 aswell as the PowerPC definition of the machine state register. When the exception has been
handled, the handler can continue executing your program without ever knowing that an
event has occurred. As specified in the
PowerPC Microprocessor Family: The Programming
Environment for 32-Bit Microprocessors, the core implements a precise interrupt model.
This means that when an interrupt is taken, the following conditions are met:
No instruction that logically follows the faulting instruction in the code stream has
started executing.
All instructions preceding the faulting instruction appear to have completed with respect
to the executing processor.
The precise location (address) of the faulting instruction is known to the exception
handler.
The instruction causing the exception might not have started executing (before
interrupt), could be partially completed, or has completed (after interrupt), depending on
In any case, a partially completed instruction is restartable and can be reexecuted after the
interrupt is handled. This precise exception model can simplify and speed up exception
processing because the software does not have to manually save the machine’s internal
pipeline states, unwind the pipelines, or cleanly terminate the faulting instruction stream. Nor
does it have to reverse the process to resume execution of the faulting stream.