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

[Thorsten Otto <halgara@xxxxxxxx>]

Hi,

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 (cookie 0x00060000)
    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).

Might not be that really important, but one of the two algorithms seems to be wrong.

Greetings,

Thorsten