Bidirectional native integration

[fengb]

Continuation of #8

Imported functions currently run in "native" mode. This means trying to use a wasm module instance in any of these functions is borderline impossible, and even if it does succeed, it'd immediately crash with a mutex error.

Example code:

(module
  (type (;0;) (func (param i32) (result i32)))
  (type (;1;) (func (param i32 i32) (result i32)))
  (import "env" "fibonacci" (func (type 0)))
  (func $mul (type 1)
    local.get 0
    local.get 1
    i32.mul)
  (export "mul" (func $mul)))

fn fibonacci(ctx: *Execution, num: i32) i32 {
    return ctx.invoke(num, num);
}

Things that need to happen to get this usecase working:

1. Convert imported functions to require *Execution as first argument.
2. Expose fn invoke() of sorts. This should be very similar to fn run()... possibly the same?
3. Should we stick the native execution frame onto the wasm stack?
   • if so, how do we store the frame?
   • if not, how do we track divergent executions? e.g. wasm -> native -> wasm -> native

[fengb]

Instance.Func = struct {
    name: ?[]const u8,
    func_type: usize,
    body: union(enum) {
        local: struct {
            locals: []Type.Value,
            instrs: []Instr,
        },
        import: struct {
            ptr: *@OpaqueType(),
        }
    }
};

Execution.Frame = packed union {
    func: u32,
    _pad: u128,
    impl: packed struct {
        func: u32,
        top: u32,
        instr: u32,
    },
    import: packed struct {
        func: u32,
        size: u32,
        frame: anyframe,
    },
};

Sharing the stack between native and wasm makes perfect sense. Similar to how "locals" takes up virtual space, we can use the same mechanism to store the async frame. Doing a corresponding wasmCall can automatically suspend the current frame and circle back when it's ready.

[fengb]

[fengb]

Running into lots of problems with async compiler bugs. This will probably have to wait until stage2