[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Future of SoftFloat use in QEMU
From: |
Thomas Huth |
Subject: |
Re: [Qemu-devel] Future of SoftFloat use in QEMU |
Date: |
Mon, 8 May 2017 17:58:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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:
- https://bugs.launchpad.net/qemu/+bug/645662
- 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...
Thomas