Re: Mostly question of whether we should support floating point values from hardware (was Re: isl29501 and multiple calibration registers)

[Jonathan Cameron <jic23@jic23.retrosnub.co.uk>]

On Wed, 27 Jun 2018 15:43:38 +0200
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> Hi Jonathan,
> 
> > https://en.wikipedia.org/wiki/Double-precision_floating-point_format.
> >
> > So in rough form...
> >
> > fls('mantissa') will get us the most significant set bit. 
> > Shift the mantissa so that falls off the top and add that shift
> > to the exponent. 
> >
> > Poke in the right places in a standard double.  
> 
> Yes, understood, this way we can format Intersil float representation
> (m*2^e) to IEEE754 (1.m*2^e).
> 
> > Now this is where it gets even uglier.   IIO assumes 2 32 bit
> > parts so we'll need to mash it into those in some reasonable
> > (ish) fashion.  The core IIO then needs to pretty print it.  
> 
> An option would be to add IIO_VAL_DOUBLE format value that would print
> ieee754 double in a similar way as '%a' option of glibc' printf
> ([-]0xh.hhhhp).

It's not exactly human readable if we print it like that so not
ideal.  Hmm. It would be nice for reading it back into
a program though.  Perhaps put out a patch doing this as an RFC
and we'll see what response we get!

> 
> A "iio_double_to_int" function would also be needed to parse a user
> inputed number under '%a' representation into two 'int' passed to
> write_raw.

yes - nasty but we'll need it.

> 
> > Hmm. This looks annoyingly like we may need to do some core
> > rework to make val and val2 64 bit relatively soon but I'd
> > rather we didn't stall this driver on that.  
> 
> Yes the splitting would be really ugly as the mantissa on 52 bit will
> have to be splitted in two parts, something like:
> 
> val: sign | exponent | mantissa (20 most valuable bits)
> val2: mantissa (32 last bits)
> 
> Or something as dirty as that ...
> 
> All of this seems really hacky but would allow user to input big
> floating values (that won't fit into val.val2 format with val and val2
> on 32 or even 64 bit format).
> 
> What do you think ?

We can make it less hacky by adding a new callback function similar
to we did for the quaternion case - read_raw_multi that at least
takes 64 bit val and val2 so we can shove a double in one of them
(without using floating point maths in kernel as that's a pain)

Jonathan

> 
> Thanks,
> 
> Mathieu