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

[Jacob Lifshay]

On Sun, Jul 14, 2019 at 1:27 AM lkcl <luke.leighton at gmail.com> wrote:
>
>> mpfr does, however, have some notable caveats: see
>> https://www.mpfr.org/mpfr-current/mpfr.html#MPFR-and-the-IEEE-754-Standard
>
>
> under-normalisation not supported, because, obviously, with an arbitrary-sized exponent you don't need to lose accuracy in the mantissa.
use mpfr_subnormalize as described in the docs. bigfloat appears to
have built-in code to use mpfr_subnormalize, though I'll have to check
that we don't end up with double rounding.

>
> >>> from bigfloat import BigFloat
> >>> b = BigFloat(1.0)
> >>> b
> BigFloat.exact('1.0000000000000000', precision=53)
> >>> b.hex()
> '0x0.80000000000000p+1'
> >>> b._exponent()
> 1
> >>> b._format_to_fixed_precision(1)
> (False, '10', -1)
> >>> b = BigFloat(52.39)
> >>> b._format_to_fixed_precision(24)
> (False, '52390000000000000568434189', -24)
> >>> b.hex()
> '0x0.d18f5c28f5c290p+6'
>
> ah ha!  perfect!  that's exactly what we need.  and there's a "BigFloat.fromhex()" function as well, so it will be possible to transfer numbers in and out of bigfloat, in order to perform conversions to (full) IEEE754 FP16/32/64 format.
I submitted a bug report to allow conversion to/from python3 int
(arbitrary-precision int) without being limited to a C long or needing
conversion to/from strings:
https://github.com/mdickinson/bigfloat/issues/80
>
> 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).

Jacob