6 ms·
I wrote this to understand bytecode compilers and interpreters. Please let me know what you think!
by tekknolagi 8y ago
I wrote this to understand bytecode compilers and interpreters. Please let me know what you think!
- Impossible 8y agoI went to the same class and I just wrote a bytecode interpreter for work. This is a nice follow up I might contact you when I start work again (still on PTO).
- tekknolagi 8y agoYes, please do -- I'd be interested to hear more.
- gravypod 8y agoThis is an amazingly comprehensive writeup! Very well done. Do you intend on implementing a JIT or an optimizing compiler pass? I'd be interested in reading those posts if you eventually write them.
- tekknolagi 8y agoIf/when I get around to it, I would quite like to write posts like that. Also posts that address the ideas at the bottom of this post. Also posts that address some of the comments in this thread, like name resolution.
- bakery2k 8y agoIt's a really good article! Nothing too advanced, but concisely explains a lot of the basic concepts of both a compiler and an interpreter.
- atdt 8y agoGreat write-up, thank you! My one suggestion is that you drop the enum meta-programming; it is a distraction. Instead do what you yourself propose: use a simple class with int attributes.
- tekknolagi 8y agoYeah, that is probably the way to go. But you know how it is... I got sucked down a rabbit-hole while trying to figure out the best enum representation in Python.
- lozenge 8y agoFOO, BAR =range(2) if you're assuming python knowledge
- tekknolagi 8y agoWow, that's a pretty good one. Thank you!
- jfoutz 8y agoThis is super neat! i'd encourage anyone who liked this to check out dybvig's thesis[1] - super readable. It's neat to see how you can cleave the runtime system and compile time system. The first two chapters, at least, are pretty cool. [1] http://agl.cs.unm.edu/~williams/cs491/three-imp.pdf http://agl.cs.unm.edu/~williams/cs491/three-imp.pdf
- daxfohl 8y agoI haven't gotten through the whole thing yet but it looks great. The textbook I have now kinda stops at AST generation, so I was assuming the rest would be way more difficult than this. This makes it look manageable!
- rurban 8y agoIt's extremely primitive. Far better tutorials and bytecide designs exist, much better than those perl-, php-, python- alike bytecodes. Unfortunately only such primitive designs get written and used. SICP e.g. starts with this and then goes into its improvements, whilst better lisps or lua start with tighter opcode designs, and do proper closures and lambda lifting. python cannot even do proper lexical blocks/functions, the most important part of a interpreter/compiler design.
- abecedarius 8y agoPython has had lexical closures for many years. They're covered in my article on a bytecode compiler for Python (with code in Python): https://codewords.recurse.com/issues/seven/dragon-taming-with-tailbiter-a-bytecode-compiler https://codewords.recurse.com/issues/seven/dragon-taming-wit... It's true that Lisp is a simpler language and thus better for learning this with if you know it.
- Lerc 8y agoMay I ask how long it took you to write? Since this is the sort of post I like, I have taken to doing technical posts on a topic myself. The thing I have found is just how time consuming it is. Maybe I'm just slow at this.
- tekknolagi 8y agoI wrote it over the course of a three or four sittings, let it sit for a couple of days, then came back and revised it after sending the draft to several people. So in total a week or so?
- ris 8y agoFor part 2, try porting it to rpython and see how hard it is to turn it into a full JIT.