Re: Probably a bug in LuaJIT x86
- From: Egor Skriptunoff <egor.skriptunoff@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 21 Aug 2018 22:30:50 +0300
On Fri, Aug 17, 2018 at 8:16 AM, Egor Skriptunoff wrote:
On Thu, Aug 16, 2018 at 11:54 PM, Mike Pall wrote:
But the addition is still done with a double intermediate numeric type.
Ok, how should I rewrite the statement
arr[i] = arr[i-2] + ror(arr[i-1], 7)
so that LuaJIT would not create intermediate double datatype?
All I want is standard int32 arithmetics with usual wraparound addition.
The absence of answers to a question usually means "stop bothering people,
find an answer yourself" :-)
Indeed, it is easy to find the phrase "64 bit integers are sticky" in the
manual (
http://luajit.org/ext_ffi_semantics.html).
So, the solution is very simple: to convert double-intermediate-expression
into int64-intermediate-expression, just append "+0LL".
arr[i] = arr[i-2] + ror(arr[i-1], 7) + 0LL
The bug disappeared.
The SHA256 implementation works correctly on LuaJIT x86 after appending
"+0LL" to the line "w[i] = ..."
It seems that with double intermediate results I have to always insert
"correctors" after every addition:
bit.tobit(x+y) -- for int32_t-compatible result
(x+y)%2^32 -- for uint32_t-compatible result
No "correctors" are needed for int64-intermediate calculations!
Is the trick with "+0LL" safe?
Does assignment of int64_t value to int32_t variable keeps low 32 bits
verbatim on all the platforms?
Other related posts:
