[libre-riscv-dev] FP unit testing (was Re: [isa-dev] FP reciprocal sqrt extension proposal)
programmerjake at gmail.com
Sun Jul 14 10:05:21 BST 2019
On Sun, Jul 14, 2019 at 1:27 AM lkcl <luke.leighton at gmail.com> wrote:
>> mpfr does, however, have some notable caveats: see
> 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()
> >>> b._exponent()
> >>> b._format_to_fixed_precision(1)
> (False, '10', -1)
> >>> b = BigFloat(52.39)
> >>> b._format_to_fixed_precision(24)
> (False, '52390000000000000568434189', -24)
> >>> b.hex()
> 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:
> 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).
More information about the libre-riscv-dev