Re: [Math] float16 on ARM

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-10-16 14:37:25

John Maddock wrote:
> 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.

#if (__ARM_FP & 2) && defined(__ARM_FP16_FORMAT_IEEE)
using float16_t = __fp16;
struct std::numeric_limits<float16_t> {
  const bool is_iec559 = true;
  etc. etc.
};
#endif

I think the difficult issues are
(a) Do we need a richer vocabulary than floatNN_t to describe the 
different formats, when more than one is supported at the same time?
(b) Can we provide a software fallback for platforms where there 
is no hardware support?

Right now, I'm trying to make a binary file containing these 16-bit 
floats that will be read (memory-mapped) on an ARM system, built on 
an x86 system.

> I also don't think we currently have any tester running on arm (for 
> example)

I was running ARM64 testers when I had an account with Scaleway, but 
I don't think anyone was looking at the results; certainly no-one 
ever asked me anything about them or seemed to notice when I turned 
them off.  I have considered reviving this now that AWS has ARM 
instances, but their smallest ARM instances are quite a lot larger 
(and more expensive) than their smallest x86 instances for some reason. 
That may change eventually.  If anyone's interested, get in touch.

Regards, Phil.