[libre-riscv-dev] FP unit testing (was Re: [isa-dev] FP reciprocal sqrt extension proposal)
luke.leighton at gmail.com
Sun Jul 14 10:22:25 BST 2019
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?
More information about the libre-riscv-dev