New opcode prefix for the relaxed-simd proposal?

[dtig]

Should relaxed-simd instructions move to use their own opcode prefix instead of reusing the one from the fixed-width SIMD proposal?

I suppose this was originally easier to use as some of the operations prototyped were a carryover from the previous SIMD proposal, but as we continue to add instructions I was hoping to hear from this group about preferences. Ideally, I would like to conform with the usual Wasm process of each proposal having its own prefix.

[lars-t-hansen]

I feel strongly that we should not add opcode prefixes "just because", and I think there should be a good justification for adding a new one. Prefixes are dear; we are going to run out, if we start using them for small tweaks such as Relaxed SIMD. I don't think it's true that each proposal has its own prefix, either - could you be more concrete about the sense in which this is the "usual process"? The reference types proposal, for example, uses a bunch of prefix-less opcodes. And I would expect that new few- or single-instruction proposals would reuse the Misc prefix (0xFC) rather than creating new prefixes.

[dtig]

Usual was probably not the right wording here, but my understanding was that post-MVP proposals, or groups of instructions that may not be commonly used should be assigned their own prefix I'm not sure why this was not the case for the reference type opcodes (perhaps someone who is aware of the history can comment?). I suppose in this case we could also continue to use the 0xfd prefix for the whole class of SIMD instructions.

The reason for filing this issue was that I find the current scheme for the relaxed instructions using the gaps in the older SIMD proposal not ideal, and I think we should have a more coordinated scheme for related groups of instructions even if they do share the same prefix. I expect we would come across this same issue for future slices of SIMD instructions. I wasn't able to find an explicit poll or discussion that already talked about this, or that the group had consensus on how we want the binary encoding to look in the future. I'm filing this here because I expect this is something we would want to resolve before the proposal is more baked in.

[lars-t-hansen]

I agree it's nice to keep opcodes together when we can so that a simple range check can be used to include/exclude a proposal. However, there's an almost limitless opcode space behind every prefix, and it's possible to allocate instructions for a proposal together in ranges of that space. The regular SIMD instructions fill the range up to 0xFD 0xFF (with 16 holes by my count). How about we instead use this scheme:

0xFD 0x00 - 0xFD 0xFF -- 128-bit SIMD MVP
0xFD 0x100 - 0xFD 0x17F -- relaxed 128-bit SIMD

... and so on, as need be, with the additional goal of keeping the encoding relatively compact. 128 entries is generous for relaxed SIMD and whether we need that much depends on whether somebody else feels that there needs to be some type of pattern to how the instructions are laid out; I don't care much about that, so reserving just 0x100 - 0x10F for the 13 new opcodes would be fine for me.

[dtig]

0xFD 0x100 - 0xFD 0x17F -- relaxed 128-bit SIMD

This encoding scheme sgtm.

[ngzhian]

Updated in https://github.com/WebAssembly/relaxed-simd/blob/main/proposals%2Frelaxed-simd%2FOverview.md#binary-format