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>
______________________________**_________________
