On Fri, Jul 13, 2012, Warner Losh wrote: > Just to jump back into the fray a bit, since this point hasn't been articulated well. > > On Jul 10, 2012, at 6:55 PM, Peter Jeremy wrote: > > > On 2012-Jul-08 19:01:07 -0700, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote: > >> Well, on the most popular hardware (that being i386/amd64), > >> ld80 will use hardware fp instruction while ld128 must be > >> done completely in software. The speed difference is > >> significant. > > > > AFAIK, of the architectures that FreeBSD supports, only sparc64 > > defines ld128 in the architecture and I don't believe there are any > > SPARC chip implementations that implement ld128 math in hardware. > > We shouldn't be gating the new math on an issue that only affects sparc64 machines. If they have ld80 level of support for that architecture, then that is sufficient to get things into the tree. There's no real benefit from making numerics good on sparc64 for the project, since our support for the platform isn't stellar and the platform itself is getting a bit long in the tooth. > > That said, if people want to do it, be my guest. If it is important enough to catch someone's attention, then it is important enough to have. It just isn't important enough to be a gating factor if nobody has signed up for it yet. I have generally encouraged people to develop both at the same time, for three reasons: 1. Development is more efficient that way. When the algorithm is fresh in your mind, it's just a question of changing the constants and polynomials. 2. The 128-bit format is increasingly being supported on other platforms via software emulation (e.g., __float128 in gcc) and may be more widely supported in hardware in the future. 3. If the ld128 implementations don't happen at the same time as the ld80 versions, it becomes a pain for ports folks, and furthermore, it may *never* get implemented. But you are right that ld128 should not be a blocking issue. If ld128 is preventing people from making progress, then that work should definitely be deferred.Received on Sat Jul 21 2012 - 12:21:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC