Wrong optimization for "... shr 0" opcode

[GoogleCodeExporter]

What version of the product are you using? On what operating system?
With SMS 2.0.
But may affect any version of DWS.

What steps will reproduce the problem?
I use to code in SMS: 
<code>Hash.A := (Hash.A+H.A)shr 0;</code>

What is the expected output? 

<code>Self$7.Hash.A$2 = (Self$7.Hash.A$2+H$2.A$2)>>>0;</code>

What do you see instead?

With newest 2.0 revision, it compiled as such when Optimization is ON:

<code>Self$7.Hash.A$2 = 0;</code>

Which is obviously wrong, and is a regression.

"... shr 0", as "... >>> 0" is used in JavaScript to force unsigned 32 bit 
integer. Used e.g. in my code to compute crc32 or SHA.

Original issue reported on code.google.com by arn...@gmail.com on 3 Feb 2014 at 3:55

[GoogleCodeExporter]

The optimization was also incorrect in the script engine (now fixed)

For the purpose of the forcing an unsigned value, I'm considering adding an 
Unsigned() built-in function, which would also allow considering an Int64 value 
in the script engine to be an unsigned.

Is there a source code version of the hash I could use to test if the 
Unsigned() would be practical?

Original comment by zar...@gmail.com on 4 Feb 2014 at 10:39

• Changed state: Started

[GoogleCodeExporter]

Unsigned() could make sense, you are right.

".. shr 0" is just a Javascript tweak.

About the hash, you can take a look at 
http://blog.synopse.info/post/2012/04/19/Smart%3A-mORMot,-from-Delphi-to-JavaScr
ipt
The CRC32 computation is enough to have a reference use of ".. shr 0".
SHA-256 could be also useful.

Thanks a lot for the quick fix!

Original comment by arn...@gmail.com on 4 Feb 2014 at 12:51

[GoogleCodeExporter]

Hmmm, the CRC32 code fails script-side where integers are 64 bits, as it 
assumes a 32bit integer for the "not" and the subsequent bit shift.

That said other CRC32 implementations I found did not have the initial & final 
"not" your code has, and so did not exhibit bitness issues.

I'm wondering about the above about what Unsigned() should mean, and if 
Unsigned32/Unsigned64 distinction is warranted. Script-side both can be 
handled, JS-side, only Unsigned32 is possible. So I guess I'll stick with 
Unsigned() getting the highest bit count unsigned.

Original comment by zar...@gmail.com on 4 Feb 2014 at 1:27

[GoogleCodeExporter]

Hmm, scratch the above, it doesn't float. Unsigned() to the highest precision 
would require returning a float (otherwise it's just a nop), so only 
Unsigned32() makes sense.

Script side it would be equivalent to an "and $FFFFFFFF" and JS-side to a ">>> 
0".

Original comment by zar...@gmail.com on 4 Feb 2014 at 1:39

[GoogleCodeExporter]

Original comment by zar...@gmail.com on 4 Feb 2014 at 2:09

• Changed state: Fixed