[libre-riscv-dev] FP unit testing (was Re: [isa-dev] FP reciprocal sqrt extension proposal)
lkcl
luke.leighton at gmail.com
Thu Jul 25 11:01:40 BST 2019
On Thursday, July 25, 2019 at 10:17:57 AM UTC+1, Jacob Lifshay wrote:
>
> do you happen to know if that's the exact order in which those tests have
> to be actioned? the reason i ask is because i got caught out when doing
> fpsqrt special cases: i'd placed zero-testing later in the list, tested -ve
> numbers (all -ve numbers) first to return canonical-NaN, and of course
> sqrt(-ve zero) is -ve zero.
>
> Those cases are more like a switch statement in C with breaks in that
> each case is independent:
>
ah ok.
> > this one "-0 -> -Inf" kiiinda makes sense if the 1/ is considered to
> take precedence over sqrt() part.
> yeah, but it makes it more annoying since otherwise the sign of the
> result (ignoring NaNs) is always positive, like you would expect from
> the mathematical limits at 0 and infinity.
>
> If I recall correctly the actual definition of reciprocal sqrt in IEEE
> 754 is (expanded):
> fn frsqrt(v) {
> let temp = sqrt(v); // IEEE 754 sqrt except it returns the exact
> mathematical result without rounding
> return 1.0 / temp; // IEEE 754 division; rounds the result
> }
>
> the reason frsqrt(-0) returns -Inf is that IEEE 754 sqrt(-0) returns
> -0 which then gets converted to -Infinity.
>
ok cool.
ah ha! right! i have an idea. if softfloat-3 rounding can be switched
*off* [just checked: unfortunately it doesn't look like there's a mode to
do that). or, i know: if it's really that simple, that's really not so
hard to add a patch to softfloat-3 to support fprsqrt.
cc'ing john hauser: john, what do you think?
l.
More information about the libre-riscv-dev
mailing list