Thanks, Andreas. It seems to me at this point that having a clean interface to fputils is the best short-term solution. Then we can defer until later the decision about which version of SoftFloat to incorporate (or perhaps in the long run we could end up with both, if there's any rationale for that... e.g., if there is additional functionality in the new version that some people might think is worth the license hassle but others may not).
Or maybe we'll be happy with fputils and we can leave the decision hanging indefinitely. Steve On Sun, Sep 22, 2013 at 4:08 AM, Andreas Sandberg <[email protected]>wrote: > OK, I'll prepare a patch to include fputils and make sure to have a clean > interface between the affected x86 code and fputils to make a future switch > as painless as possible. > > It seems like both Linux [1] and FreeBSD [2] are using an old version of > SoftFloat with a BSD-/GPL-friendly license. I'd argue that "if it works for > FreeBSD, it should work for us". We could just port FreeBSD's > implementation instead of Linux's and be sure to not include any GPL code > by accident. > > I'm pretty sure I've read somewhere that the author has been asked to > change the license to BSD/MIT, or at least remove the indemnification > clause, without success. > > //Andreas > > [1] http://lists.infradead.org/**pipermail/linux-arm-kernel/** > 2013-April/163904.html<http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html> > [2] https://github.com/freebsd/**freebsd-head/blob/master/lib/** > libc/softfloat/softfloat.txt<https://github.com/freebsd/freebsd-head/blob/master/lib/libc/softfloat/softfloat.txt> > > > On 09/21/2013 08:25 PM, Steve Reinhardt wrote: > >> I would not want anything with a non-standard license in the main repo. >> >> Getting the code re-licensed would be ideal and make this problem go away. >> >> Short of that, I think the most thorough solution is along the lines of >> what Nate proposes: have some internal interface that allows either >> fputils >> or softfloat to be used, and default to fputils, but allow people to >> compile in sofftfloat as an option. I think they should be required to >> download softfloat separately though; might as well just point them to the >> softfloat download page if we don't require any changes to the library to >> link it in. If we do require some changes, we could keep it as a separate >> repo on our server. >> >> If that's too much work though, I'm fine with just sticking with fputils >> for now, and leaving the softfloat integration as future work. >> >> Steve >> >> >> >> On Sat, Sep 21, 2013 at 9:35 AM, nathan binkert <[email protected]> wrote: >> >> 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<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<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<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/nwfpe/softfloat.h> >>> >>>> [4] >>>> https://github.com/andysan/**libfputils<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<http://m5sim.org/mailman/listinfo/gem5-dev> >>>> >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> >>> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >> >> > ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
