Re: [Qemu-devel] Future of SoftFloat use in QEMU
On 9 May 2017 at 02:56, Richard Hendersonwrote: > 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
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.
Re: [Qemu-devel] Future of SoftFloat use in QEMU
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
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 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Future of SoftFloat use in QEMU
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
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
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 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Future of SoftFloat use in QEMU
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 signature.asc Description: OpenPGP digital signature
[Qemu-devel] Future of SoftFloat use in QEMU
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