Hey, I have a few Qs, pls feel free to refer me to relevant documents (the explainer doc is really long and daunting):
When one module calls another are all the calls just one jump or is the host sometimes involved in type conversion or figuring out where to jump?
Can objects be passed along as mutable, if yes how is that memory managed?
Are there some good examples of CM repos that I can run?
ty!
When one module calls another are all the calls just one jump ...
If I understand this right the answer is "one jump". Imports are resolved at instantiation time which means at runtime there's no ambiguity as to what you're calling. The component runtime does provide facilities to copy strings between components for example though, which may also be what you're asking about (unsure)
Can objects be passed along as mutable, if yes how is that memory managed?
No, the component model is a "shared nothing" system where linear memory is an implementation detail and not part of the API.
Are there some good examples of CM repos that I can run?
others may have other suggestions, but depending on how nitty-gritty you'd like the tests in the Wasmtime and wasm-tools
repos may give you an idea of where to start. Also the wit-bindgen
repo (and probably as you've found componentize-py
tests as well). I'd also recommend the jco tests. (ok I'm just saying "look at tests" I think)
how does componentize-py work? does it just embed a wasm python runtime into the component?
@Joel Dice is the expert here, but yes it currently embeds a python interpreter/runtime in the component
Expanding on Alex's answer:
Oh sorry that's a really good point on (2) about mutable state, the "resource" type is perfect for that!
great!, followup questions:
what does each one of these functions do and why are they being exported? does the runtime need them in order to run the component, it seems like the only exported function here should be render, right?
c. render's interface in the wit file is render: func(input: string) -> string but in the wams it's, func $render (;12;) (type 4) (param i32 i32) (result i32) , how does the type conversion work and component to component calling work in this case?
thanks in advance!
cabi_realloc is necessary to allocate memory on the heap of the component to write the input string too. The wasm runtime doesn't know anything about the memory allocator used by wasm modules, so it has to call into the wasm module to allocate memory. It can't just pick an arbitrary address and write the string to.
monkeyontheloose said:
- why is there a global var (global $__stack_pointer (;0;) (mut i32) i32.const 1048576) in the wasm, is rust implementing it's own stack on top of the wasm stack?
The wasm stack can only store primitive values like integers and floats and doesn't allow taking any references to it. As such LLVM has to create a separate stack in the wasm linear memory where stack slots that have their address taken or which are too large for the wasm stack are put. This is done by LLVM, so both rustc and clang will emit __stack_pointer
.
As for how wit function signatures are lowered see https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md
it seems like the output is way too big (1.8MB), im guessing that wasms that are compiled to run on web pages are smaller but they still compile down from rust, are all components this big?
the canonicalABI doc is such a hard read fml... but ok, i'll do it haha
wasm-tools print app.wasm prints a decompile of a component afaik, if i edit this file by adding some op codes and add an import would it be possible reassamble it into a new wasm? how would one go about doing that?
Are you building in release mode? Also yoy may want to strip debug info. Debug info takes up a lot of space and is by default not stripped even in release mode. (user crates don't get it generated, but the debug info for the standard library is preserved) You can use the strip = "debuginfo"
option in the [profile.release]
section of Cargo.toml
to tell rustc to strip debug info in release mode.
will try this, currently my most urgent question is #5, how can i wat2wasm a component?
@Alex Crichton is there a way to do this?
Hi @monkeyontheloose . As far as I am aware wat2wasm
doesn't support the component model proposal, but you can use wasm-tools
from https://github.com/bytecodealliance/wasm-tools, specifically the wasm-tools parse
command to translate from the text format into binary.
thanks!
hi, this is my new user, i was monkey before, anyways, back to my original problem, we are trying to port https://github.com/DelphinusLab/zkWasm (creates zkproofs for wasm) to support component model wasms, where can one read about:
:pray:
@Alex Crichton is there anyone that help with this? :pray: (we also have a grant budget so if anyone wants to put in some hours on this problem we would gladly reciprocate the favor)
The project you are working on is pretty far from what most of us are involved in. I don't think there is going to be a whole lot of interest in working on such a radically different operating environment when we haven't even finished implementing the component model for our own immediate needs. :shrug:
To be clear: I don't mean to discourage you from asking; just trying to set expectations from my perspective.
Currently from your questions I think the answer is that precisely such documentation doesn't exist. I'd recommend exploring the component model explainer in the spec repository and the component-docs repository however
Last updated: Dec 23 2024 at 13:07 UTC