stackier VM #3

2026-08-30T02:16:36-06:00

msyds commented

2026-08-30 02:16:36 -06:00

this PR reorients the VM (and thus our planned Wasm execution model) around the stack.

procedures take their arguments from the stack

our previous VM model defined labels as taking a fixed list of arguments. while the previous model does mirror WebAssembly's functions, it does not mirror the way 계획 uses WebAssembly functions. upon this model it is much easier to implement varargs and kwargs.

stack is explicitly segmented into frames

throughout the entire compiler, we distinguish between λ-forms (user functions) and κ-forms (continuations), and it is the bytecode level where the distinction is most valuable. both forms receive arguments on the stack, but λ-forms introduce new stack frames, while κ-forms operate on the already-active frame. the result is a runtime with call stacks much resembling those produced by direct-style code.

my submission to the stack frame model is this PR's most important change, as i believe it will prove essential to implementing call/cc, lol. shouldn't be surprising! in fact, call/cc was this refactor's catalyst; for days i failed to conjure an implementation acceptable in aesthetics or robustness.

on push-calls

previously we imitated Hoot's pushing of live-out variables onto a stack. we're now just throwing everything on the stack lol. we will clean it up later.

closures

closures are now called directly by the VM's call instruction — one needn't explicitly retrieve the code pointer.

registers, labels

for (new)type-safety, Reg and Label have replaced appropriate occurrences of Name.

this PR reorients the VM (and thus our planned Wasm execution model) around the stack. ## procedures take their arguments from the stack our previous VM model defined labels as taking a fixed list of arguments. while the previous model does mirror WebAssembly's functions, it does not mirror the way 계획 uses WebAssembly functions. upon this model it is much easier to implement varargs and kwargs. ## stack is explicitly segmented into frames throughout the entire compiler, we distinguish between λ-forms (user functions) and κ-forms (continuations), and it is the bytecode level where the distinction is most valuable. both forms receive arguments on the stack, but λ-forms introduce new stack frames, while κ-forms operate on the already-active frame. the result is a runtime with call stacks much resembling those produced by direct-style code. my submission to the stack frame model is this PR's most important change, as i believe it will prove essential to implementing `call/cc`, lol. shouldn't be surprising! in fact, `call/cc` was this refactor's catalyst; for days i failed to conjure an implementation acceptable in aesthetics or robustness. ## on push-calls previously we imitated [Hoot's](https://wingolog.org/archives/2023/03/20/a-world-to-win-webassembly-for-the-rest-of-us) pushing of live-out variables onto a stack. we're now just throwing everything on the stack lol. we will clean it up later. ## closures closures are now called directly by the VM's `call` instruction — one needn't explicitly retrieve the code pointer. ## registers, labels for (new)type-safety, `Reg` and `Label` have replaced appropriate occurrences of `Name`.

msyds added 9 commits 2026-08-30 02:16:37 -06:00

wip: call/cc primitives 49292d5d01

wip: stack frames c0a44c89b4

new instrs, tail-call 9cb169f9b8

register & label newtypes 5ccb3f3e1a

return, pushcall

build / build (push) Failing after 1m23s

Details

e7c0ae9161

works albeit comically inefficiently a09c00badd

deconstruct closures only at the bytecode level 0df7280236

mark broken callcc tests 03797d573b