ds84182/luavm

Lua Virtual Machine (and various tools) for Lua so you can Lua while you Lua

LuaVM

Lua Virtual Machine for Lua so you can Lua while you Lua

Usage

To use LuaVM, first you must meet all the requirements:

• Lua 5.1 and 5.2 are the only versions supported. Unoffical versions of Lua (like LuaJIT, LuaJ, etc.) are not fully supported.
• A way to generate Lua 5.1 valid bytecode (an ASM suite is in the works, a Lua to bytecode compiler is coming)

Then, you must require the modules you need (sorry for the global namespace injections):

require("luavm.bytecode")
require("luavm.vm[your version here, 51 or 52]")

After that, simply call vm.lua[your version here, like 51 or 52].run(bytecode.load([bytecode here]))

Documentation

bytecode.load(bytecode)

Loads valid Lua 5.1 or 5.2 bytecode (as a string). Returns a table.

bytecode.save(bytecode)

Redumps bytecode tables created from bytecode.new or bytecode.load. Returns a string.

vm.run(bytecode, arguments, upvalues, globals, hook)

Starts running bytecode. Arguments, Upvalues, Globals, and Hooks are optional. Returns whatever the emulated bytecode returns. Arguments, upvalues, and globals must be a table. Hook must be a function, it is called every single instruction.

luavm's Issues

Decompiler2: Self calls are not supported

The SELF instruction just kills the decompiler right now with a failed assertion. This should be easy to implement.

Decompiler2: Inline table fields (and SETTABLEs)

Example from the current table test

r0 = {}
r0.a = 4
r1 = r0.a
return r1

TO

r0 = {}
r0.a = 4
return r0.a

This can be optimized to:

r0 = {a=4}
return r0.a

And then to:

return ({a=4}).a

Add bytecode retargeter

Retargets bytecode from one format configuration to another (size_t 8 bytes -> 4 bytes). Also could possibly upgrade bytecode to a later version of Lua.

Decompiler2 needs an official formatter

Decompiler3: Inliner is sometimes buggy

The inliner has troubles sometimes. Most of the inliner will be replaced once #17 is resolved.

Decompiler3: Varargs aren't handled correctly

Decompiler3 opts to throw an error when varargs is used. #17 should help fix this.

Restructuring TODO LIST

• Put binary files in their own directory
• Make LuaVM libraries export via return and not globals
• Expansive test system for bytecode and decompiler3
• Better README and Documentation

Decompiler3: Code generation emits invalid Lua syntax

This prevents the decompiled code from running. This needs to be fixed so we can test the decompiler output.

Decompiler3: Bridge the new block system over to the core decompilation code

The new block system properly finds all Lua block constructs (including CLOSE, needed for finding standalone do end blocks), but the decompilation core doesn't use it. It needs to be modified to switch between the old logic (for comparison) and the new logic (for accuracy).

This is technically a bug because Decompiler3 has some bugs in the current block handling code.

Decompiler2: Most breaks are untested

• While loop break
• Numeric For loop break
• Generic For loop break
• Repeat Until loop break

VM 5.1 and VM 5.2 will leak registers and upvalues after they are closed

Decompiler2: Unsupported Loops

• while true do end
• while <cond> do <...> if <cond> then <single instruction> end end
• while true do <...> end (this one is hard... kinda)
• repeat <...> until <cond>

Bytecode 5.3 does not have save support

VM 5.2 needs the VARARGS and upvalues close fix from VM 5.1

More tests for everything

The VM has a testing suite, so now the bytecode loader/patcher/dumper needs a testing suite!

Decompiler2 also needs a testing suite.

A VM Test is needed for upvalue closure on scope exit (of both inner scopes and implicit close on function exit [on error and regular return])

JIT recompiler

Would it be possible to add a JIT recompiler in order to make LuaVM run faster?

VM 5.3 does not exist