For the wasm->js calls (exits), I think that GC doesn't pose a specific problem, because the wasm caller is responsible for rooting the values. I think I can manage to implement interpreter exits with no issue.
For js->wasm calls (entries), I had a thought: perhaps we should generate webassembly stubs -- like, stubs written in WebAssembly. If you have:
```
(module
(function $f (export "f") (result i32 anyref f64)
...))
```
Then you would generate the equivalent of:
```
(module
(import "env" "void-to-i32-anyref-f64" $target
(func $target (result i32 anyref f64)))
(import "env" "make-array"
(func $make-array (param i32) (result anyref)))
(import "env" "array-set-i32"
(func $array-set-i32 (param i32 anyref i32)))
(import "env" "array-set-f64"
(func $array-set-f64 (param f64 anyref i32)))
(import "env" "array-set-anyref"
(func $array-set-anyref (param anyref anyref i32)))
(function export "void-to-i32-anyref-f64-stub" (result anyref)
(local $array anyref)
(call $target)
(i32.const 3)
(call $make-array)
(local.tee $array)
(i32.const 0)
(call $array-init-i32)
(local.get $array)
(i32.const 1)
(call $array-init-anyref)
(local.get $array)
(i32.const 2)
(call $array-init-f64)
(local.get $array)))
```
and instantiate the stub module with the target function, as well as with the helpers.
Bug 1595031 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
For the wasm->js calls (exits), I think that GC doesn't pose a specific problem, because the wasm caller is responsible for rooting the values. I think I can manage to implement interpreter exits with no issue.
For js->wasm calls (entries), I had a thought: perhaps we should generate webassembly stubs -- like, stubs written in WebAssembly. If you have:
```
(module
(function $f (export "f") (result i32 anyref f64)
...))
```
Then you would generate the equivalent of:
```
(module
(import "env" "void-to-i32-anyref-f64" $target
(func $target (result i32 anyref f64)))
(import "env" "make-array"
(func $make-array (param i32) (result anyref)))
(import "env" "array-set-i32"
(func $array-set-i32 (param i32 anyref i32)))
(import "env" "array-set-f64"
(func $array-set-f64 (param f64 anyref i32)))
(import "env" "array-set-anyref"
(func $array-set-anyref (param anyref anyref i32)))
(function export "void-to-i32-anyref-f64-stub" (result anyref)
(local $array anyref)
(call $target)
(i32.const 3)
(call $make-array)
(local.tee $array)
(i32.const 0)
(call $array-set-i32)
(local.get $array)
(i32.const 1)
(call $array-set-anyref)
(local.get $array)
(i32.const 2)
(call $array-set-f64)
(local.get $array)))
```
and instantiate the stub module with the target function, as well as with the helpers.
For the wasm->js calls (exits), I think that GC doesn't pose a specific problem, because the wasm caller is responsible for rooting the values. I think I can manage to implement interpreter exits with no issue.
For js->wasm calls (entries), I had a thought: perhaps we should generate webassembly stubs -- like, stubs written in WebAssembly. If you have:
```
(module
(function $f (export "f") (result i32 anyref f64)
...))
```
Then you would generate the equivalent of:
```
(module
(import "env" "void-to-i32-anyref-f64" $target
(func $target (result i32 anyref f64)))
(import "env" "make-array"
(func $make-array (param i32) (result anyref)))
(import "env" "array-set-i32"
(func $array-set-i32 (param i32 anyref i32)))
(import "env" "array-set-f64"
(func $array-set-f64 (param f64 anyref i32)))
(import "env" "array-set-anyref"
(func $array-set-anyref (param anyref anyref i32)))
(function export "void-to-i32-anyref-f64-stub" (result anyref)
(local $array anyref)
(call $target)
(i32.const 3)
(call $make-array)
(local.get $array)
(i32.const 2)
(call $array-set-f64)
(local.get $array)
(i32.const 1)
(call $array-set-anyref)
(local.tee $array)
(i32.const 0)
(call $array-set-i32)
(local.get $array)))
```
and instantiate the stub module with the target function, as well as with the helpers. *edit: updated order of results*