How does K/WASM plan to support memory64 proposal, specifically current unsafe wasi interop apis, wh...

# webassembly

[Oleg Yukhnevich]

How does K/WASM plan to support memory64 proposal, specifically current unsafe wasi interop apis, where pointer is UInt?
Will it be similar to K/N with 2 different targets, or no?

[Oleg Yukhnevich]

@Svyatoslav Kuzmich [JB] any idea on this?

[Svyatoslav Kuzmich [JB]]

Current thoughts is to keep the default memory as 32 bit, and add support for declaring and importing/exporting additional memories via multi-memory proposal. They could be either 32- or 64-bit.
Current unsafe APIs can’t express this. We’ll need to come up with a separate flexible low-level API.

[Svyatoslav Kuzmich [JB]]

Hopefully we won’t need separate targets

[Oleg Yukhnevich]

let believe in it 🙂
thought, introducing separate targets, like we have with native is also will be ok (from first sight, this looks similar to f.e. iosArm32 and iosArm64)
BTW, rust now has wasm32 (with different variants per emscripten and wasi) and wasm64 https://doc.rust-lang.org/rustc/platform-support.html (Im not writing in rust, just researching)

[Svyatoslav Kuzmich [JB]]

K/Wasm, unlike K/N and Rust, doesn’t use linear memory for its own allocations. Memory is used primarily to interoperate with others who use it, and depending on what other modules use, we could support both memory types at the same time in a single program.

[Svyatoslav Kuzmich [JB]]

Current sketch:

// stdlib

// Can only be implemented by empty top-level objects with special annotations
interface WasmMemory32
interface WasmMemory64

fun <reified T : WasmMemory32> loadInt(ptr: Pointer32): Int
fun <reified T : WasmMemory64> storeInt(ptr: Pointer64, value: Int)

// app

@WasmImport("otherModule", "memory")
object MyImportedMemory32 : WasmMemory32

@WasmMemoryLimits(minPages = 10, maxPages = 20)
object MyMemory64 : WasmMemory64

fun copyIntBetweenMemories(into: Pointer32, from: Pointer64) {
    storeInt<MyImportedMemory32>(
        into,
        loadInt<MyMemory64>(from)
    )
}

[Svyatoslav Kuzmich [JB]]

Of course you can create a separation of platforms in “user-space” by choosing a single memory of needed size in each platfrom and making new expect/actual-ed pointer type

[Oleg Yukhnevich]

Sounds interesting, and from first sight is super cool, will see how it will go :)
Though, I would prefer an API with explicit provinding of object instead of type if possible
Like ‘WasmMemory32.loadInt(ptr)’
Generics are not so easy to propagate when you want to provide some abstractions over it

[Svyatoslav Kuzmich [JB]]

These are just thoughts that we’ll have to validate, indeed 🙂

We’ll bikeshed the syntax and names, for sure. But we’ll want to make sure that at the lowest level each load knows it’s memory, because memory index is an immediate in Wasm. We could make a less efficient version of first-class memories on top of that.

[Oleg Yukhnevich]

Sound good!
Will try to keep my ffi up-to-date with all latest changes :)