design
design copied to clipboard
instruction encoding changes??
Hey
I'm changing a backend for a programming language theory course to target wasm/js
I'm currently writing the encoding part, and I noticed that for the conversion instruction specific they do not follow the convention of grouping by argument type but rather instruction type?
For all unop, binup, rel op and test op you can find the proper encoding by the form
encoding = base + operator offset
where the base are the first operator and the offset is simply the the nth operator in the category. an example in F#
type relop = Eq = 0 | Ne = 1 | LtS = 2 | LtU = 3 | GtS = 4 | GtU = 5 | LeS = 6 | LeU = 7 | GeS = 8 | GeU = 9
type instr = ... // all other operations
| Compare of relop
let encode = function
| compare op ->
match op with
| I32 op -> 0x46 + int op
| I64 op -> 0x51 + int op
| F32 op -> 0x5B + int op
| F64 op -> 0x61 + int op
It would lead to more efficient compilers since integer addition by a constant are inherently faster than a conditional jump.
It would impose a minor workload to change the compiler to reorder the conversion operations.
Is the suggestion to change the binary format? Unfortunately we have a rather strict backwards compatibility constraint: we can't make a change that would cause Wasm bytecode already deployed to the Web to no longer be correctly decoded.
The only way around this would be to increment the binary version number and require engines to decode both versions of binary format, which is a nuclear option we would only use if absolutely necessary. These kind of micro-optimisations for Wasm producers aren't particularly important to us, since the time taken to actually output the Wasm bytecode is normally massively eclipsed by other phases of compilation.
Yes it was, but also that in the future if you introduces more instructions make a grouping policy that would be nice.
Thanks for the comment.
We tried to maintain such regularity in the beginning, but as the language evolves, it is almost impossible to maintain it. Instruction sets tend to be much more irregular than one would like anyway. Just take a look at the SIMD proposal to see the full breadth of that. ;)
The question here appears answered; if there are any further questions; please file a new issue!