Topic: Portable Defined behavior on signed 2's
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 6 Oct 2016 18:51:24 -0700 (PDT)
Raw View
------=_Part_427_272779843.1475805084528
Content-Type: multipart/alternative;
boundary="----=_Part_428_237924321.1475805084528"
------=_Part_428_237924321.1475805084528
Content-Type: text/plain; charset=UTF-8
On Thursday, October 6, 2016 at 9:25:40 PM UTC-4, Matthew Fioravante wrote:
>
> So there is this long standing question of integer representations. C++
> tries to support as many theoretical hardware platforms as possible but
> sometimes hardware converges to one solution which is adopted for all
> practical purposes universally.
>
> This seems to be the case with the fact that as far as I know every modern
> architecture represents signed integers using 2's complement and has been
> doing so for decades.
> The practical consequence is the fact that the result of right shifting a
> signed integer is implementation defined.
>
> int x = -937;
> x >> 6; //Implementation defined result
>
> Technically this means you cannot portably right shift a signed integer in
> C++ and to add insult to injury the standard library doesn't provide any
> alternative inline function to do a portable right arithmetic shift. Some
> people have been saying we should drop support for other integer
> representations and base the C++ standard on 2's complement. I'd be onboard
> with that but there is also a compromise that effectively gives everyone
> what they want.
>
> Instead of removing theoretical support for other integer representations
> for the standard, I think as first step we should just define such
> operations on all 2's complement platforms that implement C++.
>
> In other words, the rule should be:
>
> "If your platform represents signed integers using 2's complement, then
> operator>>(signed integral, int) is defined to perform a right arithmetic
> shift. If your platform does not use 2's complement, the result of
> operator>>(signed integral, int) is implementation defined"
>
> This compromise still allows theoretical support for other integer
> representations while giving all of us living in the real world the
> portable behavior that all compilers already implement anyway. It does not
> preclude later removing support for other integer representations from the
> standard.
>
Your proposal is based on the assumption that all platforms that use 2's
complement signed integers also have a fast arithmetic right-shift. Is that
actually true? Because if it's not, then you force them to do complicated
logic that will make `operator>>` significantly slower than it ought to be.
--
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/d6b7a8bc-b916-4ecb-899b-7e8f18060d66%40isocpp.org.
------=_Part_428_237924321.1475805084528
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 6, 2016 at 9:25:40 PM UTC-4, =
Matthew Fioravante 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"ltr">So there is this long standing question of integer representati=
ons. C++ tries to support as many theoretical hardware platforms as possibl=
e but sometimes hardware converges to one solution which is adopted for all=
practical purposes universally.<div><br></div><div>This seems to be the ca=
se with the fact that as far as I know every modern architecture represents=
signed integers using 2's complement and has been doing so for decades=
..=C2=A0</div><div>The practical consequence is the fact that the result of =
right shifting a signed integer is implementation defined.</div><div><br></=
div><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#008">int</span><span style=3D"color:#000"> x </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </spa=
n><font color=3D"#006666"><span style=3D"color:#660">-</span><span style=3D=
"color:#066">937</span></font><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br>x </span><span style=3D"color:#660">>></span><fo=
nt color=3D"#006666"><span style=3D"color:#000"> </span><span style=3D"colo=
r:#066">6</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">//Implementation defined result</span=
></font><font color=3D"#006666"></font></div></code></div><br></div><div>Te=
chnically this means you cannot portably right shift a signed integer in C+=
+ and to add insult to injury the standard library doesn't provide any =
alternative inline function to do a portable right arithmetic shift. Some p=
eople have been saying we should drop support for other integer representat=
ions and base the C++ standard on 2's complement. I'd be onboard wi=
th that but there is also a compromise that effectively gives everyone what=
they want.</div><div><br></div><div>Instead of removing theoretical suppor=
t for other integer representations for the standard, I think as first step=
we should just define such operations on all 2's complement platforms =
that implement C++.</div><div><br></div><div>In other words, the rule shoul=
d be:</div><div><br></div><div>"If your platform represents signed int=
egers using 2's complement, then operator>>(signed integral, int)=
is defined to perform a right arithmetic shift. If your platform does not =
use 2's complement, the result of operator>>(signed integral, int=
) is implementation defined"</div><div><br></div><div>This compromise =
still allows theoretical support for other integer representations while gi=
ving all of us living in the real world the portable behavior that all comp=
ilers already implement anyway. It does not preclude later removing support=
for other integer representations from the standard.</div></div></blockquo=
te><div><br>Your proposal is based on the assumption that all platforms tha=
t use 2's complement signed integers also have a fast arithmetic right-=
shift. Is that actually true? Because if it's not, then you force them =
to do complicated logic that will make `operator>>` significantly slo=
wer than it ought to be.<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/d6b7a8bc-b916-4ecb-899b-7e8f18060d66%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6b7a8bc-b916-4ecb-899b-7e8f18060d66=
%40isocpp.org</a>.<br />
------=_Part_428_237924321.1475805084528--
------=_Part_427_272779843.1475805084528--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Thu, 6 Oct 2016 19:19:34 -0700 (PDT)
Raw View
------=_Part_402_819388183.1475806774478
Content-Type: multipart/alternative;
boundary="----=_Part_403_194616031.1475806774478"
------=_Part_403_194616031.1475806774478
Content-Type: text/plain; charset=UTF-8
On Thursday, October 6, 2016 at 8:51:24 PM UTC-5, Nicol Bolas wrote:
>
>
> Your proposal is based on the assumption that all platforms that use 2's
> complement signed integers also have a fast arithmetic right-shift. Is that
> actually true? Because if it's not, then you force them to do complicated
> logic that will make `operator>>` significantly slower than it ought to be.
>
I believe it is. I think Chandler Carruth implied this in his Cppcon talk.
To not implement right arithmetic shift efficiently on a 2's complement
machine is insane.
Even if there is such a beast out there, whats worse? Having an unoptimized
operator>> on that strange platform or making all of the decades of
software which already assumes the behavior incompatible with said machine?
Also what possible value is there is having operator>>() for signed
integers on a 2's complement do anything other than right shift? All it
accomplishes is a confusing incompatibility that programmers should not
spending their time worrying about.
--
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/9db7123b-a894-427a-baf8-3e1c0a2dd2bd%40isocpp.org.
------=_Part_403_194616031.1475806774478
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 6, 2016 at 8:51:24 PM UTC-5, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br>Your proposal is based on the assumption that all platforms t=
hat use 2's complement signed integers also have a fast arithmetic righ=
t-shift. Is that actually true? Because if it's not, then you force the=
m to do complicated logic that will make `operator>>` significantly s=
lower than it ought to be.<br></div></div></blockquote><div><br></div><div>=
I believe it is. I think Chandler Carruth implied this in his Cppcon talk.<=
/div><div><br></div><div>To not implement right arithmetic shift efficientl=
y on a 2's complement machine is insane.=C2=A0</div><div><br></div><div=
>Even if there is such a beast out there, whats worse? Having an unoptimize=
d operator>> on that strange platform or making all of the decades of=
software which already assumes the behavior incompatible with said machine=
?=C2=A0</div><div><br></div><div>Also what possible value is there is havin=
g operator>>() for signed integers on a 2's complement do anythin=
g other than right shift? All it accomplishes is a confusing incompatibilit=
y that programmers should not spending their time worrying about.</div></di=
v>
<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/9db7123b-a894-427a-baf8-3e1c0a2dd2bd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9db7123b-a894-427a-baf8-3e1c0a2dd2bd=
%40isocpp.org</a>.<br />
------=_Part_403_194616031.1475806774478--
------=_Part_402_819388183.1475806774478--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 07 Oct 2016 15:31:09 +0200
Raw View
Em quinta-feira, 6 de outubro de 2016, =C3=A0s 18:51:24 CEST, Nicol Bolas e=
screveu:
> Your proposal is based on the assumption that all platforms that use 2's
> complement signed integers also have a fast arithmetic right-shift. Is th=
at
> actually true? Because if it's not, then you force them to do complicated
> logic that will make `operator>>` significantly slower than it ought to b=
e.
Shifts can be defined in terms of the bit patterns, regardless of the value=
=20
that they represent. At worst, we can define them in terms of the unsigned=
=20
equivalent of the same bit pattern and let that sort itself out to the thre=
e=20
possible signed representations.
Either way, the result is well-defined, if the representation is defined.
Also note that the signed integers from <stdint.h> are required to be two's=
=20
complement.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/1504790.VcC9kqEGju%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 7 Oct 2016 08:20:55 -0700 (PDT)
Raw View
------=_Part_546_1648586497.1475853655543
Content-Type: multipart/alternative;
boundary="----=_Part_547_1191027613.1475853655543"
------=_Part_547_1191027613.1475853655543
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:
>
> Also note that the signed integers from <stdint.h> are required to be
> two's
> complement.
>
Where does the standard make that requirement?
--
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/0ba4e387-364a-4a98-850b-a82bd5ca7e69%40isocpp.org.
------=_Part_547_1191027613.1475853655543
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Also note that the=
signed integers from <stdint.h> are required to be two's=20
<br>complement.
<br></blockquote><div><br>Where does the standard make that requirement?</d=
iv></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/0ba4e387-364a-4a98-850b-a82bd5ca7e69%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ba4e387-364a-4a98-850b-a82bd5ca7e69=
%40isocpp.org</a>.<br />
------=_Part_547_1191027613.1475853655543--
------=_Part_546_1648586497.1475853655543--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 7 Oct 2016 09:16:21 -0700 (PDT)
Raw View
------=_Part_1460_217239687.1475856981166
Content-Type: multipart/alternative;
boundary="----=_Part_1461_1683150403.1475856981166"
------=_Part_1461_1683150403.1475856981166
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:
>
> On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:
>>
>> Also note that the signed integers from <stdint.h> are required to be=20
>> two's=20
>> complement.=20
>>
>
> Where does the standard make that requirement?
>
From C11 draft at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
7.20.1.1 Exact-width integer types
The typedef name intN_t designates a signed integer type with width N, no=
=20
padding
bits, *and a two=E2=80=99s complement representation*. Thus, int8_t denotes=
such a=20
signed
integer type with a width of exactly 8 bits.
Fairly certain it's been that way since stdint was introduced and the=20
requirements are fully inherited by cstdint
--=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/61105887-3a75-479e-97ed-b34e95d1449e%40isocpp.or=
g.
------=_Part_1461_1683150403.1475856981166
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bola=
s 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"ltr">On Fr=
iday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">Also note that the signed integers from <s=
tdint.h> are required to be two's=20
<br>complement.
<br></blockquote><div><br>Where does the standard make that requirement?</d=
iv></div></blockquote><div><br></div><div>From C11 draft at http://www.open=
-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf</div><div><br></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>7.20.1.=
1 Exact-width integer types</div></div><div><div><br></div></div><div><div>=
The typedef name intN_t designates a signed integer type with width N, no p=
adding</div></div><div><div>bits, <b>and a two=E2=80=99s complement represe=
ntation</b>. Thus, int8_t denotes such a signed</div></div><div><div>intege=
r type with a width of exactly 8 bits.</div></div></blockquote><div><br></d=
iv><div>Fairly certain it's been that way since stdint was introduced a=
nd the requirements are fully inherited by cstdint</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/61105887-3a75-479e-97ed-b34e95d1449e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61105887-3a75-479e-97ed-b34e95d1449e=
%40isocpp.org</a>.<br />
------=_Part_1461_1683150403.1475856981166--
------=_Part_1460_217239687.1475856981166--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 7 Oct 2016 12:56:09 -0700 (PDT)
Raw View
------=_Part_612_1111459534.1475870169702
Content-Type: multipart/alternative;
boundary="----=_Part_613_1965677805.1475870169703"
------=_Part_613_1965677805.1475870169703
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 7, 2016 at 9:16:21 AM UTC-7, Sean Middleditch wrote:
>
> On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:
>>
>> On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:
>>>
>>> Also note that the signed integers from <stdint.h> are required to be=
=20
>>> two's=20
>>> complement.=20
>>>
>>
>> Where does the standard make that requirement?
>>
>
> From C11 draft at=20
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
> 7.20.1.1 Exact-width integer types
>
> The typedef name intN_t designates a signed integer type with width N, no=
=20
> padding
> bits, *and a two=E2=80=99s complement representation*. Thus, int8_t denot=
es such=20
> a signed
> integer type with a width of exactly 8 bits.
>
>
> Fairly certain it's been that way since stdint was introduced and the=20
> requirements are fully inherited by cstdint
>
No; C++ does not inherit this requirement from C. As a practical matter,=
=20
however, it is true.
The proposal that I'm writing for std::int_t<> discusses this=20
inconsistency, but doesn't suggest a solution.
On Thursday, October 6, 2016 at 6:51:24 PM UTC-7, Nicol Bolas wrote:
> Your proposal is based on the assumption that all platforms that use 2's=
=20
> complement signed integers also have a fast arithmetic right-shift. Is th=
at=20
> actually true? Because if it's not, then you force them to do complicated=
=20
> logic that will make `operator>>` significantly slower than it ought to b=
e.
>
Imagine an x86-32 CPU without an "sar" instruction. If you wanted to=20
arithmetically shift right "eax" by "cl" bits, you could do this:
mov edx, eax
add edx, edx
sbb edx, edx
shr eax, cl
xor ecx, byte 31
shl edx, cl
add edx, edx
or eax, edx
Even without trying to optimize that more, 8 instructions isn't too bad. =
=20
It's even better in MIPS:
srl t0, a0, 31
subu t0, zero, t0
srlv a0, a0, s0
subu t1, zero, s0
sllv t0, t0, t1
or a0, a0, t0
In my opinion, the cost of being a weird architecture should be borne by=20
the weird architecture, not everyone else.
Melissa
--=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/d996dae4-8735-4385-a5b7-7ccaa2a374f9%40isocpp.or=
g.
------=_Part_613_1965677805.1475870169703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 9:16:21 AM UTC-7, Sean Middl=
editch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, October 7, 2016 =
at 9:31:45 AM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">Also note that the signed integers from <stdint.h> are requir=
ed to be two's=20
<br>complement.
<br></blockquote><div><br>Where does the standard make that requirement?</d=
iv></div></blockquote><div><br></div><div>From C11 draft at <a href=3D"http=
://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1570.=
pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5FEkXxBQhB4KcUnllA2A6SJC_cQ=
9;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1570.pd=
f\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5FEkXxBQhB4KcUnllA2A6SJC_cQ'=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg14/www/docs/n1570.p=
df</a></div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:no=
ne;padding:0px"><div><div>7.20.1.1 Exact-width integer types</div></div><di=
v><div><br></div></div><div><div>The typedef name intN_t designates a signe=
d integer type with width N, no padding</div></div><div><div>bits, <b>and a=
two=E2=80=99s complement representation</b>. Thus, int8_t denotes such a s=
igned</div></div><div><div>integer type with a width of exactly 8 bits.</di=
v></div></blockquote><div><br></div><div>Fairly certain it's been that =
way since stdint was introduced and the requirements are fully inherited by=
cstdint</div></div></blockquote><div><br>No; C++ does not inherit this req=
uirement from C.=C2=A0 As a practical matter, however, it is true.<br><br>T=
he proposal that I'm writing for std::int_t<> discusses this inco=
nsistency, but doesn't suggest a solution.<br><br><br><br><br>On Thursd=
ay, October 6, 2016 at 6:51:24 PM UTC-7, Nicol Bolas wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;">Your
proposal is based on the assumption that all platforms that use 2's=20
complement signed integers also have a fast arithmetic right-shift. Is=20
that actually true? Because if it's not, then you force them to do=20
complicated logic that will make `operator>>` significantly slower
than it ought to be.<br></blockquote><br>Imagine an x86-32 CPU without an =
"sar" instruction.=C2=A0 If you wanted to arithmetically shift ri=
ght "eax" by "cl" bits, you could do this:<br><br>mov e=
dx, eax<br>add edx, edx<br>sbb edx, edx<br>shr eax, cl<br>xor ecx, byte 31<=
br>shl edx, cl<br>add edx, edx<br>or eax, edx<br><br>Even without trying to=
optimize that more, 8 instructions isn't too bad.=C2=A0 It's even =
better in MIPS:<br><br>srl t0, a0, 31<br>subu t0, zero, t0<br>srlv a0, a0, =
s0<br>subu t1, zero, s0<br>sllv t0, t0, t1<br>or a0, a0, t0<br><br>In my op=
inion, the cost of being a weird architecture should be borne by the weird =
architecture, not everyone else.<br><br>Melissa<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/d996dae4-8735-4385-a5b7-7ccaa2a374f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d996dae4-8735-4385-a5b7-7ccaa2a374f9=
%40isocpp.org</a>.<br />
------=_Part_613_1965677805.1475870169703--
------=_Part_612_1111459534.1475870169702--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 7 Oct 2016 13:30:56 -0700 (PDT)
Raw View
------=_Part_2192_1156752710.1475872256867
Content-Type: multipart/alternative;
boundary="----=_Part_2193_1188860244.1475872256867"
------=_Part_2193_1188860244.1475872256867
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, October 7, 2016 at 12:16:21 PM UTC-4, Sean Middleditch wrote:
>
> On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:
>>
>> On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:
>>>
>>> Also note that the signed integers from <stdint.h> are required to be=
=20
>>> two's=20
>>> complement.=20
>>>
>>
>> Where does the standard make that requirement?
>>
>
> From C11 draft at=20
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
> 7.20.1.1 Exact-width integer types
>
> The typedef name intN_t designates a signed integer type with width N, no=
=20
> padding
> bits, *and a two=E2=80=99s complement representation*. Thus, int8_t denot=
es such=20
> a signed
> integer type with a width of exactly 8 bits.
>
>
> Fairly certain it's been that way since stdint was introduced and the=20
> requirements are fully inherited by cstdint
>
So it's only the exact sized types, not the `_least` types and so forth,=20
right?=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/9420cec4-a415-4c7c-95e4-b5004077737e%40isocpp.or=
g.
------=_Part_2193_1188860244.1475872256867
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 7, 2016 at 12:16:21 PM UTC-4, S=
ean Middleditch 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"ltr">On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:=
<blockquote 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">On Friday, October=
7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Also note that the signed integers from <stdint.h> a=
re required to be two's=20
<br>complement.
<br></blockquote><div><br>Where does the standard make that requirement?</d=
iv></div></blockquote><div><br></div><div>From C11 draft at <a href=3D"http=
://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1570.=
pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5FEkXxBQhB4KcUnllA2A6SJC_cQ=
9;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1570.pd=
f\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH5FEkXxBQhB4KcUnllA2A6SJC_cQ'=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg14/www/docs/n1570.p=
df</a></div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:no=
ne;padding:0px"><div><div>7.20.1.1 Exact-width integer types</div></div><di=
v><div><br></div></div><div><div>The typedef name intN_t designates a signe=
d integer type with width N, no padding</div></div><div><div>bits, <b>and a=
two=E2=80=99s complement representation</b>. Thus, int8_t denotes such a s=
igned</div></div><div><div>integer type with a width of exactly 8 bits.</di=
v></div></blockquote><div><br></div><div>Fairly certain it's been that =
way since stdint was introduced and the requirements are fully inherited by=
cstdint</div></div></blockquote><div><br>So it's only the exact sized =
types, not the `_least` types and so forth, right? <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/9420cec4-a415-4c7c-95e4-b5004077737e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9420cec4-a415-4c7c-95e4-b5004077737e=
%40isocpp.org</a>.<br />
------=_Part_2193_1188860244.1475872256867--
------=_Part_2192_1156752710.1475872256867--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 7 Oct 2016 13:38:55 -0700 (PDT)
Raw View
------=_Part_3383_856134143.1475872735815
Content-Type: multipart/alternative;
boundary="----=_Part_3384_201520402.1475872735815"
------=_Part_3384_201520402.1475872735815
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 1:30:57 PM UTC-7, Nicol Bolas wrote:
>
>
> So it's only the exact sized types, not the `_least` types and so forth,
> right?
>
Correct; the least and fast types have no requirement of being two's
complement or not having padding.
Melissa
--
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/d31d2e29-e85f-4134-8cee-b575d4e9a32d%40isocpp.org.
------=_Part_3384_201520402.1475872735815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 1:30:57 PM UTC-7, Nicol Bola=
s 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"ltr"><br><=
div>So it's only the exact sized types, not the `_least` types and so f=
orth, right? <br></div></div></blockquote><div><br>Correct; the least and f=
ast types have no requirement of being two's complement or not having p=
adding.<br><br>Melissa <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/d31d2e29-e85f-4134-8cee-b575d4e9a32d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d31d2e29-e85f-4134-8cee-b575d4e9a32d=
%40isocpp.org</a>.<br />
------=_Part_3384_201520402.1475872735815--
------=_Part_3383_856134143.1475872735815--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 7 Oct 2016 23:44:18 +0300
Raw View
On 10/07/16 22:56, Myriachan wrote:
> On Friday, October 7, 2016 at 9:16:21 AM UTC-7, Sean Middleditch wrote:
>
> On Friday, October 7, 2016 at 8:20:56 AM UTC-7, Nicol Bolas wrote:
>
> On Friday, October 7, 2016 at 9:31:45 AM UTC-4, Thiago Macieira
> wrote:
>
> Also note that the signed integers from <stdint.h> are
> required to be two's
> complement.
>
>
> Where does the standard make that requirement?
>
>
> From C11 draft at
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
>
> 7.20.1.1 Exact-width integer types
>
> The typedef name intN_t designates a signed integer type with
> width N, no padding
> bits, *and a two=E2=80=99s complement representation*. Thus, int8=
_t
> denotes such a signed
> integer type with a width of exactly 8 bits.
>
>
> Fairly certain it's been that way since stdint was introduced and
> the requirements are fully inherited by cstdint
>
> No; C++ does not inherit this requirement from C.
Is that so? Could you point me to the place in the C++ standard that=20
says this?
As far as I can see, [headers]/4 defines <cstdint> in terms of the C=20
standard, and it requires intN_t be two's complement integers.=20
[cstdint.syn]/2 reinforces that:
The header defines all types and macros the same as the C standard
library header <stdint.h>.
--=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/14159137-959b-f555-dcd9-de449be96d16%40gmail.com=
..
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 7 Oct 2016 13:56:44 -0700 (PDT)
Raw View
------=_Part_3546_1885709065.1475873804972
Content-Type: multipart/alternative;
boundary="----=_Part_3547_1638101304.1475873804972"
------=_Part_3547_1638101304.1475873804972
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 1:45:00 PM UTC-7, Andrey Semashev wrote:
>
> On 10/07/16 22:56, Myriachan wrote:
> > Fairly certain it's been that way since stdint was introduced and
> > the requirements are fully inherited by cstdint
> >
> > No; C++ does not inherit this requirement from C.
>
> Is that so? Could you point me to the place in the C++ standard that
> says this?
>
> As far as I can see, [headers]/4 defines <cstdint> in terms of the C
> standard, and it requires intN_t be two's complement integers.
> [cstdint.syn]/2 reinforces that:
>
> The header defines all types and macros the same as the C standard
> library header <stdint.h>.
>
>
>
It looks like you're right. I must have misread it before when I was
looking this up.
Melissa
--
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/3c3decc2-28fb-465d-8da2-a6b0a70cf08a%40isocpp.org.
------=_Part_3547_1638101304.1475873804972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 1:45:00 PM UTC-7, Andrey Sem=
ashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/07/16 22:56,=
Myriachan wrote:
<br>> =C2=A0 =C2=A0 Fairly certain it's been that way since stdint w=
as introduced and
<br>> =C2=A0 =C2=A0 the requirements are fully inherited by cstdint
<br>>
<br>> No; C++ does not inherit this requirement from C.
<br>
<br>Is that so? Could you point me to the place in the C++ standard that=20
<br>says this?
<br>
<br>As far as I can see, [headers]/4 defines <cstdint> in terms of th=
e C=20
<br>standard, and it requires intN_t be two's complement integers.=20
<br>[cstdint.syn]/2 reinforces that:
<br>
<br>=C2=A0 =C2=A0The header defines all types and macros the same as the C =
standard
<br>=C2=A0 =C2=A0library header <stdint.h>.
<br>
<br>
<br></blockquote><div><br>It looks like you're right.=C2=A0 I must have=
misread it before when I was looking this up.<br><br>Melissa <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/3c3decc2-28fb-465d-8da2-a6b0a70cf08a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c3decc2-28fb-465d-8da2-a6b0a70cf08a=
%40isocpp.org</a>.<br />
------=_Part_3547_1638101304.1475873804972--
------=_Part_3546_1885709065.1475873804972--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Fri, 7 Oct 2016 17:38:01 -0700 (PDT)
Raw View
------=_Part_967_1742606934.1475887081737
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, 6 October 2016 20:25:40 UTC-5, Matthew Fioravante wrote:
> So there is this long standing question of integer representations. C++ t=
ries to support as many theoretical hardware platforms as possible but some=
times hardware converges to one solution which is adopted for all practical=
purposes universally.
>=20
>=20
> This seems to be the case with the fact that as far as I know every moder=
n architecture represents signed integers using 2's complement and has been=
doing so for decades.=C2=A0
> The practical consequence is the fact that the result of right shifting a=
signed integer is implementation defined.
>=20
>=20
>=20
>=20
> int x =3D -937;
> x >> 6; //Implementation defined result
>=20
> Technically this means you cannot portably right shift a signed integer i=
n C++ and to add insult to injury the standard library doesn't provide any =
alternative inline function to do a portable right arithmetic shift. Some p=
eople have been saying we should drop support for other integer representat=
ions and base the C++ standard on 2's complement. I'd be onboard with that =
but there is also a compromise that effectively gives everyone what they wa=
nt.
>=20
>=20
> Instead of removing theoretical support for other integer representations=
for the standard, I think as first step we should just define such operati=
ons on all 2's complement platforms that implement C++.
>=20
>=20
> In other words, the rule should be:
>=20
>=20
> "If your platform represents signed integers using 2's complement, then o=
perator>>(signed integral, int) is defined to perform a right arithmetic sh=
ift. If your platform does not use 2's complement, the result of operator>>=
(signed integral, int) is implementation defined"
>=20
How is this preferable to adding a library function for 2's complement styl=
e right arithmetic shift?=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/e713b6c1-9071-4a33-8317-f78753a04269%40isocpp.or=
g.
------=_Part_967_1742606934.1475887081737--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 7 Oct 2016 17:43:56 -0700 (PDT)
Raw View
------=_Part_2469_477644697.1475887436408
Content-Type: multipart/alternative;
boundary="----=_Part_2470_2128946581.1475887436408"
------=_Part_2470_2128946581.1475887436408
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 8:38:02 PM UTC-4, Edward Catmur wrote:
>
> On Thursday, 6 October 2016 20:25:40 UTC-5, Matthew Fioravante wrote:
> > So there is this long standing question of integer representations. C++
> tries to support as many theoretical hardware platforms as possible but
> sometimes hardware converges to one solution which is adopted for all
> practical purposes universally.
> >
> >
> > This seems to be the case with the fact that as far as I know every
> modern architecture represents signed integers using 2's complement and has
> been doing so for decades.
> > The practical consequence is the fact that the result of right shifting
> a signed integer is implementation defined.
> >
> >
> >
> >
> > int x = -937;
> > x >> 6; //Implementation defined result
> >
> > Technically this means you cannot portably right shift a signed integer
> in C++ and to add insult to injury the standard library doesn't provide any
> alternative inline function to do a portable right arithmetic shift. Some
> people have been saying we should drop support for other integer
> representations and base the C++ standard on 2's complement. I'd be onboard
> with that but there is also a compromise that effectively gives everyone
> what they want.
> >
> >
> > Instead of removing theoretical support for other integer
> representations for the standard, I think as first step we should just
> define such operations on all 2's complement platforms that implement C++.
> >
> >
> > In other words, the rule should be:
> >
> >
> > "If your platform represents signed integers using 2's complement, then
> operator>>(signed integral, int) is defined to perform a right arithmetic
> shift. If your platform does not use 2's complement, the result of
> operator>>(signed integral, int) is implementation defined"
> >
>
> How is this preferable to adding a library function for 2's complement
> style right arithmetic shift
Why not have both? Give us a way to detect if an integer type uses 2's
complement, make >> do an arithmetic right shift if that's true, *and* give
us a completely platform-independent way of shifting an unsigned integer
type arithmetically.
--
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/88a3be6d-59d9-42aa-853e-bf8995c543e7%40isocpp.org.
------=_Part_2470_2128946581.1475887436408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 7, 2016 at 8:38:02 PM UTC-4, Ed=
ward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday,=
6 October 2016 20:25:40 UTC-5, Matthew Fioravante =C2=A0wrote:
<br>> So there is this long standing question of integer representations=
.. C++ tries to support as many theoretical hardware platforms as possible b=
ut sometimes hardware converges to one solution which is adopted for all pr=
actical purposes universally.
<br>>=20
<br>>=20
<br>> This seems to be the case with the fact that as far as I know ever=
y modern architecture represents signed integers using 2's complement a=
nd has been doing so for decades.=C2=A0
<br>> The practical consequence is the fact that the result of right shi=
fting a signed integer is implementation defined.
<br>>=20
<br>>=20
<br>>=20
<br>>=20
<br>> int x =3D -937;
<br>> x >> 6; //Implementation defined result
<br>>=20
<br>> Technically this means you cannot portably right shift a signed in=
teger in C++ and to add insult to injury the standard library doesn't p=
rovide any alternative inline function to do a portable right arithmetic sh=
ift. Some people have been saying we should drop support for other integer =
representations and base the C++ standard on 2's complement. I'd be=
onboard with that but there is also a compromise that effectively gives ev=
eryone what they want.
<br>>=20
<br>>=20
<br>> Instead of removing theoretical support for other integer represen=
tations for the standard, I think as first step we should just define such =
operations on all 2's complement platforms that implement C++.
<br>>=20
<br>>=20
<br>> In other words, the rule should be:
<br>>=20
<br>>=20
<br>> "If your platform represents signed integers using 2's co=
mplement, then operator>>(signed integral, int) is defined to perform=
a right arithmetic shift. If your platform does not use 2's complement=
, the result of operator>>(signed integral, int) is implementation de=
fined"
<br>>=20
<br>
<br>How is this preferable to adding a library function for 2's complem=
ent style right arithmetic shift</blockquote><div><br>Why not have both? Gi=
ve us a way to detect if an integer type uses 2's complement, make >=
> do an arithmetic right shift if that's true, <i>and</i> give us a =
completely platform-independent way of shifting an unsigned integer type ar=
ithmetically.<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/88a3be6d-59d9-42aa-853e-bf8995c543e7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/88a3be6d-59d9-42aa-853e-bf8995c543e7=
%40isocpp.org</a>.<br />
------=_Part_2470_2128946581.1475887436408--
------=_Part_2469_477644697.1475887436408--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 7 Oct 2016 18:05:42 -0700 (PDT)
Raw View
------=_Part_975_651947374.1475888742173
Content-Type: multipart/alternative;
boundary="----=_Part_976_1968464270.1475888742173"
------=_Part_976_1968464270.1475888742173
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 3:56:09 PM UTC-4, Myriachan wrote:
>
> On Thursday, October 6, 2016 at 6:51:24 PM UTC-7, Nicol Bolas wrote:
>
>> Your proposal is based on the assumption that all platforms that use 2's
>> complement signed integers also have a fast arithmetic right-shift. Is that
>> actually true? Because if it's not, then you force them to do complicated
>> logic that will make `operator>>` significantly slower than it ought to be.
>>
>
> Imagine an x86-32 CPU without an "sar" instruction. If you wanted to
> arithmetically shift right "eax" by "cl" bits, you could do this:
>
> mov edx, eax
> add edx, edx
> sbb edx, edx
> shr eax, cl
> xor ecx, byte 31
> shl edx, cl
> add edx, edx
> or eax, edx
>
> Even without trying to optimize that more, 8 instructions isn't too bad.
> It's even better in MIPS:
>
> srl t0, a0, 31
> subu t0, zero, t0
> srlv a0, a0, s0
> subu t1, zero, s0
> sllv t0, t0, t1
> or a0, a0, t0
>
> In my opinion, the cost of being a weird architecture should be borne by
> the weird architecture, not everyone else.
>
That rather depends on what the "weird architecture" is and how many users
it has.
When it comes to turning a single opcode into a sequence of 8, that's
something that we should only do with actual, hard evidence that the number
of people affected will be zero or close to zero. Remember: we're talking
about effectively making it *impossible* for them to have a fast
right-shift in cases where it would have been well-defined C++ behavior.
That is not something we should do based on a hunch. We need hard evidence.
We need to take a survey of every platform and find out exactly how much
damage such a rule will do.
We shouldn't impose the tyranny of the majority upon users who already have
to deal with crappy platforms.
--
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/f1235731-df1a-46d7-acb6-e19f9d4e861e%40isocpp.org.
------=_Part_976_1968464270.1475888742173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 7, 2016 at 3:56:09 PM UTC-4, My=
riachan 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"ltr"=
>On Thursday, October 6, 2016 at 6:51:24 PM UTC-7, Nicol Bolas wrote:<br><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Your
proposal is based on the assumption that all platforms that use 2's=20
complement signed integers also have a fast arithmetic right-shift. Is=20
that actually true? Because if it's not, then you force them to do=20
complicated logic that will make `operator>>` significantly slower
than it ought to be.<br></blockquote><br>Imagine an x86-32 CPU without an =
"sar" instruction.=C2=A0 If you wanted to arithmetically shift ri=
ght "eax" by "cl" bits, you could do this:<br><br>mov e=
dx, eax<br>add edx, edx<br>sbb edx, edx<br>shr eax, cl<br>xor ecx, byte 31<=
br>shl edx, cl<br>add edx, edx<br>or eax, edx<br><br>Even without trying to=
optimize that more, 8 instructions isn't too bad.=C2=A0 It's even =
better in MIPS:<br><br>srl t0, a0, 31<br>subu t0, zero, t0<br>srlv a0, a0, =
s0<br>subu t1, zero, s0<br>sllv t0, t0, t1<br>or a0, a0, t0<br><br>In my op=
inion, the cost of being a weird architecture should be borne by the weird =
architecture, not everyone else.<br></div></div></blockquote><br>That rathe=
r depends on what the "weird architecture" is and how many users =
it has.<br><br>When it comes to turning a single opcode into a sequence of =
8, that's something that we should only do with actual, hard evidence t=
hat the number of people affected will be zero or close to zero. Remember: =
we're talking about effectively making it <i>impossible</i> for them to=
have a fast right-shift in cases where it would have been well-defined C++=
behavior.<br><br>That is not something we should do based on a hunch. We n=
eed hard evidence. We need to take a survey of every platform and find out =
exactly how much damage such a rule will do.<br><br>We shouldn't impose=
the tyranny of the majority upon users who already have to deal with crapp=
y platforms.<br></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/f1235731-df1a-46d7-acb6-e19f9d4e861e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1235731-df1a-46d7-acb6-e19f9d4e861e=
%40isocpp.org</a>.<br />
------=_Part_976_1968464270.1475888742173--
------=_Part_975_651947374.1475888742173--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Fri, 7 Oct 2016 21:23:23 -0700 (PDT)
Raw View
------=_Part_5_284601782.1475900604058
Content-Type: multipart/alternative;
boundary="----=_Part_6_370185409.1475900604058"
------=_Part_6_370185409.1475900604058
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 8:05:42 PM UTC-5, Nicol Bolas wrote:
>
>
> That rather depends on what the "weird architecture" is and how many users
> it has.
>
> When it comes to turning a single opcode into a sequence of 8, that's
> something that we should only do with actual, hard evidence that the number
> of people affected will be zero or close to zero. Remember: we're talking
> about effectively making it *impossible* for them to have a fast
> right-shift in cases where it would have been well-defined C++ behavior.
>
Lets think about this for a minute though. What actually is the value of
fast right shift with non-portable behavior with respect to the high bits?
How many scenarios are there where you want to shift some bits and your
algorithm will work regardless of what happens to the high bits?
I'd argue a consistent and portable right shift is far more useful. We
write C++ so that it will be standard across platforms and simple
operations like bit shifts have obvious semantics without all these kinds
of technical expert level pitfalls. If there is a one off, esoteric
platform that has a faster different kind of right shift I don't think its
too much to expect the implementation provider to provide an intrinsic for
their users. Also having std::shl(), std::shr(), and std::sar() available
can help here.
Finally, bit shifting is the most fundamental of operations to implement in
hardware. Its been one of the fastest instructions on virtually all
machines for years. Any platform with such a limitation would have to be
some weird legacy platform. I can't imagine something in the future having
this problem.
> That is not something we should do based on a hunch. We need hard
> evidence. We need to take a survey of every platform and find out exactly
> how much damage such a rule will do.
>
> We shouldn't impose the tyranny of the majority upon users who already
> have to deal with crappy platforms.
>
--
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/717eb554-c73a-4eb8-9aa7-298fe8ba024b%40isocpp.org.
------=_Part_6_370185409.1475900604058
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 7, 2016 at 8:05:42 PM UTC-5, Ni=
col Bolas 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"lt=
r"><br>That rather depends on what the "weird architecture" is an=
d how many users it has.<br><br>When it comes to turning a single opcode in=
to a sequence of 8, that's something that we should only do with actual=
, hard evidence that the number of people affected will be zero or close to=
zero. Remember: we're talking about effectively making it <i>impossibl=
e</i> for them to have a fast right-shift in cases where it would have been=
well-defined C++ behavior.<br></div></blockquote><div><br></div><div>Lets =
think about this for a minute though. What actually is the value of fast ri=
ght shift with non-portable behavior with respect to the high bits? How man=
y scenarios are there where you want to shift some bits and your algorithm =
will work regardless of what happens to the high bits?</div><div><br></div>=
<div>I'd argue a consistent and portable right shift is far more useful=
.. We write C++ so that it will be standard across platforms and simple oper=
ations like bit shifts have obvious semantics without all these kinds of te=
chnical expert level pitfalls. If there is a one off, esoteric platform tha=
t has a faster different kind of right shift I don't think its too much=
to expect the implementation provider to provide an intrinsic for their us=
ers. Also having std::shl(), std::shr(), and std::sar() available can help =
here.</div><div><br></div><div>Finally, bit shifting is the most fundamenta=
l of operations to implement in hardware. Its been one of the fastest instr=
uctions on virtually all machines for years. Any platform with such a limit=
ation would have to be some weird legacy platform. I can't imagine some=
thing in the future having this problem.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">That is not something we =
should do based on a hunch. We need hard evidence. We need to take a survey=
of every platform and find out exactly how much damage such a rule will do=
..<br><br>We shouldn't impose the tyranny of the majority upon users who=
already have to deal with crappy platforms.<br></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/717eb554-c73a-4eb8-9aa7-298fe8ba024b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/717eb554-c73a-4eb8-9aa7-298fe8ba024b=
%40isocpp.org</a>.<br />
------=_Part_6_370185409.1475900604058--
------=_Part_5_284601782.1475900604058--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 7 Oct 2016 22:16:07 -0700 (PDT)
Raw View
------=_Part_11_980127348.1475903768001
Content-Type: multipart/alternative;
boundary="----=_Part_12_1260954785.1475903768001"
------=_Part_12_1260954785.1475903768001
Content-Type: text/plain; charset=UTF-8
On Saturday, October 8, 2016 at 12:23:24 AM UTC-4, Matthew Fioravante wrote:
>
> On Friday, October 7, 2016 at 8:05:42 PM UTC-5, Nicol Bolas wrote:
>>
>>
>> That rather depends on what the "weird architecture" is and how many
>> users it has.
>>
>> When it comes to turning a single opcode into a sequence of 8, that's
>> something that we should only do with actual, hard evidence that the number
>> of people affected will be zero or close to zero. Remember: we're talking
>> about effectively making it *impossible* for them to have a fast
>> right-shift in cases where it would have been well-defined C++ behavior.
>>
>
> Lets think about this for a minute though. What actually is the value of
> fast right shift with non-portable behavior with respect to the high bits?
> How many scenarios are there where you want to shift some bits and your
> algorithm will work regardless of what happens to the high bits?
>
Anytime you're dealing with a number you know is positive; the standard
specifies exactly what should happen, so such code is entirely portable.
All of the opcodes that go into making it an arithmetic shift are
irrelevant; the non-arithmetic one would be appropriate.
A better question is this: how often do you perform right shifts on signed
quantities that can have negative values?
I'd argue a consistent and portable right shift is far more useful.
>
But that's not even what is being proposed here. The proposed solution only
applies if the implementation uses 2's complement. And 2's complement
integers are not required by C++. So such behavior would only be portable
among 2's complement systems.
And indeed, the proposal as stated doesn't even propose a way to test if an
integer type is 2's complement.
We write C++ so that it will be standard across platforms and simple
> operations like bit shifts have obvious semantics without all these kinds
> of technical expert level pitfalls. If there is a one off, esoteric
> platform that has a faster different kind of right shift I don't think its
> too much to expect the implementation provider to provide an intrinsic for
> their users. Also having std::shl(), std::shr(), and std::sar() available
> can help here.
>
So you propose to potentially slow people's code down, then tell them they
can get the performance they would have had otherwise by calling a standard
library function?
Finally, bit shifting is the most fundamental of operations to implement in
> hardware. Its been one of the fastest instructions on virtually all
> machines for years. Any platform with such a limitation would have to be
> some weird legacy platform. I can't imagine something in the future having
> this problem.
>
Imagination is nice, but imagination is not *facts*. And we shouldn't move
forward with something like this without facts in hand.
At the very least, we should know about x86, ARM, IBM, and maybe one or two
other chips in relatively wide usage.
--
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/5c2d2a52-ee2b-4d1c-9751-5dfc54142a91%40isocpp.org.
------=_Part_12_1260954785.1475903768001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, October 8, 2016 at 12:23:24 AM UTC-4, Matthew=
Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Friday, October 7, 2016 at 8:05:42 PM UTC-5, Nicol Bolas wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>That rather depend=
s on what the "weird architecture" is and how many users it has.<=
br><br>When it comes to turning a single opcode into a sequence of 8, that&=
#39;s something that we should only do with actual, hard evidence that the =
number of people affected will be zero or close to zero. Remember: we'r=
e talking about effectively making it <i>impossible</i> for them to have a =
fast right-shift in cases where it would have been well-defined C++ behavio=
r.<br></div></blockquote><div><br></div><div>Lets think about this for a mi=
nute though. What actually is the value of fast right shift with non-portab=
le behavior with respect to the high bits? How many scenarios are there whe=
re you want to shift some bits and your algorithm will work regardless of w=
hat happens to the high bits?</div></div></blockquote><div><br>Anytime you&=
#39;re dealing with a number you know is positive; the standard specifies e=
xactly what should happen, so such code is entirely portable. All of the op=
codes that go into making it an arithmetic shift are irrelevant; the non-ar=
ithmetic one would be appropriate.<br><br>A better question is this: how of=
ten do you perform right shifts on signed quantities that can have negative=
values?<br><br></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>I'd argue a consistent and portable right shif=
t is far more useful.</div></div></blockquote><div><br>But that's not e=
ven what is being proposed here. The proposed solution only applies if the =
implementation uses 2's complement. And 2's complement integers are=
not required by C++. So such behavior would only be portable among 2's=
complement systems.<br><br>And indeed, the proposal as stated doesn't =
even propose a way to test if an integer type is 2's complement.<br><br=
></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>W=
e write C++ so that it will be standard across platforms and simple operati=
ons like bit shifts have obvious semantics without all these kinds of techn=
ical expert level pitfalls. If there is a one off, esoteric platform that h=
as a faster different kind of right shift I don't think its too much to=
expect the implementation provider to provide an intrinsic for their users=
.. Also having std::shl(), std::shr(), and std::sar() available can help her=
e.</div></div></blockquote><div><br>So you propose to potentially slow peop=
le's code down, then tell them they can get the performance they would =
have had otherwise by calling a standard library function?<br><br></div><bl=
ockquote 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>Finally, bi=
t shifting is the most fundamental of operations to implement in hardware. =
Its been one of the fastest instructions on virtually all machines for year=
s. Any platform with such a limitation would have to be some weird legacy p=
latform. I can't imagine something in the future having this problem.</=
div></div></blockquote><div><br>Imagination is nice, but imagination is not=
<i>facts</i>. And we shouldn't move forward with something like this w=
ithout facts in hand.<br><br>At the very least, we should know about x86, A=
RM, IBM, and maybe one or two other chips in relatively wide usage.</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/5c2d2a52-ee2b-4d1c-9751-5dfc54142a91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c2d2a52-ee2b-4d1c-9751-5dfc54142a91=
%40isocpp.org</a>.<br />
------=_Part_12_1260954785.1475903768001--
------=_Part_11_980127348.1475903768001--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 09 Oct 2016 10:20:09 +0200
Raw View
Em sexta-feira, 7 de outubro de 2016, =C3=A0s 21:23:23 CEST, Matthew Fiorav=
ante=20
escreveu:
> Finally, bit shifting is the most fundamental of operations to implement =
in
> hardware. Its been one of the fastest instructions on virtually all
> machines for years. Any platform with such a limitation would have to be
> some weird legacy platform. I can't imagine something in the future havin=
g
> this problem.
Actually, a barrel-shifter is a very expensive instruction in terms of=20
transistor counts. You basically need one path per bit that exists in your=
=20
source register.
A non-barrel shifter will instead take N clocks to run, where N is the numb=
er=20
of shifts you're doing.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/5489573.zCq4MnoAjl%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sun, 9 Oct 2016 14:02:09 +0300
Raw View
On 10/09/16 11:20, Thiago Macieira wrote:
> Em sexta-feira, 7 de outubro de 2016, =C3=A0s 21:23:23 CEST, Matthew Fior=
avante
> escreveu:
>> Finally, bit shifting is the most fundamental of operations to implement=
in
>> hardware. Its been one of the fastest instructions on virtually all
>> machines for years. Any platform with such a limitation would have to be
>> some weird legacy platform. I can't imagine something in the future havi=
ng
>> this problem.
>
> Actually, a barrel-shifter is a very expensive instruction in terms of
> transistor counts. You basically need one path per bit that exists in you=
r
> source register.
>
> A non-barrel shifter will instead take N clocks to run, where N is the nu=
mber
> of shifts you're doing.
That doesn't make arithmetic shift any more expensive than a logical=20
shift though. And despite the complexity all modern architectures=20
provide shift instructions because the operation is widely used in software=
..
--=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/15b06f28-1c5c-d5f8-ebe6-26f907f25844%40gmail.com=
..
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 10 Oct 2016 12:49:57 -0700 (PDT)
Raw View
------=_Part_2811_1865318419.1476128997193
Content-Type: multipart/alternative;
boundary="----=_Part_2812_1909532443.1476128997193"
------=_Part_2812_1909532443.1476128997193
Content-Type: text/plain; charset=UTF-8
On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bolas wrote:
>
>
> And indeed, the proposal as stated doesn't even propose a way to test if
> an integer type is 2's complement.
>
>
There already is one:
template <typename T>
struct is_twos_complement
: std::integral_constant<bool, (std::numeric_limits<T>::min() <
-std::numeric_limits<T>::max())>
{
};
From the restrictions in the Standard, the only permissible representation
that meets the above is two's complement.
Melissa
--
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/454eee59-969c-4bd7-a7d6-05f3583934bd%40isocpp.org.
------=_Part_2812_1909532443.1476128997193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bol=
as 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"ltr"><br>=
<div>And indeed, the proposal as stated doesn't even propose a way to t=
est if an integer type is 2's complement.</div><br></div></blockquote><=
div><br>There already is one:<br><br>template <typename T><br>struct =
is_twos_complement<br>: std::integral_constant<bool, (std::numeric_limit=
s<T>::min() < -std::numeric_limits<T>::max())><br>{<br>};=
<br><br>From the restrictions in the Standard, the only permissible represe=
ntation that meets the above is two's complement.<br><br>Melissa<br></d=
iv></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/454eee59-969c-4bd7-a7d6-05f3583934bd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/454eee59-969c-4bd7-a7d6-05f3583934bd=
%40isocpp.org</a>.<br />
------=_Part_2812_1909532443.1476128997193--
------=_Part_2811_1865318419.1476128997193--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 10 Oct 2016 13:38:02 -0700
Raw View
--001a113ee190917391053e88bc15
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 10, 2016 at 12:49 PM, Myriachan <myriachan@gmail.com> wrote:
> On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bolas wrote:
>>
>>
>> And indeed, the proposal as stated doesn't even propose a way to test if
>> an integer type is 2's complement.
>>
>>
> There already is one:
>
> template <typename T>
> struct is_twos_complement
> : std::integral_constant<bool, (std::numeric_limits<T>::min() <
> -std::numeric_limits<T>::max())>
> {
> };
>
> From the restrictions in the Standard, the only permissible representation
> that meets the above is two's complement.
>
Unlike C, C++ does not require signed types to be one of 2s' complement,
1's complement, or sign-magnitude. It only requires a "pure binary
representation", and several people have argued that base -2 qualifies.
(Whether the above test produces true or false for base -2 depends on
whether the bitwidth of T is even or odd.)
--
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/CAOfiQqmQbpw19g6yXDWEV_GHBDTcx1hUotsZyjQzFzAMXpQMAw%40mail.gmail.com.
--001a113ee190917391053e88bc15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 10, 2016 at 12:49 PM, Myriachan <span dir=3D"ltr"><<a href=3D"ma=
ilto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bolas wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>And indeed,=
the proposal as stated doesn't even propose a way to test if an intege=
r type is 2's complement.</div><br></div></blockquote></span><div><br>T=
here already is one:<br><br>template <typename T><br>struct is_twos_c=
omplement<br>: std::integral_constant<bool, (std::numeric_limits<T>=
;::min() < -std::numeric_limits<T>::max()<wbr>)><br>{<br>};<br>=
<br>From the restrictions in the Standard, the only permissible representat=
ion that meets the above is two's complement.</div></div></blockquote><=
div><br></div><div>Unlike C, C++ does not require signed types to be one of=
2s' complement, 1's complement, or sign-magnitude. It only require=
s a "pure binary representation", and several people have argued =
that base -2 qualifies. (Whether the above test produces true or false for =
base -2 depends on whether the bitwidth of T is even or odd.)</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/CAOfiQqmQbpw19g6yXDWEV_GHBDTcx1hUotsZ=
yjQzFzAMXpQMAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmQbpw19g6y=
XDWEV_GHBDTcx1hUotsZyjQzFzAMXpQMAw%40mail.gmail.com</a>.<br />
--001a113ee190917391053e88bc15--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 10 Oct 2016 14:27:11 -0700
Raw View
--001a1143df7457759c053e896c9c
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 10, 2016 at 1:38 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On Mon, Oct 10, 2016 at 12:49 PM, Myriachan <myriachan@gmail.com> wrote:
>
>> On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bolas wrote:
>>>
>>>
>>> And indeed, the proposal as stated doesn't even propose a way to test if
>>> an integer type is 2's complement.
>>>
>>>
>> There already is one:
>>
>> template <typename T>
>> struct is_twos_complement
>> : std::integral_constant<bool, (std::numeric_limits<T>::min() <
>> -std::numeric_limits<T>::max())>
>> {
>> };
>>
>> From the restrictions in the Standard, the only permissible
>> representation that meets the above is two's complement.
>>
>
> Unlike C, C++ does not require signed types to be one of 2s' complement,
> 1's complement, or sign-magnitude. It only requires a "pure binary
> representation", and several people have argued that base -2 qualifies.
> (Whether the above test produces true or false for base -2 depends on
> whether the bitwidth of T is even or odd.
>
For a possibly more practical example than base -2, I *think* it's also
perfectly valid for an implementation of a signed (non-char) integer to
have trap representations, correct? For instance, one implementation could
effectively be 2s complement, but with a trap representation for what would
normally be the lowest negative value, leaving the possible positive and
negative values symmetric. An integer implementation such as this has a few
advantages (trap rep, no precondition on negation, spare value for
datastructures such as an implementation-specific optional).
--
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/CANh8DE%3DiLe8fCmF-ofCpq--i3dnv5aAJ6FFN2X8whFnx4yZofw%40mail.gmail.com.
--001a1143df7457759c053e896c9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 10, 2016 at 1:38 PM, Richard Smith <span dir=3D"ltr"><<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span cl=
ass=3D"gmail-">On Mon, Oct 10, 2016 at 12:49 PM, Myriachan <span dir=3D"ltr=
"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><span>On Friday, October 7, 2016 at 10:16:08 PM UT=
C-7, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><br><div>And indeed, the proposal as stated doesn't even=
propose a way to test if an integer type is 2's complement.</div><br><=
/div></blockquote></span><div><br>There already is one:<br><br>template <=
;typename T><br>struct is_twos_complement<br>: std::integral_constant<=
;bool, (std::numeric_limits<T>::min() < -std::numeric_limits<T&=
gt;::max()<wbr>)><br>{<br>};<br><br>From the restrictions in the Standar=
d, the only permissible representation that meets the above is two's co=
mplement.</div></div></blockquote><div><br></div></span><div>Unlike C, C++ =
does not require signed types to be one of 2s' complement, 1's comp=
lement, or sign-magnitude. It only requires a "pure binary representat=
ion", and several people have argued that base -2 qualifies. (Whether =
the above test produces true or false for base -2 depends on whether the bi=
twidth of T is even or odd.</div></div></div></div></blockquote><div><br></=
div><div>For a possibly more practical example than base -2, I *think* it&#=
39;s also perfectly valid for an implementation of a signed (non-char)=C2=
=A0integer to have trap representations, correct? For instance, one impleme=
ntation could effectively be 2s complement, but with a trap representation =
for what would normally be the lowest negative value, leaving the possible =
positive and negative values symmetric. An integer implementation such as t=
his has a few advantages (trap rep, no precondition on negation, spare valu=
e for datastructures such as an implementation-specific optional).</div></d=
iv></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/CANh8DE%3DiLe8fCmF-ofCpq--i3dnv5aAJ6F=
FN2X8whFnx4yZofw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DiLe8f=
CmF-ofCpq--i3dnv5aAJ6FFN2X8whFnx4yZofw%40mail.gmail.com</a>.<br />
--001a1143df7457759c053e896c9c--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 11 Oct 2016 02:02:31 +0300
Raw View
On 10/11/16 00:27, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
> On Mon, Oct 10, 2016 at 1:38 PM, Richard Smith <richard@metafoo.co.uk
> <mailto:richard@metafoo.co.uk>> wrote:
>
> On Mon, Oct 10, 2016 at 12:49 PM, Myriachan <myriachan@gmail.com
> <mailto:myriachan@gmail.com>> wrote:
>
> On Friday, October 7, 2016 at 10:16:08 PM UTC-7, Nicol Bolas wrote:
>
>
> And indeed, the proposal as stated doesn't even propose a
> way to test if an integer type is 2's complement.
>
>
> There already is one:
>
> template <typename T>
> struct is_twos_complement
> : std::integral_constant<bool, (std::numeric_limits<T>::min() <
> -std::numeric_limits<T>::max())>
> {
> };
>
> From the restrictions in the Standard, the only permissible
> representation that meets the above is two's complement.
>
>
> Unlike C, C++ does not require signed types to be one of 2s'
> complement, 1's complement, or sign-magnitude. It only requires a
> "pure binary representation", and several people have argued that
> base -2 qualifies. (Whether the above test produces true or false
> for base -2 depends on whether the bitwidth of T is even or odd.
>
>
> For a possibly more practical example than base -2, I *think* it's also
> perfectly valid for an implementation of a signed (non-char) integer to
> have trap representations, correct? For instance, one implementation
> could effectively be 2s complement, but with a trap representation for
> what would normally be the lowest negative value, leaving the possible
> positive and negative values symmetric. An integer implementation such
> as this has a few advantages (trap rep, no precondition on negation,
> spare value for datastructures such as an implementation-specific optional).
Presumably, if the type trait is implemented by the compiler, it could
give the correct result regardless of the integer implementation. The
above can be considered as an example implementation on the currently
widespread architectures.
--
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/5209102f-2338-924a-7b15-c4a40094f122%40gmail.com.
.