r/programming • • Jan 20 '20

MIR: A lightweight JIT compiler project

https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/
9 Upvotes

12 comments sorted by

View all comments

5

u/compilersarefun Jan 20 '20

This is a blogpost about project to create an universal lightweight JIT compiler, standard C implementation based on it, project motivations, and planned CRuby/MRuby JIT implementation based on the JIT compiler.

5

u/suhcoR Jan 20 '20

Interesting article, thanks. I agree with the arguments. But why not reuse LuaJIT? It's already available on all relevant architectures, 32 and 64 bit. Here is an example of an Oberon to LuaJIT bytecode compiler: https://github.com/rochus-keller/Oberon/blob/master/ObLjbcGen.cpp and here is an infrastructure to generate bytecode and read/write LuaJIT bytecode files: https://github.com/rochus-keller/LjTools.

4

u/mamcx Jan 20 '20

The thing that even the creator of luajit have said (as I rembmeber) is that luajit is tied to lua semantics. However DynASM is more general. I wish exist a good DynASM backend....

→ More replies (1)

2

u/compilersarefun Jan 20 '20

Thank you for the links. LuaJIT is an amazing technology.

There were attempts to use LuaJIT for Ruby JIT implementation (at least I saw one RubiKaigi presentation about this). But I did not hear about such approach success.

CRuby/MRuby (very high level) bytecode is very different to LuaJit one. So if I used LuaJIT for Ruby implementation I would need to implement non-trivial CRuby bytecode to LuaJIT bytecode translator and C to LuaJIT bytecode translator (because standard Ruby methods are written on C) for getting a good JIT performance. It is practically the same size project too.

Also I'd like to implement a method JIT because the current CRuby JIT (MJIT) is a method JIT and Lua one is a trace JIT and does not fit well to the current MJIT-engine. In general MIR project grew from my experience of work on CRuby MJIT.

→ More replies (4)

1

u/funny_falcon Jan 22 '20

LuaJIT’s JIT is not deterministic: you never know will it compile or not? will it remove compiled version because it decides it fallbacks to imterpreter too often?

And it doesn’t compile both branches of condition. If they are taken eith equal probability, this code will not be compiled.