13 January 2021, 17:54 | #1 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
FPIAR not updated on unsupported FPU instruction?
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: Code:
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 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) Last edited by jotd; 13 January 2021 at 18:24. |
13 January 2021, 18:52 | #2 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
Quote:
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. 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. |
|
13 January 2021, 18:54 | #3 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
makes sense, but that doesn't confirm the FPIAR WinUAE bug.
|
13 January 2021, 19:51 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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). |
13 January 2021, 20:37 | #5 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
thanks. That would be appreciated. I'll workaround the issues for now to be able to make progress.
|
13 January 2021, 23:07 | #6 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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. |
14 January 2021, 20:52 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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. |
14 January 2021, 21:38 | #8 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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... Last edited by jotd; 14 January 2021 at 21:45. |
16 January 2021, 09:46 | #9 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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.. |
16 January 2021, 10:26 | #10 | |
Registered User
Join Date: Aug 2006
Location: Italy
Posts: 109
|
Quote:
Maybe bad compiler? |
|
16 January 2021, 13:07 | #11 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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 Code:
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 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. Last edited by jotd; 16 January 2021 at 14:37. |
19 January 2021, 20:31 | #12 | |
Registered User
Join Date: Aug 2006
Location: Italy
Posts: 109
|
Quote:
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. |
|
19 January 2021, 21:08 | #13 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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) |
20 January 2021, 20:31 | #14 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,506
|
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. |
20 January 2021, 21:02 | #15 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Demos to test FPU on SX32 MkII (020+FPU) | Rochabian | request.Demos | 1 | 21 April 2020 03:03 |
Hammerfist 1 Disk Unsupported Version! | BarryB | project.WHDLoad | 18 | 23 September 2018 21:53 |
Helter Skelter unsupported version! | BarryB | project.WHDLoad | 22 | 13 February 2017 17:17 |
microcosm strange trick unsupported | turrican3 | support.WinUAE | 11 | 28 January 2016 18:52 |
Maya (le fetiche) looking for unsupported version | CFou! | project.WHDLoad | 0 | 05 April 2013 02:46 |
|
|