Nicer bytecode

[icefoxen]

parity_wasm::elements::Opcode is a very literal translation of the serialized wasm. As such, there's a few things about it that take more work to interpret than they should. If we were to make a nicer bytecode, things we would want are:

• block, if/else etc. instructions to include the indices of their exit points (the matching end instruction) so we don't have to find the bloody thing
• fnn.const instructions to contain f32/64 instead of u32/64 so we don't have to convert them (and can check for signaling NaN's once when the bytecode is generated, not every time we execute them -- or, as currently happens, not at all)

[pepyakin]

Re (1): Yep, and you can probably throw out and don't execute all these block/loop/end opcodes.

Also, you can introduce your own opcodes, for example see wabt's alloca
https://github.com/WebAssembly/wabt/blob/8bcd84f39737a8f26da1dec33a80da7c7ee4e390/src/interp.cc#L2273

[icefoxen]

Hey, what are you doing here? You already have one interpreter to write! :-P

I'm used to HLL compilers/interpreters, so I was thinking of this basically in terms of translating to a (slightly less abstract) AST and interpreting that. I might skip it entirely if I decide to go the JIT route, I dunno.

I don't really want to add my own opcodes, at least not yet; I'm not convinced that WebAssembly's feature testing approach is actually sane and don't want to go nuts on extensions without a good way to define/distinguish them.

[pepyakin]

Hey, what are you doing here? You already have one interpreter to write! :-P

I need moar interpreters to write : D

I don't really want to add my own opcodes, at least not yet

Oops, I should have to be more clear: by "own opcodes" I mean opcodes that are used only at interpretation time and any module that contain any of these should fail validation.

[icefoxen]

Oh, that makes more sense. I guess I mean more "intermediate representation", in the compiler sense, than "abstract syntax tree".