regards,
Zsolt

“By the way, this picture gives an overview. (Picture does not exist yet.)”

Perhaps it could exist now?

* macros are used in superinstruction defs to mainly enable various kinds of code for different compilers, without stuffing all that into the forth compiler (utils/fc.py).

* the motivation for superinstructions is that when interpreting, CISC is better because it reduces dispatch overhead and does more work per instruciton, providing more context to the C++ compiler. All SM’s bytecodes are fat — what we’d call superinstructions in TT.

* the motivation for writing fat opcodes in Forth is that we can generate IL for them easily. we need the IL so we can both interpret and trace these fat opcodes. Tracing C++ means tracing x86 (or whatever) and makes it hard to recover important semantics required for optimization. (the same risk is present in forth — if it’s too low level we can boil away important semantics). its a balancing act.

* why forth? the IL is stack machine bytecode, forth is just a “source” dialect for stack machine code. an advantage of handwriting forth is easy factorability because functions do all their side effects on the stack. a disadvantage is obscurity …

* using stack machine IL is somewhat arbitrary. there is evidence that a virtual-register based IL (one-addr or two-addr encoding) would be a better fit. — we dont have to give up semantic richness to do this especially if treehydra is feasible.

> TT people often refer to their IL as “Forth” because they based the design on Forth or something

The IL is essentially a dialect of Forth. Nothing magic about Forth, it’s just a simple, small, portable language that’s easy to model and pretty close to a portable assembly language.

> Digging in to Tamarin. There doesn’t seem to be a lot of documentation on TT

Sadly, yes, this is the case. Efforts like this are highly welcomed. Mason Chang’s blog is also a good resource: http://masonchang.blogspot.com/

> Once the tracer kicks in, TT is running machine code traces (e.g. x86-64 ISA).

Actually, we don’t yet support x86-64, only x86-32, ARM, and Thumb. (x86-64 work is underway.)

> Tamarin IL is yet another stack-based bytecode

Technically, it’s not a “bytecode” because we’re currently using 16-bit opcodes…

> I think the weird stuff might be “superinstructions”, which are instructions that just implement a short sequence of basic instructions.
> Apparently they help interpreters run faster because by reducing decode overhead, like old CISC processors.

Exactly. Our Forth compiler (fc.py) tries to create superinstructions aggressively as it makes a huge difference in interpreter speed, doubling speed in a lot of cases. The faster the interpreter can run, the less agressively we have to create traces, which translates into less memory needed for traces. We’re not done yet in improving interpreter speed. There’s more work to be done here, as there’s no point in generating superinstructions for non-time-critical code (eg error handling), and conversely you want to be more aggressive in really hot spots… we need to add some profile-driven feedback to the Forth compiler to help it make those decisions; see https://bugzilla.mozilla.org/show_bug.cgi?id=432541 for more info.

> There’s also some junk about invalidating the box type, which seems to be some kind of debugging feature.

Bingo. Basically every Box is a tagged value, but there are times when we don’t bother updating the tag because we know it won’t be examined before it’s set again. Early in development this was the source of lots of heisenbugs, so in Debug builds we always update the tag, but sometimes to a value which generates assertions if you attempt to examine it.

> The “computed goto” at the end is an indirect jump to the case for the next instruction. This is some kind of optimization but I’ve
> never gotten a really convincing answer as to why it works, or if in fact it works, so I won’t go into it here.

It makes a huge difference in speed, something like 20% last I checked (try building both ways and run a performance test and you’ll see). Unfortunately, GCC is just about the only mainstream compiler that supports this feature (AFAIK). Why is it faster? Mainly because so many of our operations are small, so the overhead of dispatching is significant relative to the actual work being done. The code generated for a computed goto is often simpler/faster than for switch, and also performs better with branch prediction on modern processors.

> LBRT and LBRF (local branch if true/false?).

Actually, Long branch (32-bit offset) — there is also a BRF (16-bit offset).

> These opcodes don’t seem to be defined in the usual vm_*_interp.h, but somehow they are made to
> branch to foplabel_TRACE_super_or_extern in VMInterp.ii.

Actually, only in trace mode. What you have to keep in mind is that the interpreter has two distinct loops: do_interp(), which is used when simply interpreting a sequence of opcodes, and do_trace(), which is used when we decide that we are interpreting a “hot” section of code that might need to be jitted. do_trace() has to do considerable extra work, as it does everything that do_interp() does, PLUS build up a series of instructions to be JIT’ed. The reason for the branch to foplabel_TRACE_… is that the JIT only knows how to process the primitive set of Forth operations, so superinstructions are traced as the series of primitives they are composed of. (This is considerably slower, of course, but in do_trace() the time is completely dominated by work done by the JIT so this is generally lost in the noise.)