-
Notifications
You must be signed in to change notification settings - Fork 43
Conversation
proposals/simd/NewOpcodes.md
Outdated
@@ -100,14 +112,26 @@ | |||
| i8x16.sub | 0x71 | i16x8.sub | 0x91 | i32x4.sub | 0xb1 | i64x2.sub | 0xd1 | | |||
| i8x16.sub_sat_s | 0x72 | i16x8.sub_sat_s | 0x92 | ---- sub_sat ---- | 0xb2 | ------------- | 0xd2 | | |||
| i8x16.sub_sat_u | 0x73 | i16x8.sub_sat_u | 0x93 | ---- sub_sat ---- | 0xb3 | ------------- | 0xd3 | | |||
| ------------- | 0x74 | ------------- | 0x94 | ------------- | 0xb4 | ------------- | 0xd4 | | |||
| | 0x74 | ------------- | 0x94 | ------------- | 0xb4 | ------------- | 0xd4 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spurious change from dashes to blank?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, fixed!
Why are |
IMO we should recycle at least the opcodes where the original reserved instruction is meaningless. E.g. |
@Maratyszcza I moved |
proposals/simd/BinarySIMD.md
Outdated
| `i64x2.le_s` | `0x106`| - | | ||
| `i64x2.ge_s` | `0x107`| - | | ||
| `i64x2.all_true` | `0xc3`| - | | ||
| `f64x2.convert_low_i32x4_s` | `0xfc`| - | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fc
and fd
are taken by v128.load32_zero
and v128.load64_zero
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching that!
Ok, I pushed a new version based on @ngzhian's suggestion and compacting more instructions into previous opcode holes. This version only uses opcodes up to 0xff, which will simplify V8 at least. The only block of instructions that really got scattered were the |
Amazing bin packing work Thomas, thanks! |
proposals/simd/BinarySIMD.md
Outdated
| `i64x2.extmul_high_i32x4_s` | `0xdd`| - | | ||
| `i64x2.extmul_low_i32x4_u` | `0xde`| - | | ||
| `i64x2.extmul_high_i32x4_u` | `0xdf`| - | | ||
| `i16x8.q15mulr_sat_s` | `0x9c`| - | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it is 0x82 (i16x8.extmul_low_i8x16_s uses 0x9c)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed.
TBH I don't remember. I must have thought at the time of the last renumbering that there would be just one floating point rounding instruction for each of f32x4 and f64x2. |
256 opcodes was indeed enough for anyone 🚀 |
Merging because there were no further comments on this at today's meeting. |
Opcodes were finalized in WebAssembly#452, this updates the interpreter and spec text to use these final opcodes.
See WebAssembly/simd#452 for finalized opcodes and WebAssembly/simd#467 for some renamings.
See WebAssembly/simd#452 for finalized opcodes and WebAssembly/simd#467 for some renamings.
See WebAssembly/simd#452 for finalized opcodes and WebAssembly/simd#467 for some renamings.
Opcodes were finalized in #452, this updates the interpreter and spec text to use these final opcodes.
See WebAssembly/simd#452 for finalized opcodes and WebAssembly/simd#467 for some renamings.
A draft numbering of the most recently added instructions. I tried to keep related instructions together, so there are still holes in the opcode space. I also could have more aggressively filled holes at the expense of destroying much of the internal structure of the opcode space. There are 236 instructions, so in principle we could fit them all below
0x100
, but it would be ugly. Comments welcome :)