VM: (EXPERIMENTAL) Change to a capabilities-based system from feature flags. - #1148
Open
schungx wants to merge 6 commits into
Open
VM: (EXPERIMENTAL) Change to a capabilities-based system from feature flags.#1148schungx wants to merge 6 commits into
schungx wants to merge 6 commits into
Conversation
ImTheSquid
requested changes
Aug 21, 2026
| /// The script uses floating-point numbers, which are not available under `no_float`. | ||
| const FLOAT = 0b0000_0000_0000_0000_0001; | ||
| /// The script uses arrays, which are not available under `no_index`. | ||
| const ARRAY = 0b0000_0000_0000_0000_0010; |
Collaborator
There was a problem hiding this comment.
Bit of a nit but I think it's better to use 1 << N instead of writing out the entire binary number, it's hard to find the one here
| /// The script is built with `sync`. | ||
| const SYNC = 0b0100_0000_0000_0000_0000; | ||
| /// The script contains unsupported syntax. | ||
| const UNSUPPORTED = 0b1000_0000_0000_0000_0000; |
Collaborator
There was a problem hiding this comment.
I don't really see why this is necessary, the program can't be exported if it has unsupported items so this will never be written.
| const CUSTOM_SYNTAX = 0b0000_0010_0000_0000_0000; | ||
|
|
||
| /// The script is built with `sync`. | ||
| const SYNC = 0b0100_0000_0000_0000_0000; |
Collaborator
There was a problem hiding this comment.
This is more of a question, but what does sync change here? What capabilities does that restrict inside the binary?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is an experiment to replace the current feature flags-based fingerprint for artifacts with one based on the caps supported by a particular host build, as well as the caps required to run an artifact.
CapsThe
Capsbit-flags contains a bunch of capabilities for running an artifact inside the VM.Host Caps
Based on the build's feature flags, a set of caps for the host VM can be obtained (together with other info such as the width of integers and floats etc.).
Compilation
During compilation, when the compiler lowers from AST nodes, the caps are collected. In the end, there is a set of caps required for running that artifact, which is stored as a fingerprint together with the artifact.
Verification
The verifier supports caps as well. When an artifact is being verified, it goes through all the instructions and checks that they never require caps not available in the supported set.
Reading
Reading from a stored artifact compares the required caps (stored as fingerprint) with what the host supports. This is quite versatile.
For example, assume that an artifact is built without
no_index, but the script does not use any arrays or indexing. Then the artifact would not require theINDEXINGorARRAYcaps. Such an artifact can successfully run on a VM built withno_index. That's because, even though the host caps do not containINDEXINGnorARRAY, they are not needed to run the artifact and therefore the load is allowed to succeed.Safeguard
When the artifact is loaded, the verifying process checks the actual instruction caps with the stored fingerprint to make sure that nothing has been mucked with. That is to safeguard the situation that the fingerprint is manually edited afterwards to drop a necessary cap, which may result in errors when it is run on the VM.