File: interpreter.markdown

package info (click to toggle)
moarvm 2024.09%2Bdfsg-5
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 43,548 kB
  • sloc: cpp: 378,682; ansic: 293,618; perl: 8,274; java: 2,682; python: 1,296; makefile: 816; sh: 292
file content (19 lines) | stat: -rw-r--r-- 993 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 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.raku 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.