Re: [boost] [Math] float16 on ARM

-----Original Message----- From: Boost On Behalf Of John Maddock via Boost Sent: 15 October 2019 18:05 To: Paul A Bristow via Boost Cc: John Maddock Subject: Re: [boost] [Math] float16 on ARM

...

...

Strange complexity within Arm: "The ARM target provides hardware support for conversions between __fp16 and float values as an extension to VFP and NEON (Advanced SIMD), and from ARMv8-A provides hardware support for conversions between __fp16 and double values. GCC generates code using these hardware instructions if you compile with options to select an FPU that provides them; for example, -mfpu=neon-fp16 -mfloat-abi=softfp, in addition to the -mfp16-format option to select a half-precision format."

Unpleasant, sorry. I really, really don't wish to know all that! 😉 Paul

Me neither.

My first reaction was "yes of course we should do that", but on reflection I'm not so sure:

The intention of was to provide a *portable* set of typedefs such that each is mapped to the corresponding IEEE defined type.

And indeed, if numeric_limits::is_iec559 happens to be false, then the header will trigger a static_assert and complain that it's incorrectly configured.

So... we could provide a float16_t typedef, but if we're being consistent (and we should be), then it would only be for IEEE float16 compatible types.

My concern is quite how we detect/configure/test that.

I also don't think we currently have any tester running on arm (for example), and we certainly don't have arm CI (is there any?).

I'm also worried about the multiple layout for 16-bit, and even more about the distinction between a storage type and computation type. Mainly worrying out loud ☹ Paul PS Perhaps we should focus on what you really want to gain from this. Is an implementation of numeric_limits the most important things? Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK