2022-08-07 22:40:29 +02:00
|
|
|
//! This module implements the instruction set running on the abstract
|
|
|
|
//! machine implemented by tvix.
|
|
|
|
|
2022-08-26 19:48:39 +02:00
|
|
|
/// Index of a constant in the current code chunk.
|
2022-08-26 19:46:43 +02:00
|
|
|
#[repr(transparent)]
|
2022-08-07 22:40:29 +02:00
|
|
|
#[derive(Clone, Copy, Debug)]
|
|
|
|
pub struct ConstantIdx(pub usize);
|
|
|
|
|
2022-08-26 19:48:39 +02:00
|
|
|
/// Index of an instruction in the current code chunk.
|
2022-08-26 19:46:43 +02:00
|
|
|
#[repr(transparent)]
|
2022-08-07 22:40:29 +02:00
|
|
|
#[derive(Clone, Copy, Debug)]
|
|
|
|
pub struct CodeIdx(pub usize);
|
|
|
|
|
2022-08-26 19:54:39 +02:00
|
|
|
/// Index of a value in the runtime stack.
|
|
|
|
#[repr(transparent)]
|
2022-09-03 02:06:20 +02:00
|
|
|
#[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd)]
|
2022-08-26 19:54:39 +02:00
|
|
|
pub struct StackIdx(pub usize);
|
|
|
|
|
2022-08-26 20:48:51 +02:00
|
|
|
/// Index of an upvalue within a closure's upvalue list.
|
|
|
|
#[repr(transparent)]
|
2022-08-31 03:56:02 +02:00
|
|
|
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
|
2022-08-26 20:48:51 +02:00
|
|
|
pub struct UpvalueIdx(pub usize);
|
|
|
|
|
2022-08-26 19:48:39 +02:00
|
|
|
/// Offset by which an instruction pointer should change in a jump.
|
2022-08-26 19:46:43 +02:00
|
|
|
#[repr(transparent)]
|
|
|
|
#[derive(Clone, Copy, Debug)]
|
|
|
|
pub struct JumpOffset(pub usize);
|
|
|
|
|
2022-08-26 19:58:18 +02:00
|
|
|
/// Provided count for an instruction (could represent e.g. a number
|
|
|
|
/// of elements).
|
|
|
|
#[repr(transparent)]
|
|
|
|
#[derive(Clone, Copy, Debug)]
|
|
|
|
pub struct Count(pub usize);
|
|
|
|
|
2022-08-12 16:19:14 +02:00
|
|
|
#[warn(variant_size_differences)]
|
2022-08-07 22:40:29 +02:00
|
|
|
#[derive(Clone, Copy, Debug)]
|
|
|
|
pub enum OpCode {
|
|
|
|
// Push a constant onto the stack.
|
|
|
|
OpConstant(ConstantIdx),
|
|
|
|
|
2022-08-11 12:12:07 +02:00
|
|
|
// Discard a value from the stack.
|
|
|
|
OpPop,
|
|
|
|
|
2022-08-07 22:40:29 +02:00
|
|
|
// Push a literal value.
|
|
|
|
OpNull,
|
|
|
|
OpTrue,
|
|
|
|
OpFalse,
|
2022-08-08 01:16:28 +02:00
|
|
|
|
2022-08-08 01:51:28 +02:00
|
|
|
// Unary operators
|
|
|
|
OpInvert,
|
|
|
|
OpNegate,
|
|
|
|
|
2022-08-08 01:32:07 +02:00
|
|
|
// Arithmetic binary operators
|
2022-08-08 01:16:28 +02:00
|
|
|
OpAdd,
|
|
|
|
OpSub,
|
|
|
|
OpMul,
|
|
|
|
OpDiv,
|
2022-08-08 01:32:07 +02:00
|
|
|
|
2022-08-11 12:12:07 +02:00
|
|
|
// Comparison operators
|
2022-08-08 01:51:28 +02:00
|
|
|
OpEqual,
|
2022-08-11 10:37:04 +02:00
|
|
|
OpLess,
|
|
|
|
OpLessOrEq,
|
|
|
|
OpMore,
|
|
|
|
OpMoreOrEq,
|
2022-08-09 15:53:09 +02:00
|
|
|
|
2022-08-11 12:12:07 +02:00
|
|
|
// Logical operators & generic jumps
|
2022-08-26 19:46:43 +02:00
|
|
|
OpJump(JumpOffset),
|
|
|
|
OpJumpIfTrue(JumpOffset),
|
|
|
|
OpJumpIfFalse(JumpOffset),
|
|
|
|
OpJumpIfNotFound(JumpOffset),
|
2022-08-11 12:12:07 +02:00
|
|
|
|
2022-08-09 15:53:09 +02:00
|
|
|
// Attribute sets
|
2022-08-26 19:58:18 +02:00
|
|
|
OpAttrs(Count),
|
|
|
|
OpAttrPath(Count),
|
2022-08-10 20:01:15 +02:00
|
|
|
OpAttrsUpdate,
|
2022-08-11 14:29:11 +02:00
|
|
|
OpAttrsSelect,
|
2022-08-26 17:40:55 +02:00
|
|
|
OpAttrsTrySelect,
|
2022-08-11 16:06:23 +02:00
|
|
|
OpAttrsIsSet,
|
2022-08-09 16:11:02 +02:00
|
|
|
|
2022-08-14 23:13:57 +02:00
|
|
|
// `with`-handling
|
2022-08-26 19:54:39 +02:00
|
|
|
OpPushWith(StackIdx),
|
2022-08-14 23:38:30 +02:00
|
|
|
OpPopWith,
|
2022-08-15 00:13:17 +02:00
|
|
|
OpResolveWith,
|
fix(tvix/eval): correctly thread through dynamic upvalues
This puts together the puzzle pieces for threading dynamic
upvalues (that is, upvalues resolved from the `with`-stack) all the
way through.
Reading the test case enclosed in this commit and walking through it
is recommended to understand what problem is being tackled here.
In short, because the compiler can not statically know *which*
with-scope a dynamic argument is resolved from it needs to lay the
groundwork for resolving from *all* possible scopes.
There are multiple different approaches to doing this. The approach
chosen in this commit is that if a dynamic upvalue is detected, the
compiler will emit instructions to close over this dynamic value
in *all* enclosing lambda contexts.
It uses a new instruction for this that will leave around a sentinel
value in case an identifier could not be resolved, and wire the
location of this found value (or sentinel) up through the upvalues to
the next level of nesting.
In this tradeoff, tvix potentially closes over more upvalues than are
needed (but in practice, how often do people create *really* deep
`with`-stacks? and in *this* kind of code situation? maybe we should
even warn for this!) but avoids keeping the entire attribute sets
themselves around.
Looking at the test case, each surrounding closure will close
over *all* dynamic identifiers that are referenced later on visible to
it, but only the last one for each identifier will actually end up
being used.
This also covers our bases for an additional edge-case this creates,
in which an identifier potentially resolves to a dynamic upvalue *and*
to a dynamic value within the function's own scope (again, would
anyone really do this?) by introducing a resolution instruction for
that particular case.
There is likely some potential for cleaning up this code which is
quite ugly in some parts, but as this implementation is now carefully
calibrated to work I decided it is time to commit it and clean it up
in subsequent commits.
Change-Id: Ib701e3e6da39bd2c95938d1384036ff4f9fb3749
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6322
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
2022-08-28 02:45:45 +02:00
|
|
|
OpResolveWithOrUpvalue(UpvalueIdx),
|
2022-08-14 23:13:57 +02:00
|
|
|
|
2022-08-09 16:11:02 +02:00
|
|
|
// Lists
|
2022-08-26 19:58:18 +02:00
|
|
|
OpList(Count),
|
2022-08-11 10:50:38 +02:00
|
|
|
OpConcat,
|
2022-08-09 16:44:34 +02:00
|
|
|
|
|
|
|
// Strings
|
2022-08-26 19:58:18 +02:00
|
|
|
OpInterpolate(Count),
|
2022-08-11 13:56:27 +02:00
|
|
|
|
|
|
|
// Type assertion operators
|
|
|
|
OpAssertBool,
|
2022-08-13 16:34:20 +02:00
|
|
|
|
2022-08-13 19:17:25 +02:00
|
|
|
// Access local identifiers with statically known positions.
|
2022-08-26 19:54:39 +02:00
|
|
|
OpGetLocal(StackIdx),
|
2022-08-13 19:17:25 +02:00
|
|
|
|
2022-08-13 16:34:20 +02:00
|
|
|
// Close scopes while leaving their expression value around.
|
2022-08-26 19:58:18 +02:00
|
|
|
OpCloseScope(Count), // number of locals to pop
|
2022-08-16 14:53:35 +02:00
|
|
|
|
|
|
|
// Asserts stack top is a boolean, and true.
|
|
|
|
OpAssert,
|
2022-08-24 01:26:58 +02:00
|
|
|
|
2022-08-26 23:21:08 +02:00
|
|
|
// Lambdas & closures
|
2022-08-24 01:26:58 +02:00
|
|
|
OpCall,
|
2022-09-04 22:16:59 +02:00
|
|
|
OpTailCall,
|
2022-08-26 20:48:51 +02:00
|
|
|
OpGetUpvalue(UpvalueIdx),
|
2022-08-26 23:21:08 +02:00
|
|
|
OpClosure(ConstantIdx),
|
|
|
|
|
2022-08-28 22:53:20 +02:00
|
|
|
// Thunks
|
|
|
|
OpThunk(ConstantIdx),
|
2022-08-29 17:33:02 +02:00
|
|
|
OpForce,
|
2022-08-28 22:53:20 +02:00
|
|
|
|
2022-08-28 16:28:20 +02:00
|
|
|
/// Finalise initialisation of the upvalues of the value in the
|
|
|
|
/// given stack index after the scope is fully bound.
|
|
|
|
OpFinalise(StackIdx),
|
|
|
|
|
2022-08-26 23:21:08 +02:00
|
|
|
// The closure and thunk creation instructions have a variable
|
|
|
|
// number of arguments to the instruction, which is represented
|
|
|
|
// here by making their data part of the opcodes.
|
|
|
|
//
|
|
|
|
// The VM skips over these by advancing the instruction pointer
|
|
|
|
// according to the count.
|
|
|
|
DataLocalIdx(StackIdx),
|
2022-08-28 15:50:46 +02:00
|
|
|
DataDeferredLocal(StackIdx),
|
2022-08-26 23:21:08 +02:00
|
|
|
DataUpvalueIdx(UpvalueIdx),
|
2022-08-27 02:31:28 +02:00
|
|
|
DataDynamicIdx(ConstantIdx),
|
fix(tvix/eval): correctly thread through dynamic upvalues
This puts together the puzzle pieces for threading dynamic
upvalues (that is, upvalues resolved from the `with`-stack) all the
way through.
Reading the test case enclosed in this commit and walking through it
is recommended to understand what problem is being tackled here.
In short, because the compiler can not statically know *which*
with-scope a dynamic argument is resolved from it needs to lay the
groundwork for resolving from *all* possible scopes.
There are multiple different approaches to doing this. The approach
chosen in this commit is that if a dynamic upvalue is detected, the
compiler will emit instructions to close over this dynamic value
in *all* enclosing lambda contexts.
It uses a new instruction for this that will leave around a sentinel
value in case an identifier could not be resolved, and wire the
location of this found value (or sentinel) up through the upvalues to
the next level of nesting.
In this tradeoff, tvix potentially closes over more upvalues than are
needed (but in practice, how often do people create *really* deep
`with`-stacks? and in *this* kind of code situation? maybe we should
even warn for this!) but avoids keeping the entire attribute sets
themselves around.
Looking at the test case, each surrounding closure will close
over *all* dynamic identifiers that are referenced later on visible to
it, but only the last one for each identifier will actually end up
being used.
This also covers our bases for an additional edge-case this creates,
in which an identifier potentially resolves to a dynamic upvalue *and*
to a dynamic value within the function's own scope (again, would
anyone really do this?) by introducing a resolution instruction for
that particular case.
There is likely some potential for cleaning up this code which is
quite ugly in some parts, but as this implementation is now carefully
calibrated to work I decided it is time to commit it and clean it up
in subsequent commits.
Change-Id: Ib701e3e6da39bd2c95938d1384036ff4f9fb3749
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6322
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
2022-08-28 02:45:45 +02:00
|
|
|
DataDynamicAncestor(UpvalueIdx),
|
2022-08-07 22:40:29 +02:00
|
|
|
}
|