Opcode for catch_all

[dschuff]

The opcode for catch_all is currently specified to be 0x05. This is the same as else and it's technically unambiguous because it appears in the context of a try. But it's also the first reuse that breaks the current 1:1 correspondence between opcodes and operators; that correspondence complicates some tools and implementations, so it might not be worthwhile just to save the extra number. Should we choose an unused opcode instead? See also the discussion here

[RossTate]

Nuanced thoughts:

For the binary format, we have a common end bytecode that is shared across all block-based operators. That's useful given the desire for small binaries. It seems that else might similarly be generalized to a mid marker to be shared across all multi-block-based operators for the same reasons.

That said, although try is multi-block, different kinds of secondary blocks have different behavior. catch_all is only one such kind of secondary block.

So I can see the justification for catch_all having the same encoding as else, but I feel like it's better suited to having its own.

[rossberg]

Is this merely a problem of pretty-printing? The opcode 0x0b (end) is also generic for various constructs, which potentially have to perform different operations at this point. You could argue that 0x03 is in a similar class as a generic separator (which may or may fit here).

[wingo]

It's an inconvenience for error reporting in tooling; if you see a 0x03 you don't know whether to report a misplaced else or a misplaced catch_all. It's an inconvenience in one-pass compilers to have two possible success continuations after seeing 0x03 (one inside if, one inside try). Nothing insurmountable but if there are opcodes to spare, makes sense to me to allocate one.

[aheejin]

I'd support splitting them if that makes tool implementation and error reporting easier, unless there is any reason not to. Are we running out of opcode space for future instructions or something? It seems we have 0x19 available (see #145).

Also, not sure if this is relevant, but that end ends all block-like structure does not hold anymore; try-delegate does not have an end at the end. (It could have an end, but given that delegate does not have a body it is not necessary.)

Also cc'ing other people working on implementations: @takikawa @thibaudmichaud

[takikawa]

I would prefer having it split as well unless there are good reasons against. Both in Spidermonkey and wabt, I've noticed some cases where error messages or printing can be confusing or more difficult to make clear with the opcode sharing. It would make sense to me to keep the 1:1 correspondence as much as possible.

[eqrion]

The difference for me between end and catch_all is that the end opcode is always 'end' in the text format, no matter where it is used. Whereas the else/catch_all opcode would have a different text name depending on the context.

This leads me to think that it could be okay to share an opcode if we could agree on a common text name for the uses of the opcode. For backwards compatibility, this would likely be else.

e.g.

try
  ...
catch
  ...
else (* catch_all *)
  ...
end

I personally think re-using else for catch_all, as above, is unclear with regards to control flow. So I would agree that we should look at other opcodes.

[aheejin]

@rossberg Are we running out of opcode spaces? If not, it seems the sentiments are it'd be less confusing to split the opcodes.

[rossberg]

I'm fine with it. We won't run out because of one individual opcode (we currently have 40-50 opcodes left -- though if this sets the precedence for future constructs, then we will obviously use them up faster).

[aheejin]

Then would it be OK with everyone if we make catch_all 0x19?