[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