MoarVM Intepreter

Ops and Op Banks

The interpreter first dispatches on op bank, then on the code within that. For the core and primitive operations, that is done through a switch that is inlined directly inside of the interpreter.

The list of ops is held in src/core/oplist. This is processed by the tools/update_ops_h.p6 tool to generate src/core/ops.h and ops.c, which contain all of the metadata about the operations and operation banks.

Nested Runloops - Just Say No

There is no notion of “nested runloop”; any call into C land that wants to call back into the interpreter must persist enough information to allow it to continue its work later. It does this by saving that info into a frame and specifying a callback to resume the work. In essence, it needs to be written out as a state machine. That state machine will be called back into when a C frame is returned to. This is not particularly fun. Nested runloops and continuation barrier issues are even less fun, though.