English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 13 January 2021, 17:54   #1
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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
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)

Last edited by jotd; 13 January 2021 at 18:24.
jotd is offline  
Old 13 January 2021, 18:52   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,151
Quote:
Originally Posted by jotd View Post
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.


Quote:
Originally Posted by jotd View Post
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.
Thomas Richter is offline  
Old 13 January 2021, 18:54   #3
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
makes sense, but that doesn't confirm the FPIAR WinUAE bug.
jotd is offline  
Old 13 January 2021, 19:51   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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).
Toni Wilen is online now  
Old 13 January 2021, 20:37   #5
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
thanks. That would be appreciated. I'll workaround the issues for now to be able to make progress.
jotd is offline  
Old 13 January 2021, 23:07   #6
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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.
jotd is offline  
Old 14 January 2021, 20:52   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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.
Toni Wilen is online now  
Old 14 January 2021, 21:38   #8
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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.
jotd is offline  
Old 16 January 2021, 09:46   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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..
Toni Wilen is online now  
Old 16 January 2021, 10:26   #10
ceztko
Registered User
 
Join Date: Aug 2006
Location: Italy
Posts: 98
Quote:
Originally Posted by Toni Wilen View Post
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.

Quote:
Originally Posted by Toni Wilen View Post
Does the game (TFX?) really use 68040+ unimplemented instructions in main loop?
Maybe bad compiler?
ceztko is offline  
Old 16 January 2021, 13:07   #11
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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
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.

Last edited by jotd; 16 January 2021 at 14:37.
jotd is offline  
Old 19 January 2021, 20:31   #12
ceztko
Registered User
 
Join Date: Aug 2006
Location: Italy
Posts: 98
Quote:
Originally Posted by jotd View Post
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.
ceztko is offline  
Old 19 January 2021, 21:08   #13
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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)
jotd is offline  
Old 20 January 2021, 20:31   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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.
Toni Wilen is online now  
Old 20 January 2021, 21:02   #15
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 5,489
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.
jotd is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.17629 seconds with 15 queries