Final opcode renumbering process

[tlively]

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.

1. We decide we are happy pushing to stage 3 and freezing our opcode set.
2. We decide on final names and opcodes.
3. We push for stage 3 in the CG.
4. 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.

[zeux]

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]

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]

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]

I commented on the PR too but I find the justifications for a renumbering at this stage to be fairly meagre.