Re: LuaJIT and WebAssembly

  • From: Coda Highland <chighland@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Mon, 17 Apr 2017 10:52:08 -0700

On Mon, Apr 17, 2017 at 10:29 AM, Paul Kaletta <pk@xxxxxxxxxxxxxxx> wrote:

Am 17.04.2017 um 17:43 schrieb Coda Highland:

On Sat, Apr 15, 2017 at 9:43 AM, Paul Kaletta <pk@xxxxxxxxxxxxxxx> wrote:

Hi everybody,

I recently learned about WebAssembly/WASM, a bytecode format for web
browsers.

https://en.wikipedia.org/wiki/WebAssembly
http://webassembly.org/

The format is suitable as a compilation target for C/C++ compilers, and
so
the original Lua already runs in a WASM environment.

https://github.com/vvanders/wasm_lua

Are there any plans add a WebAssembly target to LuaJIT?  I realize that
porting LuaJIT to a new target architecture is quite an undertaking, but
I
wanted to inquire whether there is any hope.

Best regards,
Paul

I'm not sure I understand the impetus. WebAssembly is already
JIT-compiled, and you wouldn't have access to the FFI, so what benefit
would LuaJIT derive from such a port?

/s/ Adam


My guess is that WASM is not JIT-compiled, but "statically" compiled to
native machine code.  If I understand things correctly, WASM is more like (a
portable variant) of LLVM bit-code and less like Java byte code.  Full
translation to target machine code can happen before execution, there is no
tracing JIT compiler involved.

The distinction between JIT-compiled and statically-compiled is not a
particularly sharp one. Chrome's V8 Javascript engine doesn't have an
interpreter mode at all. It compiles Javascript of all sorts directly
to native machine code and executes it. It uses the behavior of that
compiled code to identify specializations and optimizations that it
can apply to the code and then recompiles it.

WASM

If LuaJIT's fast interpreter was ported to WASM, LuaJIT (the language) would
become available in the browser.  I don't know enough about LuaJIT's trace
compiler to asses whether it can be made to emit WASM.  This is why I
inquired.

LuaJIT the language without FFI is a Lua 5.2-flavored variant of Lua 5.1.

Whether or not it would actually work is an open question. WASM
doesn't define a way to execute arbitrary bytecode. It has to be
compiled into modules and run through a linker, so recompiling code on
the fly and substituting it into the rest of the program doesn't LOOK
like it's possible... but it might just require some fancy marshalling
through the Javascript API to deal with trace boundaries. This may or
may not actually be worthwhile.

I also don't see why LuaJIT's FFI should not be available.  If one can
compile C to WASM, and LuaJIT's interpreter was available in a WASM version,
it should be possible to call C code from LuaJIT programs via LuaJIT's FFI.

That would require a well-defined calling convention and dynamic
resolution of already-loaded functions in WASM modules. At present,
neither is available. Future WASM development might provide these, but
it's not there yet.

The FFI that WOULD be relevant would be FFI calls into Javascript or
other WASM modules, but that wouldn't be reusing much of LuaJIT's
existing code.

I would love to use LuaJIT (the language) as a scripting language in my
program, but so far LuaJIT (the implementation) will not run in the browser.
If I want the same scripting language both in the browser, and in a "native"
environment, I need to go with PUC Lua. I think that WebAssembly will only
become more and more important, especially for game developers.

My point is that you probably SHOULD go with PUC Lua -- not because of
any technical reason why LuaJIT could or could not be made to work,
but because the benefit of going through the porting effort is
negligible.

If you're going to put that much work into it, you're probably better
off building something more tightly integrated with the platform
instead of specifically trying to make LuaJIT itself work.

/s/ Adam

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 04-2017