Eli Bendersky has another great, even simpler introduction (from 2013) to JIT compiling but with hardcoded instructions [0]. And a more recent post on JIT compiling Brainfuck [1].

[0] https://eli.thegreenplace.net/2013/11/05/how-to-jit-an-intro...

[1] https://eli.thegreenplace.net/2017/adventures-in-jit-compila...

I wrote a blog post about a Brainfuck JIT too: https://blog.reverberate.org/2012/12/hello-jit-world-joy-of-...

Mine uses the DynASM framework developed for LuaJIT, so that the assembly instructions can be written symbolically: https://luajit.org/dynasm.html

It amazes me how often I find myself following links back to Eli's blog, unexpectedly. Dude's a treasure.

For those interested, my blog has a simple Lisp JIT (https://bernsteinbear.com/blog/) and I maintain a bunch of resources about other JITs of varying complexity on https://bernsteinbear.com/pl-resources/

I can attest that the other posts on that blog about AOT compilers are also extremely solid - concrete, practical, well-written.

That's very kind. Thank you.

Experiments like these are really fun to do in a small setting. In reality you would only get to this point after having built a complete programming language with all its parts. But in a situation like this you can start at the end, focus on generating the machine code, putting it in a memory buffer and instructing the CPU to start running it at that point. It can hardly be called a JIT compiler of course, but you definitely get an impression of its mechanics.

A couple of years ago I did the JIT 'kickstarting' machinery for fun in the Nim language: https://github.com/eterps/loader/blob/master/syscall.nim

> In reality you would only get to this point after having built a complete programming language with all its parts.

Not necessarily. You might want to JIT a domain-specific abstraction, like a regular expression engine.

Wonder if you could create a new language using this approach, designed for efficient JIT compilation: maximum programmer convenience that is still coherent with maximum runtime performance, whiteout any learning curve for the user other than the language itself.

Yes, these are called multistage languages:

https://en.wikipedia.org/wiki/Multi-stage_programming

The classic example is MetaOCaml:

https://en.wikipedia.org/wiki/OCaml#MetaOCaml

To be pedantic, this is an in-memory AOT compiler and not a JIT compiler.

As an example, here's a JIT compiler I made for BrainFuck that defers the compilation of some loops: https://github.com/danthedaniel/BF-JIT/blob/master/src/runna...

To be a bit less pedantic, this is an area that is kind of ambiguous... From one point of view it's still fair to call this "just in time".

I wish there was terminology to differentiate between kind of "on demand AOT compilation" and jits that do jitty stuff that can't be done ahead of time.

> I wish there was terminology to differentiate between kind of "on demand AOT compilation" and jits that do jitty stuff that can't be done ahead of time.

Some people differentiate between dynamic JIT compilation and static JIT compilation.

Julia uses the term just ahead of time for this, which I think fits well.

That strikes me as just-in-time optimization less so than ahead-of-time.

If the code isn't compiled until it's executed, "ahead of time" seems extremely confusing

Arguably the term "ahead of time" also suffers from the same problem. Among compiler people, "ahead of time" vs "just in time" sometimes has to do with whether the compiler uses run-time information when compiling. But the names don't reflect that, they talk about when the compilation happens.

> kind of "on demand AOT compilation"

I assume you mean something like Common Lisp does with COMPILE? (http://clhs.lisp.se/Body/f_cmp.htm) That's just called "compilation" in some circles.

Another great set of JIT introductions are

A Basic Just-In-Time Compiler https://nullprogram.com/blog/2015/03/19/

A JIT Compiler Skirmish with SELinux https://nullprogram.com/blog/2018/11/15/

More good JIT tutorials can also be found in the PyPy ecosystem, which provides tooling to add JITs to any interpreter for a language implementation written with its (R)Python toolchain.

E.g. here's a recent video: https://www.youtube.com/watch?v=fZj3uljJl_k

https://www.youtube.com/watch?v=xIW6qF8CE78&list=PLvdK1vRmp8... good video series on JIT compiler implementation

> APL [...] manages to achieve reasonable performance by having interpreter operations that apply over a large number of data elements at a time

Actually... http://www.softwarepreservation.org/projects/apl/Papers/DYNA...

I think this is the simplest JIT compiler I've seen, which also is able to compile a rather large subset of C: https://news.ycombinator.com/item?id=8746054

I really like this kind of a tutorial - start simple, show how to optimize and what to optimize for, and when things get rough, plug in scotch :)

Terry Davis, of TempleOS fame, did a video about writing a mini JIT compiler in TempleOS using HolyC: https://www.youtube.com/watch?v=RnVYXplrRkQ

I wish I had a space alien or God himself teach me low level computer architecture.

Terry Davis learned in university and on the job before the schizophrenia 'kicked in'. How he was able to focus enough to write so much solid code after the illness started, I'll never know.

It is also possible, that the illness gave him the fanatism required to maintain the focus over the years, to come so far with TempleOS. (That same fanatism and crazieness also prevented people from participating I guess.)

I bet it was less about fanaticism and more about time. Previously, he had worked full time and made money. He wasn't able to work after the illness (I think I read somewhere that he was rehired by his old company, but only lasted a few weeks).

TempleOS wasn't the first thing he worked on after becoming ill, he'd previously been working on a three-axis milling machine. https://en.wikipedia.org/wiki/Terry_A._Davis#Onset_of_illnes...