You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 25, 2025. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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).
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.
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.
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?
The text was updated successfully, but these errors were encountered: