[libre-riscv-dev] FP unit testing (was Re: [isa-dev] FP reciprocal sqrt extension proposal)

[lkcl]

On Sunday, July 14, 2019 at 10:05:35 AM UTC+1, Jacob Lifshay wrote:
>
> > i am still puzzled as to how a *soft* FP rsqrt implementation may be 
> verified and found to be a correct implementation of the IEEE754  standard. 
> All that's needed is that it provides the correct answers, since the 
> IEEE 754-2008 standard defines exactly what the answer should be in 
> all cases (ignoring different NaN encodings). 
>
>
i should have been clearer: how do we *prove* (or demonstrate, with a high 
degree of confidence) that the answers (from a bigfloat-based frsqrt) are 
correct? this is what aneesh's question comes down to.  when we're using 
sfpy (softfloat-3) it's dead-easy: use a hex-conversion of two operands 
into sfpy.Float32 (or whatever), do a mul/add/div (using operator.mul, 
operator.add etc.), and get the hex bits out of the result instance.

done.  single-operand (fsqrt) works exactly the same way.

except there _is_ no softfloat fRsqrt to do that trick.

does anyone happen to know of a soft-implementation of an IEEE754 
Reciprocal Square-Root anywhere?

l.