Initial support for wide arithmetic

[sbc100]

No interpreter support here so not enough execute the tests yet.

See https://github.com/WebAssembly/wide-arithmetic/blob/main/proposals/wide-arithmetic/Overview.md

[sbc100]

@alexcrichton did the other places you implemented this end up being this invasive (i.e. all the new plumbing needed for quaternary opcodes), or is there some way to avoid it maybe?

[alexcrichton]

Skimming over the diff here this doesn't seem entirely out of the ordinary too me (although I'm not expert in wabt's internal architecture). I've found that wide-arithmetic can land anywhere on the spectrum of easy-to-add to requires-large-refactors depending on how the wasm AST was represented previously. Not all designs lends themselves well to the addition of a new shape of instruction (many fixed inputs, multiple fixed outputs) and I think wabt is landing on the middle-end of this spectrum given its AST design.

As for avoiding it, that would either require adding a new type to the wasm type system for wide-arithmetic (e.g. i128) or more domain-specific knowledge of wabt than I have. Personally I still feel that i128 is the wrong way to go in terms of effort-vs-gain tradeoff, however.

[sbc100]

Skimming over the diff here this doesn't seem entirely out of the ordinary too me (although I'm not expert in wabt's internal architecture). I've found that wide-arithmetic can land anywhere on the spectrum of easy-to-add to requires-large-refactors depending on how the wasm AST was represented previously. Not all designs lends themselves well to the addition of a new shape of instruction (many fixed inputs, multiple fixed outputs) and I think wabt is landing on the middle-end of this spectrum given its AST design.

As for avoiding it, that would either require adding a new type to the wasm type system for wide-arithmetic (e.g. i128) or more domain-specific knowledge of wabt than I have. Personally I still feel that i128 is the wrong way to go in terms of effort-vs-gain tradeoff, however.

Good to hear.

This change wasn't actually too complex I think, considering that it includes the first instruction to return more than once thing and the fist to take 4 arguments.

[zherczeg]

It is true that the double result can be challenging for some implementations. But from wabt perspective (mostly parsing) this seems not that hard. Is there a large gain for doing BigInt arithmetic with this method instead of 32x32->64?

[alexcrichton]

There's some more info from the last update I gave to the CG (slides here) as well as the overview, but in general, yes, bigint arithmetic is more efficient with these instructions, measurably so relative to exclusively using 32-bit instructions.

[sbc100]

CC @ryandiazG

[sbc100]

@dschuff PTAL, I'd like to land this as-is, without the interpreter support initially.

[dschuff]

oops sorry I made a comment and didn't submit.

[dschuff]

I suppose this is technically a little weird since there could eventually be one that takes 4 and returns 1, and that would be the "real" Quaternary (making this one "Quaternery-binary" or something like that? Not sure if it matters right now though.

[sbc100]

Yes, for now Quaternary means exactly the signature we use for these new op-codes. They take 4 inputs and produce 2 outputs.

[dschuff]

Yeah, as long as if that happens we don't mind either just renaming this one or creating the new one with a slightly weird name, then this is fine with me.