Re: [hatari-devel] FPU update

Am 08.02.2017 um 13:40 schrieb Douglas Little <doug694@xxxxxxxxxxxxxx>:

Hi,

I'm not sure if there are any remaining problems in 6888x emulation. I am thinking about what could be tested, but most things have been tested through Douglas' great test utility and some things have been tested by Toni separately.
I think 68040 might be incorrect for some conditions, especially related to nonmaskable overflow and underflow exceptions (inexact bit set, where it shouldn't). But it that makes more sense to test and fix that while adding 68040 arithmetic exception handling.
So what is next? We need a SoftFloat routine to convert between extended precision and packed decimal floats! This is commonly used, but quite faulty with native floats. Any ideas?

I'll need to get a recent build with new changes brought into Hatari soon so I can see all the progress.

I'm quite interested to see if the HW-backed float support still has relevant bugs (other than precision differences which I accept should remain). I mean things like (0.5+/-epsilon) rounding up or down in different rounding modes, or common condition flags not being set, or being set inappropriately - that's the kind of thing that can cause breakage.

I'm thinking that the tests can be modified further to ignore small differences in computed values but observe big differences which stem from bugs. I won't actually do this yet but will look into it later on... I'll also upgrade the tests to be more comprehensive at the same time.

For now I'll take a break from it though. Good to see so much progress on float emulation support :)

D

There are definitely bugs remaining with native floats. The most severe one is related to the way that x87 handles denormalized extended precision numbers. All denormalized numbers will be be wrong by factor 2.

I think we might see some rounding errors, of which most will be not relevant for normal use. There will be some wrong inexact exceptions. I also expect to see wrong outputs (infinities, zeros) when underflow and overflow occurs. There might even occur underflows or overflows that should not occur, if the results are close to the thresholds. These things might lead to wrong condition codes being set.

I don't know exactly how x87 handles NaNs, but i suspect some differences in NaN handling, especially for signaling NaNs. Maybe signaling NaNs can't even be detected. Some functions, like FMOD, can't be emulated correctly (e.g. impossible to return quotient bits). For exception handling it will be impossible to return intermediate results, that should go into the FSAVE stack frames. If extended precision floats are not supported by the system or compiler, emulation will fail for numbers that are out of double precision range ....

Finally, and i think this is the worst thing at all, results will differ between different platforms (x86_64, ARM, POWER, etc).

I think once things are finished it makes sense to do some performance measuring and then decide, if there is any reason to keep native float code.