Date: 2019-10-16 08:47:36
> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of John Maddock via
> Sent: 15 October 2019 18:05
> To: Paul A Bristow via Boost <boost_at_[hidden]>
> Cc: John Maddock <jz.maddock_at_[hidden]>
> 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 <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 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 â¹
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
LA8 8AB UK
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk