FPU glitches

[PeterK]

You could try to run SnoopDos and write the log to a disk.

I think the problem could be that demo coders don't initialize the FPU configuration for their needs, just relying on the default setting for a new task, which is Extended Precision and Round To Nearest. But it could be a wrong assumption that the execution of the demo was the first thing that their task did and that the FPU is still configured to the default settings.

So, how do you start your demos? Did you try it with Run in order to create a new task?

[hexaae]

I usually run them from scripts (with icon and IconX...). Directly from shell is the same and I can reproduce the FPU math issue... would change using "run IkanimHires"?

Ikanim seems to open just graphics.library
TME uses mathieeesignbas, mathieeedoubtrans, mathieeedoubbas

[PeterK]

Originally Posted by hexaae

... would change using "run IkanimHires"?

I cannot predict what's going to happen then ... I would never play demos or games ...

Ikanim seems to open just graphics.library
TME uses mathieeesignbas, mathieeedoubtrans, mathieeedoubbas

graphics.library is ok, but TME should better set the FPU configuration correctly before it starts the demo, I don't expect that it uses the mathlibs for demo itself, that would be strange.

[Foebane]

I just ran the demo (download from Pouet.net) with no issues on my fastest WinUAE configuration. Maybe the framerate was lower, but I don't really care about that. My main WinUAE is 4.2.0 .

[Toni Wilen]

Moved all FPU related posts here from beta thread and renamed thread.

[Thomas Richter]

Yes, Peter's information is accurate. The 3.9 variants set the FPU mode to "round to zero", singbas to single precision, doubbas to double precision. 3.1.4 sets the precision of "singbas" to "double precision" as a "round to zero in double" followed by a "convert to single" gives the same result as "round to zero with single precision". mathieeedoubbas rounds to zero in double precision. This has the advantage that you can use singbas and doubbas intermixed, but it still has the problem of non-ideal precision.

From 3.2 onwards, math libraries consistently round to nearest (IEEE aware rounding), both the FPU and the CPU implementation, the "singbas" to single precision and the "doubbas" to double precision.

This is, from a numerical point of view, the most robust and most precise setting, though it means that you cannot, unfortunately, mix singbas and doubbas (same as 3.9 and below).

Especially, keeping the FPU in extended precision all the time, but only rounding results to single/double can cause some numerical artefacts (however, only for double precision, not for single, as strange as it sounds).

If you want more reading for all the motivation:

https://docs.oracle.com/cd/E19957-01..._goldberg.html

[hexaae]

OS 3.2 turn (spoiler: the winner is 80bit host! )

mathffp.library 46.1 ( 4-Ago-2019)
mathieeesingbas.library 47.1 ( 5-Mag-2019)
mathtrans.library 47.1 (13-Feb-2020)
mathieeesingtrans.library 45.11 ( 6-Mag-2018)
mathieeedoubtrans.library 47.2 (24-Ago-2020)
mathieeedoubbas.library 47.2 (27-Apr-2020)

Tested IkanimHires and The Martini Effect on OS3.2 fresh install using above mathlibs and...

IkanimHires: no glitch in 64bit host, 80bit host (even after Restart! I can see glitches on OS3.9 setup instead!) and 80bit soft.
TME: 64bit host glitch (same as with OS3.9), no glitch in 80bit host and 80bit soft.

Run <demo.exe> doesn't change results.

EDIT: other test using above libs from OS3.2 in OS3.9:Libs/ and... same results as above! Indeed mathlibs used have a role together with WinUAE math FPU settings with these two demos...

[PeterK]

The 64 bit host cannot be perfect, because some calculations depend on the Microsoft compiler.

@Thomas Richter

I made some tests with one of the examples for double rounding from your link above. All Mathlibs that I tested returned the same results.

But I didn't test the other examples yet. Am I doing something wrong in my test code? Try it out.


Update: Yes, the second example (t=s+y) produces indeed a double rounding issue with my mathlibs, but not with the OS mathlibs.

It seems to be exactly the constellation that I already described some years ago in our A1k.org discussion. The results of these special cases are never accurate anyway and the error is only 50% of the least significant bit of huge numbers, nearly the same amount as with the OS mathlibs, but just rounded up, not down.

It already rounds up instead of down, but only at the highest fragment bit sequence where rounding down is still possible and expected. The additional relative error is very low and this sort of double rounding happens quite rarely, so I won't care, because it has more disadvantages to use Double Precision all the time than getting these double rounding errors.

[PeterK]

Just found this statement on the TME page: https://www.pouet.net/prod.php?which=88640

FPU temporary registers:
The demo changes the FPU rounding/internal precision mode so that 32-bit values can be stored in FPU registers without getting corrupted. This way one can store addresses and integers in tmp FPU regs instead of spilling them to RAM.

No further questions ...

[Thomas Richter]

There is a "Paranoia test" which performs a really systematic checking for numerical glitches. The 3.2 CPU libraries are the first version that passes without glitches, the FPU version does so anyhow (the latter is not new, of course).

If floating point is implemented correctly, the result of a numerical operation (A op B) is precise in the sense that you would get exactly the same result by first performing A op B with infinite precision, and then round to the target precision.

[PeterK]

Thanks for the hint, Thomas,

... but where is a download link for that "Paranoia test"?

Sounds interesting, and yes, "Paranoia" might be the the right term for some of these fears, at least for the 2. double rounding example. It's about half a grain of sand in the Sahara desert, with the OS libs it's missing, with my libs it's too much.

But I'm curious about what this test could reveal. Maybe, there are more serious bugs, too?

[Toni Wilen]

Just reminding that 64-bit and 80-bit host modes are not meant to be compatible, only fast by using x87 FPU directly without compatibility adjustments. Which is more than enough when running mostly "normal" programs.

80-bit softfloat is the only fully accurate mode (and slow mode) which handles all Motorola FPU special cases.

[Thomas Richter]

Originally Posted by PeterK

Thanks for the hint, Thomas,

... but where is a download link for that "Paranoia test"?

Sorry, here:


paranoia.zip


This is the double precision version. Compiling for single precision (mathieeesingbas) is more tricky and requires a "hacky" approach since SAS/C does not support it natively.

Originally Posted by PeterK

Sounds interesting, and yes, "Paranoia" might be the the right term for some of these fears, at least for the 2. double rounding example. It's about half a grain of sand in the Sahara desert, with the OS libs it's missing, with my libs it's too much.

It rather depends on the application, doesn't it? For numerical applications, it does since such errors accumulate, depending on the stability of the numerical algorithm.

Originally Posted by PeterK

But I'm curious about what this test could reveal. Maybe, there are more serious bugs, too?

There are quite a number of tests in this test set, and the original version fluked multiple of them - you may want to look yourself.

[PeterK]

Thank you for the tests, Thomas.
It may take some time until I get it compiled, because I didn't touch the SASC-compiler the last 20 years anymore, and I never compiled anything with it more sophisticated than "hello world" or similar, before I finally moved to Assembler.