[libre-riscv-dev] bug in sfpy on FP16 integer initialisation

[Luke Kenneth Casson Leighton]

On Wed, Jul 17, 2019 at 12:14 PM Bill Zorn <bill.zorn at gmail.com> wrote:

> Yes, I suppose if you have some (HW or otherwise) implementation if IEEE
> 754, and you want to make sure it does exactly the same thing as softfloat
> 3, then you would want softfloat 3's actual integer conversion routines.

 yehyeh absolutely, nodding vigorously.

 the things that we're missing - which is entirely missing from
softfloat-3 - are:
 * u/i-16_to_f16/32/64
 * *reciprocal* (inverse) square-root.

this latter, *sigh*, we are going to have to mock up using
python-bigfloat (bindings around libmpfr).  that we've been able to
avoid that need entirely so far is a real testament to the work that
you've done, and that of john hauser.


> That is a strong argument for me to add that functionality to the
> interface, even if it's not on the "usual" path that someone would use to
> construct a float with the value of some Python integer they happened to
> have.The worst the Python wrappings should be able to do for those
> functions is tell you that your integer doesn't fit in an int32, if you
> somehow manage to screw that up.

managed that once already, i called i32_to_f64 instead of ui32_to_f64
with an unsigned integer that had bit 32 set!  My Problem To Deal With
:)

for the signed integer testing i'll need to get the unit test to
generate numbers between the ranges of INT32_MIN and INT32_MAX, not 0
and UINT32_MAX.  that's no problem, just a bit of coding.

> Out of curiosity, will you also eventually want the 80-bit or 128-bit
> types? Or can I go to sleep without having to worry about how I would try
> to get their values into and out of strings?

haha, yes, no, we definitely won't need those, not for... mmm....
estimated.... 3-5 years?

l.