-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Phase 4 Requirements #50
Comments
Yes, spec/interpreter/test-side all boxes have been checked 4 years ago, just waiting for implementations to catch up. :) Happy to see progress on this! |
Awesome! I went ahead and added an agenda item to vote Multi-Memory to Phase 4 at the in-person CG meeting, WebAssembly/meetings#1361 |
Should this proposal have a JS API that exposes multiple memories, or has some way that additional memory can be accessed from outside of Wasm? A straightforward extension could be to extend the The reason for proposing this is that without support in the compilation pipeline in the tools (someone should correct me if the Binaryen implementation is sufficient for use from a source language), or API functions in the Spec, the use of multiple memories is limited to within Wasm. While I'm not sure if there are applications that could benefit from this, adding an easily accessible API potentially encourages experimentation with the proposal, and/or usage in the future for applications. |
#27 raised the limit on the number of memories in the JS API from 1 to 100. I'm not sure anything more needs to be done to the JS API specifically, since IIUC the core spec rules allow any memory to be exported or imported; so I think it wouldn't be the |
What @dschuff said, the JS API shouldn't need anything to support this, as nothing in it depends on the fact that only a single memory can currently occur in import or export lists of a module. (Memory indices are not relevant or meaningful outside a module.) |
Thanks both! Talked this through with @dschuff, and I was working backwards from how do you distinguish which buffer belongs to which memory with multiple memory imports/exports. Leaving a little bit of detail here if it helps anyone else. For imports, the memory object is created outside of Wasm, and the index itself isn't meaningful, but can be queried from the memory object itself. Similarly named exports on instantiation should be sufficient to distinguish which between multiple exported memories. |
Hm, did you mean "and cannot be queried from the memory object itself"? Runtime objects like memory instances do not carry indices in any form, they are merely "bound" to indices (possibly multiple ones) inside a given module. Indices are like local variable names. |
Sorry I phrased the sentence wrong, the index isn't meaningful, and the buffer can be queried from the memory object (not index as implied). |
This is an issue to track the requirements needed to move multi-memory into Phase 4.
v128.loadX_lane
andv128.storeX_lane
requires backtracking #34I plan to propose the advancement to Phase 4 after we meet these requirements. Please reply if there are any remaining concerns for the phase advancement that are not listed here.
The text was updated successfully, but these errors were encountered: