Adventures in JIT compilation: Part 1 – an interpreter | Hacker News Reader

Adventures in JIT compilation: Part 1 – an interpreter

eli.thegreenplace.net

131 pointsfnord12311 comments

Part 2 is here: http://eli.thegreenplace.net/2017/adventures-in-jit-compilat...

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.

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.

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?

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.

I agree that the article itself seems great, but I like to follow along and the output adds an extra step. I shouldn't complain, really.

Can you clarify what you mean by "copying everything"?

A good thing about BF, IMHO, is that its syntax is trivial to the point of almost non-existence, and that its memory model is C-like.

Yes, sorry, I mean to make it human-readable, I always copy BF to https://copy.sh/brainfuck/ so I can check whether the output is correct. '12345' is a lot easier to read than +++++++- ++++++-+ ++++++-- +++++-++ +++++-+- or whatever.

I agree that the language itself is very likeable for the reasons you stated, but I'm partial to things that I can easily check. It's called Brainfuck for a reason. ;)

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

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... -- for a broader treatment

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

Reply on news.ycombinator.com