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

[Toni Wilen <twilen@xxxxxxxxxx>]

>> Could you also include compiled .sa files?
> 
> You should be able to produce them using any m68k cross assembler; the
> output format is binary, anyway. But they are attached below.

Thanks. I don't want unexpected assembler issues :)

After few tiny fixes (pushed to winuae repo):

Testing 68060 FPSP started:
	Unimplemented <ea>...passed
	Unimplemented data type/format...passed
	Non-maskable overflow...passed
	Non-maskable underflow...passed
Testing 68060 FPSP unimplemented instruction started:
	Unimplemented FP instructions...passed
Testing 68060 FPSP exception enabled started:
	Enabled SNAN...failed: 00000001
expected:
    FPCR=00004000 FPSR=09004080 FPIAR=083f3d5e
    FP0= ffff0000 00000000 00000001
    FP1= 7fff0000 ffffffff ffffffff
    FP2= 7fff0000 ffffffff ffffffff
    FP3= 7fff0000 ffffffff ffffffff
    FP4= 7fff0000 ffffffff ffffffff
    FP5= 7fff0000 ffffffff ffffffff
    FP6= 7fff0000 ffffffff ffffffff
    FP7= 7fff0000 ffffffff ffffffff
got:
    FPCR=00004000 FPSR=08004000 FPIAR=083f3d5e
    FP0= ffff0000 00000000 00000001
    FP1= 7fff0000 ffffffff ffffffff
    FP2= 7fff0000 ffffffff ffffffff
    FP3= 7fff0000 ffffffff ffffffff
    FP4= 7fff0000 ffffffff ffffffff
    FP5= 7fff0000 ffffffff ffffffff
    FP6= 7fff0000 ffffffff ffffffff
    FP7= 7fff0000 ffffffff ffffffff

(and crash)

Test code:

snan_0_pc:
	fadd.b		#0x2,%fp0

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.