Re: MKSOFTFLOAT for evbppc
Matt Thomas <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.powerpc |
|---|---|
| Message-ID | <[email protected]> |
On Sep 26, 2012, at 12:35 PM, David Brownlee wrote: > 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). ABI is incompatible since it changes what values are passed in normal .vs. floating point registers.