-
Notifications
You must be signed in to change notification settings - Fork 21
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
Should copying between 32 and 64-bit memories be allowed? #6
Comments
Good question! I think I'd start with disallowing it, just because it is somewhat complex and we can add it later. But if we do decide to design it now, then I think you'd want to have the instruction change signature based on the memory types (similar to other instructions). Then the size would be limited to the smaller of the two index types, i.e. given
|
Ah right that's a good point, and makes sense to me! Thinking a bit more, it may be best to basically transform this issue into "add some overview words for the interaction with the bulk memory proposal" now that it's at stage 4. I think |
@alexcrichton I think the bit-ness of I am going to mark the idea of copying between different memories as post-mvp, especially since we don't even have multiple memories yet. |
hi guys, I was playing with the experimental support in chromium for wasm64, however, chromium throws on compilation complaining about For reference, the web assembly code I was using is the below (generated by rustc from
As per the spec, this would be something that should work? |
Your memory is not a memory64 though, you need |
@lars-t-hansen okay the snippet was
|
@jiby-gh, that snippet compiles fine in the Firefox JS shell. If Chrome is giving you trouble it is possible it has not implemented memory.copy for memory64 yet. |
@lars-t-hansen right, thanks a lot for confirming, I will file a report with chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1281995), given that memory64 is experimental, i guess it's most probably not implemented yet as you pointed out. |
Reviving this ancient issue since it came up when adding table64. It looks like #7 added text to the overview that does allow copying between memories with different index types. Sadly we can't really add test for this until multi-memory lands upstream. Do folks think this is necessary or should we instead just disallow this? |
Personally I think it would be good to support this. I don't have a use case in mind that would want to use it, but otherwise copying between different-sized memories would have to have a special case of must-be-loads-and-stores where other copies can use |
I agree that it would be odd not to support this. The length-type-is-the-min-of-both-index-types part is slightly ugly, but still okay. |
Ok, I'm going to close this issue since the answer seems to be "Yes" |
This has been changed in the spec, see WebAssembly/memory64#6. Copying between memory32 and memory64 should be allowed. The type for the size is the minimum of the both index types, so only 64-bit if both memories are 64-bit. R=evih@chromium.org Bug: 345274931 Change-Id: I8d00913518c4e9a065a286af87efd0d94862e945 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5633539 Reviewed-by: Eva Herencsárová <evih@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#94506}
With the upcoming multi-memory proposal the
memory.copy
instruction will be allowed to copy between two memories, so I'm curious if the intention with this proposal is to disallow or allow copying between memories of those types?Disallowing it seems easy to me, but allowing it also seems not too hard (and possibly quite useful!). When allowing though the validation needs to be tweaked somewhat such that if either the source or destination are 64-bit memories then 64-bit offsets and such are required (I think).
The text was updated successfully, but these errors were encountered: