Re: [MiNT] FPU detection, who is wrong?

[Markus Fröschle <mfro@mubf.de>]

If I interpret p. 6-35 of the 68881/68882 Users Manual correctly, both are (at least partly) wrong. There is a table (6-6) on that page with some text above that states version number 0x1f could indicate an 68881 _as well_ as an 68882. If the first byte of the format word is 0x3f, it states it's safe to assume its a 68881.

Provided the manual is right, it seems that a clear distinction can only be made on the following byte of the state frame after the version number which is either 0x18 for a 68881 or 0x38 for a 68882 (in an idle frame). This seems to indicate the frame length (six words on 68881 vs. 14 words on 68882).

Am 16.02.2015 um 07:53 schrieb Thorsten Otto:

Hi,

I just noticed a small discrepancy in the FPU detection code. 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