←back to thread

170 points signa11 | 1 comments | | HN request time: 0.339s | source
1. o11c ◴[] No.41090139[source]
It's interesting how diametrically opposed this is to my recent explorations ... and yet, this is far better than most if only because it points out some of the decisions that would be bad (or at least could be done differently) in production.

I've ranted extensively [1] about how badly interpreters (among adjacent topics) are often taught, because so often decisions are just abruptly made without explanation of the reasoning (or, often, even that a decision is being made!).

One thing I just added was that there are (at least) 6 "arities" (which really should not be called that) of bytecode/IR:

* stack output, stack input, stack input - though often a few instructions do take arguments (push, jump)

* accumulator output/input, 1 explicit input (usually a local variable or constant)

* belt output, belt input, 1 explicit input. The first argument is always the output of the previous instruction; the explicit argument (if not a constant) specifies the output of some previous instruction. Backwards jumps will require storing many variables to a prior part of the belt, but this is simple and useful for mini expression evaluators.

* explicit output/input, explicit input - common for machine code

* explicit output, explicit input, explicit input - common for machine code

* implicit output, explicit input, explicit input - an easy way to save space for SSA (though you can also use it with mutability), though there's weirdness for phis.

[1]: https://gist.github.com/o11c/6b08643335388bbab0228db763f9921...