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

[Luke Kenneth Casson Leighton]

whoops forgot to hit reply-all, sorry bill.
p.s. you saw this right? http://bugs.libre-riscv.org/attachment.cgi?id=18
git am apply < {patchafterdownload}

On Wed, Jul 17, 2019 at 12:20 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> 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.