Support WebAssembly Core Specification 2.0

[codefromthecrypt]

Right now, we support WebAssembly Core Specification 1.0 and a few features that were marked finished, but not in a spec yet. While not recommendation phase, yet, there is a draft for 2.0 which helps us group which features will be in it. I think we can assume no more or less features will end up in that version.

https://www.w3.org/TR/2022/WD-wasm-core-2-20220419/appendix/changes.html#release-1-1

Change	Status	Feature Proposal
Sign extension instructions	✅	sign-extension-ops
Non-trapping float-to-int conversions	✅	nontrapping-float-to-int-conversions
Multiple values	✅	multi-value
Reference types	✅	reference-types
Table instructions	✅	reference-types
Multiple tables	✅	reference-types
Bulk memory and table instructions	✅	bulk-memory-operations
Vector instructions	✅	simd

[codefromthecrypt]

PS if anyone needs 2.0, please comment what tools you are using that target 2.0 and what use case and priority (timeline) it is for you. If you can workaround meanwhile with one of the features (as opposed to all of them), please note that too!

[codefromthecrypt]

ok revised the description

[codefromthecrypt]

TL;DR: we audited the new value types: externref and i128 and decided to continue use of encoding any and all value types as uint64 (for the purpose of api.Function.Call).

This means anyone invoking an exported function that has a vector ops parameter (i128) needs to split the 128bit vector (ex. i32x4) into two 64bit vectors (ex. 32x4[0,1], i32x4[2,3]). Based on research, we think this is an edge case and can help anyone with this if they ask.

---

We had lots of chats over the last couple days on how to handle the value types added to WebAssembly 2.0. The concern is the host function boundaries, and that can be split into two

• define host function: How to declare parameters for host functions using new value types
• call function: How to call exported functions whose signature includes new value types.

The new types are:

• externref which is a possibly nil opaque reference to a host pointer. In go, 64 bits should work.
• I128 currently only used for vectors (ex. v128.const) which are N (possibly 1) values packed into 128 bits. Ex. i32x4.

The biggest deal here is how important the i128bit type is to be represented as a single unit in our exported API, as opposed to split into two uint64s, representing the high and low 64bits. Remember for this discussion, the only use of this in WebAssembly 2.0 is vector instructions. There are no other proposals included in WebAssembly 2.0 that would use these.

The first question: is this a problem internally?, and it isn't. Function types are knowable before use, so it is not difficult to track how many units of 64bits should be pushed or popped from a stack. We also don't forsee any problem in JIT accessing these values.

Next, should we define host function type parameter binding for an i128? Remember this is as opposed to func hostFunc(vectorHi, vectorLo uint64) which is awkward.. Should we allow the same inbound as a single parameter, ex vector []byte or vector [16]byte? Do we have to decide this now, knowing the only use is vector ops? The decision made here is to defer it until a user asks concretely for code that uses vector ops and needs to be written as a host function. We feel changing the parser later can be done compatibly anyway and solving this in a use-case bound way is better than guessing.

Finally, and the biggest decision is do we break the function call API over this? It currently uses exclusively uint64 for parameter and return type. Ex. Call(ctx context.Context, params ...uint64) ([]uint64, error). It would be confusing to pass a different number of values than the signature suggests (in order to materialize one parameter as a 128bit vector). Similar to the host function definition problem, we also think that in the context of 2.0, where only vector types use 128-bit values, this can be punted. Meanwhile we can instruct with docs or an API how to construct 2 units give 128bits. Again similar to the problem described in the above paragraph, we don't know how a user would choose to represent the 128-bit value until they do, and they might have chosen to represent it as two uint64 anyway!

Moreover, we expect to eventually make a codegen solution for function call binding. In that case there are even less cause for concern about this as only generated code would deal with invoking "Call". However, we still need to learn if anyone would ever use i128bit for vector ops outside wasm (in a host function), and guessing ahead of time would result in tech debt.

[mathetake]

ok now the left is SMID proposal impl! 👯

[mathetake]

#644 completes arm64 backend for SIMD, therefore closing this long-standing issue!