
Adventures in JIT compilation: Part 1 – an interpreter - fnord123
http://eli.thegreenplace.net/2017/adventures-in-jit-compilation-part-1-an-interpreter/
======
fnord123
Part 2 is here: [http://eli.thegreenplace.net/2017/adventures-in-jit-
compilat...](http://eli.thegreenplace.net/2017/adventures-in-jit-compilation-
part-2-an-x64-jit.html)

------
sverige
This seems like it could be a great series. I would be more likely to read it
if the code the JIT is built for wasn't BF. It's just too tedious to follow
along by copying everything into another interpreter to make it readable.

~~~
smitherfield
Like the post says, there are plenty of others on the web about implementing
interpreters or compilers for more useful languages, and, even if it's just
Scheme, those tend to spend nearly all their time on the parser. I really like
this series because it skips the parsing part to get to the most interesting
and relevant topic: how actual language runtimes are implemented.

~~~
reymus
Well, why not just make yet another one for one of those more useful
languages, but not fall under the same trap of spending too much time on the
parser?

~~~
smitherfield
Because then you're increasing the cognitive overhead for the reader and the
time commitment overhead for the writer.

But yeah, if the author wanted to make a part 3 it might be interesting to see
his implementation for something like (a simplified subset of) Java bytecode.

------
d0vs
This looks like an AOT compiler to me, not a JIT compiler.

~~~
eliben
This is only true in the strictest interpretation of what "JIT compilation"
means. Check out the Aycock paper --
[http://eecs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literat...](http://eecs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/JustInTimeCompilation.pdf)
\-- for a broader treatment

~~~
d0vs
You're right. This was an amazing couple of posts anyway, I hope you continue
the series!

