Shouldn't softfloat FPU mode compatibility be 100%?

[softwarefailure]

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?

[Toni Wilen]

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.

[softwarefailure]

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

[Toni Wilen]

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)

[softwarefailure]

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.

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?

[Toni Wilen]

68020+68881 works fine here too. Perhaps you have JIT FPU enabled. It probably isn't fully 80-bit compatible.

[softwarefailure]

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.

[Toni Wilen]

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.

[softwarefailure]

But the WB installation *is* exactly the same every time...

[Toni Wilen]

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?

[softwarefailure]

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]

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

[Toni Wilen]

It requires codesets.library (and probably much more). I am not going to find correct versions, sorry..

[softwarefailure]

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.

[Toni Wilen]

cybergraphics is not a problem but any other library must be exact same. Could you attach it with the test executable?

[softwarefailure]

Sure, here it is: https://gofile.io/?c=7VWx0O

[Toni Wilen]

I still can't duplicate.

80-bit (both host and softfloat):

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

64-bit:

{
        "inttable": [
                1.0000000000000002,
                2.0000000000000004,
                3.0000000000000004,
                4.0000000000000008,
                5.0000000000000008
        ]
}

[softwarefailure]

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.

[Toni Wilen]

Originally Posted by softwarefailure

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?

[softwarefailure]

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:

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

My CPU/FPU settings for the test are attached to this post.

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:

{
	"inttable": [
		1.0000000000000004,
		2.0000000000000008,
		3.0000000000000013,
		4.0000000000000017,
		5.0000000000000017
	]
}