Instructions for duplicating and swapping values on stack

[mikevoronov]

Hi! I am trying to use WIT for server-side modules and found that it is a bit tricky. Basically, because there are no "common" instructions to stack-based virtual machines like dup and swap. In my setup I have several Wasm modules with separate incapsulated memories. Each module could have exports/imports with corresponding adapters.

Let's imagine two modules: ipfs_node and ipfs_rpc. The first, ipfs_node has exports with corresponding adapters. The second, ipfs_rpc also has exports and imports from ipfs_node. Each adapter has following type @interface type (func (param string) (result string))). So let's follow a little bit a process of calling ipfs_node imports from ipfs_rpc:

;; ipfs_rpc: adapter for import function ipfs.get
(@interface func (type 9)
    arg.get 0
    arg.get 1
    string.lift_memory
    call-core 9             ;; call ipfs_node.get that returns string
    dup
    string.size
    call-core 0             ;; call allocate
    swap2
    string.lower_memory
    call-core 5             ;; call set_result_size
    call-core 6             ;; call set_result_ptr
)

;; ipfs_node: adapter for export function get
(@interface func (type 8)
    arg.get 0
    string.size
    call-core 0         ;; call allocate
    arg.get 0
    string.lower_memory
    call-core 7         ;; call self.get
    call-core 3         ;; call get_result_ptr
    call-core 2         ;; call get_result_size
    string.lift_memory
    call-core 3         ;; call get_result_ptr
    call-core 2         ;; call get_result_size
    call-core 1         ;; call deallocate
)

Here I am using functions like {get, set}_result_ptr, {get, set}_result_size, because Wasmer isn't support multi-value now. So the interesting part of this flow is following:

1. Raw ipfs.get called from Wasm side of ipfs_rpc. It receives two i32 (ptr and size).
2. These 3 instructions are needed to get string from memory of ipfs_rpc

   arg.get 0
   arg.get 1
   string.lift_memory

3. Then ipfs_node export adapter is called and returns string on the stack.
4. Then we need to push this string to memory of the ipfs_rpc module. To do this we have to lower memory with string.lower_memory that consumes string object and pointer to module memory from the stack. In its turn, to obtain module memory pointer we need string size, so we have to call string.size that also consumes string object. So here we need some mechanism for duplicating and swapping values on stack. I solved it with following set of instructions (I extended WIT interpreter with these two instructions):

    dup
    string.size
    call-core 0             ;; call allocate
    swap2
    string.lower_memory

I don't know is it possible to do this without very messy tricks like returning string object together with its size from callee module. It seems reasonable to add these possibilities in some form.

[fgmccabe]

instead of stack ops like dup, swap etc we are proposing the use of let: effectively a temporary local. This is part of the function reference types proposal https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md

[mikevoronov]

Thanks! Will take a look, are there any plans to include let to the WIT proposal in the nearest future?

[fgmccabe]

I don't know what WIT folk are planning. But, they will likely follow what goes on in Interface Types on this kind of issue.

[mikevoronov]

Maybe I am getting smth wrong, are WIT (Wasm Interface Types) and Interface Types the same thing? Or maybe you mean Typed Functions instead of Interface Types.

[fgmccabe]

WIT is a sub-proposal which is part of WASI. Not really the same as Interface Types; although there is a somewhat close connection :)

[mikevoronov]

Ohh, I thought it is called WITX (or module types/linking) :). Thank you.

[mikevoronov]

So, are there any plans to include let to the interface-types proposal in the nearest future? :) I am super interested in it, because our current sub-idea (Wasm RPC) is based on interface types (yes, we know that interface-types is very unstable, but the only alternative to us is to write something like that ourself).

[fgmccabe]

this is still under discussion.