Re: MKSOFTFLOAT for evbppc

[Matt Thomas <matt%3am-software.com@localhost>]

On Sep 26, 2012, at 12:35 PM, David Brownlee wrote:

> On 26 September 2012 19:48, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>> 
>> Matt Thomas <matt%3am-software.com@localhost> writes:
>> 
>>> On Sep 20, 2012, at 8:31 PM, Simon Burge wrote:
>>> 
>>>> Matt Thomas wrote:
>>>> 
>>>>>> (Also, for the port page: does fp emulation via traps work?  Or is
>>>>>> MKSOFTFLOAT the only way that can possibly work?)
>>>>> 
>>>>> Within the past 4 months or so, I added emulation of the FPU so you can
>>>>> run without MKSOFTFLOAT=yes.
>>>> 
>>>> It looks like we've still got the same FPU emulator from the Walnut
>>>> (405GP) days.  Way back when (2001?), softfloat was orders of magnitude
>>>> faster on a Walnut.  There's the timings for an awk command issued
>>>> during a kernel build at the time:
>>>> 
>>>>    emulate:       113.554u 2778.750s 52:30.75 91.7%
>>>>    softfloat:       7.607u    1.447s  0:10.57 85.5%
>>>> 
>>>> This was the only reason we did softfloat at the time.
>>> 
>>> On a P2020, a build.sh distribution for evbppc took 6.2% less time on
>>> a softfloat userland .vs. hardfloat userland with kernel-emulation.
>>> 
>>> 10h55m32s (soft) vs. 11h38m50s (hard)
>> 
>> So it's good to hear that trapfloat (?) works (did you install that
>> build?), but 6% seems like enough that using softfloat is in order.
>> But, I see the point that having one userland usable on all evbppc is
>> nice, and perhaps not worth 6% in the standard distribution, since using
>> softfloat on machines with hardfloat (not trapfloat) is surely vastly
>> slower.
> 
> How much of this might be gained back by just a softfloat compiled
> libm and possibly libc (or is the ABI incompatible).

ABI is incompatible since it changes what values are passed in normal
.vs. floating point registers.