I'm attempting to write a Lua 5.3 VM in another language (this is for experimentations only).
The resources I've found for the moment are :
A No-Frills Introduction to Lua 5.1 VM Instructions
Lua 5.3 bytecode reference
As Lua breaks compatibility between each version, it's really difficult to find out how 5.3 bytecode works.
Do you have another source to share please ?
The official definition of the instructions of the Lua VM is in lopcodes.h, starting at OP_MOVE.
There's also the Lua 5.3 Bytecode Reference provided by the documentation for the Ravi language
(a language that uses a modified Lua 5.3 VM).
That can be found here
Related
It seems to be as much of a unicorn as the source code itself. Can't find it on the official Lua page or google. Anyone who still has it?
The manual included with the 4.1 source code is the 4.0 version( the date matches Lua 4.0 release ). I saw someone mentioning a 4.1 version of it here:
http://lua-users.org/lists/lua-l/2001-07/msg00187.html
What are the benefits of using Lua or LuaJIT for APISIX? What is the relationship between Lua 5.1, Lua 5.3 and LuaJIT?
Apache APISIX claims to be based on OpenResty (Nginx + LuaJIT). This is because LuaJIT has better performance than Lua, and has a FFI library for interacting with C code.
Source: https://apisix.apache.org/blog/2021/08/25/why-apache-apisix-chose-nginx-and-lua/#luajit-vs-go
What is the relationship between Lua 5.1, Lua 5.3 and LuaJIT?
LuaJIT is based on Lua 5.1, and Lua 5.3 has very little relation to either of them.
There is a small cherry-picked handful of features backported or re-implemented from 5.2+ in LuaJIT, for example the bit library is there to replace 5.2's bit32, but LuaJIT for the most part is just a JIT implementation of 5.1, which makes Lua 5.3 the odd one out.
I think a point needed to be claimed before that the Apache APISIX do choose the Openresty which Lua wrote. So maybe this is why Your question was scored negatively.
Then let's return to the question, What is the benefit of using Lua or Luajit. You can refer to this link
I'm curious if anyone here has built Lua 5.2 for OpenWRT?
All Google brings up is this thread disparaging Lua 5.2's new environment system, and noting how LuCI won't work with Lua 5.2.
However, I am not at all interested in using LuCI or, for that matter, most of the other Lua code supplied by OpenWRT. Compatibility with LuCI etc. is not an issue.
Therefore my question: Has anyone compiled Lua 5.2 for OpenWRT? Do all the OpenWRT patches apply cleanly? I suspect they don't; at any rate, the LNUM author has said he does not plan on supporting his patch.
Basically, I would like to know if building Lua 5.2 is feasible/has been done/sounds doable before I plunge in, lose two weeks to frustration and am then forced to give up.
I build 5.3.2 for OpenWRT Mips32r2. Should be work with 5.2.4 too.
https://github.com/markuman/zsun_fun/blob/master/mips_cross.sh
I am writing some test scripts for my Lua project and I want to be sure that they run correctly under the different Lua versions available. Since my unit testing framework can use the wrong Lua version if I misconfigure it, I would like to be extra safe and check at runtime what Lua version my tests are running under. What would be the best way to do that?
I know that a quick way to tell 5.1 and 5.2 apart is to check the _VERSION global but how can I tell regular Lua 5.1 and LuaJIT apart?
Luajit extends the standard library with a jit module. That is probably a more direct way to detect its presence:
if type(jit) == 'table' then
print(jit.version) --LuaJIT 2.0.2
end
Just a small question from a "Lua newbie"...I have been using LuaJIT and it is awesome, no the question is since LuaJIT is Lua 5.1 compatible does that mean I can use all the "LuaRocks" that standard Lua uses in LuaJIT?
For instance if I wanted to install one of the SQLite libraries (e.g. http://luaforge.net/projects/luasqlite/) - how would I install that in LuaJIT?
Do all the available "LuaRocks" work out the box with LuaJIT?
LuaJIT is designed to be drop-in compatible with the Lua stand-alone. There is no reason why any purely Lua-based Rocks shouldn't work. DLL-based Rocks ought to work as well, since the LuaJIT stand-alone DLL is compatible with the original DLL.
Concretely:
"LuaJIT is fully upwards-compatible with Lua 5.1. It supports all standard Lua library functions and the full set of Lua/C API
functions. LuaJIT is also fully ABI-compatible to Lua 5.1 at the
linker/dynamic loader level. This means you can compile a C module
against the standard Lua headers and load the same shared library from
either Lua or LuaJIT."
I think that pretty much says it all.