Table of Contents
Advertisement
If an address error occurs during exception processing for a bus error, another ad-
dress error, or a reset, the processor halts.
6.2.4 Instruction Traps
Traps are exceptions caused by instructions. They arise from either processor recog-
nition of abnormal conditions during instruction execution or from use of specific trap-
ping instructions. Traps are generally used to handle abnormal conditions that arise in
control routines.
The TRAP instruction, which always forces an exception, is useful for implementing
system calls for user programs. The TRAPcc, TRAPV, CHK, and CHK2 instructions
force exceptions when a program detects a run-time error. The DIVS and DIVU in-
structions force an exception if a division operation is attempted with a divisor of zero.
Exception processing for traps follows the regular sequence. If tracing is enabled when
an instruction that causes a trap begins execution, a trace exception will be generated
by the instruction, but the trap handler routine will not be traced (the trap exception will
be processed first, then the trace exception).
The vector number for the TRAP instruction is internally generated — part of the num-
ber comes from the instruction itself. The trap vector number, program counter value,
and a copy of the status register are saved on the supervisor stack. The saved pro-
gram counter value is the address of the instruction that follows the instruction which
generated the trap. For all instruction traps other than TRAP, a pointer to the instruc-
tion causing the trap is also saved in the fifth and sixth words of the exception stack
frame.
6.2.5 Software Breakpoints
To support hardware emulation, the CPU32 must provide a means of inserting break-
points into target code and of announcing when a breakpoint is reached.
The MC68000 and MC68008 can detect an illegal instruction inserted at a breakpoint
when the processor fetches from the illegal instruction exception vector location. Since
the VBR on the CPU32 allows relocation of exception vectors, the exception vector ad-
dress is not a reliable indication of a breakpoint. CPU32 breakpoint support is provided
by extending the function of a set of illegal instructions ($4848–$484F).
When a breakpoint instruction is executed, the CPU32 performs a read from CPU
space $0, at a location corresponding to the breakpoint number (See 5.3 Types of Ad-
dress Space). If this bus cycle is terminated by BERR, the processor performs illegal
instruction exception processing. If the bus cycle is terminated by DSACK, the proces-
sor uses the data returned to replace the breakpoint in the instruction pipeline and be-
gins execution of that instruction.
6.2.6 Hardware Breakpoints
The CPU32 recognizes hardware breakpoint requests. Hardware breakpoint requests
do not force immediate exception processing, but are left pending. An instruction
MOTOROLA
6-8
EXCEPTION PROCESSING
CPU32
REFERENCE MANUAL
Advertisement
Table of Contents
