Status of 0xFF opcode prefix

[lars-t-hansen]

We're using the prefix 0xFF internally in SpiderMonkey to represent some private opcodes (for the asm.js -> wasm translator that we use for handling asm.js, among other things). I've been looking for spec prose, reference interpreter code, or issues that designate this prefix as reserved for the implementation, but I've found nothing so far. Yet I seem to remember that it is so. Does anyone else have any more specific information about this?

[dtig]

I also remember this to be the case, though I don't think it is documented anywhere except in the meeting notes when it was discussed.
Edit: The exact wording on the poll was "Poll: 0xFF should be reserved prefix for when we run out"

[lars-t-hansen]

@dtig, nice find. That's probably good enough for us for the time being.

[rossberg]

Hm, interestingly, those notes also contain a (successful) poll that decided that "0xFF should be reserved prefix for when we run out" (of opcodes). That seems to mean something else than being reserved for implementations, though I don't know what exactly...

[lars-t-hansen]

@rossberg, i agree, but it looks like we're not in real danger of running out any time soon. Meanwhile, the "unused" prefixes we had been using for some experimental work are in imminent danger of being used by new proposals, so this seemed like a good time to try to get our house in order.

[titzer]

I support reserving 0xFF for internal use, as long as feasible, and would support spec text to that effect.

[rossberg]

I'm still a bit confused about what precisely we want to state and what guarantees that would actually imply. It sounds almost like "0xff is available to implementations until it isn't", which seems a bit like a vacuous statement for a standard?

If the goal is to prevent proposals from clobbering 0xff if they don't have to, perhaps that rather is something to note in, e.g., the process doc or some design doc?

[rossberg]

It looks like there is nothing actionable on the spec side for this, closing.

[justinmichaud]

Can we add text to the spec specifically guaranteeing that 0xFF will not be used for future expansion, and will be left for implementations to use?

(see also #1141)

"0xFF should be reserved prefix for when we run out" (of opcodes)
Then, can we pick a different value for this, and note it somewhere?

This has recently come up for us because we would like to use it as a slow-path escape hatch, but it seems like multiple parties have interesting uses for it.

[titzer]

+1 for an explicit reservation of 0xFF as illegal. Wizard uses an illegal opcode to implement instrumentation and it would be good to know there will always be a 1-byte illegal opcode.

[rossberg]

That is all fine, but my earlier comments still stand:

1. Technically, the opcode currently is illegal. Beyond that, it is not clear how the spec would be capable of saying anything normative about future versions of itself – given that it can always be modified, such a statement would be inherently meaningless. Like other backwards compat constraints, this is not spec-level but meta-level. At most, the spec could have an informal note explaining the intent.

2. The intent seems to be in contradiction with the earlier CG vote digged up by @dtig, at least as I read it. So I believe this would require an overriding vote.

[dtig]

I've added a quick agenda item for the next meeting at WebAssembly/meetings#1087. I'd also like to add some explicit polls there, so bringing this back for discussion. Would it make sense to explicitly reserve an opcode for instrumentation, and keep 0xFF for future use? Or is it reasonable to assume that implementations in the future can change their instrumentation opcodes to a new scheme (whatever we decide makes most sense in the new encoding scheme when we run out of opcode space)?

[eqrion]

That is all fine, but my earlier comments still stand:

1. Technically, the opcode currently _is_ illegal. Beyond that, it is not clear how the spec would be capable of saying anything normative about future versions of itself – given that it can always be modified, such a statement would be inherently meaningless. Like other backwards compat constraints, this is not spec-level but meta-level. At most, the spec could have an informal note explaining the intent.

I will not be able to attend the Tuesday meeting, so posting my thoughts ahead of time.

If we wanted 0xFF to be illegal to use indefinitely and not just 'until we run out and need it', we could specify 0xFF as a named invalid instruction that is in the ast/binary format/text format but validation will always fail on. At that point, I believe we'd be fairly bound by backwards compat constraints to keep it. Having a simple invalid instruction in the text format could possibly be useful for testing too.

But I think it's a valid question for whether we want this 'until we run out and need it'. My current opinion is that devoting a single byte encoding indefinitely for engines to use internally is a reasonable expense, but if other's feel strongly I'm sure engines can always find opcode space for their own uses. call $idx with $idx above the maximum allowed functions is an interesting candidate.

If this is a 'until we run out and need it' situation, then I agree with Rossberg that this belongs in the process documentation, with maybe a non-normative note in the spec text.

[tlively]

Actually, specifying an invalid instruction seems like a great way to implement 'until we run out and need it,' since we are always allowed to make previously-invalid modules validate in the future. (If we weren't allowed to do that, we couldn't change anything at all.)