upon return from the exception handler. In the case of pre-instruction exceptions, the
instruction to be executed upon return is the FPCP instruction that was attempted, but
preempted by a pending exception. For mid-instruction exceptions (other than interrupts),
two pointers are saved: the address of the FPCP instruction that caused the exception and
the address of the instruction immediately following that FPCP instruction. Furthermore,
the FPIAR contains a pointer to the FPCP instruction that caused the exception in both
cases. Thus, an exception handler can always locate the instruction that caused an excep-
tion, and identify the next instruction to be executed upon return from the handler.
When the MPU executes a return from exception (RTE) instruction, it reads the stack frame
from the top of the active system stack and restores that context. In the
case
where the
stack frame was generated by an FPCP pre-instruction exception, the context that is restored
is the MPU context of the pre-empted FPCP instruction. The FPCP instruction begins ex-
ecution in the normal manner, with the MPU writing the coprocessor command word to
the FPCP.
In the case where the RTE stack frame is generated by a coprocessor-detected mid-instruction
exception, the context restore operation is slightly different. In this case, the MPU must
complete execution of the instruction that was suspended by the exception. When the RTE
instruction completes execution, the MPU first reads the response CIR of the FPCP to
determine the next appropriate action.
NOTE
Since the MC68881 always finishes execution of the instruction that causes this
type of exception before reporting it, the response that is returned is null (CA=0,
PF = 1), which releases the main processor to continue with the execution of the
next instruction. Note that after a take mid-instruction exception primitive is re-
turned, the main processor is not required by the MC68881 to perform a read
from the response CIR before initiating the next floating-point instruction, but the
MPU always performs this action when processing a mid-instruction stack frame.
An MC68881 arithmetic exception handler (i.e., a handler for any exception other than the
BSUN exception) routine is not required to perform any action to clear the cause of an
exception. In fact, an MC68881 arithmetic exception handler may consist of a single RTE
instruction (which produces the same logical effect as disabling an exception). This is
because the main processor acknowledges the exception by writing to the control CIR
when the coprocessor signals an exception to the MPU, and the exception acknowledge
clears any pending exceptions in the MC68881, Thus, the MC68881 arithmetic exception
handler is not required to clear any status bits or read any MC68881 registers in order to
prevent the reocurrence of an exception when an RTE instruction is executed. However,
an RTE instruction alone does not prevent the reoccurrence of an MC68882 exception. The
MC68882 does not clear the pending floating-point exception in response to the exception
acknowledge. An MC68882 arithmetic exception handler must meet certain requirements
in order to clear the cause of the exception. Refer to 5.2.2
Exception Handler Code
for the
MC68882 exception handler requirements. In the case of the BSUN exception handler,
some action must be taken (as described in 6.1.1
Branch/Set on Unordered
(BSUN) by the
exception handler to avoid an infinitely executing loop.
For the MC68881, if an exception handler includes any FPCP instruction other than an
FMOVEM, an FSAVE should be the first FPCP instruction to be executed. This assures that
an exception handler cannot generate any exceptions related to, or modify the context of,
MC66661/MC66662 USER'S MANUAL
FREESCALE
6-23
To Next Page
Loading...