API for resolving function imports #318
Conversation
gumb0
force-pushed
the
linking-api
branch
2 times, most recently
from
1f02f40
to
fc6787d
Compare
gumb0
changed the title
lib/fizzy/execute.cpp
Outdated
| std::move(it->function), module.typesec[import.desc.function_type_index]}); | ||
| } | ||
|
|
||
| if (external_functions.size() != imported_functions.size()) |
|
Can you add some unit tests? |
|
Maybe to so much functional, but I was imaging the instantiation workflow to look something like: |
|
I think that is an option too, but shouldn't we design that as part of the API discussion topic? Here my goal would be something quick we can add to test the overhead of host calls. |
Looks good for C++ API, but maybe this should be a part of higher-level C++ bindings... I'd leave it simpler in this PR. |
gumb0
force-pushed
the
linking-api
branch
4 times, most recently
from
9a23f3c
to
297bcb3
Compare
| @@ -100,6 +100,20 @@ execution_result execute( | |||
| // TODO: remove this helper | |||
| execution_result execute(const Module& module, FuncIdx func_idx, std::vector<uint64_t> args); | |||
|
|
|||
| // Function that should be used by instantiate as imports, identified by module and function name. | |||
| struct ImportedFunction | |||
There was a problem hiding this comment.
I'm not very happy with the name, maybe NamedFunctionImport or NamedFunction?
|
|
||
| if (it == imported_functions.end()) | ||
| { | ||
| throw instantiate_error( |
There was a problem hiding this comment.
Decided it's not worth making separate resolve_error
|
Changelog entry perhaps? |
| { | ||
| std::string module; | ||
| std::string name; | ||
| std::function<execution_result(Instance&, std::vector<uint64_t>, int depth)> function; |
There was a problem hiding this comment.
I think ImportedFunction should have two more fields:
std::vector<ValType> inputs;std::optional<ValType> result;(where empty meansvoid)
And check that against the type section. Abort on mismatch.
There was a problem hiding this comment.
It can be then
struct NamedExternalFunction
{
std::string module;
std::string name;
ExternalFunction external_function;
};
There was a problem hiding this comment.
Yeah I guess it could, but that's quite a few different structs to address when declaring these. (From a user perspective.)
There was a problem hiding this comment.
Alternative is to use a string (similar to what wasm3 and emscripten is doing): parameters followed by colon followed by return types.
e.g. ii:v would mean it takes two 32-bit inputs and returns void.
The same in wasm3 is v(ii) and iiv in emscripten.
test/unittests/api_test.cpp
Outdated
| {"mod1", "foo1", {}, ValType::i32, function_returning_value(0)}, | ||
| {"mod1", "foo2", {ValType::i32}, ValType::i32, function_returning_value(1)}, | ||
| {"mod2", "foo1", {ValType::i32}, ValType::i32, function_returning_value(2)}, | ||
| {"mod2", "foo2", {ValType::i64}, std::nullopt, function_returning_void}, |
There was a problem hiding this comment.
Can you add one test case somewhere which takes 2 inputs?
There was a problem hiding this comment.
Made this void function take 2 parameters
|
Looks good to me, but as discussed in chat lets do the changelog in a single PR at the release time instead, so please remove the commit :) |
|
Looks good to me, but as discussed in chat lets do the changelog in a single PR at the release time instead, so please remove the commit :)
@chfast though wanted to have it in each PR, as I understood. |
No description provided.