English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 01 November 2019, 22:45   #1
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Shouldn't softfloat FPU mode compatibility be 100%?

So I have this little test program to convert a double to a string with utmost precision (DBL_DECIMAL_DIG). When trying to convert the double "3" to a string that way, the output on WinUAE is:

a) 2.9999999999999991 for Host (64-bit)
b) 3.0000008583071302 for Host (80-bit)
c) 3.0000000000000008 for Softfloat (80-bit)

On real hardware, however, the result is just

3

As it should be.

I can understand that the two host modes aren't 100% precise but shouldn't softfloat mode offer 100% compatibility to the results on real hardware?
softwarefailure is offline  
Old 01 November 2019, 23:10   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
Not enough information. Exact same CPU and FPU? If 68040/060 library, same versions? Example binary?

Note that logaritmic and trigonometric instructions are not 100% accurate because no one knows how they work internally (but it isn't really needed, see below)

"Fortunately" real 68040+ does not support them either which means you should still get identical results if 68040/060 and "Unimplemented FPU emu" is NOT ticked (and 68040/060.library is installed). Note that 68040/060 missing logaritmic and trigonometric FPU instruction emulation also does not return 100% identical results compared to 6888x.
Toni Wilen is offline  
Old 01 November 2019, 23:23   #3
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
CPU is set to 68020, 68040.library 43.0, 68060.library 43.1. I've tried to untick "Unimplemented FPU emu" but it doesn't make a difference.

Here is the test binary, maybe you can get it working: https://gofile.io/?c=GaRYfr
softwarefailure is offline  
Old 02 November 2019, 10:55   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
Works for me. "HMM: 3" is result (68040 + softfloat + unimplemented unticked, 46.3 68040.library).

Code executes FLOGN (log) and FETOX (power) instructions. Softfloat uses emulation logic based on Motorola FPSP (68040+ FPU emulation library) for these instructions which should guarantee identical results. Real 68888x may or may not return slightly differrent result. (I can test this later).

Check that you get few "FPU IMPLEMENTED INSTRUCTION/FPU DISABLED EXCEPTION" log lines when you run the code. This means "hardware" FPU didn't implement it and it was trapped and emulated by FPSP.

EDIT: Also same result with unimplemented ticked.

EDIT2: 3 also in 80-bit host mode. Only 64-bit host returns wrong answer (2.9999999999999991)

Last edited by Toni Wilen; 02 November 2019 at 11:15.
Toni Wilen is offline  
Old 02 November 2019, 13:10   #5
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Ok, seems that the problem was using a 68020 CPU. When switching to 68040+(softfloat or host 80bit)+unimplemented unticked it indeed works correctly. When enabling unimplemented it doesn't work correctly for host 80 bit and softfloat with unimplemented enabled only starts to work after the program is executed for a second time. When running it the first time with softfloat+unimplemented enabled, I get 3.0000000000000008. Starting with the second time it's always 3 as it should.

Quote:
Softfloat uses emulation logic based on Motorola FPSP (68040+ FPU emulation library) for these instructions which should guarantee identical results
So does this mean that using 68040+softfloat+unimplemented unticked should be 100% compatible to the results on real 68040 hardware?
softwarefailure is offline  
Old 02 November 2019, 13:16   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
68020+68881 works fine here too. Perhaps you have JIT FPU enabled. It probably isn't fully 80-bit compatible.
Toni Wilen is offline  
Old 02 November 2019, 14:58   #7
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
When using 68020+68881 it doesn't work the first time a program is started, but only starting with the second attempt. The first time the programs returns 3.0000000000000008, then 3 for all consecutive times.
softwarefailure is offline  
Old 02 November 2019, 15:10   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
Can't duplicate. I always get correct result.

It sounds like FPU rounding/precision mode is not set when program starts and FPU mode before program runs is not what program expects. Or something like that.

This is the reason why it is always very good idea to use exact same WB installation when comparing to remove most unknown variables.
Toni Wilen is offline  
Old 02 November 2019, 15:14   #9
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
But the WB installation *is* exactly the same every time...
softwarefailure is offline  
Old 02 November 2019, 15:15   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
I meant same when comparing between emulated and matching real hardware config.

Any other comparison is invalid, especially when using programs that don't take over the system.

EDIT: Does same happen if you run without startup-sequence?

Last edited by Toni Wilen; 02 November 2019 at 15:22.
Toni Wilen is offline  
Old 02 November 2019, 17:34   #11
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Quote:
EDIT: Does same happen if you run without startup-sequence?
No, then it actually works when I start it the first time already.

However, I've just discovered now that my big program, which uses the same code as the small test program to convert a double to a string, never seems to work correctly on UAE. It always prints 3.0000000000000008. On real hardware it prints 3. Quite frustrating to see, just when I thought this was solved
softwarefailure is offline  
Old 02 November 2019, 18:49   #12
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Here is the big test program. It is supposed to print

{"inttable": [1,2,3,4,5]}

But it prints 3.0000000000000008 instead of 3 on WinUAE, even with all the settings discussed above. I just can't get it to work. The code is the same as in the small test program. Strangely, it works in the small program but not in the big one.

https://gofile.io/?c=P6PiW4
softwarefailure is offline  
Old 03 November 2019, 16:58   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
It requires codesets.library (and probably much more). I am not going to find correct versions, sorry..
Toni Wilen is offline  
Old 03 November 2019, 20:26   #14
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Yes, it needs codesets.library and a RTG Amiga (cybergraphics.library). Unfortunately, I couldn't come up with a more compact demo program because when isolating the code it actually works (as shown above) but in the big program it doesn't work correctly on WinUAE, only on real hardware.
softwarefailure is offline  
Old 03 November 2019, 20:31   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
cybergraphics is not a problem but any other library must be exact same. Could you attach it with the test executable?
Toni Wilen is offline  
Old 03 November 2019, 20:38   #16
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Sure, here it is: https://gofile.io/?c=7VWx0O
softwarefailure is offline  
Old 04 November 2019, 19:12   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
I still can't duplicate.

80-bit (both host and softfloat):

Code:
{
        "inttable": [
                1,
                2,
                3,
                4,
                5
        ]
}
64-bit:
Code:
{
        "inttable": [
                1.0000000000000002,
                2.0000000000000004,
                3.0000000000000004,
                4.0000000000000008,
                5.0000000000000008
        ]
}
Toni Wilen is offline  
Old 05 November 2019, 20:17   #18
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Hmm, so any ideas what else I can try to get this to work like on your system? My system is pretty much a naked OS3.9 installation with RTG and AHI. No patches or anything except the ones that come with OS3.9.

What could be the reason that it doesn't work here? I've pretty much tried all combinations imaginable in the FPU settings. And JIT is always off, of course.
softwarefailure is offline  
Old 05 November 2019, 20:24   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
Quote:
Originally Posted by softwarefailure View Post
Hmm, so any ideas what else I can try to get this to work like on your system? My system is pretty much a naked OS3.9 installation with RTG and AHI. No patches or anything except the ones that come with OS3.9.

What could be the reason that it doesn't work here? I've pretty much tried all combinations imaginable in the FPU settings. And JIT is always off, of course.
Any difference if you boot using WB 3.1 disk? (with required lib copied to libs: )
(I tried OS3.9, no difference..)

Do you get same behavior when you select 64-bit FPU? And do you get different or same results as above?
Toni Wilen is offline  
Old 05 November 2019, 20:44   #20
softwarefailure
Registered User

 
Join Date: Mar 2016
Location: Germany
Posts: 58
Quote:
Any difference if you boot using WB 3.1 disk? (with required lib copied to libs: )
I have a plain OS 3.1 installation on WinUAE and it shows the very same result. I get:

Code:
{
        "inttable": [
                1,
                2,
                3.0000000000000004,
                4,
                5
        ]
}
My CPU/FPU settings for the test are attached to this post.

Quote:
Do you get same behavior when you select 64-bit FPU? And do you get different or same results as above?
No, with a 64-bit FPU I get different results. In that case the values are even more off. This is the result with Host (64-bit) mode:

Code:
{
	"inttable": [
		1.0000000000000004,
		2.0000000000000008,
		3.0000000000000013,
		4.0000000000000017,
		5.0000000000000017
	]
}
Attached Thumbnails
Click image for larger version

Name:	cpufpu.PNG
Views:	36
Size:	93.1 KB
ID:	65105  
softwarefailure 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
SoftFloat FPU emulation arti support.WinUAE 6 10 July 2017 15:23
Mode 100 anim compression softwarefailure Coders. General 3 12 January 2015 12:20
Modifying a Panasonic JU-257A515P for 100% compatibility - help desperately needed! lennonlives Hardware mods 1 23 August 2008 14:36
Input --> Compatibility mode... DamienD support.WinUAE 14 30 October 2005 01:21

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 00:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09136 seconds with 16 queries