Future-proof memory instructions

[rossberg]

The MVP allows only one static memory or table, and respective operators do not index a table explicitly. Loads and stores already have a flag immediate that could be instrumented in a future extension to allow them to access either multiple memories or even first-class memories.

This PR reserves a flag byte for the other 3 remaining instructions on memories and tables: current_memory, grow_memory and call_indirect. That way, a future extension to multiple or first class tables/memories will not require duplicating any opcode.

[titzer]

It's not clear how we will extend the load/store instructions in the future. E.g. we could extend the flags field (which currently only contains the offset), which means no new instructions. Or, we could introduce prefixes. If we introduce prefixes, then the prefixes could as well apply to these instructions.

So I'd rather we not add this, since if we introduce new instructions, or add prefixes, these immediates will be unnecessary.

[lukewagner]

Actually, I thought of one not-totally-subjective reason that puts me in favor of this proposal:

We've talked about 3 ways to indicate which Memory/Table you want a given op to access:

1. the default (the only option in the MVP)
2. an imported or internally-defined table identified by immediate index (post-MVP, when multiple memories/tables are allowed)
3. a dynamic table passed by first-class reference on the operand stack (post-MVP, with the GC feature)

Initially, I thought that 2 was of mild value, since 3 is more general and so I've generally assumed we wouldn't add 2. But I've remembered one useful property of 2: it categorically avoids using the GC feature which I expect will end up carrying some cost in implementations, even if it is only very lightly used. And while multiple memories is of questionable value outside of GC contexts, I know compiled C/C++ code can make use of multiple tables, once given homogeneous table types, to avoid the signature check on call_indirect. Also there are CFI applications.

So if we were able to express 1-3 just using the flags fields, then we save 50 ops which, even if "ops are cheap", is probably worth something. E.g., it might make the difference between all non-SIMD ops fitting in the 1-byte encoding. So from that, this PR follows. Sure we could do something custom for current_memory/grow_memory, but symmetry.

[titzer]

On the other hand, this would be the only change to 0xD other than a simple renumbering, which makes WABT's 0xC -> 0xD translation a tad harder.

[lukewagner]

That's true, but it should still be highly mechanical.

[lukewagner]

Actually, based on the reasoning that "any op that uses the default (memory|table) should have a flags immediate so that we can add non-default options in the future", it seems that call_indirect should also get a flags.

[rossberg]

@lukewagner, added.

[lukewagner]

Thanks, lgtm

[titzer]

I see the use case for multiple static tables in the future, and although I'm more skeptical about multiple static memories, I think it's fine to land this change as is, so LGTM

[rossberg]

Landing with LGTMs above.