Except luajit has boxed 64bit integers: there's no reason you couldn't have them act just like lua 5.3 64 bit ints. In the majority of real use cases you can narrow down to the 32bit ints already supported by luajit.

Even from the Lua C API standpoint? I'm not very familiar with it.

Tarantool[1], a general-purpose database and app server based on LuaJIT, has Lua/C API to work with 64-bit numbers and even custom cdata objects [2]. I can extract this code into a separate library for you.

[1]: http://tarantool.org/ [2]: https://github.com/tarantool/tarantool/blob/1.7/src/lua/util...

Currently in luajit you're just "not meant to" work with ffi cdata from the C api. You can... even if it's not pretty.

However, I was more saying that there isn't a technical reason that lua 5.3 integer behaviour couldn't reuse the existing (boxed) 64bit integer support in luajit. Which would mean that the slim tagged NaN tagged value approach can be kept.

I think the main problem here is that there are several semantic differences between 5.3's and LuaJIT's integers which would make this a bit dodgy; eg. rounding behavior and mixed float-integer arithmetic are different.

IMO 5.3 should have done what LuaJIT did and require a suffix for 64-bit integer literals (say `L` to avoid conflict with LuaJIT's `LL`). Given how rarely Lua code needs true integers this large, that probably would have worked better. It also would have avoided the gotchas of porting code to 5.3 where the integral numbers you never add `.0` to are suddenly real integers instead of floats.

I'd love for LuaJIT to get 5.3's bitwise ops but the semantic differences between the integer implementations would make this interesting to say the least.

Not sure what you talk about.. lua5.3 stores 64bit integers in the same tagged union it stored doubles so the value size didn't grow at all. 64bit ints only need a new tag value (which was available before).

IIRC, Lua 5.2 uses NaN tagging as LuaJIT does, and has 64bits values.

All Lua5.x versions use 8-byte union plus 1-byte tag, that's 12-byte TValue (16-byte on 64bit targets).

(somewhat off topic) Mike authored a cunning patch to un-box short strings, sadly it got never mainlined. http://lua-users.org/wiki/FastStringPatch

Edit, yes, v5.2 supports the NaN trick (see the comments above http://www.lua.org/source/5.2/lobject.h.html#NNMARK), but only on x86.

I suppose the Lua authors wanted to avoid the memory limitations of LuaJIT on 64bits machines.

---- Original below:

I thought v5.2 used NaN tagging but I may be wrong. At least the beta versions did. I misremembered that post to refer to the final version: http://lua-users.org/lists/lua-l/2011-07/msg00180.html

Quoted in full:

----

Lua 5.2 beta implements the "NaN trick": it packs all Lua values into a single double value by representing non-numeric values as signaled NaNs, which are (usually) not produced by the system.

This trick should work on most 32-bit machines that follow IEEE 754-2008 for double representation. However, currently it is being enabled only by predefined macro __i386__ (and similars). We would like to know what other platforms could benefit from this trick (and what macros should we check in luaconf.h). You can force the trick by compiling Lua with -DLUA_NANTRICKLE (for little endian systems) or -DLUA_NANTRICKBE (for big endian).

(Of course, we would also like to know whether there are problems with this implementation.)

-- Roberto

----

I also think I remember people (maybe Mike Pall) reporting perf regressions between 5.2 and 5.3 because of the cache bloat introduced by mandatory 128bits values (on 64bits systems).

Thanks, my bad. I didn't know they tried it in 5.2.