Wish the proportional variants were available for inspection somewhere (the web page or the specimen). I’ve been enjoying using another “designed for code” proportional font in emacs lately, and it’s really surprisingly good. The variable width makes it much more humane, but it’s not too variable, so it doesn’t look weird in a code buffer like, say, DejaVu Sans would.
Ta. I actually just went ahead and installed it to try it. On my (Windows) system it looks a lot more narrow than your sample, but I’m giving it a shot for today.
The problem is jq is becoming a standard and working its way into a bunch of mainline scripts. I wish someone would write a book on it. I can do simple queries but find some of the syntaxes to be impenetrable.
Wow great to see this! I remarked after one of the chapters in craftinginterpreters that I didn’t find a lot of literature on bytecode VMs.
There are a lot of books on compilers, but not as much for interpreters (i.e. the bytecode compiler + dynamic runtime combo that many languages use).
There are the Lua papers, a few blog posts about Python, some papers about the predecessor to OCaml, and craftinginterpreters, but not much else I could find. I found this book recently, but it’s not specifically about the compiler / VM:
Basically the idea is that Python has a “dumb” compiler and a very rich runtime. (This fact has been impressed upon me by hacking on its source code!). I want to make it have more of a smart compiler and small/dumb runtime.
One of the features of the T3X compiler is a portable bytecode interpreter. Here’s the source, I think you’ll like it: https://www.t3x.org/t3x/t.t.html
Abstract: A definitional interpreter should be clear and easy to write, but it may run 4–10 times slower than a well-crafted bytecode interpreter. In a case study focused on implementation choices, we explore ways of making definitional interpreters faster without expending much programming effort. We implement, in OCaml, interpreters based on three semantics for a simple subset of Lua. We compile the OCaml to x86 native code, and we systematically investigate hundreds of combinations of algorithms and data structures. In this experimental context, our fastest interpreters are based on natural semantics; good algorithms and data structures make them 2–3 times faster than interpreters. Our best interpreter, created using only modest effort, runs only times slower than a mature bytecode interpreter implemented in C.
Wow thanks! This is exactly the kind of thing I’m looking for.
For example, even the first sentence is somewhat new to me. Has anyone else made a claim about how much slower a tree interpreter (I assume that’s what they mean by definitional) is than a bytecode interpreter? I’ve never seen that.
I know that both Ruby and R switched from tree interpreters to bytecode VMs in the last 5-8 years or so, but I don’t recall what kind of speedup they got. That’s something to research (and would make a good blog post).
Anyway I will be reading this and following citations :-) I did find a nice paper on the design of bytecode VM instructions. Right now choosing instructions seems to be in the category of “folklore”. For example, there are plenty of explanations of Python’s bytecode, but no explanations of WHY they are as such. I think it was basically ad hoc evolution.
We present an extensive, annotated bibliography of the abstract machines designed for each of the main programming paradigms (imperative, object oriented, functional, logic and concurrent). We conclude that whilst a large number of efficient abstract machines have been designed for particular language implementations, relatively little work has been done to design abstract machines in a systematic fashion.
A good term to search for is “abstract machine” (rather than bytecode interpreter). The OCaml paper is called the “ZINC Abstract Machine” and it’s quite good.
There is a bunch of literature on stuff like the SECD machine, which is an abstract machine for Lisp, and which you can find real implementations for.
There seems to be less literature on stack / register bytecode interpreters. The Lua papers seem to be the best read in that area.
Wish the proportional variants were available for inspection somewhere (the web page or the specimen). I’ve been enjoying using another “designed for code” proportional font in emacs lately, and it’s really surprisingly good. The variable width makes it much more humane, but it’s not too variable, so it doesn’t look weird in a code buffer like, say, DejaVu Sans would.
Here’s a look: https://imgur.com/a/hSeO38h
Ta. I actually just went ahead and installed it to try it. On my (Windows) system it looks a lot more narrow than your sample, but I’m giving it a shot for today.
The proportional
llooks too thin to me. I use Dina because I need a pixel font for sharp renderingCompletely unrelated but this is a beautiful Emacs theme. It’s so hard to find a nice light-background one.
Looks like Solarized Light to me!
This is doom-one-light and it’s a great theme indeed. There’s also a dark variant.
jo is pretty rad, too. It handles creation of JSON much easier than jq.
Do you have any recommendations to do the reverse?
You want to destroy JSON?
This comment mentions
gron.Thanks!
The problem is jq is becoming a standard and working its way into a bunch of mainline scripts. I wish someone would write a book on it. I can do simple queries but find some of the syntaxes to be impenetrable.
https://stedolan.github.io/jq/manual/
Linking to the manual isn’t really helpful. Do you have other more insightful resources to offer?
None. But I found the manual to be excellent. There’s even examples for almost everything.
Wow great to see this! I remarked after one of the chapters in craftinginterpreters that I didn’t find a lot of literature on bytecode VMs.
There are a lot of books on compilers, but not as much for interpreters (i.e. the bytecode compiler + dynamic runtime combo that many languages use).
There are the Lua papers, a few blog posts about Python, some papers about the predecessor to OCaml, and craftinginterpreters, but not much else I could find. I found this book recently, but it’s not specifically about the compiler / VM:
http://patshaughnessy.net/ruby-under-a-microscope
Anyway I am glad to see another addition to this small space! :)
I’m hoping to find some time to really push into my compiler / VM project this winter: http://www.oilshell.org/blog/2018/03/04.html .
Basically the idea is that Python has a “dumb” compiler and a very rich runtime. (This fact has been impressed upon me by hacking on its source code!). I want to make it have more of a smart compiler and small/dumb runtime.
There’s also Nils M Holm’s books: http://t3x.org/
That’s just pure gold :O
Which parts discuss bytecode interpreters? I see a lot of different things there, including native code compilers, but no bytecode interpreters.
One of the features of the T3X compiler is a portable bytecode interpreter. Here’s the source, I think you’ll like it: https://www.t3x.org/t3x/t.t.html
Not a book, but you still might find this paper interesting: Engineering Definitional Interpreters:
Abstract: A definitional interpreter should be clear and easy to write, but it may run 4–10 times slower than a well-crafted bytecode interpreter. In a case study focused on implementation choices, we explore ways of making definitional interpreters faster without expending much programming effort. We implement, in OCaml, interpreters based on three semantics for a simple subset of Lua. We compile the OCaml to x86 native code, and we systematically investigate hundreds of combinations of algorithms and data structures. In this experimental context, our fastest interpreters are based on natural semantics; good algorithms and data structures make them 2–3 times faster than interpreters. Our best interpreter, created using only modest effort, runs only times slower than a mature bytecode interpreter implemented in C.
Wow thanks! This is exactly the kind of thing I’m looking for.
For example, even the first sentence is somewhat new to me. Has anyone else made a claim about how much slower a tree interpreter (I assume that’s what they mean by definitional) is than a bytecode interpreter? I’ve never seen that.
I know that both Ruby and R switched from tree interpreters to bytecode VMs in the last 5-8 years or so, but I don’t recall what kind of speedup they got. That’s something to research (and would make a good blog post).
Anyway I will be reading this and following citations :-) I did find a nice paper on the design of bytecode VM instructions. Right now choosing instructions seems to be in the category of “folklore”. For example, there are plenty of explanations of Python’s bytecode, but no explanations of WHY they are as such. I think it was basically ad hoc evolution.
Would mind sharing what that paper is? I’d love to read more about how to do this properly.
I’m pretty sure this is the one I was thinking of:
ABSTRACT MACHINES FOR PROGRAMMING LANGUAGE IMPLEMENTATION
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.68.234
We present an extensive, annotated bibliography of the abstract machines designed for each of the main programming paradigms (imperative, object oriented, functional, logic and concurrent). We conclude that whilst a large number of efficient abstract machines have been designed for particular language implementations, relatively little work has been done to design abstract machines in a systematic fashion.
A good term to search for is “abstract machine” (rather than bytecode interpreter). The OCaml paper is called the “ZINC Abstract Machine” and it’s quite good.
There is a bunch of literature on stuff like the SECD machine, which is an abstract machine for Lisp, and which you can find real implementations for.
There seems to be less literature on stack / register bytecode interpreters. The Lua papers seem to be the best read in that area.
This guy is asking a similar question: https://stackoverflow.com/questions/1142848/bytecode-design
This is great, thank you for sharing!