Open TannerRogalsky opened 8 years ago
Although it may be a ton of work potentially a LuaJit alike can be made that can produce JS code. Which can be compiled by the browser. Which could potentially be faster than straight Lua compile for the web. It probably would be worth it, but probably is way too much work.
I wouldn't count on it being more performant, actually. Any JS code that would be run from Lua would almost certainly have to be run through eval
which would have significant overhead.
It would still be really nice if only for browser feature detection.
I meant like it compiles the Lua code to optimized JS code. Like how luajit compiles Lua code.
Oh! That might be possible if done ahead of time. If Lua can be transformed into LLVM bytecode then it follows that it might be able to be run through emscripten. That's an interesting idea! It's separate from the issue of lacking a JS or C++ FFI, though.
Quick research: http://lua-users.org/wiki/LlvmLua
A potential solution that doesn't need a full port of luajit: https://github.com/facebook/luaffifb That said, it does use dynasm so presumably it'd need a bit of patching to support asm.js
Luajit's ffi module can be used as a library iirc. But I do have a question. What would be the point in supporting ffi? It seems unlikely that one would be able to wrap libraries with it and it may not even give a performance increase without JIT.
I think making a JS ffi would be more useful. (If the user wants to do something involving browser APIs) (I apologize for double posting can't seem to edit on the mobile site.)
Love.js is built against Lua5.1. LuaJIT does not have a browser port and it's assembly can't be readily ported using emscripten.
A potential alternative (although not a solution) could be to expose a JavaScript FFI using
emscripten_run_script
: https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-from-c-c