about summary refs log tree commit diff
path: root/tvix/eval/src/disassembler.rs
diff options
context:
space:
mode:
authorVincent Ambo <mail@tazj.in>2022-08-26T23·16+0300
committertazjin <tazjin@tvl.su>2022-09-03T21·55+0000
commitf88d248f483af0cf1b83152367376b6b90893aac (patch)
treefc9c38978d8f261e195dde1c5995cbc031ee8f2f /tvix/eval/src/disassembler.rs
parent0f06d0ca333d879f914fb6f8e0803a9d5acd3d03 (diff)
feat(tvix/eval): implement runtime closure construction (OpClosure) r/4629
Implements the final bit of logic remaining for wiring up closures,
which is the runtime construction of closure objects.

When encountering an OpClosure, the VM walks through the bytecode
collecting all the upvalue location operands (see commit introducing
the OpCode::Data* variants for details) and stores the runtime values
in the new closures upvalue vector.

After that, the handling of the closure itself becomes functionally
identical to that of lambdas.

With this initial implementation of closures there are several large
optimisation potentials available, the two most notable ones are:

- Distinguish the runtime representation of lambdas and closures
  explicitly.

- Detect and handle multiple-arity functions directly in the compiler.

However, for both of these we should wait until we have appropriate
benchmarking infrastructure in place. This is because our test
implementations have shown that the complexity of either of these
changes is quite significant, and we do not yet know if they really
pay off.

Change-Id: I077e977810fd5cb2b1ecd7f1a119e728025dd786
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6295
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Diffstat (limited to 'tvix/eval/src/disassembler.rs')
0 files changed, 0 insertions, 0 deletions