From: John Maddock (jz.maddock_at_[hidden])
Date: 2019-10-15 17:05:17
>> 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
My first reaction was "yes of course we should do that", but on
reflection I'm not so sure:
The intention of <boost/cstdmath.hpp> was to provide a *portable* set of
typedefs such that each is mapped to the corresponding IEEE defined type.
And indeed, if numeric_limits<float32_t>::is_iec559 happens to be false,
then the header will trigger a static_assert and complain that it's
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk