|
From: | Richard Henderson |
Subject: | Re: [Qemu-devel] Future of SoftFloat use in QEMU |
Date: | Mon, 8 May 2017 18:56:33 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 |
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~
[Prev in Thread] | Current Thread | [Next in Thread] |