Re: [hatari-devel] FPU detection, who is wrong?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


> This null state frame is generated until the first nonconditional
> floatingpoint instruction is executed (conditionals include FNOP, FBcc,
> FDBcc, FScc, and FTRAPcc).

Uh, oh. I wasn't aware that FNOP is treated as "conditonal". So Hatari is correct, and this is another bug in the detection code.


Toni Wilen <twilen@xxxxxxxxxx> schrieb am 18:48 Dienstag, 17.Februar 2015:


> Beside from catching line-F exceptions, it then expects an IDLE frame
> being saved. This works for 030, but not for 040/060, which creates a
> NULL frame instead. If i insert some other FPU instruction after the
> fnop, it works as expected. So apparently the fnop is not executed at all.


Ok, this is different problem.

FNOP (and some other FPU instructions) works differently in 68040+ vs
68881/68882, from chapter 9.8 in 68040 manual:

This null state frame is generated until the first nonconditional
floatingpoint instruction is executed (conditionals include FNOP, FBcc,
FDBcc, FScc, and FTRAPcc). Floating-point conditional instructions do
not set an internal flag, which changes the state frame from null to
idle. If these instructions are the only ones executed after a reset or
an FRESTORE of a null state frame, then when FSAVE is executed, it
stacks a null state frame instead of an idle state frame. Note that this
function is different from that of the MC68881 and MC68882, and software
must be aware of this difference if compatibility with the MC68881 and
MC68882 is desired. Once a nonconditional floatingpoint
instruction is executed, an FSAVE generates an idle state frame.








Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/