------=_Part_4215_317481352.1428441058651
Content-Type: multipart/alternative;
 boundary="----=_Part_4216_1559703916.1428441058651"

------=_Part_4216_1559703916.1428441058651
Content-Type: text/plain; charset=UTF-8

I beleive binary shifting should be predefined functions included in a
standard header.
The << / >> operators for both logical and arithmetic shift depending on
signed/unsigned input is impractical, and makes it much harder for
compilers to optimize for certain assembly instruction sets.
Of course, << / >> will have to be supported for backwards compatibility.

But which way would be best?
Arithmetic or logical, circular or normal. Should these options be defined
as parts of function names, or as arguments to the functions?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4216_1559703916.1428441058651
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I beleive binary shifting should be predefined functions i=
ncluded in a standard header.<br>The &lt;&lt; / &gt;&gt; operators for both=
 logical and arithmetic shift depending on signed/unsigned input is impract=
ical, and makes it much harder for compilers to optimize for certain assemb=
ly instruction sets.<br>Of course, &lt;&lt; / &gt;&gt; will have to be supp=
orted for backwards compatibility.<br><br>But which way would be best?<br>A=
rithmetic or logical, circular or normal. Should these options be defined a=
s parts of function names, or as arguments to the functions?<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4216_1559703916.1428441058651--
------=_Part_4215_317481352.1428441058651--

.

On Tue, Apr 7, 2015 at 5:10 PM,  <tomatopippsalt@gmail.com> wrote:
> I beleive binary shifting should be predefined functions included in a
> standard header.
> The << / >> operators for both logical and arithmetic shift depending on
> signed/unsigned input is impractical, and makes it much harder for compilers
> to optimize for certain assembly instruction sets.
> Of course, << / >> will have to be supported for backwards compatibility.
>

Lawrence Crowl is working on a fixed-point number paper, which
planned to propose these utilities at the same time.  You can
contact him for details.

There was also a bitwise ops paper mentioning it:

    http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3864.html

Not sure whether the author plan to update the paper though.

And there is always a choice: sit down and write paper.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 07 April 2015 14:10:58 tomatopippsalt@gmail.com wrote:
> The << / >> operators for both logical and arithmetic shift depending on
> signed/unsigned input is impractical, and makes it much harder for
> compilers to optimize for certain assembly instruction sets.

What are you basing this statement on? Why do you think it's impractical? Why
is it harder for certain assembly instruction sets?

> Of course, << / >> will have to be supported for backwards compatibility.
>
> But which way would be best?
> Arithmetic or logical, circular or normal. Should these options be defined
> as parts of function names, or as arguments to the functions?

Separate functions. Very few people require rotation, but a lot of people
require shifting, so they shouldn't be required to select the common scenario
from the not-so-common.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_7263_1171833840.1428550629100
Content-Type: multipart/alternative;
 boundary="----=_Part_7264_438822243.1428550629100"

------=_Part_7264_438822243.1428550629100
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Macieira wrote:
>
> > Of course, << / >> will have to be supported for backwards
> compatibility.
> >
> > But which way would be best?
> > Arithmetic or logical, circular or normal. Should these options be
> defined
> > as parts of function names, or as arguments to the functions?
>
> Separate functions. Very few people require rotation, but a lot of people
> require shifting, so they shouldn't be required to select the common
> scenario
> from the not-so-common.
>
>
I for one would love a standard way of explicitly requesting signed right
shifts that copy the sign bit (i.e. formally defined as division by power
of 2 rounding toward negative infinity).  Similarly, signed left shifts
that don't snot out nasal demons if I shift out a set sign bit.  What to do
with overly-large shift values is an interesting question, though.  What
exactly signed left shift does on non-two's-complement systems is also more
complicated.

Bit rotation would be nice for avoiding #ifdef mazes for intrinsics.  I
agree that rotation is rare these days outside cryptography, so should
probably be a different name that doesn't have to be selected against.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_7264_438822243.1428550629100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Of course, &lt=
;&lt; / &gt;&gt; will have to be supported for backwards compatibility.
<br>&gt;=20
<br>&gt; But which way would be best?
<br>&gt; Arithmetic or logical, circular or normal. Should these options be=
 defined
<br>&gt; as parts of function names, or as arguments to the functions?
<br>
<br>Separate functions. Very few people require rotation, but a lot of peop=
le=20
<br>require shifting, so they shouldn't be required to select the common sc=
enario=20
<br>from the not-so-common.
<br>
<br></blockquote><div><br>I for one would love a standard way of explicitly=
 requesting signed right shifts that copy the sign bit (i.e. formally defin=
ed as division by power of 2 rounding toward negative infinity).&nbsp; Simi=
larly, signed left shifts that don't snot out nasal demons if I shift out a=
 set sign bit.&nbsp; What to do with overly-large shift values is an intere=
sting question, though.&nbsp; What exactly signed left shift does on non-tw=
o's-complement systems is also more complicated.<br><br>Bit rotation would =
be nice for avoiding #ifdef mazes for intrinsics.&nbsp; I agree that rotati=
on is rare these days outside cryptography, so should probably be a differe=
nt name that doesn't have to be selected against.<br><br>Melissa<br></div><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_7264_438822243.1428550629100--
------=_Part_7263_1171833840.1428550629100--

.

------=_Part_1259_1268908989.1428677226393
Content-Type: multipart/alternative;
 boundary="----=_Part_1260_2040763413.1428677226393"

------=_Part_1260_2040763413.1428677226393
Content-Type: text/plain; charset=UTF-8

http://stackoverflow.com/questions/776508/circular-shift-operations-in-c

There do some people need rotation instead of shifting. And currently the
'standard' solution, i.e. do not use asm, but just c / c++ language
features, needs two shiftings and one bitwise or, which should be
significant slower than one processor instruction rol / ror.

On Thursday, April 9, 2015 at 11:37:09 AM UTC+8, Myriachan wrote:
>
> On Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Macieira wrote:
>>
>> > Of course, << / >> will have to be supported for backwards
>> compatibility.
>> >
>> > But which way would be best?
>> > Arithmetic or logical, circular or normal. Should these options be
>> defined
>> > as parts of function names, or as arguments to the functions?
>>
>> Separate functions. Very few people require rotation, but a lot of people
>> require shifting, so they shouldn't be required to select the common
>> scenario
>> from the not-so-common.
>>
>>
> I for one would love a standard way of explicitly requesting signed right
> shifts that copy the sign bit (i.e. formally defined as division by power
> of 2 rounding toward negative infinity).  Similarly, signed left shifts
> that don't snot out nasal demons if I shift out a set sign bit.  What to do
> with overly-large shift values is an interesting question, though.  What
> exactly signed left shift does on non-two's-complement systems is also more
> complicated.
>
> Bit rotation would be nice for avoiding #ifdef mazes for intrinsics.  I
> agree that rotation is rare these days outside cryptography, so should
> probably be a different name that doesn't have to be selected against.
>
> 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1260_2040763413.1428677226393
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><a href=3D"http://stackoverflow.com/questions/776508/circu=
lar-shift-operations-in-c">http://stackoverflow.com/questions/776508/circul=
ar-shift-operations-in-c</a><div><br></div><div>There do some people need r=
otation instead of shifting. And currently the 'standard' solution, i.e. do=
 not use asm, but just c / c++ language features, needs two shiftings and o=
ne bitwise or, which should be significant slower than one processor instru=
ction rol / ror.<br><br>On Thursday, April 9, 2015 at 11:37:09 AM UTC+8, 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 Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Macieira wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">&gt; Of course, &lt;&lt; / &gt;&gt; will=
 have to be supported for backwards compatibility.
<br>&gt;=20
<br>&gt; But which way would be best?
<br>&gt; Arithmetic or logical, circular or normal. Should these options be=
 defined
<br>&gt; as parts of function names, or as arguments to the functions?
<br>
<br>Separate functions. Very few people require rotation, but a lot of peop=
le=20
<br>require shifting, so they shouldn't be required to select the common sc=
enario=20
<br>from the not-so-common.
<br>
<br></blockquote><div><br>I for one would love a standard way of explicitly=
 requesting signed right shifts that copy the sign bit (i.e. formally defin=
ed as division by power of 2 rounding toward negative infinity).&nbsp; Simi=
larly, signed left shifts that don't snot out nasal demons if I shift out a=
 set sign bit.&nbsp; What to do with overly-large shift values is an intere=
sting question, though.&nbsp; What exactly signed left shift does on non-tw=
o's-complement systems is also more complicated.<br><br>Bit rotation would =
be nice for avoiding #ifdef mazes for intrinsics.&nbsp; I agree that rotati=
on is rare these days outside cryptography, so should probably be a differe=
nt name that doesn't have to be selected against.<br><br>Melissa<br></div><=
/div></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1260_2040763413.1428677226393--
------=_Part_1259_1268908989.1428677226393--

.

--001a113ac5b6f046d70513600b0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FWIW
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3990.pdf
El 10/4/2015 11:47, "Zijie He" <hzj_jie@hotmail.com> escribi=C3=B3:

> http://stackoverflow.com/questions/776508/circular-shift-operations-in-c
>
> There do some people need rotation instead of shifting. And currently the
> 'standard' solution, i.e. do not use asm, but just c / c++ language
> features, needs two shiftings and one bitwise or, which should be
> significant slower than one processor instruction rol / ror.
>
> On Thursday, April 9, 2015 at 11:37:09 AM UTC+8, Myriachan wrote:
>>
>> On Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Macieira wrote:
>>>
>>> > Of course, << / >> will have to be supported for backwards
>>> compatibility.
>>> >
>>> > But which way would be best?
>>> > Arithmetic or logical, circular or normal. Should these options be
>>> defined
>>> > as parts of function names, or as arguments to the functions?
>>>
>>> Separate functions. Very few people require rotation, but a lot of
>>> people
>>> require shifting, so they shouldn't be required to select the common
>>> scenario
>>> from the not-so-common.
>>>
>>>
>> I for one would love a standard way of explicitly requesting signed righ=
t
>> shifts that copy the sign bit (i.e. formally defined as division by powe=
r
>> of 2 rounding toward negative infinity).  Similarly, signed left shifts
>> that don't snot out nasal demons if I shift out a set sign bit.  What to=
 do
>> with overly-large shift values is an interesting question, though.  What
>> exactly signed left shift does on non-two's-complement systems is also m=
ore
>> complicated.
>>
>> Bit rotation would be nice for avoiding #ifdef mazes for intrinsics.  I
>> agree that rotation is rare these days outside cryptography, so should
>> probably be a different name that doesn't have to be selected against.
>>
>> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113ac5b6f046d70513600b0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">FWIW<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3990.pd=
f">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3990.pdf</a></p=
>
<div class=3D"gmail_quote">El 10/4/2015 11:47, &quot;Zijie He&quot; &lt;<a =
href=3D"mailto:hzj_jie@hotmail.com">hzj_jie@hotmail.com</a>&gt; escribi=C3=
=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><a href=3D"http://stackoverflow.com/questions/776508/circular-shift-opera=
tions-in-c" target=3D"_blank">http://stackoverflow.com/questions/776508/cir=
cular-shift-operations-in-c</a><div><br></div><div>There do some people nee=
d rotation instead of shifting. And currently the &#39;standard&#39; soluti=
on, i.e. do not use asm, but just c / c++ language features, needs two shif=
tings and one bitwise or, which should be significant slower than one proce=
ssor instruction rol / ror.<br><br>On Thursday, April 9, 2015 at 11:37:09 A=
M UTC+8, Myriachan 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 Tuesday, April 7, 2015 at 5:54:14 PM UTC-7, Thiago Macieira wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">&gt; Of course, &lt;&lt; / &gt;&=
gt; will have to be supported for backwards compatibility.
<br>&gt;=20
<br>&gt; But which way would be best?
<br>&gt; Arithmetic or logical, circular or normal. Should these options be=
 defined
<br>&gt; as parts of function names, or as arguments to the functions?
<br>
<br>Separate functions. Very few people require rotation, but a lot of peop=
le=20
<br>require shifting, so they shouldn&#39;t be required to select the commo=
n scenario=20
<br>from the not-so-common.
<br>
<br></blockquote><div><br>I for one would love a standard way of explicitly=
 requesting signed right shifts that copy the sign bit (i.e. formally defin=
ed as division by power of 2 rounding toward negative infinity).=C2=A0 Simi=
larly, signed left shifts that don&#39;t snot out nasal demons if I shift o=
ut a set sign bit.=C2=A0 What to do with overly-large shift values is an in=
teresting question, though.=C2=A0 What exactly signed left shift does on no=
n-two&#39;s-complement systems is also more complicated.<br><br>Bit rotatio=
n would be nice for avoiding #ifdef mazes for intrinsics.=C2=A0 I agree tha=
t rotation is rare these days outside cryptography, so should probably be a=
 different name that doesn&#39;t have to be selected against.<br><br>Meliss=
a<br></div></div></blockquote></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ac5b6f046d70513600b0d--

.

--001a11c221b271a79f0513293301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7 April 2015 at 16:10, <tomatopippsalt@gmail.com> wrote:

> The << / >> operators for both logical and arithmetic shift depending on
> signed/unsigned input is impractical, and makes it much harder for
> compilers to optimize for certain assembly instruction sets.
>

I thought most of the edge cases lead to either undefined or unspecified
behavior, which should help, not hinder, optimization.

Looking at the rules from N4296
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf>
 [expr.shift]:

The operands shall be of integral or unscoped enumeration type and integral
promotions are performed. The type of the result is that of the promoted
left operand. The behavior is undefined if the right operand is negative,
or greater than or equal to the length in bits of the promoted left operand=
..


The value of E1 << E2  is E1  left-shifted E2  bit positions; vacated bits
are zero-filled. If E1  has an unsigned type, the value of the result is E1
=C3=85~ 2E2 , reduced modulo one more than the maximum value representable =
in
the result type. Otherwise, if E1  has a signed type and non-negative
value, and E1=C3=85~2E2  is representable in the corresponding unsigned typ=
e of
the result type, then that value, converted to the result type, is the
resulting value; otherwise, the behavior is undefined.


The value of E1 >> E2  is E1  right-shifted E2  bit positions. If E1  has
an unsigned type or if E1  has a signed type and a non-negative value, the
value of the result is the integral part of the quotient of E1/2E2 . If E1
has a signed type and a negative value, the resulting value is
implementation-defined.


Which of those specifically are hindering optimization?

Of course, << / >> will have to be supported for backwards compatibility.
>

> But which way would be best?
> Arithmetic or logical, circular or normal.
>

All three of course, as they have different use cases.  Well, instead of
"normal" I'd like to see "fast for code which avoids the edge cases", given
your claim that there is something in the current definition that is
getting in the way of optimization


> Should these options be defined as parts of function names, or as
> arguments to the functions?
>

Unless there is a good reason for wanting to specify this at run time, I'd
prefer it as part of the function name.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c221b271a79f0513293301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 7 April 2015 at 16:10,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tomatopippsalt@gmail.com" target=3D"_blank">tomatopippsalt@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr">The &lt;&lt; / &gt;&gt; operator=
s for both logical and arithmetic shift depending on signed/unsigned input =
is impractical, and makes it much harder for compilers to optimize for cert=
ain assembly instruction sets.<br></div></blockquote><div><br></div><div>I =
thought most of the edge cases lead to either undefined or unspecified beha=
vior, which should help, not hinder, optimization.</div><div><br></div><div=
>Looking at the rules from=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2014/n4296.pdf">N4296</a>=C2=A0[expr.shift]:</div><div><=
br></div><div><p style=3D"margin:0px;font-size:10px;font-family:Helvetica">=
The operands shall be of integral or unscoped enumeration type and integral=
 promotions are performed. The type of the result is that of the promoted l=
eft operand. The behavior is undefined if the right operand is negative, or=
 greater than or equal to the length in bits of the promoted left operand.<=
/p><p style=3D"margin:0px;font-size:10px;font-family:Helvetica"><br></p>
<p style=3D"margin:0px;font-size:10px;font-family:Helvetica">The value of E=
1 &lt;&lt; E2=C2=A0 is E1=C2=A0 left-shifted E2=C2=A0 bit positions; vacate=
d bits are zero-filled. If E1=C2=A0 has an unsigned type, the value of the =
result is E1 =C3=85~ 2<span style=3D"font-size:7px">E2</span> , reduced mod=
ulo one more than the maximum value representable in the result type. Other=
wise, if E1=C2=A0 has a signed type and non-negative value, and E1=C3=85~2<=
span style=3D"font-size:7px">E2=C2=A0</span> is representable in the corres=
ponding unsigned type of the result type, then that value, converted to the=
 result type, is the resulting value; otherwise, the behavior is undefined.=
</p><p style=3D"margin:0px;font-size:10px;font-family:Helvetica"><br></p>
<p style=3D"margin:0px;font-size:10px;font-family:Helvetica">The value of E=
1 &gt;&gt; E2=C2=A0 is E1=C2=A0 right-shifted E2=C2=A0 bit positions. If E1=
=C2=A0 has an unsigned type or if E1=C2=A0 has a signed type and a non-nega=
tive value, the value of the result is the integral part of the quotient of=
 E1/2<span style=3D"font-size:7px">E2</span> . If E1 has a signed type and =
a negative value, the resulting value is implementation-defined.</p></div><=
div><br></div><div><p style=3D"margin:0px;font-size:12px;font-family:Times"=
><br></p></div><div>Which of those specifically are hindering optimization?=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Of course, &lt;&lt; =
/ &gt;&gt; will have to be supported for backwards compatibility.=C2=A0</di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><br>But which way would be=
 best?<br>Arithmetic or logical, circular or normal. </div></blockquote><di=
v><br></div><div>All three of course, as they have different use cases.=C2=
=A0 Well, instead of &quot;normal&quot; I&#39;d like to see &quot;fast for =
code which avoids the edge cases&quot;, given your claim that there is some=
thing in the current definition that is getting in the way of optimization<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Should these option=
s be defined as parts of function names, or as arguments to the functions?<=
/div></blockquote><div><br></div><div>Unless there is a good reason for wan=
ting to specify this at run time, I&#39;d prefer it as part of the function=
 name.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:=
-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c221b271a79f0513293301--

.

------=_Part_289_945329343.1430434262502
Content-Type: multipart/alternative;
 boundary="----=_Part_290_1066247295.1430434262502"

------=_Part_290_1066247295.1430434262502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, April 13, 2015 at 9:57:36 AM UTC-7, Nevin ":-)" Liber wrote:
>
> On 7 April 2015 at 16:10, <tomatop...@gmail.com <javascript:>> wrote:
>
>> The << / >> operators for both logical and arithmetic shift depending on=
=20
>> signed/unsigned input is impractical, and makes it much harder for=20
>> compilers to optimize for certain assembly instruction sets.
>>
>
> I thought most of the edge cases lead to either undefined or unspecified=
=20
> behavior, which should help, not hinder, optimization.
>
> Looking at the rules from N4296=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf>
>  [expr.shift]:
>
> ...
>

> Which of those specifically are hindering optimization?
>
>
I agree with you that there doesn't seem to be anything hindering=20
optimization there.  However, I think that having these functions exist=20
would be nice on their own.  Very often, I want two's complement modular=20
behavior, and it is a hassle to get it.  Often, getting what is needed=20
requires suboptimal code, even when a single instruction on the target=20
platform would suffice.
=20

> Of course, << / >> will have to be supported for backwards compatibility.=
=20
>>
>
>> But which way would be best?
>> Arithmetic or logical, circular or normal.=20
>>
>
> All three of course, as they have different use cases.  Well, instead of=
=20
> "normal" I'd like to see "fast for code which avoids the edge cases", giv=
en=20
> your claim that there is something in the current definition that is=20
> getting in the way of optimization
>
>
What about functions for code that needs the edge cases to work?  In other=
=20
words, functions designed for these cases, when one needs them:

1. Arithmetic signed shift left, permitting shifting 1's off the left. =20
Essentially:
static_cast<decltype(value <<=20
shift)>(static_cast<std::make_unsigned_t<T>>(value) << shift)

2. Arithmetic signed shift right, defined as division by a power of 2 with=
=20
rounding toward -=E2=88=9E.

On two's-complement targets, compilers would just implement these as normal=
=20
shifts with undefined behavior optimizations inhibited.  Whether to define=
=20
what happens if shift is too large with these is an interesting question.

I'm not saying to make these the standard functions, just an available set=
=20
of them.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_290_1066247295.1430434262502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 13, 2015 at 9:57:36 AM UTC-7, Nevin ":-)"=
 Liber 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 7 April 2015 at 16:10,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"SuVU0g6P26sJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">tomatop...@gmail.com</a>&gt;</span> wrote:<br><=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">The &lt;&l=
t; / &gt;&gt; operators for both logical and arithmetic shift depending on =
signed/unsigned input is impractical, and makes it much harder for compiler=
s to optimize for certain assembly instruction sets.<br></div></blockquote>=
<div><br></div><div>I thought most of the edge cases lead to either undefin=
ed or unspecified behavior, which should help, not hinder, optimization.</d=
iv><div><br></div><div>Looking at the rules from&nbsp;<a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2=
Fn4296.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFazwzyFeVWoj09LM4Du4HHmr0jyw'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4296=
..pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFazwzyFeVWoj09LM4Du4HHmr0jyw';retur=
n true;">N4296</a>&nbsp;[expr.shift]:</div><div><br></div>...</div></div></=
div></blockquote><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><div class=3D"gmail_quote"><div></div><div><p style=3D"margin:0px;=
font-size:12px;font-family:Times"><br></p></div><div>Which of those specifi=
cally are hindering optimization?</div><div><br></div></div></div></div></b=
lockquote><div><br>I agree with you that there doesn't seem to be anything =
hindering optimization there.&nbsp; However, I think that having these func=
tions exist would be nice on their own.&nbsp; Very often, I want two's comp=
lement modular behavior, and it is a hassle to get it.&nbsp; Often, getting=
 what is needed requires suboptimal code, even when a single instruction on=
 the target platform would suffice.<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr">Of course, &lt;&lt; / &gt;&gt; will=
 have to be supported for backwards compatibility.&nbsp;</div></blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br>But which way would be best?<br>Arith=
metic or logical, circular or normal. </div></blockquote><div><br></div><di=
v>All three of course, as they have different use cases.&nbsp; Well, instea=
d of "normal" I'd like to see "fast for code which avoids the edge cases", =
given your claim that there is something in the current definition that is =
getting in the way of optimization</div><div><br></div></div></div></div></=
blockquote><div><br>What about functions for code that needs the edge cases=
 to work?&nbsp; In other words, functions designed for these cases, when on=
e needs them:<br><br>1. Arithmetic signed shift left, permitting shifting 1=
's off the left.&nbsp; Essentially:<br>static_cast&lt;decltype(value &lt;&l=
t; shift)&gt;(static_cast&lt;std::make_unsigned_t&lt;T&gt;&gt;(value) &lt;&=
lt; shift)<br><br>2. Arithmetic signed shift right, defined as division by =
a power of 2 with rounding toward -=E2=88=9E.<br><br>On two's-complement ta=
rgets, compilers would just implement these as normal shifts with undefined=
 behavior optimizations inhibited.&nbsp; Whether to define what happens if =
shift is too large with these is an interesting question.<br><br>I'm not sa=
ying to make these the standard functions, just an available set of them.</=
div><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_290_1066247295.1430434262502--
------=_Part_289_945329343.1430434262502--

.