[Qemu-devel] Future of SoftFloat use in QEMU

[Alex Bennée]

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.

So what else can we do?

We could investigate having both libraries included in QEMU. It seems
the API has changed quite a bit so that might be possible although there
would be hackage involved in having two different softfloat.h's
involved.

This would be useful if we wanted to take a piecemeal approach to
updating the library. For example we could just use softfloat3 when we
need the newer features (e.g. FP16).

Or we could convert one architecture at a time so each qemu binary links
against either a version 2 or version 3 softfloat library. Of course
that does run the risk of permanently holding two versions of softfloat
in the code if the less maintained guest architectures don't convert
quickly.

So any thoughts about what would make the best approach?

--
Alex Bennée