multi-memory

multi-memory copied to clipboard

while the spec is reasonably simple and clear at wasm bytecode level, i'm not sure how it's supposed to interact with high level languages compiled into wasm. (eg. C)

is non-default memory supposed to be accessible from languages like C at all? as memory index is encoded as an immediate, it doesn't seem straightforward to implement "far" pointers which can access those memories.

or, is this feature mainly for offline tools which rewrite instructions?

is non-default memory supposed to be accessible from languages like C at all?

No, not without a language extension to add some notion of new address spaces with incompatible pointers. It's possible that we will have such language extensions in clang in the future, but probably not soon.

Other existing languages are in similar situations, although brand new languages could try to account for the possibility of having multiple memories in their core design.

is this feature mainly for offline tools which rewrite instructions?

Exactly. Multi-memory will be useful for code instrumentation and for merging multiple modules into one.

is non-default memory supposed to be accessible from languages like C at all? as memory index is encoded as an immediate, it doesn't seem straightforward to implement "far" pointers which can access those memories.

There are languages that supports address spaces, OpenCL for example, and they should be able to handle memory indices without fat pointers.

is non-default memory supposed to be accessible from languages like C at all?

No, not without a language extension to add some notion of new address spaces with incompatible pointers. It's possible that we will have such language extensions in clang in the future, but probably not soon.

Other existing languages are in similar situations, although brand new languages could try to account for the possibility of having multiple memories in their core design.

is this feature mainly for offline tools which rewrite instructions?

Exactly. Multi-memory will be useful for code instrumentation and for merging multiple modules into one.

ok. thank you for explanation.

is non-default memory supposed to be accessible from languages like C at all? as memory index is encoded as an immediate, it doesn't seem straightforward to implement "far" pointers which can access those memories.

There are languages that supports address spaces, OpenCL for example, and they should be able to handle memory indices without fat pointers.

interesting. do you mean this stuff? https://en.wikipedia.org/wiki/OpenCL#Memory_hierarchy

The best option so far would be the fancy pointers in C++ allocators (which was supposed to be to support near/far) wasm::ptr<T, uint memidx=0> however you will need to create specific specializations for nearly everything because most of the std lib assumes that those can be converted to a raw dereferenceable pointer which is the entire issue with the index being an immediate of the instruction.

Unless you implement the deref of a "far" pointer when multiple memories are present through a switch. Same with all other memory ops taking that memory index as an immediate. And then you are hoping that the compiler and/or the implementation can inline and constant fold the memory index and pick the correct intrinsic.

Sorry, I missed the notification somehow.

do you mean this stuff? https://en.wikipedia.org/wiki/OpenCL#Memory_hierarchy

Yes, that is what I meant. LLVM supports this via addrspace annotation which works similarly to memindex in this proposal: 0 is the default, and there are no assigned meaning to other ones. It should be possible to lower those annotations to mulit-memory. OpenCL doesn't have to be the source language, especially given what it is meant to be used for, it just has a very similar model built into it.

fancy pointers in C++ allocators (which was supposed to be to support near/far) wasm::ptr<T, uint memidx=0>

This actually sounds like a good option. The problem, as pointed out, is referencing locations across memories. It is a useful feature, as it would eliminate duplicating code for the sake of targeting a different memory. OpenCL also considered that and has 'generic' (address space agnostic) pointer since version 2.0.

Filed #32 for cross-memory references.

Closing this as answered.