multi-memory

multi-memory copied to clipboard

When a parser has parsed v128.load8_lane 0, it does not know whether 0 is a memory index and the memarg and lane index are still to come or whether 0 is the lane index and the memory index and memarg were both empty. To resolve this ambiguity, the parser has to initially assume the 0 is a memory index and if it encounters an error it has to retry parsing the instruction assuming 0 is the lane index. To my knowledge this is the only place in the text format that requires this kind of backtracking; I think we've tried to be careful to avoid it. Is it worth changing the format of memory indices to fix this? Unfortunately it's too late to change the format of the lane indices since they're already in the standard.

I believe something similar happened before with table.init, when we moved to multiple tables.

We could require the (memory 0) syntax to spell out the memory, following the syntax we use in other places. But for consistency, we'd then have to do that on all load/store instructions, which would be rather tedious.

I think we could still change the syntax for lanes (say, to lane=0), but keep allowing the current syntax as backwards compat form that you can only use without a memory index. But I suppose that doesn't actually fix your problem, because that would come after...

I actually wouldn't mind having (memory X) everywhere, but I do agree it could get tedious. I also wouldn't mind keeping the backtracking for these instructions; it's not like they should come up a lot and the backtracking is fairly minor and well contained.

I just noticed that we already define memuse ::= '(' memory x:memidx ') in the text format, so it already exists if we want to use it for memory references in instructions as well.

@tlively, yes, that's why I brought it up. But the tediousness argument still stands.

I just noticed that memory.init has a similar problem where e.g. figuring out whether the 5 in memory.init 5 is supposed to be a memory or data index requires backtracking.

Edit: ah, you already mentioned table.init, so I suppose this is already known. The difference is that memory.init is implemented in binaryen but table.init is not.

What about memory=N, to be more consistent with the offset=N syntax for load/store?