Closed Hexcede closed 2 years ago
This would require some kind of tracking of u32 vs u64. ffi
takes care of this in luajit
. Possibly instead of representing all u32s as u64s with upper zero bits, instead truncate the values so that u32s are represented as a table of 1 byte, whereas u64s are represented as a table of 2 bytes. This would allow for arbitrary length numbers as long as those lengths are byte-aligned (e.g. no 7 bit numbers or anything, not that those are going to show up in wasm).
Actually, alternatively it may be easier to just define __eq
metamethods differently for u32
vs u64
but use the same structure. I do not believe the performance implications of this would be significant when using shared metatables and it would avoid having to rewrite APIs to support truncated values.
It could possibly even save performance (assuming proper 32 bit support) to use an __eq
metamethod since we wouldn't need to add any code paths for truncated numbers. It sounds like the more appealing route to me either way.
P.s. this is effectively what the luajit case has with ffi
since the ffi
numbers are compared by ==
.
Many 32 bit tests are only failing due to the usage of 64 bit libraries. For example,
int_literals.wast.lua
loads a constant4294967295
and compares it with-1
in one of its tests, but this fails due to the usage ofrt.eq.i64
inluau_assert.lua
. There are several more complex cases like this.