-
Notifications
You must be signed in to change notification settings - Fork 459
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
[interpreter] Section payload size is inefficiently encoded #625
Comments
This was a conscious implementation choice. The binary format is intentionally defined to allow padding, since this enables backpatching, which is not just used by the interpreter but by most other generators as well, as far as I'm aware. One could optimise this with sufficient work, but both encodings are correct. There are only a few sections in a binary, so a couple of extra bytes for each are usually in the noise. |
I agree that this is legal according to the spec, but I'd be hesitant to assume that most other generators use padding here. A generator that does enough staging in RAM (like mine) can use efficient encoding. This actually threw me off during development because my sizes came out smaller when round-tripping 3rd party WASMs. |
Also, in the specification
So the implementation should correctly patch and output |
@RyanLamansky, at least the ones I am aware of do (or did). @tharvik, I agree that the text you cite is somewhat inaccurate, which is why that formulation is avoided in the actual specification. |
In binary, the section payload size is inefficiently encoded.
It is generated by the
binary/encode.ml
, the output is still correctly loadedby
binary/decode.ml
but defy the purpose of using a compact representation forthe
Section
payload size.A payload size is a
varuint7
, the upper byte set indicate a next block to readin stream. For the problem at hand, it would be decoded so
[0x84 0x80 0x80 0x80 0x00] fold ((a,b) => a | ((b & 0x7F) << 7))
which equals 4.
The correct (or smallest)
varuint7
encoding would be directly0x04
.Example text format
Hex stream
Header
type
00 61 73 6D
uint8
\0asm
01 00 00 00
uint8
Sections
type
01
varuint7
84 80 80 80 00
/04
varuint7
Type
type
01
varuint32
Func Type
type
60
varint7
00
varuint
00
varuint
The text was updated successfully, but these errors were encountered: