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
Given all the features this new library has I suggest we do upgrade
to Softfloat 3c. Your idea on keeping both two versions of this
library until all targets have been converted sound like an effective
plan.
