-
Notifications
You must be signed in to change notification settings - Fork 57
Correspondence between adapter and import/export funcs #119
Comments
Your assumption is not correct. CA -> ACA -> ACB -> CB where ACA and ACB are the import adapter and export adapters respectively. The 'bridge' between ACA and ABC looks like a regular function call - except that the function signatures are expressed as Interface Types. CA knows how to call ACA because module A imports a function and the 'wrapper' module supplies ACA as the implementation of the import. ACA knows to call ACB because the host embedder (or other entity) has designated module AB (adapted module B) as the way of satsifying the import by ACA. ACB knows to call CB because AB wraps module B and effectively imports module B: i.e., function CB satisfies the import(s) that AB makes. This whole story is actually (going to be) part of the module linking story where modules can be composed in useful ways. Does this clarify? |
Sorry, my question was unclear.
My question is related exactly to this correspondence. How to exactly point out that this adapter implements (wraps) this core function? I can't find this info in the docs of this repo, Wasmer uses scheme with |
In all cases, it uses existing mechanisms, specifically, invoking an imported function. There is no separate mechanism for calling adapter functions. |
It seems that you mean that |
An import adapter function has a core wasm signature. Its role is to act as the importee: i.e., when a core wasm module imports a function, the import adapter counts as satisfying the import. For normal imports, this is handled by (a) providing an implementation for the imported function and (b) letting the host connect your implementation as the import for the module. |
Thank you, got it. I think, It would be really good to describe this somewhere in the docs. |
What is a way of correspondence indication between adapter and core funcs? I can't find this in the docs in this repo. As far as I know, it is done by the implementation subsection that contain correspondence between types of adapter and core func types like here.
If it is true, lets imagine the situation where we have several functions with the same type:
(@interface type (func (param string) (result string)))
. All adapter for these functions will be similar except arg ofcall-core
instructions. So to differentiate we need several ephemeral types for adapters and core functions (like in the example here - the only differencecall-core 6
andcall-core 7
and they have to have unique type for all adapter because of this way of organizing of the implementation section).The text was updated successfully, but these errors were encountered: