[Qemu-devel] Future of SoftFloat use in QEMU

[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

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

On 05/08/2017 09:58 AM, 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.

Our fork is stuck at 2a because the license of 2b had compatibility
problems (it had legal restrictions that prevent interaction with GPL).

> 
> 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.

And this different license is what?

> See: http://www.jhauser.us/arithmetic/SoftFloat-3c/doc/SoftFloat-history.html

which says merely "Replaced the license text supplied by the University
of California, Berkeley." but not WHAT the actual license text is.  Are
we lucky enough that it might have a 2-clause BSD license?

/me goes digging...

http://www.jhauser.us/arithmetic/SoftFloat-3c/doc/SoftFloat.html

>  The following applies to the whole of SoftFloat Release 3c as well as to each source file individually.
> 
> Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017 The Regents of the University of California. All rights reserved.
> 
> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
> 
>     Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer.
> 
>     Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.
> 
>     Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
> 
> THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS”, AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

Not a 2-clause BSD, but sure looks exactly like the stock 3-clause BSD
license.  Yay - https://www.gnu.org/licenses/license-list.en.html says
it is compatible with GPL, and thus we can use it in qemu!

> So any thoughts about what would make the best approach?

No quick thoughts on the best way to proceed, but at least (from my
non-lawyer perspective) it looks like we CAN quit maintaining our fork.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Aurelien Jarno]

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, ...

Do we know if all those changes are also in the new softfloat version,
and if it is not the case if we can work with upstream to implement
that? That seems to me like a pre-requisite before trying to get this
new version in QEMU, either as an option or as the only version.

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

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

[Thomas Huth]

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

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
aurelien@aurel32.net                 http://www.aurel32.net

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

[Daniel P. Berrange]

On Mon, May 08, 2017 at 03:58:59PM +0100, Alex Bennée wrote:
> 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.

Based on way Peter achieved the switch to softfloat 2a, we can
reasonably identify the set of custom QEMU changes to the
original 2a code base.  From that diff, plus the subsequent
git history, it is within realm of practicality to at least
identify areas where we might need enhance/customize version 3.

> 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.

Maintaining our own fork forever certainly feels unappealing,
particularly with the big feature gap you identify for FP16

> 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?

WRT to supporting the FP16 feature, I'd certainly vote for using softfloat3,
over trying to re-implement FP16 ourselves in the old codebase we have a fork
of, even if that means us carrying both versions forever (provided having
both versions present in QEMU doesn't cause us symbol clashes ?).

Incrementally converting existing usage to softfloat3 is reasonable, but
doesn't seem like a decision that needs to be an immediate blocker for
FP16 usage. Given our desire to kill off areas of code which are not actively
maintained, it could be reasonable to set a timebox on softfloat3 conversion
for architectures eg must be completed within 3 release cycles, or we'll
consider the architecture unmaintained and subject for removal.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Richard Henderson]

On 05/08/2017 07:58 AM, 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.

But also now using thread-local globals instead of passing in a structure with 
all of the parameters.  So, really, we'd probably wind up touching every 
function if we were to import it.

> 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.

Another possibility is the code that's shared between the linux kernel 
(include/math-emu) and glibc (soft-fp).  The glibc version has support for f16 
while the kernel doesn't.  But the glibc version is LGPL 2.1, which I'd expect 
to be ok.

It is mildly nasty in that it's a collection of macros, but that's how we 
managed really good performance with the compiler tech of 15 years ago.  On the 
other hand, it would be fairly easy to adjust the support macros to achive 
source compatibility with our current code.

Just a thought...


r~

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

[Peter Maydell]

On 9 May 2017 at 02:56, Richard Henderson <rth@twiddle.net> wrote:
> Another possibility is the code that's shared between the linux kernel
> (include/math-emu) and glibc (soft-fp).  The glibc version has support for
> f16 while the kernel doesn't.  But the glibc version is LGPL 2.1, which I'd
> expect to be ok.
>
> It is mildly nasty in that it's a collection of macros, but that's how we
> managed really good performance with the compiler tech of 15 years ago.  On
> the other hand, it would be fairly easy to adjust the support macros to
> achive source compatibility with our current code.

Having tangled with that collection of macros 15 years ago I
definitely can't recommend it ;-)

thanks
-- PMM

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

[G 3]

> 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.