Skip to content
This repository was archived by the owner on Apr 25, 2025. It is now read-only.

How is a non-default memory index to be denoted in the text format? #17

Closed
lars-t-hansen opened this issue Jan 18, 2021 · 3 comments
Closed

Comments

@lars-t-hansen
Copy link
Contributor

The context is this comment. Currently wasm-tools will accept a memory index denoted simply by an integer trailing the opcode. This conflicts with the SIMD spec, which wants an integer trailing the opcode to denote a vector lane in some contexts; for instructions with both a memory operand and a lane operand the conflict must be resolved.

I can't find anything in the proposal or interpreter here about what the present proposal thinks is a reasonable way of denoting the memory index in the text format.

Similarly to offset and alignment, may we assume that a keyword must be used, eg memory=n or memidx=n? @rossberg, opinions?

@rossberg
Copy link
Member

Segments use (memory $i) and (table $i), respectively. Similarly, various references to types use (type $i). So (memory $i) seems like the best choice here.

That would also extend nicely to some future syntactic sugar for aliases that we have been converging on for the module linking proposal (e.g., WebAssembly/module-linking#19).

alexcrichton added a commit to alexcrichton/multi-memory that referenced this issue Nov 4, 2021
This commit intends to apply WebAssembly#17 to the test suite by using `(memory
...)` instead of bare indices which can be confused with other proposals
such as SIMD which use bare indices for other purposes.
@rossberg
Copy link
Member

This has been resolved in the recent merge from upstream (#26). Turns out there isn't actually a conflict, and using a plain index is much simpler in terms of the yacc grammar.

We could still consider allowing explicitly tagged references, but then I'd be inclined to consistently allow them in all similar places, which is a bigger change.

@rossberg
Copy link
Member

Closing as resolved.

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

No branches or pull requests

2 participants