FPIAR not updated on unsupported FPU instruction?

[jotd]

hi, probably a question that only Toni can answer,


Using the debugger, 040 or 060 config, obviously disabling emulation of unsupported instructions (where winuae does a great job) I get this:

FPSR: 00000000 FPCR: 00000000 FPIAR: 00000000 N=0 Z=0 I=0 NAN=0
00000100 f200 5c32                FMOVECR.X #0x32 [#1.000000e+00],FP0
Next PC: 00000104
>t
Exception 11, PC=00000104
Cycles: 8 Chip, 16 CPU. (V=0 H=54 -> V=0 H=62)
  D0 D0D0D0D0   D1 D1D1D1D1   D2 D2D2D2D2   D3 D3D3D3D3
  D4 D4D4D4D4   D5 D5D5D5D5   D6 D6D6D6D6   D7 D7D7D7D7
  A0 483E2000   A1 483FE13E   A2 483E2000   A3 A3A3A3A3
  A4 A4A4A4A4   A5 A5A5A5A5   A6 A6A6A6A6   A7 0007FFEC
USP  0007FC00 ISP  0007FFEC SFC  00000005 DFC  00000005
CACR 80008000 TC   00008000 ITT0 00000000 ITT1 00000000
DTT0 00000000 DTT1 00000000 BUSC 00000000 VBR  483ED000
URP  483FC000 SRP  483FC000 PCR  04300602
T=00 S=1 M=0 X=0 N=1 Z=0 V=0 C=0 IMASK=0 STP=0
0: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
2: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
4: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
6: 7FFF-7FFFFFFF-FFFFF800 +nan 7FFF-7FFFFFFF-FFFFF800 +nan
FPSR: 00000000 FPCR: 00000000 FPIAR: 00000000 N=0 Z=0 I=0 NAN=0
483E3C90 007c 0700                OR.W #$0700,SR
Next PC: 483e3c94

the unsupported instruction triggers LINEF, but FPIAR remains at 0

This simple test was made because I have issues with Motorola official FPSP on 68060, which is VERY different from 68040 FPSP (which probably doesn't use FPIAR, but 68060 version uses it).

Obscure Winuae bug?

Tested on real 68060 the library doesn't crash at that point. It crashes later, on some hooks that I have installed.

One workaround would be to set FPIAR to the proper address but that's tricky since the stackframe points to the instruction AFTER the unsupported instruction. So a bit of decoding/instruction size table would be needed... slowing down the process. I can set that for now to be able to investigate the next problem, that's for sure.

Strangely enough, on the real example I'm testing FPIAR is NOT zero, but points to another FPU instruction (FMOVE.D, which is valid for the 68060)

[Thomas Richter]

Originally Posted by jotd

This simple test was made because I have issues with Motorola official FPSP on 68060, which is VERY different from 68040 FPSP (which probably doesn't use FPIAR, but 68060 version uses it).

The 68040 does the full operand fetch and provides a very large stack frame on which the fpsp can find all missing operands. The 68060 doesn't do that, so the FPSP has to decode the opcode itself and fetch the data itself.



This is one particular implementation bug of many 68060.libraries, namely to create a MuForce hit within the FPSR in case an operand needs to be loaded from an unmapped address. The library needs to forward the access error.

Originally Posted by jotd

Strangely enough, on the real example I'm testing FPIAR is NOT zero, but points to another FPU instruction (FMOVE.D, which is valid for the 68060)

That would surprise me. It could be, however, that the FMOVE.D requires help by the FPSP as well because its argument is not normalized, or its result requires denormalization. The 68060 FPU doesn't do that either and requires help.

[jotd]

makes sense, but that doesn't confirm the FPIAR WinUAE bug.

[Toni Wilen]

WinUAE sets FPIAR if it is FTRAPcc, FDBcc or FScc (possibly only in 4.5 betas).

I don't think all unsupported instructions set it but I can check it later this week using my tester (only generate FPU instruction tests that generate unsupported exception).

[jotd]

thanks. That would be appreciated. I'll workaround the issues for now to be able to make progress.

[jotd]

fixed the next problem. Now TFX runs on a 68060 with that library. Not sure of the speed, though. Would slow FPU emulation still beat scalar math of the non-FPU executable?

I checked the source code too and there's probably room for micro-optimizations (long bra instead of 16-bit bra for instance), we'll see when/if a future WinUAE is able to run that code.

[Toni Wilen]

FPIAR being updated or not and exception type does not seem to be that simple with 68060..

It seems to partially decode addressing mode first, for example unimplemented instruction will still generate normal F-line without modifying FPIAR if addressing mode is impossible (for example F<xx>.B An,FPx). But there was also some weird situations that need more testing, for example F<implemented>.X Dn,FPx which seems to work strangely. (But I have already noticed 68060 can work very strangely if instruction is "impossible", for example FMOVEM.X #imm,FPx-FPy does not generate exceptions and also zeroes listed FP registers!. So perhaps it is best to not attempt to emulate it perfectly and simply ignore "impossible" conditions)

I also confirmed FMOVECR always updates FPIAR.

[jotd]

yeah, impossible conditions can be seem as undefined behaviour. Almost noone uses the FPU so even less people use illegal fpu opcodes just to detect if a real 060 is running.

ATM I'm going to try to patch all occurrences of the unsupported instructions in the game by following the line-f calls on 68040 (it works on winuae) and patching to avoid the trap (would save time).

for instance I think I can safely replace FMOVECR #$32,FP0 by FMOVE #1,FP0 since rounding probably doesn't matter with 1. I don't see the point of using FMOVECR to set FP0 to 1.0...