I'm porting a small piece of Java code into D, but I've run into this:

int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) << 7) + (x13 >>> 24);

I have a basic understanding of those operators in both languages, but I can't find a sufficiently detailed explanation to tell me how to translate the Java into D and know that it's guaranteed to give the same result. Can someone tell me the correct D code to use?

On Monday, 1 May 2017 at 15:45:00 UTC, bachmeier wrote:
> I'm porting a small piece of Java code into D, but I've run into this:
>
> int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) << 7) + (x13 >>> 24);
>
> I have a basic understanding of those operators in both languages, but I can't find a sufficiently detailed explanation to tell me how to translate the Java into D and know that it's guaranteed to give the same result. Can someone tell me the correct D code to use?

It's the same code in D. It extracts consecutive bits in x12 and x13 (and maskxx), put them at the beginning (right shift) and add them.

On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:

> It's the same code in D. It extracts consecutive bits in x12 and x13 (and maskxx), put them at the beginning (right shift) and add them.

Thanks.

On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
> It's the same code in D. It extracts consecutive bits in x12 and x13 (and maskxx), put them at the beginning (right shift) and add them.

 Reminds me... was the unsigned shift >>> ever fixed?

On 2017-05-01 17:45, bachmeier wrote:
> I'm porting a small piece of Java code into D, but I've run into this:
>
> int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) << 7) +
> (x13 >>> 24);
>
> I have a basic understanding of those operators in both languages, but I
> can't find a sufficiently detailed explanation to tell me how to
> translate the Java into D and know that it's guaranteed to give the same
> result. Can someone tell me the correct D code to use?

Not sure if this is still the case. But this [1] suggests that D doesn't have an evaluation order defined but Java does.

[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder

-- 
/Jacob Carlborg

On Monday, 1 May 2017 at 19:06:36 UTC, Jacob Carlborg wrote:

> Not sure if this is still the case. But this [1] suggests that D doesn't have an evaluation order defined but Java does.
>
> [1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder

That's good to know but shouldn't be an issue for this code.

On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:
> On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
>> It's the same code in D. It extracts consecutive bits in x12 and x13 (and maskxx), put them at the beginning (right shift) and add them.
>
>  Reminds me... was the unsigned shift >>> ever fixed?

What was wrong with it?

> 
> Not sure if this is still the case. But this [1] suggests that D doesn't have an evaluation order defined but Java does.
> 
> [1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder
> 
To me, this [2] suggests otherwise ;)
Or am I missing something?

[2] https://dlang.org/spec/expression.html#order-of-evaluation

On Monday, 1 May 2017 at 21:04:15 UTC, bachmeier wrote:
> On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:
>>  Reminds me... was the unsigned shift >>> ever fixed?
>
> What was wrong with it?

Doing a broad test I'm seeing an issue with short & byte versions... Course that's probably due to the default upcasting to int rather than short/byte, while the >>>= works just fine. So...

byte f0 >> fffffff8
byte f0 >>> 7ffffff8
short f000 >> fffff800
short f000 >>> 7ffff800

On 2017-05-02 01:27, Faux Amis wrote:

> To me, this [2] suggests otherwise ;)
> Or am I missing something?
>
> [2] https://dlang.org/spec/expression.html#order-of-evaluation

From that link:

"Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression".

-- 
/Jacob Carlborg