Re: [Qemu-devel] Future of SoftFloat use in QEMU

[Aurelien Jarno]

On 2017-05-08 17:58, Thomas Huth wrote:
> On 08.05.2017 17:36, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2017-05-08 15:58, Alex Bennée wrote:
> >> Hi,
> >>
> >> We've got a task coming up to implement half-precision floating point
> >> (FP16) for ARMv8.2. As you know pretty much all our floating point in
> >> QEMU is handled by our internal fork of John R. Hauser's BSD SoftFloat
> >> library. Our current implementation is based on version 2a which doesn't
> >> support FP16.
> >>
> >> As it happens there has been a new release of SoftFloat recently.
> >> Version 3 is a complete re-write which made a number of changes, some
> >> notable ones being:
> >>
> >>   - Complete rewrite, different use license than earlier releases.
> >>   - Renaming most types and functions, upgrading some algorithms
> >>     - restructuring the source files, and making SoftFloat into a true 
> >> library.
> >>   - Added functions to convert between floating-point and unsigned 
> >> integers, both 32-bit and 64-bit (uint32_t and uint64_t).
> >>   - Added functions for fused multiply-add, for all supported 
> >> floating-point formats except 80-bit double-extended-precision.
> >>   - Added support for a fifth rounding mode, near_maxMag (round to 
> >> nearest, with ties to maximum magnitude, away from zero).
> >>
> >> And in the most recent release as of February 2017, 3c:
> >>
> >>   - Added optional rounding mode odd (round to odd, also known as jamming).
> >>   - Implemented the common 16-bit “half-precision” floating-point format 
> >> (float16_t)
> >>
> >> See: 
> >> http://www.jhauser.us/arithmetic/SoftFloat-3c/doc/SoftFloat-history.html
> >>
> >> Of course the softfloat in QEMU's tree hasn't been static either. We've
> >> made numerous changes over the years to add and fix various features,
> >> including features that have since been added to the upstream softfloat.
> >> It seems unlikely we could switch to the newer softfloat without risking
> >> breaking something. However if we look at back-porting stuff from the
> >> newer library we essentially get to own our version of softfloat
> >> forever.
> > 
> > There have been many many changes in our forked version of softfloat:
> > qNaN/sNaN, IEEE754-2008 functions, squash input denormal, many floatx80
> > fixes, ...
> 
> Note that we've apparently also got plenty of bugs in our version of
> softloat left, for example:

I don't say that our version of softfloat is bug free, but I would not
blame softfloat without further investigation:

> - https://bugs.launchpad.net/qemu/+bug/645662

qemu/i386 doesn't use softfloat for many instructions, but rather rely
on the float/double type of the host. This is mostly because softfloat
doesn't provide directly usable trigonometric functions. There are also
a few simple ones that might be more easily converted to softfloat.

> - http://lists.nongnu.org/archive/html/qemu-ppc/2017-05/msg00187.html
> 
> ... would be interesting to know whether such issues are fixed with the
> newer version of softfloat...

The exception flags are likely to be a bug in the PowerPC
implementation, as this CPU provides more fine grained exception than
what softfloat provides. The actual wrong answers which match the
expected fpscr value look very suspicious to me.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net