Skip to content

Add initial support for the multi-memory proposal#2263

Merged
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
alexcrichton:multi-memory
Oct 14, 2020
Merged

Add initial support for the multi-memory proposal#2263
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
alexcrichton:multi-memory

Conversation

@alexcrichton
Copy link
Copy Markdown
Member

This commit adds initial (gated) support for the multi-memory wasm
proposal. This was actually quite easy since almost all of wasmtime
already expected multi-memory to be implemented one day. The only real
substantive change is the memory.copy intrinsic changes, which now
accounts for the source/destination memories possibly being different.

@github-actions github-actions Bot added cranelift Issues related to the Cranelift code generator cranelift:wasm wasmtime:api Related to the API of the `wasmtime` crate itself labels Oct 5, 2020
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Oct 5, 2020

Subscribe to Label Action

cc @peterhuene

Details This issue or pull request has been labeled: "cranelift", "cranelift:wasm", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

Copy link
Copy Markdown
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thanks for cleaning up the imported vs defined memory copy stuff.

Please also update https://github.com/bytecodealliance/wasmtime/blob/main/docs/stability-wasm-proposals-support.md for multi-memory

r=me with that

Comment thread crates/runtime/src/instance.rs Outdated
@fitzgen
Copy link
Copy Markdown
Member

fitzgen commented Oct 13, 2020

Also would be good to add support for generating multi-memory to wasm-smith, if you're interested in doing that. My idea for how supporting proposals would work there is that the Config trait would have a fn multi_memory(&self) -> bool trait method.

This commit adds initial (gated) support for the multi-memory wasm
proposal. This was actually quite easy since almost all of wasmtime
already expected multi-memory to be implemented one day. The only real
substantive change is the `memory.copy` intrinsic changes, which now
accounts for the source/destination memories possibly being different.
@alexcrichton alexcrichton merged commit e659d5c into bytecodealliance:main Oct 14, 2020
@alexcrichton alexcrichton deleted the multi-memory branch October 14, 2020 00:13
cfallin pushed a commit that referenced this pull request Nov 30, 2020
This commit adds initial (gated) support for the multi-memory wasm
proposal. This was actually quite easy since almost all of wasmtime
already expected multi-memory to be implemented one day. The only real
substantive change is the `memory.copy` intrinsic changes, which now
accounts for the source/destination memories possibly being different.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cranelift:wasm cranelift Issues related to the Cranelift code generator wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants