Repository navigation
Final opcode renumbering process #129
Description
Since we plan on softly freezing our instruction set when we reach stage 3, that will also be a good time to finalize the opcode names and numbers before many engines dive into their implementation work.
It won't be possible to synchronize a renumbering across the entire ecosystem all at once because different projects have different release cycles, but the closer we can come to approximating a coordinated release, the shorter the period of disruption will be for our bleeding-edge users. With that in mind, I would like to propose the following schedule of events.
- We decide we are happy pushing to stage 3 and freezing our opcode set.
- We decide on final names and opcodes.
- We push for stage 3 in the CG.
- We recommend that engines and tools update their naming and numbering no earlier than three weeks and no later than four weeks after the vote for stage 3.
Steps 2 and 3 can happen in parallel, but we will aim to have finished finalizing names and opcodes by the time of the vote for stage 3 or as soon as possible afterward. Our recommendation of renumbering window will be shared with the CG after the vote and also announced at that time in a dedicated issue in this repo.
The time span of three to four weeks after reaching stage 3 is meant to give implementors adequate time to implement any necessary changes.
Activity
zeux commentedon Nov 6, 2019
Just a quick note: I have come to regret changing v8x16.shuffle opcode. Defacto it’s still 0xfd 0x03 in LLVM/Chrome and the difference doesn’t help during development - e.g. I have a local WABT build with the old opcode...
If the renumbering will actually affect many opcodes then it doesn’t matter because we’re going to go through a major breakage period, but if only a few opcodes are going to get moved then we could consider moving it back to 0x03.
tlively commentedon Nov 6, 2019
Thanks, @zeux! I agree that in hindsight changing the shuffle opcode wasn't helpful, but I don't think it's critical to put it back right now. We have had a few bug reports of the mismatch between wabt and other projects, but it's probably not worth a patch since the opcode freeze and renumbering is hopefully not too far off anyway.
tlively commentedon Apr 1, 2020
We ended up doing a soft freeze of the opcodes after we went to phase 3, but the renumbering can be discussed concretely in #209. We should recommend that implementations aim to make the switch between three and four weeks after the renumbering is merged, or some other span of time TBD.
lars-t-hansen commentedon Apr 1, 2020
I commented on the PR too but I find the justifications for a renumbering at this stage to be fairly meagre.