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
{{ message }}
Repository navigation
Inconsistencies across multiple pages of instruction lists #2020
Hello, I'm beginning to study Wasm as a hobby. I think I've found some editorial bugs.
As a first step in learning, I wanted to know what kind of instructions Wasm has, so I searched and found wasm-ops. That chart was a great help, but I noticed it was a bit outdated, so I next tried to create a new chart.
Since I was at it, I thought I'd automate the table creation and started writing a script. But now, as a beginner, I'm a bit confused.
When I generated a table from the instruction list, I realized multiple name inconsistencies within the specification pages themselves.
I found such inconsistencies on (at least) three pages. I believe that each pages provide a comprehensive list of Wasm instructions.
1 contains instructions that end with {name}_{numtype}_{sx} (like i32.trunc_f32_u), but others contain {name}_{sx}_{numtype} (i32.trunc_u_f32) with the same {name}
2 says 0xBB is f32.promote_f64 but others say it's f64.promote_f32
[Update]2 and Text Format4 categorizes struct.*/array.* as "Reference Instructions," as the same as ref.*, but 3 categorizes them as a separate "Aggregate Instructions"
In addition, Validation5 categorizes them as "Aggregate Reference Instructions" (another different name)
However, I don't believe the above is complete. For example, there seem to be at least three other pages titled "Instructions,"564 but I haven't investigated those yet.
call_ref (and return_call_ref) missing from the binary format section are oversights. Will fix.
1 contains instructions that end with {name}_{numtype}_{sx} (like i32.trunc_f32_u), but others contain {name}_{sx}_{numtype} (i32.trunc_u_f32) with the same {name}
Yes, the naming inconsistency is a bug.
2 says 0xBB is f32.promote_f64 but others say it's f64.promote_f32
That also looks like a typo. It should certainly be f64.promote_f32.
[Update]2 and Text Format4 categorizes struct.*/array.* as "Reference Instructions," as the same as ref.*, but 3 categorizes them as a separate "Aggregate Instructions"
Yeah, not really a bug, just some (longer) chapters make a more fine-grained categorisation. I'll look into making this more uniform.
Most of the above should be fixed now, except for the naming inconsistencies in conversion instructions. These will be fixed automatically once we have ported the instruction index to SpecTec.
Thank you, I've confirmed all fixes but the naming inconsistencies.
As for SpecTec, I learned about it for the first time. (Shame on me, I hadn't read the PLDI paper) It sounds promising, so I'll wait for the fix with that.
Activity
rossberg commentedon Oct 27, 2025
Thanks for pointing out these bugs. Quick reply to some of your points:
That's actually correct, because
endis not an instruction in its own right, just an opcode that is part of another instruction (similarlyelse).call_ref(andreturn_call_ref) missing from the binary format section are oversights. Will fix.Yes, the naming inconsistency is a bug.
That also looks like a typo. It should certainly be f64.promote_f32.
Yeah, not really a bug, just some (longer) chapters make a more fine-grained categorisation. I'll look into making this more uniform.
rossberg commentedon Nov 2, 2025
Most of the above should be fixed now, except for the naming inconsistencies in conversion instructions. These will be fixed automatically once we have ported the instruction index to SpecTec.
tadd commentedon Nov 19, 2025
Thank you, I've confirmed all fixes but the naming inconsistencies.
As for SpecTec, I learned about it for the first time. (Shame on me, I hadn't read the PLDI paper) It sounds promising, so I'll wait for the fix with that.