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...

[Toni Wilen]

winuae.7z updated, FPIAR is now updated, at least in any sane unimplemented instruction situation.

Does the game (TFX?) really use 68040+ unimplemented instructions in main loop? Using 6888x FPU in a game feels strange, 6888x is relatively slow (68040+ is fast), normal integer math should be faster and accuracy should be more than enough for a game..

[ceztko]

Originally Posted by Toni Wilen

Using 6888x FPU in a game feels strange, 6888x is relatively slow (68040+ is fast), normal integer math should be faster and accuracy should be more than enough for a game..

If we are talking about [ Show youtube player ] game, then flight simulators are definitely one kind of games that would benefit from using Floating Point arithmetic for accuracy, and FPU for performance. Programming would definitely be much more simple basically handling all the world coordinates using a single type.

Originally Posted by Toni Wilen

Does the game (TFX?) really use 68040+ unimplemented instructions in main loop?

Maybe bad compiler?

[jotd]

There are definitely FPU calls in the loop.

Beside the trigonometric calls, there are 2 only unsupported calls types:

FINTRZ (rounding)
FMOVECR (move rom constants)

I've checked the rounding code and it looks complicated to handle all the cases.
If the values are small, provided that FPCR is properly configured I was thinking about

    move.l  d0,-(a7)
    fmove  fpcr,-(a7)
    fmove  #$10,fpcr
    fmove.l fp0,d0
    fmove.l d0,fp1
    fmove (a7)+,fpcr
    move.l  (a7)+,d0

not bad compiler. There were never a 040 version (there were, but the one on the CD is unusable). 040 uses 020 version which uses integer arithmetic as Toni guessed.

And yes, the on-chip FPU calls are not that performant, which explains that they decided not to waste silicon and go software instead. Depending on the application, interpolation tables may be enough.

btw thanks Toni for the winuae beta. Is there a new beta downloadable? only got b15 which is one week old.

[ceztko]

Originally Posted by jotd

040 uses 020 version which uses integer arithmetic as Toni guessed.

We all know that Toni has the crystal ball .
Still, I didn't understand if the game has executables that uses the FPU at all (at least partially), or if the game is 100% integer arithmetic. Can you clarify? Thank you very much.

[jotd]

The game has 100% integer arithmetic version and 68881 based FPU versions. No 68040+FPU version exist.

68040 & 68060 don't have 68881 but it can be emulated by software. 680x0.library does that, as well as MuRedox, Oxypatcher, Cyberpatcher, of course it can also fail depending on the program.... Within whdload those programs are inactive and I had to install my own fpu emulation (built from Motorola FPSP sources)

[Toni Wilen]

Some new information about FPIAR behavior (FPSP for 68060 comes with test code which I didn't notice previously. It was mentioned in Hatari mailing list few days ago)

68060: Almost all FPU instructions update FPIAR, even if it does not cause exception.

68040: same as 68060 except FPU instructions like FScc, FTRAPcc, FBcc and DBcc don't modify FPIAR. (Perhaps others too)

6888x: FPIAR is only updated if instruction caused arithmetic exception.

[jotd]

as you said before, even if FPIAR is updated more than it should, that allow FPSP to work. In other cases we don't need it.

I'll suppose you'll publish a new beta when it's ready.