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

[Thomas Huth <th.huth@xxxxxx>]

 Hi,

Am Mon, 16 Feb 2015 08:37:21 +0000 (UTC)
schrieb Thorsten Otto <halgara@xxxxxxxx>:

> I just noticed a small discrepancy in the FPU detection code between
> MiNT/Hatari. When it comes to distinguish between 68881/68882, the
> code in MiNT looks like this:
>    moveq    #0x06,d0    // if neither, so maybe a 68882
>    move.b   (sp)+,d1
>    cmpi.b   #0x1f,d1
>    beq.s    fexit
>    moveq    #0x04,d0    // must be 68881
>    bra.s    fexit
> (the stack contains an IDLE frame of an FSAVE instruction at this
> point). So MiNT reports 68882 if the revision number is 0x1f, 68881
> otherwise. However, the opposite code in Hatari looks like this:
> static int get_fpu_version (void) { int v = 0;
> 
>     switch (currprefs.fpu_model)
>     {
>     case 68881:
>         v = 0x1f;
>         break;
>     case 68882:
>         v = 0x20;
>         break;
>     case 68040:
>         if (currprefs.fpu_revision == 0x40)
>             v = 0x40;
>         else
>             v = 0x41;
>         break;
>     }
>     return v;
> }
> 
> I.e for the 68881/68882 case, it is just the opposite. Unfortunately,
> i could not find any documention about which revision number is
> reported by the FPU, the only thing i found is that the length of
> stacked frame is different (0x1c for 68881, and 0x3c for 68882).

Looking at the 68881 user's manual ...

https://archive.org/stream/bitsavers_motorola68anual1ed1987_15689294/68881_68882_Users_Manual_1ed_1987#page/n244/mode/1up

.... it seems like both are wrong - 68881 can report 0x1f and 0x3f, and
68882 reports 0x1f. Newer versions of the FPUs could report even other
version numbers. To distinguish both, the length field should be used
instead, I think.

I've cc-ed Toni Wilen ... maybe he knows where the 0x20 comes from...?

 Thomas