Is the move binary spec still up to date?

Hi,

Is the VM spec defined here: move/vm.md at main · move-language/move · GitHub still valid?
I’m currently running into issues when trying to parse the STRUCT_HANDLES table.

Sam states in this post (Tips for writing bytecode -> <something> or <something> -> bytecode tools for Move · Issue #817 · move-language/move · GitHub) that the spec might not be up to date and im not sure which part exactly.
If it’s not updated; any chance that’s doable within the next weeks?

Many thanks!

14 Likes

The StructHandle definition seems indeed to be outdated.
nominal resource is an Ability-Flag and the type_parameters is a struct (AbilitySet + bool) instead of a plain enum.

6 Likes

Hi @danielmoos out of date docs in Move are indeed a known issue. Apologies for the inconvenience. Please help keep us accountable by filing a Github issue on this.

5 Likes

Hi Daniel, file_format.rs is indeed your safest bet in terms of finding up-to-date information on the bytecode format at this point. Happy to answer any questions you have about file format or verifier behavior if it helps.

4 Likes

Hey Ade,
Hey Sam,

Thank you for the swift reply!
I’ll make sure to collect a list of diffs between the spec and the actual file_format.rs once I’m done with the things on my side.

Is there any documentation around how the VM works in detail? I do have a basic understanding of ASM so it’s not total gibberish to me but some more information surely would help.

I’ve also seen that FunctionHandle does also make use of the AbilitySet flag (instead of the TypeParameterKind enum). Is there a reason to wrap the u8 in a vector instead of just leaving the flag as a single byte? (according to the spec, the old implementation was not using a flag - thus the vector made kinda sense).

pub struct FunctionHandle {
    /// The module that defines the function.
    pub module: ModuleHandleIndex,
    /// The name of the function.
    pub name: IdentifierIndex,
    /// The list of arguments to the function.
    pub parameters: SignatureIndex,
    /// The list of return types.
    pub return_: SignatureIndex,
    /// The type formals (identified by their index into the vec) and their constraints
    pub type_parameters: Vec<AbilitySet>,
}
2 Likes

Hi @danielmoos,

I apologize as I’m not entirely sure I understand the question, but what I think you are asking is just in general to explain pub type_parameters: Vec<AbilitySet>?

Move functions can take a (possibly empty) list of type parameters. Those type parameters can be constrained, restricting the possible types that can be used as arguments to that parameter. In other words, in order to be a valid type argument, the type must satisfy the constraint specified. Currently, the only constraints allowed are ability constraints (though we might add some non-ability related constraints in the future). So today, in the type parameter can specify some set of abilities that the type argument must have. That type argument could have more abilities than those specified, but it must have at least those.

Putting this all together, pub type_parameters: Vec<AbilitySet>, declares both how many type parameters the function has, and what the constraints are for those type parameters. The type parameters are then identified by their index into this vector.

3 Likes

Hey @tnowacki
Got it!
For some reason I thought that a FunctionHandle is restricted to have at max one TypeParameter.

Appreciate the explanation.

Best,
Daniel

E: regarding my comment above in terms for documentation how the different bytecodes are processed by the VM: Just found the comments for them in the file_format.rs which should be sufficient for now

2 Likes

Question: Will we see MetaData table in SUI byte-code?

If so, can I presume the key and value vectors are uleb128 count followed by bytes? And, will there be indication of what type(s) the keys and values are?

Regards

1 Like