WASI 64

[trcrsired]

I am working on creating the wasi64 interface. Put an issue here so we can have a discussion.

WebAssembly/wasi-libc#444

[cpetig]

As a related topic I really miss a way to express size_t in WIT/WASI, e.g. like "(un)signed-pointer" or "sptr" mapping to i32 or i64 depending on the target architecture.

A 32bit entity with no unnecessary overhead for wasm32, but flexible enough for a 64bit pointer in wasm64 where it is needed. (To be honest this probably feels unnecessary as long as you only work with wasm32 targets, my strongest motivation stems from also using WIT for native application interfaces)

This is most felt in the wasi-thread implementation for wasm64 (part of your patch) where the code doesn't match the witx definition.

PS: I searched for any discussion of this topic in the archives, but did only find posts predating wasm64 advancing to phase 3. And WebAssembly/memory64#43 indicates that there is some work left before progressing to phase 4.

[loganek]

Based on the PR there's some ambiguity around naming nad potential other concerns; I'm going to prepare a few slides and discuss the concerns with the WASI subgroup in the meeting: WebAssembly/meetings#1479

[cpetig]

In the meantime I learned that there are architectures where intptr_t and size_t have different size, but that might be out of scope for WIT, even though I wouldn't mind making this distinction.

E.g. see https://stackoverflow.com/questions/1464174/size-t-vs-uintptr-t

So signed-pointer and signed-size would be the long names, perhaps the shorter pointer and size and uptr and usize look more elegant?

[sunfishcode]

A major concern here is maintenance. wasi-libc maintenance resources are not abundant right now, and adding another dimension of targets creates more work for everyone. And the more work we do extending Preview 1, as proposed here, the more work it takes to transition to Preview 2.

[trcrsired]

In the meantime I learned that there are architectures where intptr_t and size_t have different size, but that might be out of scope for WIT, even though I wouldn't mind making this distinction.

E.g. see https://stackoverflow.com/questions/1464174/size-t-vs-uintptr-t

So signed-pointer and signed-size would be the long names, perhaps the shorter pointer and size and uptr and usize look more elegant?

on wasm it does not matter. Also, i do not think you should try to make wasm support these wierd architectures, because clearly wasm does not support things like i24, it only supports i8,i16,i32,i64. there are no i24 for example. So wasm only supports sizeof(size_t) == sizeof(uintptr_t) == sizeof(void*)

i did changed that to uintptr_t and size_t, but wasi folks do not want to make that change. it does not matter either.

[cpetig]

I just found Luke proposing idxtype from the memory64 spec in 2022 at WebAssembly/component-model#22 (comment) - so perhaps this name could become consensus.