English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 13 January 2021, 18:54   #1
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,907
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 19:24.
jotd is offline  
Old 13 January 2021, 19:52   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 840
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, 19:54   #3
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,907
makes sense, but that doesn't confirm the FPIAR WinUAE bug.
jotd is offline  
Old 13 January 2021, 20:51   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,538
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, 21:37   #5
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,907
thanks. That would be appreciated. I'll workaround the issues for now to be able to make progress.
jotd is offline  
Old Yesterday, 00:07   #6
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,907
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 Yesterday, 21:52   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,538
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 Yesterday, 22:38   #8
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,907
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; Yesterday at 22:45.
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 04:03
Hammerfist 1 Disk Unsupported Version! BarryB project.WHDLoad 18 23 September 2018 22:53
Helter Skelter unsupported version! BarryB project.WHDLoad 22 13 February 2017 18:17
microcosm strange trick unsupported turrican3 support.WinUAE 11 28 January 2016 19:52
Maya (le fetiche) looking for unsupported version CFOU! project.WHDLoad 0 05 April 2013 03: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 23:24.


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