Update 64x2 instructions #115
Conversation
|
Does the V8 implementation status need to be updated as well, or do we still have unimplemented 64x2 instructions? |
|
Good point, they are only implemented for x64 and arm64 (and some for ia32), so I'm not sure if it counts as implemented or not. |
|
For V8 implementation status, it's fully supported when the operations are implemented on all (officially) supported architectures to make sure that a binary that works on one platform does not fail decode with an unimplemented opcode on a different platform. |
I was thinking of these as "conversion" operators, since these are i64x2 -> f64x2.
Thanks for clarifying, in that case the implementation status should be left empty. |
A poll was held at CG meeting today, the consensus was for Option 3 of WebAssembly#101. This means we have all the f64x2 instructions, and some of the more common i64x2 that have been benchmarked. This change reflects that option in the proposal text, binary text, and implementation status. Fixes WebAssembly#101.
| | `i64x2.shl` | `0x87`| - | | ||
| | `i64x2.shr_s` | `0x88`| - | | ||
| | `i64x2.shr_u` | `0x89`| - | | ||
| | `i64x2.add` | `0x8a`| - | | ||
| | `i64x2.mul` | `0x8c`| - | |
There was a problem hiding this comment.
I thought we were reserving 0x90 for i64x2.mul.
i8x16.mul(0x5d) = i8x16.neg(0x51) + 12
i16x8.mul(0x6e) = i16x8.neg(0x62) + 12
i32x4.mul(0x7f) = i32x4.neg(0x73) + 12
i64x2.mul(0x8c) = i64x2.neg(0x84) + 8?
There was a problem hiding this comment.
Good point, I don't think these are final yet, we will look at the actual opcodes again once we have a complete set. There will probably be reordering required.
There was a problem hiding this comment.
We were pretty intentional in laying out the opcode space about a year ago before we started adding new instructions, so I think we should respect those decisions where possible.
There was a problem hiding this comment.
I'm happy to change the opcode of i64x2.mul, but with new instructions like the load_splat and load_extend, the space of i8x16 and the space of i64x2 will not be the same size anymore, and this nice equation mapping *.neg to *.mul will conflict with the goal of keeping all the i8x16 instructions together (supposing there is such a goal).
There was a problem hiding this comment.
Right, I agree that for new instructions like load_splat, load_extend, narrowing, and widening just putting them at the end of the opcode space for now is the best move.
A poll was held at CG meeting today, the consensus was for Option 3 of
#101.
This means we have all the f64x2 instructions, and some of the more
common i64x2 that have been benchmarked. This change reflects that
option in the proposal text, binary text, and implementation status.
Fixes #101.