-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lambda support in VM: Wolfgang's PR plus some simplifications (removing mask, clarifying ops) #15387
base: 11-21-lambda-compiler-completion
Are you sure you want to change the base?
Lambda support in VM: Wolfgang's PR plus some simplifications (removing mask, clarifying ops) #15387
Conversation
⏱️ 54m total CI duration on this PR
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
// Since bytecode version 8 | ||
LdFunction(_) => Opcodes::LD_FUNCTION, | ||
LdFunctionGeneric(_) => Opcodes::LD_FUNCTION_GENERIC, | ||
Invoke(_) => Opcodes::INVOKE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we want InvokeFunction, EarlyBindFunction for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Though I wonder if we should rename Call
as CallFunctionHandle
for similar consistency. :-)
42421fe
to
92ae56c
Compare
ebb0fcc
to
8154bb7
Compare
[move-vm] Types and opcodes for closures This PR implements the extensions needed in the file format for representing closures: - The type (SignatureToken) has a new variant `Function(args, result, abilities)` to represent a function type - The opcodes are extendeed by operations `ClosPack`, `ClosPackGeneric`, and `ClosEval` This supports bit masks for specifyinng which arguments of a function are captured when creating a closure. Bytecode verification is extended to support the new types and opcodes. The implementation of consistency, type, and reference safety should be complete. What is missing are: - File format serialization - Interpreter and value representation - Value serialization - Connection of the new types with the various other type representations
…rser work: - `LdFunction`, `LdFunctionGeneric` = generate a closure from a defined function - `EarlyBind` = bind more arguments to any closure - `Invoke` = call a closure with final arguments Add some description/semantics to `file_format.rs` to better describe the implementation which will be needed. Get rid of complex Mask calculations in favor of simpler early bninding of `k` initial arguments. Hopefully keep all bytecode verifier operations working the same.
…eFunction based on George's suggestion
92ae56c
to
3c02ba1
Compare
d52d75a
to
f49f228
Compare
Description
This PR started with a cherry-pick commit of Wolfgang's draft PR 15171 = commit #d85b919.
On top of that, I
not requiring a defined function handle except in
LdFunction[Generic]
.EarlyBind
andInvoke
because of the way the verifier works today.file_format.rs
which I'd worked out previously.The current operations are:
-
LdFunction
,LdFunctionGeneric
= generate a closure from a defined function-
EarlyBind
= bind more arguments to any closure-
Invoke
= call a closure with final argumentsAs noted by Wolfgang in his commit, we are still lacking:
How Has This Been Tested?
Barely tested, just running through existing tests
Key Areas to Review
Did I lose any verifier support when modfiying Wolfgang's opcodes?