Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoding of opcodes #112

Open
fgmccabe opened this issue Feb 24, 2025 · 3 comments
Open

Encoding of opcodes #112

fgmccabe opened this issue Feb 24, 2025 · 3 comments

Comments

@fgmccabe
Copy link
Collaborator

The explainer introduces six instructions: cont.new, cont.bind, resume, resume_throw, suspend, switch.

While this is not a large number, it is more than 1. Furthermore, it is entirely possible that we will need to describe additional instructions.

At the moment, the opcodes 0xe0 through 0xe5 are also described.

The wasm opcode space is getting pretty crowded nowadays. (In fact, the above codes already conflict with some internal opcodes used within V8).

Also, since suspend/resume instructions are unlikely to be that frequent in the code, the code size argument does not seem pressing.

I would like to suggest using some space in one of the existing prefix groups: GC (0xfb), Numeric (0xfc), Simd (0xfd) or Atomic (0xfe).

The one with the most room is Numeric (last used sub-opcode 0x31) but maybe the one that makes most sense is GC (last used opcode is 0xb8)

Another suggestion made to me: have a specific 'experimental' prefix to be used by proposals until (just before) they reach phase 4.

@tlively
Copy link
Member

tlively commented Feb 25, 2025

The GC prefix or a new prefix would make sense to me. Choosing an experimental prefix (0xff?) with a documented intention to change it before phase 4 also makes sense to me, and is something we have wished we had done for other proposals as well.

@titzer
Copy link
Contributor

titzer commented Mar 19, 2025

TBH I prefer that they remain unprefixed and low, because these opcodes are fundamental additions to control flow constructs.

Or, to put it another way, I cannot imagine other instructions that would be better to put in the low holes that exist in the opcode space today, so I think these new stack-switching opcodes fit best these low holes.

@tlively
Copy link
Member

tlively commented Mar 19, 2025

FWIW we now have standard precedent for prefixed control flow instructions: br_on_cast and br_on_cast_fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants