Update BinarySIMD.md #42
Conversation
Update opcodes to use hex values, and include reserved opcodes for integer min/max operations.
| | `i8x16.add_saturate_s` | `0x28`| - | | ||
| | `i8x16.add_saturate_u` | `0x29`| - | | ||
| | `i16x8.add_saturate_s` | `0x2a`| - | | ||
| | `i16x8.add_saturate_u` | `0x2b`| - | |
There was a problem hiding this comment.
Maybe reserve opcodes here as well?
There was a problem hiding this comment.
Can reserve, did you have something specific in mind to fill the space?
There was a problem hiding this comment.
I was thinking {i32x4,i64x2}.add_sat_{s,u} could logically go here, even if it could not be implemented reasonably today. My thinking is that we should reserve opcodes to be maximally future proof and ensure we have a nice layout no matter how hardware or our priorities change. But if there is no way we would ever want to add these ops, then reserving opcodes for them probably isn't necessary.
| | `i8x16.sub_saturate_s` | `0x2c`| - | | ||
| | `i8x16.sub_saturate_u` | `0x2d`| - | | ||
| | `i16x8.sub_saturate_s` | `0x2e`| - | | ||
| | `i16x8.sub_saturate_u` | `0x2f`| - | |
There was a problem hiding this comment.
{i32x4,i64x2}.sub_saturate_{s,u}
proposals/simd/BinarySIMD.md
Outdated
| | `i64x2.all_true` | `0x48`| - | | ||
| | `i8x16.eq` | `0x49`| - | | ||
| | `i16x8.eq` | `0x4a`| - | | ||
| | `i32x4.eq` | `0x4c`| - | |
There was a problem hiding this comment.
Looks like the hole is in the wrong place here.
| | `f32x4.abs` | `0x7f`| - | | ||
| | `f64x2.abs` | `0x80`| - | | ||
| | `f32x4.min` | `0x87`| - | | ||
| | `f64x2.min` | `0x88`| - | |
There was a problem hiding this comment.
This part of the opcode space is mostly float-only operations. Would it make sense to reserve opcodes for integer min/max elsewhere? It could be similar to add, sub, and mul. Alternatively, we could reorganize to put floating point arithmetic ops next to their integer counterparts.
There was a problem hiding this comment.
That makes sense, I mostly just ported an old pull request to the new space. I could go ahead and re-organize so the floating point arithmetic ops are next to the integer ones, or just move the sprinkled in Floating point ops to the end (which is somewhat consistent with other Wasm opcodes - the separation between integer/floating point opcodes). Alternatively I would prefer to order these according to type - mostly because some types have operations that are not supported on other types, and it makes the overall organization cleaner IMO. WDYT?
There was a problem hiding this comment.
Moving all fp ops to the end sounds good. I generally prefer ordering by operation over ordering by type, though.
There was a problem hiding this comment.
The MVP instructions are grouped first by what kind of instruction (unary, binary, conversion, etc.) then by type. It would be nice to do the same here, if we could.
|
Closing in favor of #48 |
Update opcodes to use hex values, and include reserved opcodes for integer min/max operations.