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
> > <s...@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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
