The problem with the approach is that it's not real JIT-compilation, it's just assembly templates with basic substitutions.

By not using LLVM, you're missing all the optimizations it does.

▲

the-lazy-guy an hour ago | parent | next [-]

This is absolutely a JIT-compiler. It compiles code into machine code. This is a surprisingly efficient way to get noticeable speedup relative to interpretation. Also it is much safer than proper optimising compiler. Say ebpf jit-compiler functions very similarly, because it is fast and _secure_ way to jit. (well, there's a bit of cheating because before emitting bpf bytecode it goes through gcc/clang pipeline).

LLVM is a large dependency if you need to JIT. There are plenty of smaller (and much faster) alternatives which are much better fit for smaller projects. Larger projects usually roll out their own jit-pipeline because they can integrate better with the source language/interpreter and apply tricks LLVM is not well suited to (say, LLVM is not great at deoptimisation). I think only Julia is really a heavy user of LLVM JIT, also it is known for extremely slow repl from time to time.

	▲	mort96 an hour ago \| parent [-]
		To back up the "surprisingly efficient way to get a speed-up" thing: I once wrote a toy compiler, without an optimizer and without even a register allocator (so all variables lived in stack memory). In my test benchmarks it was roughly 4x slower than Clang at -O3, IIRC. That's not exactly blazing fast for a low level C-like language, but it's not bad. It's infinitely faster than what I've ever gotten a toy interpreter to be.

▲

mort96 an hour ago | parent | prev | next [-]

A non-optimizing compiler is a real compiler.

▲

IshKebab an hour ago | parent | prev [-]

This absolutely is real JIT compilation. Copy and patch is a very well known JIT compilation technique.