Component model strategy for embedded

[cpetig]

Dear Chris, sorry for taking quite long to read and reply to your proposal!

I see a potential path to combine preview1 and 0.2/0.3 - by using a core module binary representation of a "component" (this involves the "cm32p2|" naming of symbols https://github.com/WebAssembly/component-model/blob/add-build-targets/design/mvp/BuildTargets.md (and was previously called "wasit2")), potentially even compiled as a shared library (to achieve the relocatability of the data section) - but this sacrifices the insulation between modules. Insulation would require multi-memory, basically the wasip2 module file format is best suited for insulation.

To get the overhead of the canonical ABI down, caller provided buffers described in WebAssembly/component-model#369 are most promising. I clearly aim for reducing the heap memory allocation overhead per call down to zero using the shared memory buffer mechanism because of real-time constraints and functional safety argumentation.

I am sorry, that even though there is good progress on definition and implementation, these technologies are not yet available right now.

[cpetig]

Also please keep in mind that the API is always defined in a shared nothing way. To alternate between full insulation and shared everything linking, even within the same binary, only the binding code has to be re-created using a different configuration. And separating shared everything compiled parts or fusing shared nothing parts just requires bridging code (similar to https://github.com/cpetig/wit-bindgen/tree/work-in-progress/crates/cpp/tests/native_strings/w2c2 )

[cpetig]

Just for the record: The jco glue code approach to connect multiple core modules combined with above core module definition makes a lot of sense to me.