Skip to content
This repository has been archived by the owner on Dec 22, 2021. It is now read-only.

Final opcodes #452

Merged
merged 6 commits into from Feb 19, 2021
Merged

Final opcodes #452

merged 6 commits into from Feb 19, 2021

Conversation

tlively
Copy link
Member

@tlively tlively commented Feb 6, 2021

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 :)

@@ -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 |
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, fixed!

@Maratyszcza
Copy link
Contributor

Why are 0xe2 and 0xee reserved for round?

@Maratyszcza
Copy link
Contributor

Maratyszcza commented Feb 8, 2021

IMO we should recycle at least the opcodes where the original reserved instruction is meaningless. E.g. 0x67-0x6a opcodes are meaningless for widen instructions. Also, AFAICT it is missing v128.any_true.

@tlively
Copy link
Member Author

tlively commented Feb 8, 2021

@Maratyszcza I moved v128.any_true to 0x53 because it's now a one-off instruction, but if that renumbering would be disruptive, I could move it back to where it was.

| `i64x2.le_s` | `0x106`| - |
| `i64x2.ge_s` | `0x107`| - |
| `i64x2.all_true` | `0xc3`| - |
| `f64x2.convert_low_i32x4_s` | `0xfc`| - |

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching that!

@tlively
Copy link
Member Author

tlively commented Feb 9, 2021

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 f64x2 rounding instructions, which are scattered among the integer operations.

@ngzhian
Copy link
Member

ngzhian commented Feb 9, 2021

Amazing bin packing work Thomas, thanks!

| `i64x2.extmul_high_i32x4_s` | `0xdd`| - |
| `i64x2.extmul_low_i32x4_u` | `0xde`| - |
| `i64x2.extmul_high_i32x4_u` | `0xdf`| - |
| `i16x8.q15mulr_sat_s` | `0x9c`| - |

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed.

@tlively
Copy link
Member Author

tlively commented Feb 9, 2021

Why are 0xe2 and 0xee reserved for round?

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.

@zeux
Copy link
Contributor

zeux commented Feb 11, 2021

256 opcodes was indeed enough for anyone 🚀

proposals/simd/NewOpcodes.md Show resolved Hide resolved
@tlively
Copy link
Member Author

tlively commented Feb 19, 2021

Merging because there were no further comments on this at today's meeting.

@tlively tlively merged commit 2c28fa8 into master Feb 19, 2021
@alexcrichton alexcrichton deleted the final-opcodes branch February 19, 2021 18:45
@alexcrichton alexcrichton restored the final-opcodes branch February 19, 2021 18:45
ngzhian added a commit to ngzhian/simd that referenced this pull request Feb 26, 2021
Opcodes were finalized in WebAssembly#452, this updates the interpreter and spec
text to use these final opcodes.
ngzhian added a commit to ngzhian/wasmparser that referenced this pull request Mar 2, 2021
See WebAssembly/simd#452 for finalized opcodes
and WebAssembly/simd#467 for some renamings.
ngzhian added a commit to ngzhian/wasmparser that referenced this pull request Mar 2, 2021
See WebAssembly/simd#452 for finalized opcodes
and WebAssembly/simd#467 for some renamings.
ngzhian added a commit to ngzhian/wasmparser that referenced this pull request Mar 3, 2021
See WebAssembly/simd#452 for finalized opcodes
and WebAssembly/simd#467 for some renamings.
ngzhian added a commit that referenced this pull request Mar 3, 2021
Opcodes were finalized in #452, this updates the interpreter and spec
text to use these final opcodes.
bmeurer pushed a commit to wasdk/wasmparser that referenced this pull request Mar 4, 2021
See WebAssembly/simd#452 for finalized opcodes
and WebAssembly/simd#467 for some renamings.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants