Motorola M68060 User Manual page 367

MC68060 Software Package
C.2.2.1 UNIMPLEMENTED INTEGER INSTRUCTION EXCEPTION MODULE ENTRY
POINTS. The _isp_unimp function is implemented such that the unimplemented integer
instruction exception vector table entry typically points directly to _isp_unimp. If the system
software chooses to perform operations prior to entering the _isp_unimp function, it may do
so as long as the system stack points to the exception stack frame at the time of entry.
C.2.2.2 UNIMPLEMENTED INTEGER INSTRUCTION EXCEPTION MODULE CALL-
OUTS. The call-outs _real_trace, _real_chk, _real_divbyzero, and _real_access are defined
to provide the system integrator a choice of either having the module point directly to the
actual trace, chk, divide-by-zero, and access error handler, or to an alternate routine that
would fetch the address of the exception handler from the vector table prior to jumping to
the actual handlers. The direct implementation is ideal for systems that do not anticipate any
changes to the vector table and performance is more critical. The indirect approach of con-
sulting the vector table is more accurate in that if the instruction were implemented, the
actual handler's address is fetched from the appropriate vector table entry before branching
there.
Other call-outs which are common to the floating-point kernel module are discussed in C.4
Operating System Dependencies . These call-outs include the discussion of the
_real_access and other operating-system-dependent functions.
The _isp_done call-out is provided as a means for the system to do any clean-up, if any is
necessary, before executing the RTE instruction to return to normal instruction execution.
The unimplemented integer instruction exception handler will either branch to this call-out or
create an appropriate exception frame and branch to the call-outs _real_trace, _real_chk,
_real_divbyzero, or _real_access routines as outlined previously.
C.2.2.3 CAS MISALIGNED ADDRESS AND CAS2 EMULATION-RELATED CALL-OUTS
AND ENTRY POINTS. The CAS instruction with misaligned address and CAS2 emulation
is the most system dependent of all MC68060ISP code. The emulation code may require
interaction with a system's interrupt, paging and access error recovery mechanisms. The
emulation algorithm uses the MOVEC of the BUSCR register to assert the LOCK and
LOCKE signals during emulation. The following is a description of the main steps in the em-
ulation process:
1. Decode instruction and fetch all data from registers as necessary. In addition, if any of
the operand pages are non-resident, then they must be paged in and not be allowed
to be paged out or marked invalid for any reason until the emulation process ends. For
each operand address, the MC68060ISP calls _real_lock_page() which must be pro-
vided by the host operating system to "lock" the pages. This routine should also check
to see if the address passed is valid and writable. If not, then an error result should be
returned to the MC68060ISP.
2. The MC68060ISP then calls the "core" emulation code for either "cas" or "cas2". The
MC68060ISP references the "core" routines by calling either the _real_cas() or
_real_cas2() call-outs. If the emulation code provided is sufficient for a given system,
then the system integrator can make these call-outs immediately re-enter the package
by calling either _isp_cas() or _isp_cas2() entry points.These entry points will perform
the required emulation. If the "core" routines provided need to be replaced by a more
C-6 M68060 USER'S MANUAL MOTOROLA