You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, dyncall instruction translates into two operations in the VM: call dyn. This works mostly fine, but it does result in caller instruction returning an unintuitive (and probably wrong) value.
Specifically, the caller instruction should return the MAST root of the context we are currently in. So, if we do something like:
proc.foo
caller
# => [MAST_ROOT_OF_FOO, ...]
end
begin
call.foo
end
But, if we use dyncall instruction, the result will be different:
proc.foo
caller
# => [HASH_DYN_NODE, ...]
end
begin
procref.foo
dyncall
end
This is because when we execute the call instruction, we set the MAST root of the new context to the hash of the callee. In case of dyncall, the callee is just a single dyn node - so, that's what gets used to set the MAST root.
Off the top of my head, there are two ways to fix this:
Update the semantics of the call operation to check if the next operation is dyn, and if so, use the top of the stack to set the MAST root. This may result in pretty complicated constraints - so, not sure if it will be worth it.
Introduce a new dedicate operation for dyncall. This will behave basically like call operation except it will use the top of the stack to set the MAST root of the context. I think dyncall will need to be a "very high degree" operation, and so we can do this only after we free up one of such operation slots (i.e., after #1457).
The text was updated successfully, but these errors were encountered:
Currently,
dyncall
instruction translates into two operations in the VM:call dyn
. This works mostly fine, but it does result incaller
instruction returning an unintuitive (and probably wrong) value.Specifically, the
caller
instruction should return the MAST root of the context we are currently in. So, if we do something like:But, if we use
dyncall
instruction, the result will be different:This is because when we execute the
call
instruction, we set the MAST root of the new context to the hash of the callee. In case ofdyncall
, the callee is just a singledyn
node - so, that's what gets used to set the MAST root.Off the top of my head, there are two ways to fix this:
call
operation to check if the next operation isdyn
, and if so, use the top of the stack to set the MAST root. This may result in pretty complicated constraints - so, not sure if it will be worth it.dyncall
. This will behave basically likecall
operation except it will use the top of the stack to set the MAST root of the context. I thinkdyncall
will need to be a "very high degree" operation, and so we can do this only after we free up one of such operation slots (i.e., after #1457).The text was updated successfully, but these errors were encountered: