Re: MKSOFTFLOAT for evbppc

On 26 September 2012 19:48, Greg Troxel <[email protected]> wrote:
>
> Matt Thomas <[email protected]> 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).

Thinking about etc.sparc/ld.so.conf:
libc.so.12 machdep.cpu_arch  8:libsparc_v8.so.0,libc.so.12
9:libsparc_v8.so.0,libc.so.12