Re: [hatari-devel] Possible bug in 060 exception stack frames

[Toni Wilen <twilen@xxxxxxxxxx>]

> Documentation says:
> 
> --
> 6.6.2.2 TRAP ENABLED RESULTS (FPCR SNAN BIT SET).
> 
> If the destination is not a floating-point data register (FMOVE OUT
> instruction), the destination (memory or integer data register) is
> written with the same data as though the trap were disabled (FPCR SNAN
> bit clear), and then control is passed to the user SNAN handler as a
> post-instruction exception. If desired, the user SNAN handler can
> overwrite the result.
> 
> For floating-point data register destinations, the source (if
> register-to-register instruction) and destination floating-point data
> registers are not modified. Control is passed to the user SNAN handler
> as a pre-instruction exception when the next floating-point instruction
> is encountered. In this case, the SNAN user handler should supply the
> result.
> --
> 
> So according to documentation (Test code has FP0 destination), following
> FPU instruction should trigger the SNAN exception. But test code expects
> immediate post-instruction exception and gets confused if it gets
> delayed until next FPU instruction.

I did some real 68060 tests. As usual, documentation does not want to
tell the whole truth.

It mentions many times something like "Since FMOVE to/from the FPCR,
FPSR, or FPIAR and FMOVEM instructions cannot generate floating-point
exceptions, you can do blahblahblah" but this only means those
instructions can't generate exceptions internally and won't modift FPIAR
(so that FPIAR still points to instruction that caused the exception)
but they do still cause exception if there is pending FPU exception
generated by previous FPU instruction. Even FMOVEM.X does this.

This explains why SNAN, OPERR and DZ tests work.

Patch coming later..