Boost logo

Boost :

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.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at