Re: [hatari-devel] FPU update

[Thomas Huth <th.huth@xxxxxx>]

Am Sat, 11 Feb 2017 11:44:09 +0100
schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:

> Am 11.02.2017 um 08:38 schrieb Thomas Huth <th.huth@xxxxxx>:
> 
> > Am Wed, 8 Feb 2017 12:40:02 +0000
> > 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.  
> > 
> > You could also try to compile with USE_SOFT_LONG_DOUBLE ... maybe
> > that helps with your precision problems, too?
> > 
> > Thomas
> >   
> USE_SOFT_LONG_DOUBLE has been removed a while before (2014). It never
> did anything else than preserve full size data in FPU registers on
> systems, that have no extended precision floats (not all bits fit in
> double precision and are effectively lost). This was only useful, if
> data was copied to and from memory using FPU registers without any
> arithmetic operations. It did not affect precision of calculations.

Sorry, I meant USE_LONG_DOUBLE. I got confused by the left-over
USE_SOFT_LONG_DOUBLE in sysconfig.h (hint to Toni: That obviously can
be removed now).

 Thomas