Comments (22)
Support was recently added to Binaryen, but hasn't been added to LLVM yet.
from multi-memory.
Yes, exactly.
from multi-memory.
I'm curious if there is any example of "high level language being compiled to WebAssembly with multi-memory support"?
I searched for a long time but still haven't found any. :(
from multi-memory.
(sorry, misread the above comment)
Support was recently added to Binaryen, but hasn't been added to LLVM yet.
Is anybody working on LLVM support? LLVM IR has address spaces, that can be used to represent multiple memories.
from multi-memory.
No, nobody is currently working on multimemory in LLVM, although Igalia's work adding support for tables is very similar to what would need to happen to support multiple memories as well.
from multi-memory.
I'm curious if there is any example of "high level language being compiled to WebAssembly with multi-memory support"? I searched for a long time but still haven't found any. :(
I don't know of any either, probably because of the current lack of implementations. Hopefully we will soon break the chicken-and-egg problem. Did you have a particular thing you wanted to learn from an example?
from multi-memory.
I'm curious if there is any example of "high level language being compiled to WebAssembly with multi-memory support"? I searched for a long time but still haven't found any. :(
I don't know of any either, probably because of the current lack of implementations. Hopefully we will soon break the chicken-and-egg problem. Did you have a particular thing you wanted to learn from an example?
I have come up an technique leveraging the multi-memory support of the WebAssembly and now need some test cases.
So I got a high-level coding application and wanted to rewrite it for working on multi-memory, then compile it to wasm.
And such high-level coding method is what I wanted to learn.
from multi-memory.
Igalia's work adding support for tables is very similar to what would need to happen to support multiple memories as well.
What does this work look like? LLVM has addrspace
attribute which in some cases has exactly the same meaning as multiple memories (think OpenCL before version 2), though I've also read about supporting GC object using that.
from multi-memory.
One of the more compelling use cases I've stumbled on is virtualizing interfaces that use memory. E.g. implementing a Wasm module that has an imported memory from the "user", which it may read and/or write, and then a private memory that is used to store additional internal state and possibly communicate with other modules.
AFAICT It would be possible to write such a module in C with address space annotations.
from multi-memory.
yes, that’s what I want to learn.
How does this addr space annotations work?
One of the more compelling use cases I've stumbled on is virtualizing interfaces that use memory. E.g. implementing a Wasm module that has an imported memory from the "user", which it may read and/or write, and then a private memory that is used to store additional internal state and possibly communicate with other modules.
AFAICT It would be possible to write such a module in C with address space annotations.
from multi-memory.
How does this addr space annotations work?
With Clang and C/C++ it is __attribute__((address_space(N)))
before the type, though the N
for the purposes of multiple memories needs to be a constant.
Example:
int incr_from_mem3(__attribute__((address_space(3))) int * ptr) {
return (*ptr) + 1;
}
(Edit) Even though this would lead to addrspace
in the LLVM IR, Wasm backend would quietly ignore it at the moment, though it should not be too hard to enable that.
from multi-memory.
How does this addr space annotations work?
With Clang and C/C++ it is
__attribute__((address_space(N)))
before the type, though theN
for the purposes of multiple memories needs to be a constant.Example:
int incr_from_mem3(__attribute__((address_space(3))) int * ptr) { return (*ptr) + 1; }(Edit) Even though this would lead to
addrspace
in the LLVM IR, Wasm backend would quietly ignore it at the moment, though it should not be too hard to enable that.
I see, thanks for explanation.
from multi-memory.
Since address spaces need to be statically allocated by the LLVM backend for WebAssembly, it would not be scalable to try to use them to support multiple memories directly. Tables are modeled in LLVM IR as global arrays in a special address space so that an arbitrary number of them may be created. The Wasm object file format used with LLVM was also extended with additional relocation types for tables. The same patterns would work well for modeling multi-memory as well.
from multi-memory.
I actually find that take somewhat surprising; given that address spaces also need to be statically allocated in the wasm module, requiring the same static allocation at the LLVM IR level seems like it should scale exactly as well in LLVM as it would in wasm itself? Tables are different in the sense that there's not really any obvious analog in the IR already (not just for tables, but also for the references they contain).
from multi-memory.
I am going to second what @dschuff said, aren't memories statically declared, why would they need to get the same dynamic treatments tables get?
from multi-memory.
By "statically allocated in the backend," I mean statically allocated when LLVM is compiled, not when the user program is compiled. So if you had a 1:1 mapping between address spaces and memories, then when you compile LLVM, you would have to determine what the maximum number of memories an LLVM IR module could reference at that point. In contrast, the scheme used for tables allows user programs to use an arbitrary number of tables.
from multi-memory.
Is this discussion is just about the LLVM internal representation? At the C or C++ level these would still be address space annotations on pointer types?
from multi-memory.
So if you had a 1:1 mapping between address spaces and memories, then when you compile LLVM, you would have to determine what the maximum number of memories an LLVM IR module could reference at that point.
There is a hard limit on number of memories, memory index is one byte, I think.
from multi-memory.
Is this discussion is just about the LLVM internal representation? At the C or C++ level these would still be address space annotations on pointer types?
At the C or C++ level these would most likely be new annotations like __attribute__((wasm_memory))
, since clang would also have to check a bunch of semantic restrictions (such as ensuring that the arrays are not address-taken) just like it does for tables.
There is a hard limit on number of memories, memory index is one byte, I think.
No, just like all other indices in Wasm, memory indices are LEB128 values.
from multi-memory.
At the C or C++ level these would most likely be new annotations like
__attribute__((wasm_memory))
, since clang would also have to check a bunch of semantic restrictions (such as ensuring that the arrays are not address-taken) just like it does for tables.
Oh, so you mean they would be globally-declared (non-address taken) arrays into which the program would index with integers?
from multi-memory.
Related Issues (20)
- Text format for data segments may be confusing with passive data segments HOT 2
- Read only memories? HOT 11
- Binary format is out of date HOT 3
- How is a non-default memory index to be denoted in the text format? HOT 3
- Text syntax for SIMD lane index vs memory index operands HOT 1
- Possibility to dynamically add memories at runtime? HOT 2
- Overlap with recent issue raised on the main WASM design repo HOT 5
- Contradiction in multi-memory binary format instruction rules HOT 3
- A question about high level language interaction HOT 7
- Referencing locations across memories HOT 10
- Text format: parsing `v128.loadX_lane` and `v128.storeX_lane` requires backtracking HOT 6
- Multi-Memory Lowering & Memory Imports HOT 1
- Use-case for multi-memory: Flutter Web Engine linking with wasm-compiled skia (C++) and ICU4X (Rust) HOT 5
- Use-case for multi-memory: dart2wasm to implement ByteBuffer/TypedList objects with linear memory HOT 8
- Use-case for multi-memory: Component Model object transfer browser polyfill HOT 2
- Additional test cases for multi-memory HOT 3
- Use-case for multi-memory: Less overhead tracking of store calls to facilitate networked rollback HOT 1
- Use case for multi-memory: Sharing persistent datastructures between threads
- Implementation support HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from multi-memory.