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.