dsimcha wrote:
> == Quote from KennyTM~ (kennytm@gmail.com)'s article
>> No, it will _silently_ break code that uses >>> as unsigned right shift.
> 
> Well, we could get around this by making >>> an error for a few releases, and then
> only after everyone's removed their >>>s that mean unsigned shift, we could drop
> in the rotate semantics.

It'll still silently break code moving from D1 to D2.

KennyTM~ wrote:
> On Dec 7, 09 03:41, Don wrote:
>> dsimcha wrote:
>>> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>>>> Andrei Alexandrescu:
>>>>> Should we yank operator>>>?
>>>> We can change it purpose and add the other one:
>>>> <<< rotate left
>>>>>>> rotate right
>>>> Bye,
>>>> bearophile
>>>
>>> This is a good idea, although rotate may be seldom enough used not to
>>> warrant its
>>> own (possibly overloadable) operator. std.intrinsic might be a better
>>> place for
>>> rotate. On the other hand, rotate is a single ASM instruction, at
>>> least on x86.
>>> In a close to the metal language, there needs to be a straightforward,
>>> efficient
>>> way to access it.
>>
>> I think DMD should just do what gcc does: recognize that
>> (x << 32-n | x>>n) is ror n
>> (x << n | x>> 32-n) is rol n
>>
>> where x is int. Ugly, but doesn't require an intrinsic.
>>
> 
> It's still better to provide a std.???.rol(T)(T x) and ror because that (least) ugly code only works if you already know x is a uint. That ror code won't work if x is signed (int: cast into uint first) or is 64-bit (ulong: replace 32 with (8*x.sizeof)).

That's why I said 'where x is uint'. I was trying to keep the example simple.
There is no way anyone should EVER be doing a rotation on a signed type -- that's insane.

Don:

> I think DMD should just do what gcc does: recognize that
> (x << 32-n | x>>n)  is ror n
> (x << n | x>> 32-n) is rol n
> where x is int. Ugly, but doesn't require an intrinsic.

Thanks, but no thanks, it's too much ugly and it gets even more ugly if you need to use that with ulongs or ushorts, etc. It seems Walter doesn't want to remove the unsigned shift, so for the rotations it's much better to add a rol/ror to std.intrinsic (plus something to read the carry bit, etc).

Bye,
bearophile

bearophile wrote:
> Don:
> 
>> I think DMD should just do what gcc does: recognize that
>> (x << 32-n | x>>n)  is ror n
>> (x << n | x>> 32-n) is rol n
>> where x is int. Ugly, but doesn't require an intrinsic.
> 
> Thanks, but no thanks, it's too much ugly and it gets even more ugly if you need to use that with ulongs or ushorts, etc. It seems Walter doesn't want to remove the unsigned shift, so for the rotations it's much better to add a rol/ror to std.intrinsic (plus something to read the carry bit, etc).
> 
> Bye,
> bearophile

The problem is, std.intrinsic is scarcely more portable than inline asm.
It doesn't even work on LDC!
You then get problems with user defined types that want to have a rotate.
BTW, if the above intrinsic existed, you would just define:

T ror(T)(T x, uint n)
{
  return (x << ((T.sizeof*8)-n) | x>>n);
}

On Dec 7, 09 05:02, Don wrote:
> bearophile wrote:
>> Don:
>>
>>> I think DMD should just do what gcc does: recognize that
>>> (x << 32-n | x>>n) is ror n
>>> (x << n | x>> 32-n) is rol n
>>> where x is int. Ugly, but doesn't require an intrinsic.
>>
>> Thanks, but no thanks, it's too much ugly and it gets even more ugly
>> if you need to use that with ulongs or ushorts, etc. It seems Walter
>> doesn't want to remove the unsigned shift, so for the rotations it's
>> much better to add a rol/ror to std.intrinsic (plus something to read
>> the carry bit, etc).
>>
>> Bye,
>> bearophile
>
> The problem is, std.intrinsic is scarcely more portable than inline asm.
> It doesn't even work on LDC!
> You then get problems with user defined types that want to have a rotate.
> BTW, if the above intrinsic existed, you would just define:
>
> T ror(T)(T x, uint n)
> {
> return (x << ((T.sizeof*8)-n) | x>>n);
> }

Shouldn't that be a problem of ldc, the implementation of std.intrinsic, or both? The interface of std.intrinsic is perfectly fine.

Don:
> It doesn't even work on LDC!

Are you sure? I think they work with LDC.


> You then get problems with user defined types that want to have a rotate.

Having two built-in operators to perform rotations can solve that, but I agree it may be overkill.


> BTW, if the above intrinsic existed, you would just define:

I see.

Bye,
bearophile

On 7-12-2009 0:11, Andrei Alexandrescu wrote:
> D has operator >>> which means "unsigned shift to the right", inherited from Java. But it doesn't need it because D has unsigned types, which can be used to effect unsigned shift. (Java, lacking unsigned types, had no other way around but to define a new operator.)
> 
> Should we yank operator>>>?
> 
> 
> Andrei

Ah!! Keep it, but let it mean "rotate right" and introduce <<< to mean "rotate left"!

There's currently no rotate operator and the only way to do rotate is
either write unportable inline asm or do "(x<<s) | (x>>(sizeof(x)*8-s))"

OK, so people coming from Java *will* be surprised  :)

L.

On 7-12-2009 1:24, bearophile wrote:
> Andrei Alexandrescu:
>> Should we yank operator>>>?
> 
> We can change it purpose and add the other one:
> <<< rotate left
>>>> rotate right
> 
> Bye,
> bearophile

I thought that idea was so crazy that I just went ahead and post it myself...

Good idea though ;)

L.

Walter Bright Wrote:

> dsimcha wrote:
> > == Quote from KennyTM~ (kennytm@gmail.com)'s article
> >> No, it will _silently_ break code that uses >>> as unsigned right shift.
> > 
> > Well, we could get around this by making >>> an error for a few releases, and then only after everyone's removed their >>>s that mean unsigned shift, we could drop in the rotate semantics.
> 
> It'll still silently break code moving from D1 to D2.

Well, I could see the value of poviding a rotate operator.

Since >>> is tainted, what about >>@ and <<@ for integral rotation?

Jerry

On Dec 7, 09 09:11, Jerry Quinn wrote:
> Walter Bright Wrote:
>
>> dsimcha wrote:
>>> == Quote from KennyTM~ (kennytm@gmail.com)'s article
>>>> No, it will _silently_ break code that uses>>>  as unsigned right shift.
>>>
>>> Well, we could get around this by making>>>  an error for a few releases, and then
>>> only after everyone's removed their>>>s that mean unsigned shift, we could drop
>>> in the rotate semantics.
>>
>> It'll still silently break code moving from D1 to D2.
>
> Well, I could see the value of poviding a rotate operator.
>
> Since>>>  is tainted, what about>>@ and<<@ for integral rotation?
>
> Jerry
>

Why these must be implemented through additional operators?