Re: [hatari-devel] FPU update

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

Am 08.02.2017 um 19:48 schrieb Toni Wilen <twilen@xxxxxxxxxx>:

>> There are definitely bugs remaining with native floats. The most severe
>> one is related to the way that x87 handles denormalized extended
> 
> <snip>
> 
> IMHO attempting to fix those are not worth the trouble but also remember
> that there is huge difference between Next and Amiga (and I assume Atari
> too) FPU use cases.
> 
> FPU is mostly used for basic maths and OS does not use or require FPU.
> Only (much) more expansive models had FPU. Practically no one uses FPU
> instructions like FMOD or arithmetic exceptions and so on (I guess some
> complex 3d renderers may be an exception). It is mainly add, sub, neg,
> abs, mul, div, tst and cmp, no too small or too large numbers used.
> Native FPU is perfectly fine in this use case.
> 
> Then there is Next that is something completely different, FPU is
> standard, OS uses FPU for everything possible (and more!) where small
> rounding or accuracy errors can cause corrupted desktop graphics or
> fonts. It even uses packed FPU datatype heavily. Softfloat being the
> default (or even the only option) makes sense in this situation.
> 

I agree that for NeXT it might make more sense due to heavy usage of floats. But isn't it risky to keep known bad floating point emulation for the other systems? I think some applications will still make use of the floats and then one might run into problems (maybe depending on the host system platform).
As an example: There is some special piece of software for the NeXT that effectively turns it into a Mac. Mac OS did not explicitly require and FPU. But with the FPU emulation used in Hatari 2.0.0 even the simple calculator (only does + - * /) crashed the whole system due to bad FINT emulation. Many other applications also caused crashes due to the same issue.
I don't say that Hatari needs to use SoftFloat. I just wonder, why not use it? No more sorrows with floats ...