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?).
Mostly thinking out loud yours, John.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
