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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jul 17 12:20:05 BST 2019

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?


More information about the libre-riscv-dev mailing list