Seems like we could simply have both in the tree, default to fputils, but give softfloat as a compile option.
Also, has anyone tried to contact the author to ask for a BSD or MIT license? Nate On Sat, Sep 21, 2013 at 8:21 AM, Ali Saidi <[email protected]> wrote: > > On Sep 20, 2013, at 3:25 AM, Andreas Sandberg <[email protected]> wrote: > >> On 09/20/2013 12:29 AM, Steve Reinhardt wrote: >>> On Thu, Sep 19, 2013 at 2:21 PM, Nathan Binkert <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> > On Sept. 19, 2013, 9:17 p.m., Ali Saidi wrote: >>> > > please don't commit. The language in the license seems >>> troubling to me at least. >>> >>> Really? What part? I looked at it, and it doesn't seem >>> particularly problematic. >>> >>> >>> The blanket indemnification seems like a concept that lawyers might balk >>> at. I don't recall seeing a phrase like this before; it seems like a step >>> beyond the "no warranty" BSD clause. Is this a standard open-source >>> license? >> >> It's not. I've done some more digging and it seems like Cisco are using >> SoftFloat with the troublesome license. Linux on the other hand uses an >> older version of SoftFloat, which doesn't contain the most troublesome parts >> of the licence. However, there was some debate over the issue [1] some time >> ago. In the end, they decided to keep softfloat since they are using an >> older version [2]. See [3] for the source. >> >> I think we need to include something like softfloat to properly support >> floating point properly, especially on x86, in the long term. In the short >> term, there are several fixes for x86 that require support for converting >> to/from 80-bit floats. >> >> As I see it, there are three solutions if the licence turns out to be a >> blocker: 1) We use the softfloat version in the kernel. This probably >> requires a bit of hacking to get it to work in our environment. It's should >> bre doable, but we need to be careful to avoid GPL problems. 2) We use >> inline assembly which is supported by both clang and gcc. This makes it >> impossible to compile gem5's x86 frontend for anything other than x86. 3) We >> include libfputils which I wrote some time ago. It currently supports >> conversion to and from 80-bit floats and can identify float classes >> (different types of NaNs, infinities, etc.). Its main limitation when >> converting from 80-bit floats to doubles is that it truncates the mantissa >> (rounds towards zero) instead of doing proper rounding. This code is BSD, so >> there are no licensing issues here. >> >> I'd like to see this resolved quickly, I only have a limited time window to >> merge the gem5 patches from my previous project and that window is quickly >> coming to an end. My guess is that using libfputils is the quickest route to >> solving the problem, but using softfloat from the kernel is a better long >> term solution. >> >> //Andreas >> >> [1] >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162121.html >> [2] >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html >> [3] >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/nwfpe/softfloat.h >> [4] https://github.com/andysan/libfputils >> > Seems like fputils is the fastest way forward. > Ali > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
