makes an exception pending, the exception is reported on the next read operation of the
response CIR. Therefore, all reads of the response CIR must be ready to take an exception.
If the read of the response CIR occurs in the middle of an instruction, a take mid-instruction
exception is taken. The dialog shown in Figure 7-32 is a generic case that applies to all
instructionsand to every read of the response CIR after the instruction has issued its first
response. The first response is the response issued by the conversion unit (CU) or the
arithmetic processing unit (APU) to the bus interface unit (BIU), not the null primitive (CA = 1,
IA=I) at the beginning of an instruction when (in an MC68881) the APU is busy or (in the
MC68882) the CU is busy.
The MC68882 dialog is similar, except that the exception handler must begin with an FSAVE
instruction. The significant difference is that the write exception acknowledge operation
does not cause the MC68882 to return a null primitive. The FSAVE instruction of the
exception handler changes the primitive to a null primitive.
In the MC68882, an instruction that is executing in the arithmetic processing unit (APU)
concurrently with another instruction in the conversion unit (CU) may cause an exception.
The instruction in the CU reports the exception as a mid-instruction exception when it
completes. Figure 7-32 shows the dialog for this case using a general instruction dialog.
When the previous instruction causes an exception, the read response CIR operation for
the current instruction reads a take mid-instruction primitive, and the main processor
performs exception processing. As in the nonconcurrent case, the write exception ac-
knowledge operation does not cause the MC68882 to return a null primitive. The FSAVE
instruction of the exception handler changes the primitive to a null primitive. Figure 7-33
shows the same case but with a specific instruction (FMOVE FPm,<ea>) in the CU.
When the exception handler does not contain an FSAVE instruction, the take mid-instruction
exception primitive i s not replaced by a null primitive, and the next floating-point instruction
takes the exception again. Figure 7-34 shows the dialog for a mid-instruction exception
that uses an incomplete handler.
Figure 7-35 shows the concurrent case using an exception handler that does not include
the BSET instruction. Following the return from the exception handler, the main processor
reads the take mid-instruction exception primitive from the response CIR and performs
exception processing again for the same exception.
7.5.4.3 MID-INSTRUCTION INTERRUPT. This dialog is utilized by the FPCP only if an
interrupt is pending during the calculation phase of the FMOVE FPm,<ea> instruction. In
this case, the protocol for the normal execution of the instruction is followed except that
the main processor performs exception processing for the interrupt, executes the interrupt
handler, and returns to the point where the dialog was suspended in the middle of the
execution of the instruction by the FPCP. From the perspective of the FPCP, the dialog
appears to follow the normal sequence, with a long delay between successive reads of the
response CIR by the main processor.
The dialog for this operation is shown in Figure 7-36. (For simplicity, this diagram assumes
that the destination data format is not packed decimal with a dynamic k factor.) Note that
it is possible (even probable) that the conversion of the output operand is completed before
the main processor returns from the interrupt. Thus, the response CIR is prepared to return
the evaluate effective address and transfer data primitive as soon as the main processor
returns. Since the read of this primitive causes the FPCP to discard it and change the
MC68881/MC68882 USER'S MANUAL FREESCALE
7-35