Topic: 128 bit integers
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Tue, 2 Oct 2018 01:09:27 -0700 (PDT)
Raw View
------=_Part_1727_829828649.1538467767419
Content-Type: multipart/alternative;
boundary="----=_Part_1728_676804981.1538467767419"
------=_Part_1728_676804981.1538467767419
Content-Type: text/plain; charset="UTF-8"
I just posted the following to the WG14 reflector, copying it here for some
std-proposals extra feedback.
Niall
--- cut ---
Dear WG14,
As you may know, C++ is busy adding variable bit number support to itself
(`int<128>`, `uint<256>` etc), but what I find myself yearning for is a
simple, ordinary, builtin 128-bit signed and unsigned integer type which
acts exactly like a normal integer, just bigger.
1. Would WG14 approve of adding builtin 128-bit signed and unsigned integer
types to C22? If so, I can write the paper.
2. If so, what would be the preferred choice of naming? Some choices:
a) Leaving the type unspecified, and instead say that `uint128_t` and
`int128_t` will typedef to whatever it is.
b) `unsigned long long long` and `long long long`.
c) `_UInt128` and `_Int128`.
In terms of prior art, GCC and clang already implement 128-bit integers
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done so
for many years now. There is definitely an established user base, surprise
ought to be very limited.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org.
------=_Part_1728_676804981.1538467767419
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I just posted the following to the WG14 reflector, copying=
it here for some std-proposals extra feedback.<div><br></div><div>Niall</d=
iv><div><br></div><div>--- cut ---<br><div><br></div><div><div>Dear WG14,</=
div><div><br></div><div>As you may know, C++ is busy adding variable bit nu=
mber support to itself (`int<128>`, `uint<256>` etc), but what =
I find myself yearning for is a simple, ordinary, builtin 128-bit signed an=
d unsigned integer type which acts exactly like a normal integer, just bigg=
er.</div><div><br></div><div>1. Would WG14 approve of adding builtin 128-bi=
t signed and unsigned integer types to C22? If so, I can write the paper.</=
div><div><br></div><div>2. If so, what would be the preferred choice of nam=
ing? Some choices:</div><div><br></div><div>=C2=A0 a) Leaving the type unsp=
ecified, and instead say that `uint128_t` and `int128_t` will typedef to wh=
atever it is.</div><div><br></div><div>=C2=A0 b) `unsigned long long long` =
and `long long long`.</div><div><br></div><div>=C2=A0 c) `_UInt128` and `_I=
nt128`.</div><div><br></div><div><br></div><div>In terms of prior art, GCC =
and clang already implement 128-bit integers (https://gcc.gnu.org/onlinedoc=
s/gcc/_005f_005fint128.html) and have done so for many years now. There is =
definitely an established user base, surprise ought to be very limited.</di=
v><div><br></div><div>Niall</div></div><div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e=
%40isocpp.org</a>.<br />
------=_Part_1728_676804981.1538467767419--
------=_Part_1727_829828649.1538467767419--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Oct 2018 23:35:26 -0700
Raw View
On Tuesday, 2 October 2018 01:09:27 PDT Niall Douglas wrote:
> In terms of prior art, GCC and clang already implement 128-bit integers
> (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done so
> for many years now. There is definitely an established user base, surprise
> ought to be very limited.
Note that 128-bit integers in GCC and Clang are only supported on 64-bit
architectures. That's probably because it's practically the same code that
they need for 32-bit platforms to support 64-bit integers, just on a platform
with a wider register.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3643236.xe1PxKylTG%40tjmaciei-mobl1.
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 2 Oct 2018 23:39:35 -0700 (PDT)
Raw View
------=_Part_2043_1685468534.1538548775087
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Niall,
Since you are asking specifically for 128 bit integers, I believe the right=
choice would be to just add int128_t and uint128_t alias (to unspecified t=
ypes) into <cstdint>. Since the presence of most of the aliases in that hea=
der is already conditionally provided, it should not be a burden to impleme=
ntations. The only problem in this area is that we should consider deprecat=
ing intmax_t and uintmax_t. Other discussions have pointed that it was a ba=
d idea to introduce them, since an implementation can=E2=80=99t change its =
definition without potentially breaking binary compatibility.
Just my two eurocent,
Alberto=20
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b6c21320-0aa7-4b3f-9572-71946338979c%40isocpp.or=
g.
------=_Part_2043_1685468534.1538548775087--
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Wed, 3 Oct 2018 12:35:24 -0500
Raw View
--0000000000004b569b057756775e
Content-Type: text/plain; charset="UTF-8"
Why does it matter whether it's built-in? What would uint128_t do that
uint<128> wouldn't?
Also can someone link me to the proposal that defines uint<128> and
friends? Thanks
On Tue, Oct 2, 2018 at 3:09 AM Niall Douglas <nialldouglas14@gmail.com>
wrote:
> I just posted the following to the WG14 reflector, copying it here for
> some std-proposals extra feedback.
>
> Niall
>
> --- cut ---
>
> Dear WG14,
>
> As you may know, C++ is busy adding variable bit number support to itself
> (`int<128>`, `uint<256>` etc), but what I find myself yearning for is a
> simple, ordinary, builtin 128-bit signed and unsigned integer type which
> acts exactly like a normal integer, just bigger.
>
> 1. Would WG14 approve of adding builtin 128-bit signed and unsigned
> integer types to C22? If so, I can write the paper.
>
> 2. If so, what would be the preferred choice of naming? Some choices:
>
> a) Leaving the type unspecified, and instead say that `uint128_t` and
> `int128_t` will typedef to whatever it is.
>
> b) `unsigned long long long` and `long long long`.
>
> c) `_UInt128` and `_Int128`.
>
>
> In terms of prior art, GCC and clang already implement 128-bit integers (
> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done
> so for many years now. There is definitely an established user base,
> surprise ought to be very limited.
>
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
*Brian Bi*
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOCzCMsrzC8JAL1OZ3e28pDtd0UZiwWHsvj29-rKez7JA%40mail.gmail.com.
--0000000000004b569b057756775e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why does it matter whether it's built-in? What would u=
int128_t do that uint<128> wouldn't?<div><br></div><div>Also can =
someone link me to the proposal that defines uint<128> and friends? T=
hanks</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oc=
t 2, 2018 at 3:09 AM Niall Douglas <<a href=3D"mailto:nialldouglas14@gma=
il.com">nialldouglas14@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I just posted the following to the WG14 refl=
ector, copying it here for some std-proposals extra feedback.<div><br></div=
><div>Niall</div><div><br></div><div>--- cut ---<br><div><br></div><div><di=
v>Dear WG14,</div><div><br></div><div>As you may know, C++ is busy adding v=
ariable bit number support to itself (`int<128>`, `uint<256>` e=
tc), but what I find myself yearning for is a simple, ordinary, builtin 128=
-bit signed and unsigned integer type which acts exactly like a normal inte=
ger, just bigger.</div><div><br></div><div>1. Would WG14 approve of adding =
builtin 128-bit signed and unsigned integer types to C22? If so, I can writ=
e the paper.</div><div><br></div><div>2. If so, what would be the preferred=
choice of naming? Some choices:</div><div><br></div><div>=C2=A0 a) Leaving=
the type unspecified, and instead say that `uint128_t` and `int128_t` will=
typedef to whatever it is.</div><div><br></div><div>=C2=A0 b) `unsigned lo=
ng long long` and `long long long`.</div><div><br></div><div>=C2=A0 c) `_UI=
nt128` and `_Int128`.</div><div><br></div><div><br></div><div>In terms of p=
rior art, GCC and clang already implement 128-bit integers (<a href=3D"http=
s://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html" target=3D"_blank">htt=
ps://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html</a>) and have done so=
for many years now. There is definitely an established user base, surprise=
ought to be very limited.</div><div><br></div><div>Niall</div></div><div><=
br></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-=
45a4-aa06-d871d8efb20e%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br=
><div></div><div></div><div></div></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOCzCMsrzC8JAL1OZ3e28pDtd0UZiwW=
Hsvj29-rKez7JA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOCzCMsrzC8=
JAL1OZ3e28pDtd0UZiwWHsvj29-rKez7JA%40mail.gmail.com</a>.<br />
--0000000000004b569b057756775e--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 3 Oct 2018 12:31:32 -0700 (PDT)
Raw View
------=_Part_1524_2060408542.1538595092697
Content-Type: multipart/alternative;
boundary="----=_Part_1525_182893966.1538595092697"
------=_Part_1525_182893966.1538595092697
Content-Type: text/plain; charset="UTF-8"
One issue with the current C++ Standard is that it does not allow cstdint
to define anything other than 8/16/32/64/max, whereas the C Standard does.
So an implementation cannot currently define a std::uint128_t but could
define a uint128_t.
The C Standard mentions the possibility of non-power-of-2 sizes, calling
out uint24_t as an example. (Trivia: uint24_t would actually be a sensible
type on an eZ80.)
The C++ Standard ought to do the same as the C Standard. We also should
get a proposal for std::uint_t<N> and such.
A separate problem with something like uint128_t is that it breaks the
definition of uintmax_t. We can't change uintmax_t on an existing
platform, because that's a breaking change. And if uint128_t exists and is
larger than uintmax_t, what does that mean?
Melissa
On Wednesday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote:
>
> Why does it matter whether it's built-in? What would uint128_t do that
> uint<128> wouldn't?
>
> Also can someone link me to the proposal that defines uint<128> and
> friends? Thanks
>
> On Tue, Oct 2, 2018 at 3:09 AM Niall Douglas <nialldo...@gmail.com
> <javascript:>> wrote:
>
>> I just posted the following to the WG14 reflector, copying it here for
>> some std-proposals extra feedback.
>>
>> Niall
>>
>> --- cut ---
>>
>> Dear WG14,
>>
>> As you may know, C++ is busy adding variable bit number support to itself
>> (`int<128>`, `uint<256>` etc), but what I find myself yearning for is a
>> simple, ordinary, builtin 128-bit signed and unsigned integer type which
>> acts exactly like a normal integer, just bigger.
>>
>> 1. Would WG14 approve of adding builtin 128-bit signed and unsigned
>> integer types to C22? If so, I can write the paper.
>>
>> 2. If so, what would be the preferred choice of naming? Some choices:
>>
>> a) Leaving the type unspecified, and instead say that `uint128_t` and
>> `int128_t` will typedef to whatever it is.
>>
>> b) `unsigned long long long` and `long long long`.
>>
>> c) `_UInt128` and `_Int128`.
>>
>>
>> In terms of prior art, GCC and clang already implement 128-bit integers (
>> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done
>> so for many years now. There is definitely an established user base,
>> surprise ought to be very limited.
>>
>> 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
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> *Brian Bi*
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bb2c51f1-8fdf-4a94-8edb-8c4183b70968%40isocpp.org.
------=_Part_1525_182893966.1538595092697
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>One issue with the current C++ Standard is that it do=
es not allow cstdint to define anything other than 8/16/32/64/max, whereas =
the C Standard does.=C2=A0 So an implementation cannot currently define a s=
td::uint128_t but could define a uint128_t.</div><div><br></div><div>The C =
Standard mentions the possibility of non-power-of-2 sizes, calling out uint=
24_t as an example.=C2=A0 (Trivia: uint24_t would actually be a sensible ty=
pe on an eZ80.)<br></div><div><br></div><div>The C++ Standard ought to do t=
he same as the C Standard.=C2=A0 We also should get a proposal for std::uin=
t_t<N> and such.</div><div><br></div><div>A separate problem with som=
ething like uint128_t is that it breaks the definition of uintmax_t.=C2=A0 =
We can't change uintmax_t on an existing platform, because that's a=
breaking change.=C2=A0 And if uint128_t exists and is larger than uintmax_=
t, what does that mean?</div><div><br></div><div>Melissa<br></div><div><br>=
</div>On Wednesday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Why does it mat=
ter whether it's built-in? What would uint128_t do that uint<128>=
wouldn't?<div><br></div><div>Also can someone link me to the proposal =
that defines uint<128> and friends? Thanks</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 2, 2018 at 3:09 AM Niall Doug=
las <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
liJPCjqVAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">nialldo...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">I just posted the following to the WG14 reflector, cop=
ying it here for some std-proposals extra feedback.<div><br></div><div>Nial=
l</div><div><br></div><div>--- cut ---<br><div><br></div><div><div>Dear WG1=
4,</div><div><br></div><div>As you may know, C++ is busy adding variable bi=
t number support to itself (`int<128>`, `uint<256>` etc), but w=
hat I find myself yearning for is a simple, ordinary, builtin 128-bit signe=
d and unsigned integer type which acts exactly like a normal integer, just =
bigger.</div><div><br></div><div>1. Would WG14 approve of adding builtin 12=
8-bit signed and unsigned integer types to C22? If so, I can write the pape=
r.</div><div><br></div><div>2. If so, what would be the preferred choice of=
naming? Some choices:</div><div><br></div><div>=C2=A0 a) Leaving the type =
unspecified, and instead say that `uint128_t` and `int128_t` will typedef t=
o whatever it is.</div><div><br></div><div>=C2=A0 b) `unsigned long long lo=
ng` and `long long long`.</div><div><br></div><div>=C2=A0 c) `_UInt128` and=
`_Int128`.</div><div><br></div><div><br></div><div>In terms of prior art, =
GCC and clang already implement 128-bit integers (<a href=3D"https://gcc.gn=
u.org/onlinedocs/gcc/_005f_005fint128.html" target=3D"_blank" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3=
A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2F_005f_005fint128.html\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEtd5QQ4_6Rkh8qWHqrQDloKev_xw';return true;" =
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
cc.gnu.org%2Fonlinedocs%2Fgcc%2F_005f_005fint128.html\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEtd5QQ4_6Rkh8qWHqrQDloKev_xw';return true;">https://=
gcc.gnu.org/<wbr>onlinedocs/gcc/_005f_<wbr>005fint128.html</a>) and have do=
ne so for many years now. There is definitely an established user base, sur=
prise ought to be very limited.</div><div><br></div><div>Niall</div></div><=
div><br></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
liJPCjqVAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"liJPCjqVAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4111d349-b11d-45a4-<wbr>aa06-=
d871d8efb20e%40isocpp.org</a><wbr>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi=
</i></font><br><div></div><div></div><div></div></div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bb2c51f1-8fdf-4a94-8edb-8c4183b70968%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bb2c51f1-8fdf-4a94-8edb-8c4183b70968=
%40isocpp.org</a>.<br />
------=_Part_1525_182893966.1538595092697--
------=_Part_1524_2060408542.1538595092697--
.
Author: inkwizytoryankes@gmail.com
Date: Wed, 3 Oct 2018 14:23:13 -0700 (PDT)
Raw View
------=_Part_1923_1556733897.1538601793411
Content-Type: multipart/alternative;
boundary="----=_Part_1924_579479255.1538601793411"
------=_Part_1924_579479255.1538601793411
Content-Type: text/plain; charset="UTF-8"
On Wednesday, October 3, 2018 at 9:31:32 PM UTC+2, Myriachan wrote:
>
> One issue with the current C++ Standard is that it does not allow cstdint
> to define anything other than 8/16/32/64/max, whereas the C Standard does.
> So an implementation cannot currently define a std::uint128_t but could
> define a uint128_t.
>
> The C Standard mentions the possibility of non-power-of-2 sizes, calling
> out uint24_t as an example. (Trivia: uint24_t would actually be a sensible
> type on an eZ80.)
>
> The C++ Standard ought to do the same as the C Standard. We also should
> get a proposal for std::uint_t<N> and such.
>
> A separate problem with something like uint128_t is that it breaks the
> definition of uintmax_t. We can't change uintmax_t on an existing
> platform, because that's a breaking change. And if uint128_t exists and is
> larger than uintmax_t, what does that mean?
>
>
Its not native size? We could redefine it as biggest that can be handle by
CPU. For current implementation it will stay same but in new it could be
less than uint64.
> Melissa
>
> On Wednesday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote:
>>
>> Why does it matter whether it's built-in? What would uint128_t do that
>> uint<128> wouldn't?
>>
>> Also can someone link me to the proposal that defines uint<128> and
>> friends? Thanks
>>
>> On Tue, Oct 2, 2018 at 3:09 AM Niall Douglas <nialldo...@gmail.com>
>> wrote:
>>
>>> I just posted the following to the WG14 reflector, copying it here for
>>> some std-proposals extra feedback.
>>>
>>> Niall
>>>
>>> --- cut ---
>>>
>>> Dear WG14,
>>>
>>> As you may know, C++ is busy adding variable bit number support to
>>> itself (`int<128>`, `uint<256>` etc), but what I find myself yearning for
>>> is a simple, ordinary, builtin 128-bit signed and unsigned integer type
>>> which acts exactly like a normal integer, just bigger.
>>>
>>> 1. Would WG14 approve of adding builtin 128-bit signed and unsigned
>>> integer types to C22? If so, I can write the paper.
>>>
>>> 2. If so, what would be the preferred choice of naming? Some choices:
>>>
>>> a) Leaving the type unspecified, and instead say that `uint128_t` and
>>> `int128_t` will typedef to whatever it is.
>>>
>>> b) `unsigned long long long` and `long long long`.
>>>
>>> c) `_UInt128` and `_Int128`.
>>>
>>>
>>> In terms of prior art, GCC and clang already implement 128-bit integers (
>>> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done
>>> so for many years now. There is definitely an established user base,
>>> surprise ought to be very limited.
>>>
>>> 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 email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> *Brian Bi*
>>
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/55b27206-4086-4201-a78d-2ef98b6e4282%40isocpp.org.
------=_Part_1924_579479255.1538601793411
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, October 3, 2018 at 9:31:32 PM UTC+2,=
Myriachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>One issue with the current C++ Standard is that it does not allow =
cstdint to define anything other than 8/16/32/64/max, whereas the C Standar=
d does.=C2=A0 So an implementation cannot currently define a std::uint128_t=
but could define a uint128_t.</div><div><br></div><div>The C Standard ment=
ions the possibility of non-power-of-2 sizes, calling out uint24_t as an ex=
ample.=C2=A0 (Trivia: uint24_t would actually be a sensible type on an eZ80=
..)<br></div><div><br></div><div>The C++ Standard ought to do the same as th=
e C Standard.=C2=A0 We also should get a proposal for std::uint_t<N> =
and such.</div><div><br></div><div>A separate problem with something like u=
int128_t is that it breaks the definition of uintmax_t.=C2=A0 We can't =
change uintmax_t on an existing platform, because that's a breaking cha=
nge.=C2=A0 And if uint128_t exists and is larger than uintmax_t, what does =
that mean?</div><div><br></div></div></blockquote><div><br></div><div>Its n=
ot native size? We could redefine it as biggest that can be handle by CPU. =
For current implementation it will stay same but in new it could be less th=
an uint64.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div>Melissa<br></div><div><br></div>On Wedn=
esday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">Why does it matter whether it'=
;s built-in? What would uint128_t do that uint<128> wouldn't?<div=
><br></div><div>Also can someone link me to the proposal that defines uint&=
lt;128> and friends? Thanks</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Tue, Oct 2, 2018 at 3:09 AM Niall Douglas <<a rel=3D"n=
ofollow">nialldo...@gmail.com</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">I just posted the following to the WG14 reflecto=
r, copying it here for some std-proposals extra feedback.<div><br></div><di=
v>Niall</div><div><br></div><div>--- cut ---<br><div><br></div><div><div>De=
ar WG14,</div><div><br></div><div>As you may know, C++ is busy adding varia=
ble bit number support to itself (`int<128>`, `uint<256>` etc),=
but what I find myself yearning for is a simple, ordinary, builtin 128-bit=
signed and unsigned integer type which acts exactly like a normal integer,=
just bigger.</div><div><br></div><div>1. Would WG14 approve of adding buil=
tin 128-bit signed and unsigned integer types to C22? If so, I can write th=
e paper.</div><div><br></div><div>2. If so, what would be the preferred cho=
ice of naming? Some choices:</div><div><br></div><div>=C2=A0 a) Leaving the=
type unspecified, and instead say that `uint128_t` and `int128_t` will typ=
edef to whatever it is.</div><div><br></div><div>=C2=A0 b) `unsigned long l=
ong long` and `long long long`.</div><div><br></div><div>=C2=A0 c) `_UInt12=
8` and `_Int128`.</div><div><br></div><div><br></div><div>In terms of prior=
art, GCC and clang already implement 128-bit integers (<a href=3D"https://=
gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2F_005f_005fint128.html\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEtd5QQ4_6Rkh8qWHqrQDloKev_xw';return=
true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3=
A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2F_005f_005fint128.html\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEtd5QQ4_6Rkh8qWHqrQDloKev_xw';return true;">=
https://gcc.gnu.org/<wbr>onlinedocs/gcc/_005f_<wbr>005fint128.html</a>) and=
have done so for many years now. There is definitely an established user b=
ase, surprise ought to be very limited.</div><div><br></div><div>Niall</div=
></div><div><br></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4111d349-b11d-45a4-<wbr>aa06-=
d871d8efb20e%40isocpp.org</a><wbr>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi=
</i></font><br><div></div><div></div><div></div></div></div></div></div>
</blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/55b27206-4086-4201-a78d-2ef98b6e4282%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55b27206-4086-4201-a78d-2ef98b6e4282=
%40isocpp.org</a>.<br />
------=_Part_1924_579479255.1538601793411--
------=_Part_1923_1556733897.1538601793411--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Thu, 4 Oct 2018 01:06:15 -0700 (PDT)
Raw View
------=_Part_106_825631221.1538640375588
Content-Type: multipart/alternative;
boundary="----=_Part_107_1699012024.1538640375588"
------=_Part_107_1699012024.1538640375588
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
>
>
> Since you are asking specifically for 128 bit integers, I believe the=20
> right choice would be to just add int128_t and uint128_t alias (to=20
> unspecified types) into <cstdint>. Since the presence of most of the=20
> aliases in that header is already conditionally provided, it should not b=
e=20
> a burden to implementations. The only problem in this area is that we=20
> should consider deprecating intmax_t and uintmax_t. Other discussions hav=
e=20
> pointed that it was a bad idea to introduce them, since an implementation=
=20
> can=E2=80=99t change its definition without potentially breaking binary=
=20
> compatibility.=20
>
Thanks everybody for your feedback.
The discussion on WG14 has been considerably more detailed, but as a=20
reasonable summary:
1. There is widespread consensus that intmax_t et al should reflect the=
=20
largest *basic* integer type. And therefore it wouldn't change.
2. I'm going to propose that C implements http://wg21.link/P0539 *A=20
Proposal to add wide_int Template Class* directly into the C language.
3. Probably a dramatically simplified subset of the proposed syntax in=
=20
http://wg21.link/P0989 *Standardizing Extended Integers* would be=20
proposed.
And we shall see what happens!
Niall
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c979210f-264b-4148-b966-f2313f38002a%40isocpp.or=
g.
------=_Part_107_1699012024.1538640375588
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Since you=
are asking specifically for 128 bit integers, I believe the right choice w=
ould be to just add int128_t and uint128_t alias (to unspecified types) int=
o <cstdint>. Since the presence of most of the aliases in that header=
is already conditionally provided, it should not be a burden to implementa=
tions. The only problem in this area is that we should consider deprecating=
intmax_t and uintmax_t. Other discussions have pointed that it was a bad i=
dea to introduce them, since an implementation can=E2=80=99t change its def=
inition without potentially breaking binary compatibility.
<br>
</blockquote><div><br></div><div>Thanks everybody for your feedback.</div><=
div><br></div><div>The discussion on WG14 has been considerably more detail=
ed, but as a reasonable summary:</div><div><ol><li>There is widespread cons=
ensus that intmax_t et al should reflect the largest <i>basic</i>=C2=A0inte=
ger type. And therefore it wouldn't change.<br></li><li>I'm going t=
o propose that C implements=C2=A0http://wg21.link/P0539=C2=A0<i>A Proposal =
to add wide_int Template Class</i> directly into the C language.</li><li>Pr=
obably a dramatically simplified subset of the proposed syntax in <a href=
=3D"http://wg21.link/P0989">http://wg21.link/P0989</a>=C2=A0<i>Standardizin=
g Extended Integers</i> would be proposed.</li></ol><div>And we shall see w=
hat happens!</div></div><div><br></div><div>Niall</div><div><br></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c979210f-264b-4148-b966-f2313f38002a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c979210f-264b-4148-b966-f2313f38002a=
%40isocpp.org</a>.<br />
------=_Part_107_1699012024.1538640375588--
------=_Part_106_825631221.1538640375588--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Thu, 4 Oct 2018 05:34:13 -0700 (PDT)
Raw View
------=_Part_211_2025052863.1538656453925
Content-Type: multipart/alternative;
boundary="----=_Part_212_85662757.1538656453925"
------=_Part_212_85662757.1538656453925
Content-Type: text/plain; charset="UTF-8"
On Thursday, October 4, 2018 at 3:06:15 AM UTC-5, Niall Douglas wrote:
>
>
> 1. There is widespread consensus that intmax_t et al should reflect
> the largest *basic* integer type. And therefore it wouldn't change.
> 2. I'm going to propose that C implements http://wg21.link/P0539 *A
> Proposal to add wide_int Template Class* directly into the C language.
> 3. Probably a dramatically simplified subset of the proposed syntax in
> http://wg21.link/P0989 *Standardizing Extended Integers* would be
> proposed.
>
>
I just want to point out that P0989 is an April Fool's joke.
Cue Tony strenuously denying this in 3... 2...
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/618c6701-abd5-4caa-8917-c1a15a5840d5%40isocpp.org.
------=_Part_212_85662757.1538656453925
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 4, 2018 at 3:06:15 AM UTC-5, =
Niall Douglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><ol><li>There is widespread consensus that intmax_t et al sho=
uld reflect the largest <i>basic</i>=C2=A0integer type. And therefore it wo=
uldn't change.<br></li><li>I'm going to propose that C implements=
=C2=A0<a href=3D"http://wg21.link/P0539" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fwg21.link%2FP0539\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFlKl2JJfBcwx0VQ=
G77odGzzePLjQ';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0539\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNFlKl2JJfBcwx0VQG77odGzzePLjQ';return true;">http://wg21.li=
nk/<wbr>P0539</a>=C2=A0<i>A Proposal to add wide_int Template Class</i> dir=
ectly into the C language.</li><li>Probably a dramatically simplified subse=
t of the proposed syntax in <a href=3D"http://wg21.link/P0989" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0989\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEp-erx1wKI5ipT5uOkAXiD4r8B-A';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0989\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEp-erx1wKI5ipT5uOkAXiD4r8B-A';return=
true;">http://wg21.link/P0989</a>=C2=A0<i>Standar<wbr>dizing Extended Inte=
gers</i> would be proposed.</li></ol></div></div></blockquote><div><br></di=
v><div>I just want to point out that P0989 is an April Fool's joke.=C2=
=A0</div><div><br></div><div>Cue Tony strenuously denying this in 3... 2...=
=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/618c6701-abd5-4caa-8917-c1a15a5840d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/618c6701-abd5-4caa-8917-c1a15a5840d5=
%40isocpp.org</a>.<br />
------=_Part_212_85662757.1538656453925--
------=_Part_211_2025052863.1538656453925--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Thu, 4 Oct 2018 05:38:00 -0700 (PDT)
Raw View
------=_Part_223_1012390185.1538656681005
Content-Type: text/plain; charset="UTF-8"
I had noticed the first of April date, and most of the proposal is obviously terrible. However there are some good ideas in there, and I'm going to propose them for standardisation. 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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/869310a4-67f1-4594-8157-e33ae7d7e0f3%40isocpp.org.
------=_Part_223_1012390185.1538656681005--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 04 Oct 2018 09:17:17 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">April fool's?! </div><div style=3D"width: 100%; font-size:=
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color:=
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255=
);"><br></div><div style=3D"width: 100%; font-size: initial; font-family: C=
alibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-=
align: initial; background-color: rgb(255, 255, 255);">Pure coincidence I s=
ay!</div><div style=3D"width: 100%; font-size: initial; font-family: Calibr=
i, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align=
: initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"w=
idth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-ser=
if, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-co=
lor: rgb(255, 255, 255);">Don't forget to consider the rebuttal, http://wg2=
1.link/p0990</div><div style=3D"width: 100%; font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">Sent from my&=
nbsp;BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-s=
pacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; tex=
t-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb=
(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: =
Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b=
>Barry Revzin</div><div><b>Sent: </b>Thursday, October 4, 2018 8:34 AM</div=
><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To:=
</b>std-proposals@isocpp.org</div><div><b>Subject: </b>[std-proposals] Re:=
128 bit integers</div></div></td></tr></tbody></table><div style=3D"border=
-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-w=
idth: 1pt; font-size: initial; text-align: initial; background-color: rgb(2=
55, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr"><br><br>On Thursday, October 4, 2018 at 3:06:15 AM UTC-5, Niall Do=
uglas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><ol><li>There is widespread consensus that intmax_t et al should reflec=
t the largest <i>basic</i> integer type. And therefore it wouldn't cha=
nge.<br></li><li>I'm going to propose that C implements <a href=3D"htt=
p://wg21.link/P0539" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0539\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFlKl2JJfBcwx0VQG77odGzzePLjQ';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg=
21.link%2FP0539\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFlKl2JJfBcwx0VQG77o=
dGzzePLjQ';return true;">http://wg21.link/<wbr>P0539</a> <i>A Proposal=
to add wide_int Template Class</i> directly into the C language.</li><li>P=
robably a dramatically simplified subset of the proposed syntax in <a href=
=3D"http://wg21.link/P0989" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0=
989\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEp-erx1wKI5ipT5uOkAXiD4r8B-A';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A=
%2F%2Fwg21.link%2FP0989\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEp-erx1wKI5=
ipT5uOkAXiD4r8B-A';return true;">http://wg21.link/P0989</a> <i>Standar=
<wbr>dizing Extended Integers</i> would be proposed.</li></ol></div></div><=
/blockquote><div><br></div><div>I just want to point out that P0989 is an A=
pril Fool's joke. </div><div><br></div><div>Cue Tony strenuously denyi=
ng this in 3... 2... </div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/618c6701-abd5-4caa-8917-c1a15a5840d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/618c6701-abd5-4caa-8917-c1a15a58=
40d5%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20181004131717.5218385.95339.62406%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20181004131717.5218385.95339.62406%40gm=
ail.com</a>.<br />
.
Author: John McFarlane <john@mcfarlane.name>
Date: Fri, 5 Oct 2018 14:18:15 +0100
Raw View
--00000000000067bb0705777b1b36
Content-Type: text/plain; charset="UTF-8"
If you're collecting related papers, you might want to mention P0539 which
is a 100% serious paper.
On Thu, Oct 4, 2018, 13:38 Niall Douglas <nialldouglas14@gmail.com> wrote:
> I had noticed the first of April date, and most of the proposal is
> obviously terrible. However there are some good ideas in there, and I'm
> going to propose them for standardisation. 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/869310a4-67f1-4594-8157-e33ae7d7e0f3%40isocpp.org
> .
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnT%3Dt-PL4BRU4viPp5Es63JZ%3D2AO52Cmc1AWBv5QyYd0RQ%40mail.gmail.com.
--00000000000067bb0705777b1b36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
If you're collecting related papers, you might want to mention=C2=A0P05=
39 which is a 100% serious paper.<br><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Thu, Oct 4, 2018, 13:38 Niall Douglas <<a href=3D"mailto:ni=
alldouglas14@gmail.com">nialldouglas14@gmail.com</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">I had noticed the first of April date, and mos=
t of the proposal is obviously terrible. However there are some good ideas =
in there, and I'm going to propose them for standardisation. Niall<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/869310a4-67f1-4594-8157-e33ae7d7e0f3%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/869310a4-67f1-4594-8157-e33ae7d7e0f3%4=
0isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnT%3Dt-PL4BRU4viPp5Es63JZ%3D2AO=
52Cmc1AWBv5QyYd0RQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnT%3Dt-=
PL4BRU4viPp5Es63JZ%3D2AO52Cmc1AWBv5QyYd0RQ%40mail.gmail.com</a>.<br />
--00000000000067bb0705777b1b36--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Fri, 5 Oct 2018 08:42:21 -0700 (PDT)
Raw View
------=_Part_815_231582402.1538754141941
Content-Type: multipart/alternative;
boundary="----=_Part_816_802768560.1538754141942"
------=_Part_816_802768560.1538754141942
Content-Type: text/plain; charset="UTF-8"
On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote:
>
> If you're collecting related papers, you might want to mention P0539 which
> is a 100% serious paper.
>
>>
>> My C proposal paper is actually a direct response to P0539, and it
discusses what I think are showstopper problems with that paper, and why we
need a language solution instead. As I wrote:
WG21 is currently proceeding down a library-based path for implementing
extended precision integers (https://wg21.link/P0539), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.
Current proposal being discussed on the WG14 reflector looks as follows:
1. For any integer type excluding _Bool (char, short, int, long, long
long), one may extend it into an extended arithmetic type by annotating it
with "_Wide(N)":
- _Wide(4) int
- long long _Wide(2)
This simply tells the compiler to emit the add-with-carry or
multiply-with-carries instructions necessary to increase the precision of
the specified arithmetic type. And before anyone asks, yes it is legal to
widen small types:
- _Wide(2) short (NOT an int)
- _Wide(4) char (NOT an int)
2. These wide integer types are not integral types, and thus do not affect
intmax_t etc. ABI remains unchanged.
3. As the compiler knows the size of these at compile time, and that they
will always be some twos power multiple of an integral type, implementation
cost for compiler vendors is straightforward. *Optimising* them is hard,
but then so is optimisation in any case.
4. These extended types would have the same ABI as a struct of however many
of their integral type e.g. _Wide(4) long int has the same ABI as struct {
long int[4] }. So they'll get passed mostly by reference, whatever the
current calling convention says. Nothing changes for the calling convention.
5. My current feeling is that these wide arithmetic types should have the
alignment of their integral type but doubled as necessary. This enables
them to "stand in" for types hardware available on bigger CPUs. It also
enables SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit
integer adds four times faster than with the scalar instructions for
example.
6. I'm still deciding on whether to support _Complex or not.
7. I'm minded that wide multiplication does not emit doubled precision
outputs, but that instead we gain a new multiplication operator whose
result type is double the precision of that of its input types. My
suggestion would be **. That new operator would apply to the integral types
too. In particular, Intel CPUs have had a special opcode for 64 bit x 64
bit = 128 bit multiply for a while now, but making use of it without
intrinsics has been hard.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791%40isocpp.org.
------=_Part_816_802768560.1538754141942
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFar=
lane wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If you're colle=
cting related papers, you might want to mention=C2=A0P0539 which is a 100% =
serious paper.<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br></blockquote></div></blockquote><div>My C proposal paper is actually a=
direct response to P0539, and it discusses what I think are showstopper pr=
oblems with that paper, and why we need a language solution instead. As I w=
rote:</div><div><br></div><div><pre wrap=3D"">WG21 is currently proceeding =
down a library-based path for implementing
extended precision integers (<a class=3D"moz-txt-link-freetext" href=3D"htt=
ps://wg21.link/P0539">https://wg21.link/P0539</a>), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.</pre></div><div><br>=
</div><div>Current proposal being discussed on the WG14 reflector looks as =
follows:</div><div><br></div> 1. For any integer type excluding _Bool (char=
, short, int, long, long long), one may extend it into an extended
arithmetic type by annotating it with "_Wide(N)":<div><br></div><=
div>=C2=A0 =C2=A0 - _Wide(4) int</div><div>=C2=A0 =C2=A0 - long long _Wide(=
2)<br><div><br></div><div>This simply tells the compiler to emit the add-wi=
th-carry or
multiply-with-carries instructions necessary to increase the precision of
the specified arithmetic type. And before anyone asks, yes it is legal to w=
iden small types:</div><div><br></div><div>=C2=A0 =C2=A0 - _Wide(2) short (=
NOT an int)</div><div>=C2=A0 =C2=A0 - _Wide(4) char (NOT an int)</div><div>=
<br></div><div>2. These wide integer types are not integral types, and thus=
do
not affect intmax_t etc. ABI remains unchanged.</div><div><br></div><div>3.=
As the compiler knows the size of these at compile time, and that
they will always be some twos power multiple of an integral type,
implementation cost for compiler vendors is straightforward.
*Optimising* them is hard, but then so is optimisation in any case.</div><d=
iv><br></div><div>4. These extended types would have the same ABI as a stru=
ct of however
many of their integral type e.g. _Wide(4) long int has the same ABI
as struct { long int[4] }. So they'll get passed mostly by reference,
whatever the current calling convention says. Nothing changes for the
calling convention.</div><div><br></div><div>5. My current feeling is that =
these wide arithmetic types should have
the alignment of their integral type but doubled as necessary. This
enables them to "stand in" for types hardware available on bigger=
CPUs.
It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do
8x 128-bit integer adds four times faster than with the scalar
instructions for example.</div><div><br></div><div>6. I'm still decidin=
g on whether to support _Complex or not.<br></div></div><div><br></div><div=
>7. I'm minded that wide multiplication does not emit doubled precision=
outputs, but that instead we gain a new multiplication operator whose resu=
lt type is double the precision of that of
its input types. My suggestion would be **. That new operator would
apply to the integral types too. In particular, Intel CPUs have had a
special opcode for 64 bit x 64 bit =3D 128 bit multiply for a while now,
but making use of it without intrinsics has been hard.<br></div><div><br></=
div><div>Niall</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791=
%40isocpp.org</a>.<br />
------=_Part_816_802768560.1538754141942--
------=_Part_815_231582402.1538754141941--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 05 Oct 2018 09:22:13 -0700
Raw View
On Friday, 5 October 2018 08:42:21 PDT Niall Douglas wrote:
> 7. I'm minded that wide multiplication does not emit doubled precision
> outputs, but that instead we gain a new multiplication operator whose
> result type is double the precision of that of its input types. My
> suggestion would be **. That new operator would apply to the integral types
> too. In particular, Intel CPUs have had a special opcode for 64 bit x 64
> bit = 128 bit multiply for a while now, but making use of it without
> intrinsics has been hard.
That's one of the things what int128_t was useful for. Just cast one of the
operands to it before doing the multiplication and you get a 128-bit result.
So I feel we don't need a new operator if we can programmatically find the
integer of the next size
That's how Qt implements the mul_overflow() operation if the compiler does not
support __builtin_mul_overflow() but does support 128-bit integers. We use
QIntegerForSize<sizeof(T) * 2>::Signed or Unsigned. See:
https://code.woboq.org/qt5/qtbase/src/corelib/global/qnumeric_p.h.html#314
For MSVC, we have to do as you said: use the _mul128 and _umul128 intrinsic,
as seen a few lines below in the same file.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3208512.tJF4vxScjB%40tjmaciei-mobl1.
.
Author: "'Alisdair Meredith' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 05 Oct 2018 13:10:09 -0400
Raw View
--Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Does your proposal address _Atomic in C, and atomic<integral> in C++? I wa=
nt to be sure that no-one is laboring under conflicting assumptions here, e=
ven when it means stating the (apparently) obvious.
Sent from my iPhone
> On Oct 5, 2018, at 11:42 AM, Niall Douglas <nialldouglas14@gmail.com> wro=
te:
>=20
>> On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote:
>> If you're collecting related papers, you might want to mention P0539 whi=
ch is a 100% serious paper.
>>>=20
> My C proposal paper is actually a direct response to P0539, and it discus=
ses what I think are showstopper problems with that paper, and why we need =
a language solution instead. As I wrote:
>=20
> WG21 is currently proceeding down a library-based path for implementing
> extended precision integers (https://wg21.link/P0539), but my issue with
> it is that it is very hard to get the compiler to predictably generate
> optimal code with a library only solution. In particular, compilers fail
> to spot when they can use carry-adds or carry-multiplies from hints
> provided by generic C or C++ code. This is why I have become convinced
> we need a language based implementation so compilers know exactly what
> they are supposed to do. Hence me coming here to WG14.
>=20
> Current proposal being discussed on the WG14 reflector looks as follows:
>=20
> 1. For any integer type excluding _Bool (char, short, int, long, long lon=
g), one may extend it into an extended arithmetic type by annotating it wit=
h "_Wide(N)":
>=20
> - _Wide(4) int
> - long long _Wide(2)
>=20
> This simply tells the compiler to emit the add-with-carry or multiply-wit=
h-carries instructions necessary to increase the precision of the specified=
arithmetic type. And before anyone asks, yes it is legal to widen small ty=
pes:
>=20
> - _Wide(2) short (NOT an int)
> - _Wide(4) char (NOT an int)
>=20
> 2. These wide integer types are not integral types, and thus do not affec=
t intmax_t etc. ABI remains unchanged.
>=20
> 3. As the compiler knows the size of these at compile time, and that they=
will always be some twos power multiple of an integral type, implementatio=
n cost for compiler vendors is straightforward. *Optimising* them is hard, =
but then so is optimisation in any case.
>=20
> 4. These extended types would have the same ABI as a struct of however ma=
ny of their integral type e.g. _Wide(4) long int has the same ABI as struct=
{ long int[4] }. So they'll get passed mostly by reference, whatever the c=
urrent calling convention says. Nothing changes for the calling convention.
>=20
> 5. My current feeling is that these wide arithmetic types should have the=
alignment of their integral type but doubled as necessary. This enables th=
em to "stand in" for types hardware available on bigger CPUs. It also enabl=
es SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit intege=
r adds four times faster than with the scalar instructions for example.
>=20
> 6. I'm still deciding on whether to support _Complex or not.
>=20
> 7. I'm minded that wide multiplication does not emit doubled precision ou=
tputs, but that instead we gain a new multiplication operator whose result =
type is double the precision of that of its input types. My suggestion woul=
d be **. That new operator would apply to the integral types too. In partic=
ular, Intel CPUs have had a special opcode for 64 bit x 64 bit =3D 128 bit =
multiply for a while now, but making use of it without intrinsics has been =
hard.
>=20
> Niall
>=20
> --=20
> 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=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791%40isocpp.=
org.
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8%40me.com.
--Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto">Does your proposal address _Atomic in C=
, and atomic<integral> in C++? I want to be sure that no-one is=
laboring under conflicting assumptions here, even when it means stating th=
e (apparently) obvious.<br><br><div id=3D"AppleMailSignature" dir=3D"ltr">S=
ent from my iPhone</div><div dir=3D"ltr"><br>On Oct 5, 2018, at 11:42 AM, N=
iall Douglas <<a href=3D"mailto:nialldouglas14@gmail.com">nialldouglas14=
@gmail.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div dir=
=3D"ltr"><div dir=3D"ltr">On Friday, October 5, 2018 at 2:18:30 PM UTC+1, J=
ohn McFarlane wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If you're =
collecting related papers, you might want to mention P0539 which is a =
100% serious paper.<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><br></blockquote></div></blockquote><div>My C proposal paper is actua=
lly a direct response to P0539, and it discusses what I think are showstopp=
er problems with that paper, and why we need a language solution instead. A=
s I wrote:</div><div><br></div><div><pre wrap=3D"">WG21 is currently procee=
ding down a library-based path for implementing
extended precision integers (<a class=3D"moz-txt-link-freetext" href=3D"htt=
ps://wg21.link/P0539">https://wg21.link/P0539</a>), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.</pre></div><div><br>=
</div><div>Current proposal being discussed on the WG14 reflector looks as =
follows:</div><div><br></div> 1. For any integer type excluding _Bool (char=
, short, int, long, long long), one may extend it into an extended
arithmetic type by annotating it with "_Wide(N)":<div><br></div><div> =
- _Wide(4) int</div><div> - long long _Wide(2)<br><div=
><br></div><div>This simply tells the compiler to emit the add-with-carry o=
r
multiply-with-carries instructions necessary to increase the precision of
the specified arithmetic type. And before anyone asks, yes it is legal to w=
iden small types:</div><div><br></div><div> - _Wide(2) short (=
NOT an int)</div><div> - _Wide(4) char (NOT an int)</div><div>=
<br></div><div>2. These wide integer types are not integral types, and thus=
do
not affect intmax_t etc. ABI remains unchanged.</div><div><br></div><div>3.=
As the compiler knows the size of these at compile time, and that
they will always be some twos power multiple of an integral type,
implementation cost for compiler vendors is straightforward.
*Optimising* them is hard, but then so is optimisation in any case.</div><d=
iv><br></div><div>4. These extended types would have the same ABI as a stru=
ct of however
many of their integral type e.g. _Wide(4) long int has the same ABI
as struct { long int[4] }. So they'll get passed mostly by reference,
whatever the current calling convention says. Nothing changes for the
calling convention.</div><div><br></div><div>5. My current feeling is that =
these wide arithmetic types should have
the alignment of their integral type but doubled as necessary. This
enables them to "stand in" for types hardware available on bigger CPUs.
It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do
8x 128-bit integer adds four times faster than with the scalar
instructions for example.</div><div><br></div><div>6. I'm still deciding on=
whether to support _Complex or not.<br></div></div><div><br></div><div>7. =
I'm minded that wide multiplication does not emit doubled precision outputs=
, but that instead we gain a new multiplication operator whose result type =
is double the precision of that of
its input types. My suggestion would be **. That new operator would
apply to the integral types too. In particular, Intel CPUs have had a
special opcode for 64 bit x 64 bit =3D 128 bit multiply for a while now,
but making use of it without intrinsics has been hard.<br></div><div><br></=
div><div>Niall</div><div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527b791%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/b5d854b4-c24e-4a3f-8fcc-3c793527=
b791%40isocpp.org</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8%=
40me.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/970A16E4-63F6-4DAB-B3A3-EEDA0AF4C2A8%40m=
e.com</a>.<br />
--Apple-Mail-08A3EE0F-11BF-480A-A64A-C3756C456C62--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Sun, 7 Oct 2018 14:11:31 -0700 (PDT)
Raw View
------=_Part_1366_1355950367.1538946691660
Content-Type: multipart/alternative;
boundary="----=_Part_1367_1074305575.1538946691660"
------=_Part_1367_1074305575.1538946691660
Content-Type: text/plain; charset="UTF-8"
On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair Meredith wrote:
>
> Does your proposal address _Atomic in C, and atomic<integral> in C++? I
> want to be sure that no-one is laboring under conflicting assumptions here,
> even when it means stating the (apparently) obvious.
>
> Do bear in mind that my proposal is a generalised wide integer proposal
for C. So, P0539, but at the C language level.
It does not address Atomic. I have asked WG14 if it ought to address
Atomic, and we shall see what they prefer.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6c06881-6aa6-47c5-ac7f-df29cfdf021c%40isocpp.org.
------=_Part_1367_1074305575.1538946691660
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair M=
eredith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
">Does your proposal address _Atomic in C, and atomic<integral> in C+=
+? =C2=A0I want to be sure that no-one is laboring under conflicting assump=
tions here, even when it means stating the (apparently) obvious.<br><br></d=
iv></blockquote><div>Do bear in mind that my proposal is a generalised wide=
integer proposal for C. So, P0539, but at the C language level.</div><div>=
=C2=A0</div><div>It does not address Atomic. I have asked WG14 if it ought =
to address Atomic, and we shall see what they prefer.</div><div><br></div><=
div>Niall=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6c06881-6aa6-47c5-ac7f-df29cfdf021c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6c06881-6aa6-47c5-ac7f-df29cfdf021c=
%40isocpp.org</a>.<br />
------=_Part_1367_1074305575.1538946691660--
------=_Part_1366_1355950367.1538946691660--
.
Author: olaf@join.cc
Date: Mon, 8 Oct 2018 02:36:28 -0700 (PDT)
Raw View
------=_Part_1233_416345227.1538991388678
Content-Type: multipart/alternative;
boundary="----=_Part_1234_661640338.1538991388678"
------=_Part_1234_661640338.1538991388678
Content-Type: text/plain; charset="UTF-8"
Op vrijdag 5 oktober 2018 17:42:22 UTC+2 schreef Niall Douglas:
>
> On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote:
>>
>> If you're collecting related papers, you might want to mention P0539
>> which is a 100% serious paper.
>>
>>>
>>> My C proposal paper is actually a direct response to P0539, and it
> discusses what I think are showstopper problems with that paper, and why we
> need a language solution instead. As I wrote:
>
> WG21 is currently proceeding down a library-based path for implementing
> extended precision integers (https://wg21.link/P0539), but my issue with
> it is that it is very hard to get the compiler to predictably generate
> optimal code with a library only solution. In particular, compilers fail
> to spot when they can use carry-adds or carry-multiplies from hints
> provided by generic C or C++ code. This is why I have become convinced
> we need a language based implementation so compilers know exactly what
> they are supposed to do. Hence me coming here to WG14.
>
>
What about having 'intrinsics' for carry-adds, carry-multiplies and other
operations (saturating and wrapping ops for example)?
> Current proposal being discussed on the WG14 reflector looks as follows:
>
> 1. For any integer type excluding _Bool (char, short, int, long, long
> long), one may extend it into an extended arithmetic type by annotating it
> with "_Wide(N)":
>
> - _Wide(4) int
> - long long _Wide(2)
>
> This simply tells the compiler to emit the add-with-carry or
> multiply-with-carries instructions necessary to increase the precision of
> the specified arithmetic type. And before anyone asks, yes it is legal to
> widen small types:
>
> - _Wide(2) short (NOT an int)
> - _Wide(4) char (NOT an int)
>
> 2. These wide integer types are not integral types, and thus do not affect
> intmax_t etc. ABI remains unchanged.
>
> 3. As the compiler knows the size of these at compile time, and that they
> will always be some twos power multiple of an integral type, implementation
> cost for compiler vendors is straightforward. *Optimising* them is hard,
> but then so is optimisation in any case.
>
> 4. These extended types would have the same ABI as a struct of however
> many of their integral type e.g. _Wide(4) long int has the same ABI as
> struct { long int[4] }. So they'll get passed mostly by reference, whatever
> the current calling convention says. Nothing changes for the calling
> convention.
>
> 5. My current feeling is that these wide arithmetic types should have the
> alignment of their integral type but doubled as necessary. This enables
> them to "stand in" for types hardware available on bigger CPUs. It also
> enables SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit
> integer adds four times faster than with the scalar instructions for
> example.
>
> 6. I'm still deciding on whether to support _Complex or not.
>
> 7. I'm minded that wide multiplication does not emit doubled precision
> outputs, but that instead we gain a new multiplication operator whose
> result type is double the precision of that of its input types. My
> suggestion would be **. That new operator would apply to the integral types
> too. In particular, Intel CPUs have had a special opcode for 64 bit x 64
> bit = 128 bit multiply for a while now, but making use of it without
> intrinsics has been hard.
>
> 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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c6445d4e-d43f-4c03-82c8-856e8570fca2%40isocpp.org.
------=_Part_1234_661640338.1538991388678
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op vrijdag 5 oktober 2018 17:42:22 UTC+2 schreef Niall Dou=
glas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Frida=
y, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">If you're collecting related papers, you migh=
t want to mention=C2=A0P0539 which is a 100% serious paper.<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div></bl=
ockquote><div>My C proposal paper is actually a direct response to P0539, a=
nd it discusses what I think are showstopper problems with that paper, and =
why we need a language solution instead. As I wrote:</div><div><br></div><d=
iv><pre>WG21 is currently proceeding down a library-based path for implemen=
ting
extended precision integers (<a href=3D"https://wg21.link/P0539" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fwg21.link%2FP0539\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHa2a4HM7KvXHO0M_CGjLC6tAiBcQ';return true;" onclick=3D"this.=
href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2FP0539=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHa2a4HM7KvXHO0M_CGjLC6tAiBcQ';=
return true;">https://wg21.link/P0539</a>), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.</pre></div></div></b=
lockquote><div><br></div><div>What about having 'intrinsics' for ca=
rry-adds, carry-multiplies and other operations (saturating and wrapping op=
s for example)?</div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div></div><div>Current proposal being discussed on the WG14 refl=
ector looks as follows:</div><div><br></div> 1. For any integer type exclud=
ing _Bool (char, short, int, long, long long), one may extend it into an ex=
tended
arithmetic type by annotating it with "_Wide(N)":<div><br></div><=
div>=C2=A0 =C2=A0 - _Wide(4) int</div><div>=C2=A0 =C2=A0 - long long _Wide(=
2)<br><div><br></div><div>This simply tells the compiler to emit the add-wi=
th-carry or
multiply-with-carries instructions necessary to increase the precision of
the specified arithmetic type. And before anyone asks, yes it is legal to w=
iden small types:</div><div><br></div><div>=C2=A0 =C2=A0 - _Wide(2) short (=
NOT an int)</div><div>=C2=A0 =C2=A0 - _Wide(4) char (NOT an int)</div><div>=
<br></div><div>2. These wide integer types are not integral types, and thus=
do
not affect intmax_t etc. ABI remains unchanged.</div><div><br></div><div>3.=
As the compiler knows the size of these at compile time, and that
they will always be some twos power multiple of an integral type,
implementation cost for compiler vendors is straightforward.
*Optimising* them is hard, but then so is optimisation in any case.</div><d=
iv><br></div><div>4. These extended types would have the same ABI as a stru=
ct of however
many of their integral type e.g. _Wide(4) long int has the same ABI
as struct { long int[4] }. So they'll get passed mostly by reference,
whatever the current calling convention says. Nothing changes for the
calling convention.</div><div><br></div><div>5. My current feeling is that =
these wide arithmetic types should have
the alignment of their integral type but doubled as necessary. This
enables them to "stand in" for types hardware available on bigger=
CPUs.
It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do
8x 128-bit integer adds four times faster than with the scalar
instructions for example.</div><div><br></div><div>6. I'm still decidin=
g on whether to support _Complex or not.<br></div></div><div><br></div><div=
>7. I'm minded that wide multiplication does not emit doubled precision=
outputs, but that instead we gain a new multiplication operator whose resu=
lt type is double the precision of that of
its input types. My suggestion would be **. That new operator would
apply to the integral types too. In particular, Intel CPUs have had a
special opcode for 64 bit x 64 bit =3D 128 bit multiply for a while now,
but making use of it without intrinsics has been hard.<br></div><div><br></=
div><div>Niall</div><div><br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6445d4e-d43f-4c03-82c8-856e8570fca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6445d4e-d43f-4c03-82c8-856e8570fca2=
%40isocpp.org</a>.<br />
------=_Part_1234_661640338.1538991388678--
------=_Part_1233_416345227.1538991388678--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 8 Oct 2018 03:03:57 -0700 (PDT)
Raw View
------=_Part_1468_1544752567.1538993037333
Content-Type: multipart/alternative;
boundary="----=_Part_1469_1261587926.1538993037333"
------=_Part_1469_1261587926.1538993037333
Content-Type: text/plain; charset="UTF-8"
Il giorno domenica 7 ottobre 2018 23:11:31 UTC+2, Niall Douglas ha scritto:
>
> On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair Meredith wrote:
>>
>> Does your proposal address _Atomic in C, and atomic<integral> in C++? I
>> want to be sure that no-one is laboring under conflicting assumptions here,
>> even when it means stating the (apparently) obvious.
>>
>> Do bear in mind that my proposal is a generalised wide integer proposal
> for C. So, P0539, but at the C language level.
>
>
>
I was wondering why the C standard allows implementations to optionally add
intN_t and uintN_t for any N (including 128 and non-powers-of-two like 24),
but C++ only mentions 8, 16, 32 and 64. Is there a strong rationale for
that? Would it hurt to explicitly allow those "exotic" integer types to be
conditionally-supported in C++ also?
Alberto
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dcccedf6-65d6-4ad4-91a1-43e492b4d6c2%40isocpp.org.
------=_Part_1469_1261587926.1538993037333
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Il giorno domenica 7 ottobre 2018 23:11:31 UTC+2, Nial=
l Douglas ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair Meredith =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Does your p=
roposal address _Atomic in C, and atomic<integral> in C++? =C2=A0I wa=
nt to be sure that no-one is laboring under conflicting assumptions here, e=
ven when it means stating the (apparently) obvious.<br><br></div></blockquo=
te><div>Do bear in mind that my proposal is a generalised wide integer prop=
osal for C. So, P0539, but at the C language level.</div><div>=C2=A0</div><=
br></div></blockquote><div><br></div><div>I was wondering why the C standar=
d allows implementations to optionally add intN_t and uintN_t for any N (in=
cluding 128 and non-powers-of-two like 24), but C++ only mentions 8, 16, 32=
and 64. Is there a strong rationale for that? Would it hurt to explicitly =
allow those "exotic" integer types to be conditionally-supported =
in C++ also?</div><div><br></div><div>Alberto<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dcccedf6-65d6-4ad4-91a1-43e492b4d6c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dcccedf6-65d6-4ad4-91a1-43e492b4d6c2=
%40isocpp.org</a>.<br />
------=_Part_1469_1261587926.1538993037333--
------=_Part_1468_1544752567.1538993037333--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Mon, 8 Oct 2018 12:47:24 -0700 (PDT)
Raw View
------=_Part_534_536467798.1539028044815
Content-Type: multipart/alternative;
boundary="----=_Part_535_712441930.1539028044815"
------=_Part_535_712441930.1539028044815
Content-Type: text/plain; charset="UTF-8"
>
> What about having 'intrinsics' for carry-adds, carry-multiplies and other
> operations (saturating and wrapping ops for example)?
>
Firstly, I am unaware of any precedent for that sort of intrinsic in either
C or C++. It seems too specific for standardisation to me, but maybe I'm
wrong.
Secondly, such a thing would be rather hardware dependent. For example RISC
V has no carry flag, and thus no carry based arithmetic. So kinda hard to
standardise such support.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc8a38f8-683c-4853-8f35-b88f5d8c1bdf%40isocpp.org.
------=_Part_535_712441930.1539028044815
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>What about having 'intrinsics' for carry-adds, carry-multi=
plies and other operations (saturating and wrapping ops for example)?</div>=
</div></blockquote><div><br></div><div>Firstly, I am unaware of any precede=
nt for that sort of intrinsic in either C or C++. It seems too specific for=
standardisation to me, but maybe I'm wrong.</div><div><br></div><div>S=
econdly, such a thing would be rather hardware dependent. For example RISC =
V has no carry flag, and thus no carry based arithmetic. So kinda hard to s=
tandardise such support.</div><div><br></div><div>Niall</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bc8a38f8-683c-4853-8f35-b88f5d8c1bdf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bc8a38f8-683c-4853-8f35-b88f5d8c1bdf=
%40isocpp.org</a>.<br />
------=_Part_535_712441930.1539028044815--
------=_Part_534_536467798.1539028044815--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Mon, 8 Oct 2018 12:50:51 -0700 (PDT)
Raw View
------=_Part_1829_897990856.1539028251071
Content-Type: multipart/alternative;
boundary="----=_Part_1830_89269715.1539028251071"
------=_Part_1830_89269715.1539028251071
Content-Type: text/plain; charset="UTF-8"
>
>
> I was wondering why the C standard allows implementations to optionally
> add intN_t and uintN_t for any N (including 128 and non-powers-of-two like
> 24), but C++ only mentions 8, 16, 32 and 64. Is there a strong rationale
> for that? Would it hurt to explicitly allow those "exotic" integer types to
> be conditionally-supported in C++ also?
>
> C and C++ are required to define "least" and "fast" forms of various bit
sized integers, and only if the architecture permits exactly 8, 16, 32 and
64 bits does it define typedefs for those.
My proposal would leave integral arithmetic alone. What the hardware
supports, it supports. Extended precision integers are by definition at
least four fold slower than the hardware supported integers, and often much
slower than that again. So they ought to exist in a different "space" to
integral integers if that makes sense. Then it's clear they're not like
normal integers, they are obviously different.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a16d540-2063-4cdd-8e09-d91cc85b7041%40isocpp.org.
------=_Part_1830_89269715.1539028251071
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>I was wondering why the C standard allows implement=
ations to optionally add intN_t and uintN_t for any N (including 128 and no=
n-powers-of-two like 24), but C++ only mentions 8, 16, 32 and 64. Is there =
a strong rationale for that? Would it hurt to explicitly allow those "=
exotic" integer types to be conditionally-supported in C++ also?</div>=
<div><br></div></div></blockquote><div>C and C++ are required to define &qu=
ot;least" and "fast" forms of various bit sized integers, an=
d only if the architecture permits exactly 8, 16, 32 and 64 bits does it de=
fine typedefs for those.</div><div><br></div><div>My proposal would leave i=
ntegral arithmetic alone. What the hardware supports, it supports. Extended=
precision integers are by definition at least four fold slower than the ha=
rdware supported integers, and often much slower than that again. So they o=
ught to exist in a different "space" to integral integers if that=
makes sense. Then it's clear they're not like normal integers, the=
y are obviously different.</div><div><br></div><div>Niall</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7a16d540-2063-4cdd-8e09-d91cc85b7041%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a16d540-2063-4cdd-8e09-d91cc85b7041=
%40isocpp.org</a>.<br />
------=_Part_1830_89269715.1539028251071--
------=_Part_1829_897990856.1539028251071--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Mon, 8 Oct 2018 13:01:20 -0700 (PDT)
Raw View
------=_Part_1732_263516300.1539028880494
Content-Type: multipart/alternative;
boundary="----=_Part_1733_1461855509.1539028880494"
------=_Part_1733_1461855509.1539028880494
Content-Type: text/plain; charset="UTF-8"
On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair Meredith wrote:
>
> Does your proposal address _Atomic in C, and atomic<integral> in C++? I
> want to be sure that no-one is laboring under conflicting assumptions here,
> even when it means stating the (apparently) obvious.
>
So, WG14 seem to feel it ought to address _Atomic with support for
arbitrary fixed length extended precision integers. I shall try my best to
write something coherent on that.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b114-365a53ecf256%40isocpp.org.
------=_Part_1733_1461855509.1539028880494
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair M=
eredith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto=
">Does your proposal address _Atomic in C, and atomic<integral> in C+=
+? =C2=A0I want to be sure that no-one is laboring under conflicting assump=
tions here, even when it means stating the (apparently) obvious.<br></div><=
/blockquote><div><br></div><div>So, WG14 seem to feel it ought to address _=
Atomic with support for arbitrary fixed length extended precision integers.=
I shall try my best to write something coherent on that.</div><div><br></d=
iv><div>Niall=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b114-365a53ecf256%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b114-365a53ecf256=
%40isocpp.org</a>.<br />
------=_Part_1733_1461855509.1539028880494--
------=_Part_1732_263516300.1539028880494--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 8 Oct 2018 13:38:44 -0700 (PDT)
Raw View
------=_Part_1611_18997016.1539031124752
Content-Type: multipart/alternative;
boundary="----=_Part_1612_573991978.1539031124752"
------=_Part_1612_573991978.1539031124752
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno luned=C3=AC 8 ottobre 2018 21:50:51 UTC+2, Niall Douglas ha scrit=
to:
>
>
>> I was wondering why the C standard allows implementations to optionally=
=20
>> add intN_t and uintN_t for any N (including 128 and non-powers-of-two li=
ke=20
>> 24), but C++ only mentions 8, 16, 32 and 64. Is there a strong rationale=
=20
>> for that? Would it hurt to explicitly allow those "exotic" integer types=
to=20
>> be conditionally-supported in C++ also?
>>
>> C and C++ are required to define "least" and "fast" forms of various bit=
=20
> sized integers, and only if the architecture permits exactly 8, 16, 32 an=
d=20
> 64 bits does it define typedefs for those.
>
According to my interpretation of the C and C++ standards, if the=20
implementation has a integer types of exactly N bits, it is allowed to=20
provide intN_t and uintN_t aliases in C11 for any N, but it can do so in=20
C++11/14/17 only if N =3D 8, 16, 32, 64. For example, paragraph 7.20.1.1/2 =
in=20
C11 explicitly mentions the possibility to have a uint24_t type. Under this=
=20
interpretation, an implementation may provide int128_t and uint128_t types=
=20
in C but not in C++. I find this strange. Am I missing something?
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/16778768-d08a-41f9-825f-cc683461610e%40isocpp.or=
g.
------=_Part_1612_573991978.1539031124752
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Il giorno luned=C3=AC 8 ottobre 2018 21:50:51 UTC+=
2, Niall Douglas ha scritto:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><br></div><div>I was wondering why the C standard allows implementations =
to optionally add intN_t and uintN_t for any N (including 128 and non-power=
s-of-two like 24), but C++ only mentions 8, 16, 32 and 64. Is there a stron=
g rationale for that? Would it hurt to explicitly allow those "exotic&=
quot; integer types to be conditionally-supported in C++ also?</div><div><b=
r></div></div></blockquote><div>C and C++ are required to define "leas=
t" and "fast" forms of various bit sized integers, and only =
if the architecture permits exactly 8, 16, 32 and 64 bits does it define ty=
pedefs for those.</div></div></blockquote><div><br></div><div>According to =
my interpretation of the C and C++ standards, if the implementation has a i=
nteger types of exactly N bits, it is allowed to provide intN_t and uintN_t=
aliases in C11 for any N, but it can do so in C++11/14/17 only if N =3D 8,=
16, 32, 64. For example, paragraph 7.20.1.1/2 in C11=20
explicitly mentions the possibility to have a uint24_t type. Under this int=
erpretation, an implementation may provide int128_t and uint128_t types in =
C but not in C++. I find this strange. Am I missing something?<br></div></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/16778768-d08a-41f9-825f-cc683461610e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16778768-d08a-41f9-825f-cc683461610e=
%40isocpp.org</a>.<br />
------=_Part_1612_573991978.1539031124752--
------=_Part_1611_18997016.1539031124752--
.
Author: Bo Persson <bop@gmb.dk>
Date: Mon, 8 Oct 2018 23:10:50 +0200
Raw View
On 2018-10-08 22:38, Alberto Barbati wrote:
>=20
>=20
> Il giorno luned=C3=AC 8 ottobre 2018 21:50:51 UTC+2, Niall Douglas ha scr=
itto:
>=20
>=20
> I was wondering why the C standard allows implementations to
> optionally add intN_t and uintN_t for any N (including 128 and
> non-powers-of-two like 24), but C++ only mentions 8, 16, 32 and
> 64. Is there a strong rationale for that? Would it hurt to
> explicitly allow those "exotic" integer types to be
> conditionally-supported in C++ also?
>=20
> C and C++ are required to define "least" and "fast" forms of various
> bit sized integers, and only if the architecture permits exactly 8,
> 16, 32 and 64 bits does it define typedefs for those.
>=20
>=20
> According to my interpretation of the C and C++ standards, if the=20
> implementation has a integer types of exactly N bits, it is allowed to=20
> provide intN_t and uintN_t aliases in C11 for any N, but it can do so in=
=20
> C++11/14/17 only if N =3D 8, 16, 32, 64. For example, paragraph 7.20.1.1/=
2=20
> in C11 explicitly mentions the possibility to have a uint24_t type.=20
> Under this interpretation, an implementation may provide int128_t and=20
> uint128_t types in C but not in C++. I find this strange. Am I missing=20
> something?
>=20
The C++ synopsis only describes the types that are required (if present=20
on the hardware). It doesn't say that this is all that is allowed, but=20
rather refers the rest to the C standard.
16.4/2:
"The header defines all types and macros the same as the C standard=20
library header <stdint.h>.
See also: ISO C 7.20"
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ppgh0n%24usq%241%40blaine.gmane.org.
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 9 Oct 2018 08:38:00 +0200
Raw View
> Il giorno 8 ott 2018, alle ore 23:10, Bo Persson <bop@gmb.dk> ha scritto:
>=20
>> On 2018-10-08 22:38, Alberto Barbati wrote:
>> Il giorno luned=C3=AC 8 ottobre 2018 21:50:51 UTC+2, Niall Douglas ha sc=
ritto:
>> I was wondering why the C standard allows implementations to
>> optionally add intN_t and uintN_t for any N (including 128 and
>> non-powers-of-two like 24), but C++ only mentions 8, 16, 32 and
>> 64. Is there a strong rationale for that? Would it hurt to
>> explicitly allow those "exotic" integer types to be
>> conditionally-supported in C++ also?
>> C and C++ are required to define "least" and "fast" forms of various
>> bit sized integers, and only if the architecture permits exactly 8,
>> 16, 32 and 64 bits does it define typedefs for those.
>> According to my interpretation of the C and C++ standards, if the implem=
entation has a integer types of exactly N bits, it is allowed to provide in=
tN_t and uintN_t aliases in C11 for any N, but it can do so in C++11/14/17 =
only if N =3D 8, 16, 32, 64. For example, paragraph 7.20.1.1/2 in C11 expli=
citly mentions the possibility to have a uint24_t type. Under this interpre=
tation, an implementation may provide int128_t and uint128_t types in C but=
not in C++. I find this strange. Am I missing something?
>=20
> The C++ synopsis only describes the types that are required (if present o=
n the hardware). It doesn't say that this is all that is allowed, but rathe=
r refers the rest to the C standard.
>=20
> 16.4/2:
>=20
> "The header defines all types and macros the same as the C standard libra=
ry header <stdint.h>.
>=20
> See also: ISO C 7.20"
English is not my mother language, but I have always interpreted that state=
ment with the meaning =E2=80=9CThe header defines all types and macros *des=
cribed in the previous paragraphs* the same as the C standard library heade=
r <stdint.h>=E2=80=9D. Since types and macros were introduced without a de=
finition, this interpretation makes sense to me. It would make less sense t=
o define something that hasn=E2=80=99t been previously described. Moreover,=
if we were actually to define *all types and macros of <stdint.h> in the s=
ame way as C does*, we would have to put them in the global namespace. If t=
he intent of that statement is to import optional C11 types not described b=
y the C++ standard in namespace std, I believe the statement ought to be mo=
re explicit.=20
Just my opinion,
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8DB52CAF-5EF3-48E0-914E-E200ABB78873%40gmail.com=
..
.
Author: John McFarlane <john@mcfarlane.name>
Date: Tue, 9 Oct 2018 08:26:23 +0100
Raw View
--00000000000072df3f0577c6a799
Content-Type: text/plain; charset="UTF-8"
On Fri, 5 Oct 2018 at 16:42 Niall Douglas <nialldouglas14@gmail.com> wrote:
> On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John McFarlane wrote:
>>
>> If you're collecting related papers, you might want to mention P0539
>> which is a 100% serious paper.
>>
>>>
>>> My C proposal paper is actually a direct response to P0539, and it
> discusses what I think are showstopper problems with that paper, and why we
> need a language solution instead. As I wrote:
>
> WG21 is currently proceeding down a library-based path for implementing
> extended precision integers (https://wg21.link/P0539), but my issue with
> it is that it is very hard to get the compiler to predictably generate
> optimal code with a library only solution. In particular, compilers fail
> to spot when they can use carry-adds or carry-multiplies from hints
> provided by generic C or C++ code. This is why I have become convinced
> we need a language based implementation so compilers know exactly what
> they are supposed to do. Hence me coming here to WG14.
>
> This makes it a lot clearer that you're talking about P0539. I would not
use shorthand `int<128>` to describe that library type.
I'm not sure why you think that implementers are restricted to supplying
pure-library solutions or why using something like the free functions in
P0103 would not solve this. Do you go into any more detail about the
reasons you don't think a library solution is practical for C++?
>
> Current proposal being discussed on the WG14 reflector looks as follows:
>
> 1. For any integer type excluding _Bool (char, short, int, long, long
> long), one may extend it into an extended arithmetic type by annotating it
> with "_Wide(N)":
>
> - _Wide(4) int
> - long long _Wide(2)
>
> This simply tells the compiler to emit the add-with-carry or
> multiply-with-carries instructions necessary to increase the precision of
> the specified arithmetic type. And before anyone asks, yes it is legal to
> widen small types:
>
> - _Wide(2) short (NOT an int)
> - _Wide(4) char (NOT an int)
>
> 2. These wide integer types are not integral types, and thus do not affect
> intmax_t etc. ABI remains unchanged.
>
> 3. As the compiler knows the size of these at compile time, and that they
> will always be some twos power multiple of an integral type, implementation
> cost for compiler vendors is straightforward. *Optimising* them is hard,
> but then so is optimisation in any case.
>
> 4. These extended types would have the same ABI as a struct of however
> many of their integral type e.g. _Wide(4) long int has the same ABI as
> struct { long int[4] }. So they'll get passed mostly by reference, whatever
> the current calling convention says. Nothing changes for the calling
> convention.
>
That would seem to imply they have 4 sign bits but presumably they don't,
right?
>
> 5. My current feeling is that these wide arithmetic types should have the
> alignment of their integral type but doubled as necessary. This enables
> them to "stand in" for types hardware available on bigger CPUs. It also
> enables SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit
> integer adds four times faster than with the scalar instructions for
> example.
>
Are you only aiming for powers of two? That's another way in which this
would differ from P0539.
John
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnSQWm52fKDQQuH1B3skP3O2tO_5N2gtfJYpZ_P3bMMseQ%40mail.gmail.com.
--00000000000072df3f0577c6a799
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 5 Oct =
2018 at 16:42 Niall Douglas <<a href=3D"mailto:nialldouglas14@gmail.com"=
>nialldouglas14@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Friday, October 5, 2018 at 2:18:30 PM UTC+1, John=
McFarlane wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">If you're coll=
ecting related papers, you might want to mention=C2=A0P0539 which is a 100%=
serious paper.<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><br></blockquote></div></blockquote></div><div dir=3D"ltr"><div>My C prop=
osal paper is actually a direct response to P0539, and it discusses what I =
think are showstopper problems with that paper, and why we need a language =
solution instead. As I wrote:</div><div><br></div><div><pre>WG21 is current=
ly proceeding down a library-based path for implementing
extended precision integers (<a class=3D"m_8064402588688211753moz-txt-link-=
freetext" href=3D"https://wg21.link/P0539" target=3D"_blank">https://wg21.l=
ink/P0539</a>), but my issue with
it is that it is very hard to get the compiler to predictably generate
optimal code with a library only solution. In particular, compilers fail
to spot when they can use carry-adds or carry-multiplies from hints
provided by generic C or C++ code. This is why I have become convinced
we need a language based implementation so compilers know exactly what
they are supposed to do. Hence me coming here to WG14.</pre></div></div></b=
lockquote><div>This makes it a lot clearer that you're talking about P0=
539. I would not use shorthand `int<128>` to describe that library ty=
pe.</div><div><br></div><div>I'm not sure why you think that implemente=
rs are restricted to supplying pure-library solutions or why using somethin=
g like the free functions in P0103 would not solve this. Do you go into any=
more detail about the reasons you don't think a library solution is pr=
actical for C++?<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><br></div><div>Current proposal being discussed on the WG14 reflector l=
ooks as follows:</div><div><br></div> 1. For any integer type excluding _Bo=
ol (char, short, int, long, long long), one may extend it into an extended
arithmetic type by annotating it with "_Wide(N)":<div><br></div><=
div>=C2=A0 =C2=A0 - _Wide(4) int</div><div>=C2=A0 =C2=A0 - long long _Wide(=
2)<br><div><br></div><div>This simply tells the compiler to emit the add-wi=
th-carry or
multiply-with-carries instructions necessary to increase the precision of
the specified arithmetic type. And before anyone asks, yes it is legal to w=
iden small types:</div><div><br></div><div>=C2=A0 =C2=A0 - _Wide(2) short (=
NOT an int)</div><div>=C2=A0 =C2=A0 - _Wide(4) char (NOT an int)</div><div>=
<br></div><div>2. These wide integer types are not integral types, and thus=
do
not affect intmax_t etc. ABI remains unchanged.</div><div><br></div><div>3.=
As the compiler knows the size of these at compile time, and that
they will always be some twos power multiple of an integral type,
implementation cost for compiler vendors is straightforward.
*Optimising* them is hard, but then so is optimisation in any case.</div><d=
iv><br></div><div>4. These extended types would have the same ABI as a stru=
ct of however
many of their integral type e.g. _Wide(4) long int has the same ABI
as struct { long int[4] }. So they'll get passed mostly by reference,
whatever the current calling convention says. Nothing changes for the
calling convention.</div></div></div></blockquote><div><br></div><div>That =
would seem to imply they have 4 sign bits but presumably they don't, ri=
ght?<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br=
></div><div>5. My current feeling is that these wide arithmetic types shoul=
d have
the alignment of their integral type but doubled as necessary. This
enables them to "stand in" for types hardware available on bigger=
CPUs.
It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do
8x 128-bit integer adds four times faster than with the scalar
instructions for example.</div></div></div></blockquote><div><br></div><div=
>Are you only aiming for powers of two? That's another way in which thi=
s would differ from P0539.<br></div><div><br></div><div>John</div><br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnSQWm52fKDQQuH1B3skP3O2tO_5N2gt=
fJYpZ_P3bMMseQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnSQWm52fKDQ=
QuH1B3skP3O2tO_5N2gtfJYpZ_P3bMMseQ%40mail.gmail.com</a>.<br />
--00000000000072df3f0577c6a799--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Tue, 9 Oct 2018 01:51:02 -0700 (PDT)
Raw View
------=_Part_892_1103273674.1539075063061
Content-Type: multipart/alternative;
boundary="----=_Part_893_1896959956.1539075063061"
------=_Part_893_1896959956.1539075063061
Content-Type: text/plain; charset="UTF-8"
>
> I'm not sure why you think that implementers are restricted to supplying
> pure-library solutions or why using something like the free functions in
> P0103 would not solve this. Do you go into any more detail about the
> reasons you don't think a library solution is practical for C++?
>
I do go into more detail, but the crux of it is that to get efficient
codegen, you're going to either have to (a) hint to the compiler using
intrinsics what you're doing or (b) have the compiler special case how it
interprets wide_integer<>. I would argue in that case, just bite the bullet
and add it to the core C language.
> That would seem to imply they have 4 sign bits but presumably they don't,
>> right?
>>
>
They do not.
>
>> 5. My current feeling is that these wide arithmetic types should have the
>> alignment of their integral type but doubled as necessary. This enables
>> them to "stand in" for types hardware available on bigger CPUs. It also
>> enables SIMD vectorisation by optimisers - AVX-512 CPUs can do 8x 128-bit
>> integer adds four times faster than with the scalar instructions for
>> example.
>>
>
> Are you only aiming for powers of two? That's another way in which this
> would differ from P0539.
>
> There are many more C compiler implementations than C++ compilers. WG14
feels it is important that a C compiler can be easily implemented by a
single person in a reasonable period of time. Using powers of two covers
the majority use case at minimum implementation expense, indeed such
implementation for arbitrary fixed length extended precision integers could
be done within a day or two.
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/04fe952f-e38b-4982-b5cc-3b5002261d50%40isocpp.org.
------=_Part_893_1896959956.1539075063061
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div>I'm not sure why you think that imp=
lementers are restricted to supplying pure-library solutions or why using s=
omething like the free functions in P0103 would not solve this. Do you go i=
nto any more detail about the reasons you don't think a library solutio=
n is practical for C++?<br></div></div></div></blockquote><div><br></div><d=
iv>I do go into more detail, but the crux of it is that to get efficient co=
degen, you're going to either have to (a) hint to the compiler using in=
trinsics what you're doing or (b) have the compiler special case how it=
interprets wide_integer<>. I would argue in that case, just bite the=
bullet and add it to the core C language.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That wo=
uld seem to imply they have 4 sign bits but presumably they don't, righ=
t?<br></div></div></blockquote></div></div></blockquote><div><br></div><div=
>They do not.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div><br></div><div>5. My current feeling is=
that these wide arithmetic types should have
the alignment of their integral type but doubled as necessary. This
enables them to "stand in" for types hardware available on bigger=
CPUs.
It also enables SIMD vectorisation by optimisers - AVX-512 CPUs can do
8x 128-bit integer adds four times faster than with the scalar
instructions for example.</div></div></div></blockquote><div><br></div><div=
>Are you only aiming for powers of two? That's another way in which thi=
s would differ from P0539.<br></div><br></div></div></blockquote><div>There=
are many more C compiler implementations than C++ compilers. WG14 feels it=
is important that a C compiler can be easily implemented by a single perso=
n in a reasonable period of time. Using powers of two covers the majority u=
se case at minimum implementation expense, indeed such implementation for a=
rbitrary fixed length extended precision integers could be done within a da=
y or two.</div><div><br></div><div>Niall</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/04fe952f-e38b-4982-b5cc-3b5002261d50%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/04fe952f-e38b-4982-b5cc-3b5002261d50=
%40isocpp.org</a>.<br />
------=_Part_893_1896959956.1539075063061--
------=_Part_892_1103273674.1539075063061--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 9 Oct 2018 13:36:29 +0200
Raw View
Am Mo., 8. Okt. 2018 um 22:38 Uhr schrieb Alberto Barbati
<albertobarbati@gmail.com>:
>
>
>
> Il giorno luned=C3=AC 8 ottobre 2018 21:50:51 UTC+2, Niall Douglas ha scr=
itto:
>>>
>>>
>>> I was wondering why the C standard allows implementations to optionally=
add intN_t and uintN_t for any N (including 128 and non-powers-of-two like=
24), but C++ only mentions 8, 16, 32 and 64. Is there a strong rationale f=
or that? Would it hurt to explicitly allow those "exotic" integer types to =
be conditionally-supported in C++ also?
>>>
>> C and C++ are required to define "least" and "fast" forms of various bit=
sized integers, and only if the architecture permits exactly 8, 16, 32 and=
64 bits does it define typedefs for those.
>
>
> According to my interpretation of the C and C++ standards, if the impleme=
ntation has a integer types of exactly N bits, it is allowed to provide int=
N_t and uintN_t aliases in C11 for any N, but it can do so in C++11/14/17 o=
nly if N =3D 8, 16, 32, 64. For example, paragraph 7.20.1.1/2 in C11 explic=
itly mentions the possibility to have a uint24_t type. Under this interpret=
ation, an implementation may provide int128_t and uint128_t types in C but =
not in C++. I find this strange. Am I missing something?
>
Please take a look at
http://cplusplus.github.io/LWG/lwg-active.html#2820
which should solve the current deviation between C and C++ (at least
that seems to be the intention).
Thanks,
- Daniel
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGNvRgDozYv5_bEM6mkrFF-Nz%2Bm%3D6rb1fHfL5nyOzuA=
UwtObVg%40mail.gmail.com.
.
Author: olafvdspek@gmail.com
Date: Tue, 9 Oct 2018 06:35:53 -0700 (PDT)
Raw View
------=_Part_2159_479309680.1539092153244
Content-Type: multipart/alternative;
boundary="----=_Part_2160_1263561493.1539092153244"
------=_Part_2160_1263561493.1539092153244
Content-Type: text/plain; charset="UTF-8"
Op maandag 8 oktober 2018 21:47:24 UTC+2 schreef Niall Douglas:
>
> What about having 'intrinsics' for carry-adds, carry-multiplies and other
>> operations (saturating and wrapping ops for example)?
>>
>
> Firstly, I am unaware of any precedent for that sort of intrinsic in
> either C or C++. It seems too specific for standardisation to me, but maybe
> I'm wrong.
>
Maybe, maybe not. I've wondered about intrinsics like "read (aligned)
big-endian / little-endian 8/16/32/64-bit value from *p" before. They seem
kinda simple to define for appropriate definitions of simple. ;)
Same for this one.
> Secondly, such a thing would be rather hardware dependent. For example
> RISC V has no carry flag, and thus no carry based arithmetic. So kinda hard
> to standardise such support.
>
> Would emulation of the intrinsic be worse than doing it without the
intrinsic? In that case a way to detect the intrinsic being available would
make sense.
Not having the intrinsic at all just makes it much harder for everybody
that still needs the functionality.
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b92f5a7d-109d-4386-a0ed-e33d088672e0%40isocpp.org.
------=_Part_2160_1263561493.1539092153244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op maandag 8 oktober 2018 21:47:24 UTC+2 schreef Niall Dou=
glas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>What about having =
9;intrinsics' for carry-adds, carry-multiplies and other operations (sa=
turating and wrapping ops for example)?</div></div></blockquote><div><br></=
div><div>Firstly, I am unaware of any precedent for that sort of intrinsic =
in either C or C++. It seems too specific for standardisation to me, but ma=
ybe I'm wrong.</div></div></blockquote><div><br></div><div>Maybe, maybe=
not. I've wondered about intrinsics like "read (aligned) big-endi=
an / little-endian 8/16/32/64-bit value from *p" before. They seem kin=
da simple to define for appropriate definitions of simple. ;)</div><div>Sam=
e for this one.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>Secondly, such a thing would be rather hardwa=
re dependent. For example RISC V has no carry flag, and thus no carry based=
arithmetic. So kinda hard to standardise such support.</div><div><br></div=
></div></blockquote><div>Would emulation of the intrinsic be worse than doi=
ng it without the intrinsic? In that case a way to detect the intrinsic bei=
ng available would make sense.</div><div><br></div><div>Not having the intr=
insic at all just makes it much harder for everybody that still needs the f=
unctionality.</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b92f5a7d-109d-4386-a0ed-e33d088672e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b92f5a7d-109d-4386-a0ed-e33d088672e0=
%40isocpp.org</a>.<br />
------=_Part_2160_1263561493.1539092153244--
------=_Part_2159_479309680.1539092153244--
.
Author: "'Alisdair Meredith' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 09 Oct 2018 09:39:19 -0400
Raw View
--Apple-Mail=_46581A95-EB9A-4F2C-8296-1697805CE5F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Thanks - my main concern is that the topic is either explicitly addresses, =
or
explicitly not addressed, so readers off the proposal do not have differing
understandings!
AlisdairM
> On Oct 8, 2018, at 16:01, Niall Douglas <nialldouglas14@gmail.com> wrote:
>=20
> On Friday, October 5, 2018 at 6:10:37 PM UTC+1, Alisdair Meredith wrote:
> Does your proposal address _Atomic in C, and atomic<integral> in C++? I =
want to be sure that no-one is laboring under conflicting assumptions here,=
even when it means stating the (apparently) obvious.
>=20
> So, WG14 seem to feel it ought to address _Atomic with support for arbitr=
ary fixed length extended precision integers. I shall try my best to write =
something coherent on that.
>=20
> Niall=20
>=20
> --=20
> 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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b114-365a53ecf256%40isocpp.=
org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf21d232-=
2924-45bc-b114-365a53ecf256%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>.
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6F96D8A5-D6EA-4858-A15C-28477A36E4AE%40me.com.
--Apple-Mail=_46581A95-EB9A-4F2C-8296-1697805CE5F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; line-break: after-white-space;" class=3D"">Thanks - my main concer=
n is that the topic is either explicitly addresses, or<div class=3D"">expli=
citly not addressed, so readers off the proposal do not have differing</div=
><div class=3D"">understandings!</div><div class=3D""><br class=3D""></div>=
<div class=3D"">AlisdairM<br class=3D""><div><br class=3D""><blockquote typ=
e=3D"cite" class=3D""><div class=3D"">On Oct 8, 2018, at 16:01, Niall Dougl=
as <<a href=3D"mailto:nialldouglas14@gmail.com" class=3D"">nialldouglas1=
4@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><di=
v class=3D""><div dir=3D"ltr" class=3D"">On Friday, October 5, 2018 at 6:10=
:37 PM UTC+1, Alisdair Meredith wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"auto" class=3D"">Does your proposal address _Atomic in =
C, and atomic<integral> in C++? I want to be sure that no-one i=
s laboring under conflicting assumptions here, even when it means stating t=
he (apparently) obvious.<br class=3D""></div></blockquote><div class=3D""><=
br class=3D""></div><div class=3D"">So, WG14 seem to feel it ought to addre=
ss _Atomic with support for arbitrary fixed length extended precision integ=
ers. I shall try my best to write something coherent on that.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">Niall </div></div><div cl=
ass=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b114-365a53ecf256%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"">https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf21d232-2924-45bc-b1=
14-365a53ecf256%40isocpp.org</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6F96D8A5-D6EA-4858-A15C-28477A36E4AE%=
40me.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/6F96D8A5-D6EA-4858-A15C-28477A36E4AE%40m=
e.com</a>.<br />
--Apple-Mail=_46581A95-EB9A-4F2C-8296-1697805CE5F6--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 9 Oct 2018 06:45:51 -0700 (PDT)
Raw View
------=_Part_2025_37634827.1539092751963
Content-Type: multipart/alternative;
boundary="----=_Part_2026_125467666.1539092751963"
------=_Part_2026_125467666.1539092751963
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno marted=C3=AC 9 ottobre 2018 13:36:40 UTC+2, Daniel Kr=C3=BCgler h=
a scritto:
>
> >=20
> > According to my interpretation of the C and C++ standards, if the=20
> implementation has a integer types of exactly N bits, it is allowed to=20
> provide intN_t and uintN_t aliases in C11 for any N, but it can do so in=
=20
> C++11/14/17 only if N =3D 8, 16, 32, 64. For example, paragraph 7.20.1.1/=
2=20
> in C11 explicitly mentions the possibility to have a uint24_t type. Under=
=20
> this interpretation, an implementation may provide int128_t and uint128_t=
=20
> types in C but not in C++. I find this strange. Am I missing something?=
=20
> >=20
>
> Please take a look at=20
>
> http://cplusplus.github.io/LWG/lwg-active.html#2820=20
>
> which should solve the current deviation between C and C++ (at least=20
> that seems to be the intention).=20
>
>
Daniel, thank you very much for the pointer. The proposed resolution of=20
this issue completely addresses my concerns. I hope it will get integrated=
=20
in C++2a.
Alberto
--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/83c3e7fb-b58a-40e1-a6bb-958e86c33aab%40isocpp.or=
g.
------=_Part_2026_125467666.1539092751963
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Il giorno marted=C3=AC 9 ottobre 2018 13:36:40 UTC+2, =
Daniel Kr=C3=BCgler ha scritto:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>>
<br>> According to my interpretation of the C and C++ standards, if the =
implementation has a integer types of exactly N bits, it is allowed to prov=
ide intN_t and uintN_t aliases in C11 for any N, but it can do so in C++11/=
14/17 only if N =3D 8, 16, 32, 64. For example, paragraph <a href=3D"http:/=
/7.20.1.1/2" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\x3dhttp%3A%2F%2F7.20.1.1%2F2\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNHJjLqHDKaWdtZG9qmlu4DD8zPTgA';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F7.2=
0.1.1%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHJjLqHDKaWdtZG9qmlu4DD8zP=
TgA';return true;">7.20.1.1/2</a> in C11 explicitly mentions the possib=
ility to have a uint24_t type. Under this interpretation, an implementation=
may provide int128_t and uint128_t types in C but not in C++. I find this =
strange. Am I missing something?
<br>>
<br>
<br>Please take a look at
<br>
<br><a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#2820" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-active.html%2=
32820\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG33BbpU2Omjim0Wulmi_JqXkzYIg&=
#39;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-active.html%232820\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNG33BbpU2Omjim0Wulmi_JqXkzYIg';return tr=
ue;">http://cplusplus.github.io/<wbr>LWG/lwg-active.html#2820</a>
<br>
<br>which should solve the current deviation between C and C++ (at least
<br>that seems to be the intention).
<br>
<br></blockquote><div><br></div><div>Daniel, thank you very much for the po=
inter. The proposed resolution of this issue completely addresses my concer=
ns. I hope it will get integrated in C++2a.<br></div><div><br></div><div>Al=
berto<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/83c3e7fb-b58a-40e1-a6bb-958e86c33aab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83c3e7fb-b58a-40e1-a6bb-958e86c33aab=
%40isocpp.org</a>.<br />
------=_Part_2026_125467666.1539092751963--
------=_Part_2025_37634827.1539092751963--
.