[std-proposals] Optional fixed point arithmetic was standardised into C in 2008. Why doesn't C++ adopt it?

[Niall Douglas]

So, learned something new from WG14 today, namely that C standardised
optional fixed point arithmetic back in 2004, with a second edition in
2008. I didn't know that before. Here is a pre-publication draft of the
standard *ISO/IEC TR 18037:2008*:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf

Why doesn't WG21 simply adopt this instead of the (library) fixed point
arithmetic proposals currently before it?

Niall

[Ville Voutilainen]

Post by Niall Douglas
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
Why doesn't WG21 simply adopt this instead of the (library) fixed point arithmetic proposals currently before it?

Probably for the same reason why complex is a library type in C++;
WG21 thinks it can do better with a library approach than
with a built-in one.

[Niall Douglas]

Post by Niall Douglas

Post by Niall Douglas
So, learned something new from WG14 today, namely that C standardised

optional fixed point arithmetic back in 2004, with a second edition in
2008. I didn't know that before. Here is a pre-publication draft of the

Post by Niall Douglas
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
Why doesn't WG21 simply adopt this instead of the (library) fixed point

arithmetic proposals currently before it?
Probably for the same reason why complex is a library type in C++;
WG21 thinks it can do better with a library approach than
with a built-in one.

Well, sure. But I really wish the authors of the relevant papers before
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.

Niall

[John McFarlane]

Post by Niall Douglas

Post by Niall Douglas
So, learned something new from WG14 today, namely that C standardised
optional fixed point arithmetic back in 2004, with a second edition in
2008. I didn't know that before. Here is a pre-publication draft of the

Post by Niall Douglas
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
Why doesn't WG21 simply adopt this instead of the (library) fixed point

arithmetic proposals currently before it?
Probably for the same reason why complex is a library type in C++;
WG21 thinks it can do better with a library approach than
with a built-in one.

Well, sure. But I really wish the authors of the relevant papers before
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.
Niall

Here's a brief mention of N1169:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.

Post by Niall Douglas
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org?utm_medium=email&utm_source=footer>
.

[John McFarlane]

Post by John McFarlane

Post by Niall Douglas

Post by Niall Douglas
So, learned something new from WG14 today, namely that C standardised
optional fixed point arithmetic back in 2004, with a second edition in
2008. I didn't know that before. Here is a pre-publication draft of the

Post by Niall Douglas
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
Why doesn't WG21 simply adopt this instead of the (library) fixed

point arithmetic proposals currently before it?
Probably for the same reason why complex is a library type in C++;
WG21 thinks it can do better with a library approach than
with a built-in one.

Well, sure. But I really wish the authors of the relevant papers before
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.
Niall

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.

I nearly forgot: here's much the same conclusion being made in the other
C++ fixed-point proposal.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0106r0.html#prior_art

John

Post by John McFarlane

Post by Niall Douglas
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Niall Douglas]

Post by Niall Douglas
Well, sure. But I really wish the authors of the relevant papers before

Post by Niall Douglas
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.

Thanks for the links.

Sure I get that freeform exponents are useful, but to my inexperienced and
untrained eye the fixed exponent choices in N1169 were because the codegen
would come out much cleaner, and in which I would assume it is therefore
faster and/or more predictable.

Now if I'm totally wrong on that, then that's great to learn. But I don't
think P0037 or P0106 can just hand wave N1169 away like they do. N1169
ought to be *refuted* as being empirically inferior to whatever approach is
being proposed.

I'll put this another way. If the Elsewhere Memory SG is approved, it's on
that SG to explain in its proposed changes to the C++ memory model to
support mapped memory why the multiple address spaces feature of N1169 was
not adopted (if that's what the SG ends up choosing). After all, LLVM and
other compilers already implement N1169, there is plenty of empirical
experience, and *it's an ISO standard*. Not following the currently
standard way of doing things in a standards proposal seems to me a high
claim to make - you need to *refute* the current approach, ideally
empirically.

Does that make sense? If it does, that's my concern. I'd like to see
side-by-side godbolt with clang showing N1169 output on one side, and
proposed standard output on the other, in which N1169 output is obviously
no better. Then I'd consider that having freeform exponents has no cost,
and all is rosy and dandy.

Niall

[Brian Bi]

Post by Niall Douglas
Well, sure. But I really wish the authors of the relevant papers before

Post by John McFarlane

Post by Niall Douglas
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.

Thanks for the links.
Sure I get that freeform exponents are useful, but to my inexperienced and
untrained eye the fixed exponent choices in N1169 were because the codegen
would come out much cleaner, and in which I would assume it is therefore
faster and/or more predictable.

To my even more inexperienced and untrained eye, the fixed set of types in
N1169 is because C doesn't have templates and therefore has no easy way to
construct arbitrarily parametrized types like the proposed fixed-width
arithmetic library types for C++.

Post by Niall Douglas
Now if I'm totally wrong on that, then that's great to learn. But I don't
think P0037 or P0106 can just hand wave N1169 away like they do. N1169
ought to be *refuted* as being empirically inferior to whatever approach
is being proposed.
I'll put this another way. If the Elsewhere Memory SG is approved, it's on
that SG to explain in its proposed changes to the C++ memory model to
support mapped memory why the multiple address spaces feature of N1169 was
not adopted (if that's what the SG ends up choosing). After all, LLVM and
other compilers already implement N1169, there is plenty of empirical
experience, and *it's an ISO standard*. Not following the currently
standard way of doing things in a standards proposal seems to me a high
claim to make - you need to *refute* the current approach, ideally
empirically.

I'm not totally clear on what the current relationship is between ISO C and
ISO C++, but my understanding is that C and C++ have diverged in philosophy
to such an extent that the fact that something is done a certain way in C
isn't even persuasive (let alone presumptive) evidence that C++ would be
best served by a similar approach.

Post by Niall Douglas
Does that make sense? If it does, that's my concern. I'd like to see
side-by-side godbolt with clang showing N1169 output on one side, and
proposed standard output on the other, in which N1169 output is obviously
no better. Then I'd consider that having freeform exponents has no cost,
and all is rosy and dandy.
Niall
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%40isocpp.org?utm_medium=email&utm_source=footer>
.

[David Brown]

Post by Niall Douglas
Well, sure. But I really wish the authors of the relevant papers
before WG21 described in their motivation why they think that a
library approach is clearly superior to an already published
standard. That's a fairly high bar, in my opinion, to meet when
essentially proposing "I don't think the standardised way is
sufficient for reasons A, B and C. Here's what I propose instead
...". And I don't remember such explanatory text in motivations.
I was hoping somebody could link me to such a text, I could read
it, and as someone without domain expertise in fixed point
arithmetic, I could go away feeling satisfied WG21 is on the
right track on this.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169>
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.
Thanks for the links.
Sure I get that freeform exponents are useful, but to my inexperienced
and untrained eye the fixed exponent choices in N1169 were because the
codegen would come out much cleaner, and in which I would assume it is
therefore faster and/or more predictable.
Now if I'm totally wrong on that, then that's great to learn. But I
don't think P0037 or P0106 can just hand wave N1169 away like they do.
N1169 ought to be /refuted/ as being empirically inferior to whatever
approach is being proposed.

One of the biggest problems with the N1169 approach is that it has types
that have fixed but implementation-specified sizes. This is completely
and totally useless to embedded programmers (or any other programmers
interested in fixed point). It does not matter how efficient they are
implemented if no one knows what they are!

If you are programming in an embedded system, you want fixed point
numbers in the "Q" format. (Sometimes people use different names, but
it is the same thing.) You want something like Q4.12, which is a 16-bit
signed integer scaled by 2 ^ 12. Or you want UQ0.8, which is an 8-bit
unsigned integer scaled by 2 ^ 8 - i.e., a number between 0 and just
under 1. You need to know the exact range, and exact precision, and
exact size - N1169's "signed short _Fract", etc., are totally
meaningless. It is /infinitely/ more important that you have the exact
sizes you want than that you have a type that can be implemented
efficiently on the target hardware.

For ordinary integers, embedded programmers use int16_t, uint32_t - they
don't use "int" or "short".

A solution that does not give you this level of control and this
information should be rejected out of hand.


I also think you are misunderstanding the state of N1169. It is a TR
proposal that no one uses, with only a small part of it implemented on a
few toolchains. It is not part of the C standards. Rejecting it does
not mean throwing away useful work or implementations.


I haven't yet read through the linked C++ fixed point proposals. But
one thing that would be nice to have in them is an encouragement for
implementations to have specialised cases of the templates with more
optimal code for their targets. For example, on the AVR microcontroller
you would expect that Q2.6 multiplication be implemented with shifts and
masks from general code, but that Q1.7 would use inline assembly for the
"fractional multiply" instruction that many AVR devices support. Then
developers can choose formats with most efficient implementations - but
their primary motivation for choice is the format needed for correct code.

Post by Niall Douglas
I'll put this another way. If the Elsewhere Memory SG is approved, it's
on that SG to explain in its proposed changes to the C++ memory model to
support mapped memory why the multiple address spaces feature of N1169
was not adopted (if that's what the SG ends up choosing). After all,
LLVM and other compilers already implement N1169, there is plenty of
empirical experience, and /it's an ISO standard/. Not following the
currently standard way of doing things in a standards proposal seems to
me a high claim to make - you need to /refute/ the current approach,
ideally empirically.
Does that make sense? If it does, that's my concern. I'd like to see
side-by-side godbolt with clang showing N1169 output on one side, and
proposed standard output on the other, in which N1169 output is
obviously no better. Then I'd consider that having freeform exponents
has no cost, and all is rosy and dandy.
Niall

[David Brown]

Post by Niall Douglas
So, learned something new from WG14 today, namely that C standardised
optional fixed point arithmetic back in 2004, with a second edition in
2008. I didn't know that before. Here is a pre-publication draft of the
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
Why doesn't WG21 simply adopt this instead of the (library) fixed point
arithmetic proposals currently before it?

Well, almost no C compilers support that standard - because almost no
one wants to use it. The TR has 3 key areas that are supposed to
improve C programming in the embedded world. It covers fixed-point
arithmetic in a way no one wants (especially not embedded programmers),
named address spaces that are underpowered, and hardware I/O that is not
needed, not useful, and contrary to the way every embedded compiler and
programmer handles it.

The TR for "C Extensions to support embedded processors" is a huge
disappointment, a result of a /total/ failure to look at the realities
of the industry in terms of what embedded toolchains provide and what
embedded programmers want, combined with an absurd time schedule. While
the group behind this spend many years slowly writing the document in a
couple of versions, everyone in the embedded development industry got on
with their jobs. So by the time it was published, it would have been
irrelevant even if it had been useful.

I only know of one compiler that has some implementation of this TR's
fixed point types - that is gcc, which implements it on some targets. I
have tried it, and the code generated is hopeless despite the target
processor having support for some fixed point formats. It is basically
a matter of a gcc developer in the past having implemented the front-end
parts and very basic code generation, presumably with the intention that
others would pick up the ball and turn it into more optimal code now
that the process had been started. However, it has seen no interest
(AFAIK) from either compiler developers or users.

I haven't heard anything about a C++ standard library for fixed-point
arithmetic, but it would be very difficult to produce something worse
than this C "extension" TR that has been rightly ignored.

[Niall Douglas]

Post by David Brown
I only know of one compiler that has some implementation of this TR's
fixed point types - that is gcc, which implements it on some targets. I
have tried it, and the code generated is hopeless despite the target
processor having support for some fixed point formats. It is basically
a matter of a gcc developer in the past having implemented the front-end
parts and very basic code generation, presumably with the intention that
others would pick up the ball and turn it into more optimal code now
that the process had been started. However, it has seen no interest
(AFAIK) from either compiler developers or users.
Useful to learn, thanks.

Niall

[John McFarlane]

Post by David Brown
I only know of one compiler that has some implementation of this TR's
fixed point types - that is gcc, which implements it on some targets. I
have tried it, and the code generated is hopeless despite the target
processor having support for some fixed point formats. It is basically
a matter of a gcc developer in the past having implemented the front-end
parts and very basic code generation, presumably with the intention that
others would pick up the ball and turn it into more optimal code now
that the process had been started. However, it has seen no interest
(AFAIK) from either compiler developers or users.
Useful to learn, thanks.

Yes, thanks David. I feel I now have a better idea of why it's so hard to
find any information about N1169 online.

Mostly so it's noted somewhere, I'll go ahead and try to compare the C++
solutions (P0106 and P0037) with N1169 in depth. I will doubtless get some
facts wrong...
- P0106 and P0037 are library-based abstractions over integer-like types
such as the fundamental types. N1169 aims to provide fundamental types
which are an abstraction over registers and instructions found in DSPs,
FPGAs etc..
- P0106 and P0037 (to varying extents) provide lossless arithmetic
operations (because they are based on integers which also perform many
operations losslessly). N1169's arithmetic operations right-shift their
results eagerly to match the operand types (because that's really all you
can do with C's type system) and so drop low bits routinely.
- This means that if you don't have said processor features, N1169 has you
paying for those shifts whether you use them or not. You often do need them
and P0106 and P0037 provide them but only when you are expressly doing
something like assigning back to the operand type.
- The downside is that you need wider results for intermediate types --
especially for multiplication -- which N1169 would take care of 'under the
hood'.
- N1169 also offers some support for rounding and overflow -- the intention
being to harness those processor features. P0037 sidesteps those issues and
P0106 supports them in software or hardware (but most likely software).
- N1169's approach is to under-specify its types in order to account for
the fact that hardware support varies so much. I guess the intent was to
follow `int`'s example of being different (e.g. in width) from platform to
platform. But there are more and greater differences in fixed-point
hardware. P0106 hides all such details and lets the user chose the exact
range and resolution (effectively integer and fractional bit counts) to
ensure that behaviour is predictable across different implementations.
P0037, again, sidesteps this issue by allowing the user to choose the
backing type. If they choose the <cstdint> types, they can largely iron out
those differences. N1169 doesn't even appear to be compatible with
<stdint.h>'s aliases.

I tried to come up with some examples of P0037 out-performing N1169 in
terms of codegen but without using the exotic fixed-point hardware for
which N1169 is designed, the results don't seem very fair. Here is a circle
intersection test
using P0037 https://gcc.godbolt.org/z/BqxsbS
and N1169 https://gcc.godbolt.org/z/pGRmZU.

The N1169 code eagerly shifts the values which helps avoid overflow but
reduces precision. The P0037 solution relies on integer promotion to avoid
overflow and so is more resource hungry (32-bit values!) but also more
precise. It is a feature of P0037 that you have this control. You can widen
intermediate types yourself when promotion fails you or you can use the
P0828 type and stop worrying about intermediate width. P0106 does something
similar.

I'm not convinced that if I revised P0037 in the future that it would
really help to add this info but I'm happy to do so.

John

[Niall Douglas]

Post by John McFarlane
I tried to come up with some examples of P0037 out-performing N1169 in
terms of codegen but without using the exotic fixed-point hardware for
which N1169 is designed, the results don't seem very fair. Here is a circle
intersection test
using P0037 https://gcc.godbolt.org/z/BqxsbS
and N1169 https://gcc.godbolt.org/z/pGRmZU.
The N1169 code eagerly shifts the values which helps avoid overflow but
reduces precision. The P0037 solution relies on integer promotion to avoid
overflow and so is more resource hungry (32-bit values!) but also more
precise. It is a feature of P0037 that you have this control. You can widen
intermediate types yourself when promotion fails you or you can use the
P0828 type and stop worrying about intermediate width. P0106 does something
similar.
I'm not convinced that if I revised P0037 in the future that it would
really help to add this info but I'm happy to do so.
I find the above compelling proof that P0037 is much superior. The codegen

for P0037 is much better. And P0037 is much more flexible.

The reason I raised all this is because I was aghast at how poor codegen
library based extended precision integers generate. I've tried a number of
implementation libraries now, they are all far inferior to compiler based
for the 128 bit integer case. And I find that important - some will argue
that future compilers will optimise better, but I have found that a
crapshoot in the past. Far better to standardise based on existing
optimiser tech, then we know for sure.

Anyway I preempt my paper. Thanks John for all the detail.

Niall