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

Reply via email to