Re: [gem5-dev] Review Request 2018: ext: Include Bochs's SoftFloat implementation

[Andreas Sandberg]

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
[2] 
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 <n...@binkert.org> 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 <sa...@umich.edu> wrote:

On Sep 20, 2013, at 3:25 AM, Andreas Sandberg <andr...@sandberg.pp.se>
wrote:

On 09/20/2013 12:29 AM, Steve Reinhardt wrote:
On Thu, Sep 19, 2013 at 2:21 PM, Nathan Binkert <n...@binkert.org<mailto:
n...@binkert.org>> 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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev


_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev