Closed autodidaddict closed 4 years ago
For reference, the following functions will need to be ported to working within wasmtime's constraints:
externs, exported by host, imported by guest (wapc
namespace):
__console_log
__host_call
__guest_request
__host_response
__host_response_len
__guest_response
__guest_error
__host_error
__host_error_len
Functions called by host, exported by guest:
__guest_call
Note to self: One other thing that concerns me is that wasmer gives us a Ctx
inside the signature of the calls made out of the guest module into the host (which is 99% of the activity of the waPC contract). It looks like wasmtime's Callable
is in a trait, so it should theoretically be possible to maintain a reference to the wasmtime Instance
inside some struct so that in each of these functions we can manipulate the module memory.
More research. It looks like there's a way for the externs to have a VMContext
parameter, which should let me access the module's memory and functions. Deep down in the bowels of the cmdline binary, there's a signature translator:
Still trying to decipher how, or if, this is applicable.
Current version of waPC utilizes
wasmer
,wasmer-runtime
, andwasmer-wasi
for its webassembly interpreting and JIT compiling. See if it's possible to port this underlying support to the bytecode alliance'swasmtime
library.NOTES - It looks like function calling is pretty straightforward and should be easily translatable. The one embedding sample I've seen doesn't show how to construct the externs you pass to the module instance, nor does it show you how to manipulate module memory from a guest invocation, so those feel like the biggest unknowns.
Ideally I'd also like to know how well wasmtime performs when making simple invocations. The main things we need to be able to continue to do in the wasmtime implementation: