Goals

• New Wasmi bytecode encodes immediates inline and no longer requires function local constants.
• New Wasmi bytecode is optimized towards direct threaded code with pointer sized op-code "tags".

Currently Wasmi bytecode is organized in 64-bit sized Instructions.

The advantage of this design is that Instruction is pointer sized on common 64-bit systems which has positive performance effects.
However, in a recent experiment, bloating Instruction to 128-bit we could not see significant translation or execution performance regressions. Therefore, it makes sense to further experiment with what is possible with 128-bit Instructions.

Ideally, we could use 128-bit Instructions to get rid of function local constants in Wasmi entirely since they allow encoding 64-bit immediate operands inline since 14 bytes are available to operands per Instruction (2 bytes for the tag). With 64-bit Instructions only 6 byte were available - not enough to encode 64-bit immediate operands.

This has a huge potential and could also speed-up Wasmi's execution performance and memory footprint during execution. On the one handside a function's Instruction sequence becomes roughly twice as large, but on the contrary we no longer have to keep function local constants around.

An experiment conducted on spidermonkey.wasm's (func 0) we found that over 95% of all stack slots are reserved for function local constants which is extremely wasteful. The reason is that so many instructions only allow for 16-bit immediate operands. With the 128-bit design we could potentially reduce this number to 0 and end up with 20 times less memory footprint per call frame on the call stack in these cases.

This issue tracks progress on the matter.