Thanks for the suggestion. I think mostly people who want to use LuaJIT as a backend for another language, not primarily Lua programmers, might be interested in my work. Here is an article describing the project: https://medium.com/@rochus.keller/implementing-call-by-refer...
> LuaJIT as a backend for another language, not primarily Lua programmers
Not exactly backend but that kinda fits my use case. I have a C embedded application that I need scripting on. Nothing unsecure from the user, from my own backend, but it requires a foreign function interface, and its a super constrained device.
Lua, JavaScript, forth, etc. None I’ve been able to find anything I like under 50 kB flash or are even slightly “friendly”.
Found one in JavaScript was close, but it’s an interpreted language which means every letter of code is a byte I need to transfer then have parsed.
I’ll look into this. Esp if it’s still possible to send just bytecode in.
Notice that if I remember correctly, you can generate bytecode on the PC (by using the luajit command) and have the resulting bytecode loaded through the C API on your device as if it were a regular script.
The problem with eLua and others is that they either try and replace C or they focus on the headers/registers/peripherals of the micro. Design it to be the environment you do all your work in. Get there, stay there. It’s why eLua appears to have terrible micro support because they only have the bandwidth for specific chips. Other options like MicroPython have a VM you are never supposed to leave.
I think you’re right that Lua is the way to go. But I have yet to see someone package it nicely for gcc and to be included and built from an MCU IDE (Keil, Segger Emebbeded, IAR, etc). I’ll keep looking.
It loads and runs a Lua source code file which calls the exported C function. Lua compiles the source code into byte code before running it but that can also be done ahead of time with the Lua compiler:
Just a nit on the JIT... JavaScript is almost always compiled, regardless of whether there is a JIT or not.
A typical JavaScript system first compiles the JS source code into bytecode. Then it starts executing (interpreting) the bytecode.
If there is a JIT, that is a second compiler. It monitors the execution of the bytecode to find hot spots where it compiles the bytecode into machine language.
You are missing https://libraries.io/github/fperrad/tvmjit
which adds a nice macro and OO layer (in lisp syntax) on top of LuaJIT. A much nicer way to use this superior VM.
Thanks, interesting. But so far I don't see such a big advantage over LuaJIT or the Lua language that would justify creating a new, incompatible fork. It's just another variant, not necessarily a better one. Or have I missed something which is so much better than the original?
RaptorJIT is working well for Snabb but it's not clear what other projects can benefit from it. We're using Lua to compete with C while most other projects seem to be using it to compete with Go/Python/node. So for the moment I'm not actively courting new users because I don't find many kindred spirits in the wider LuaJIT community.
EDIT: To clarify, the big advantage of RaptorJIT is that it takes dramatically less time and effort to profile and optimize programs to become competitive with C. If you're spending a lot of time scratching your head over long 'jit.dump' reports then RaptorJIT will save you lots of time. That's a big win for Snabb hackers but we seem to spend much more time on JIT-optimization than other LuaJIT users.
(Anecdotally it seems like most other LuaJIT users eventually give up on understanding the JIT entirely because they don't see it as being worth the effort. This doesn't really bode well for LuaJIT world domination.)
I really like the streams and resources you put up, Luke. Thanks for clarifying. Studio is so cool, I've been looking at maybe hacking it to work with my spreadsheet compiler, using Lua (or maybe LJ bytecode) as IR, and source maps.
Your live streams are a massive resource.
They are so dazzling to others that they'll sit through an explanation of phi nodes, while I assure you they would not otherwise. If you ever want a change of pace, we'd probably be interested in bringing you on board in 2020.
Cheers, and I hope the fellas are doing well. :- )
This is very interesting work! I am poking around CPython and Python bytecode to learn about compilation/VM/interpretation and I was thinking about writing cose directly in Python bytecode to play with.
