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

[Luke Kenneth Casson Leighton]

On Wed, Jul 17, 2019 at 11:37 AM Bill Zorn <bill.zorn at gmail.com> wrote:
>
> I'm glad you're having success with the library, and I'm glad you figured this out.

aww i really wanted to find a youtube clip of B.O.B from Monsters v
Aliens, saying "i may not have a brain, gentleman..."   ah ha!
 https://getyarn.io/yarn-clip/da358bd0-d32b-479d-ab7b-c409ce6fe1cd

:)

> I guess I'll have to be very careful not to break anything in the softfloat bindings when I update to the latest softposit library, which I should do soon :)

we're not so concerned about posit (luckily)

> Out of curiosity - what do you need int to float conversion for, specifically?

basically what we're doing is developing a hardware IEEE754 unit (and
using sfpy to confirm that it's correct).  therefore, anything that a
hardware IEEE754 FPU is expected to have, *we* have to have, and
therefore need to test it.

> I left the softfloat 'C-style' int to float conversion functions out of
> the bindings deliberately, because they don't really make a lot of
> sense in Python.

 it doesn't matter: it's the accurate (convenient) access to the
softfloat-3 functionality that we need, rather than any particular
"pythonic" behaviour.

> an int32 is a terrible datatype for holding the value of a float32,
> since it only covers a tiny portion of the dynamic range (i.e. most
> large magnitude floats, which are actually integers, aren't int32s
> because they would overflow).

 doesn't matter, because we expect the integer values to be verbatim
untouched as they pass through softfloat.

 what we're testing is that our hardware IEEE754 FPU throws the
*exact* same exceptions, has the *exact* same Inf and NaN values, and
so on, as softfloat.


> Since this is all in Python, where integers can be really big, and the supported softfloat datatypes are all no larger than doubles, it made the most sense to me to do any int to float conversions at the Python level rather than in C. So if you have a Python integer (call it a) that you want to convert to a Float16 by value, I would just have written:
>
> Float16(float(a))

 yeh.  this would lose the corner-cases, through the python conversion
getting in the way.  we *really* need the absolute direct unaltered
access to softfloat-3.  if there's *any* interference by actual
"python", modifying or not providing the binary representations (or a
direct equivalent of them), we have a problem.

 so this is why passing in a python int (and having it be converted
behind the scenes to an int16, uint32 or whatever) is ok, but having
*python* perform the conversion from int to float is absolutely out of
the question.


> As you found out the hard way, sfpy is designed to be fast and convenient for dealing with the binary representations of floats, not so much with their real values.

 my brain thoroughly melted a few hours ago.  i've been using that
exact functionality for months: inputting the binary representation of
floats, performing sfpy add/mul/div, getting the result back (as a
binary representation) then comparing it against the equivalent
IEEE754 hardware simulation.


> That said, if there is a particular functionality you need, I'd be happy to add it to the library.

 that'd be fantastic.  one thing that we will need, some time in the
next few months, is the option to build the "tininess" selection, when
building softfloat-3 for RISC-V interoperability.

     # /*----------------------------------------------------------------------------
     # | Software floating-point underflow tininess-detection mode.
     # *----------------------------------------------------------------------------*/
-    # extern uint_fast8_t softfloat_detectTininess; # THREAD_LOCAL
-    # cdef enum:
-    #     softfloat_tininess_beforeRounding = 0
-    #     softfloat_tininess_afterRounding  = 1
+    extern uint_fast8_t softfloat_detectTininess; # THREAD_LOCAL
+    cdef enum:
+        softfloat_tininess_beforeRounding = 0
+        softfloat_tininess_afterRounding  = 1

many thanks, bill.

l.