Re: [hatari-devel] FPU update

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

Am 10.02.2017 um 15:43 schrieb Toni Wilen <twilen@xxxxxxxxxx>:

>> 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 ...
> 
> The problem is JIT, it has JIT FPU mode which uses native FPU. Then the
> following "problem" is Amiga software, there are many programs that only
> use FPU (without separate non-FPU binary) because it is faster on real
> hardware. 99% of those use very basic math.
> 
> Many users also only want speed, not compatibility. (Usually they want
> both...). If emulation speed would suddenly drop by x% (x being >=5% or
> so), I would get lots of "bug" reports.
> 
> -> I have to support both modes. I also always prefer giving users the
> choice between speed or accuracy. Actually I have habit of giving users
> far too many choices!
> 
I see. I was not thinking about JIT. I never tried using it. Speed does not matter too much for Previous. It is more about compatibility and portability.
Supporting both modes is maybe not the worst idea. Once things are finished, i'll try to measure the speed difference. Maybe i also want to keep some switching, at least compile time. But it is too early to decide now. For now i try to not break native float support while continuing work on SoftFloat.