[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MKSOFTFLOAT for evbppc
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
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
Main Index |
Thread Index |