Interaction with the memory64 proposal

[alexcrichton]

With the memory64 proposal for WebAssembly this will change the internal representation of types in the canonical ABI, notably where strings/lists now have 64-bit pointers and lengths instead of 32-bit pointers/lengths as they would today. The canonical ABI isn't fully fleshed out on the main branch yet but I wanted to open this issue ahead of time to start the discussion and log it at least.

In my mind the memory64 proposal provides a great opportunity to showcase how definitions of APIs at the component model layer works well regardless of the underlying wasm module. For example today WASI isn't specified for memory64 and might take a significant amount of work for both engines and toolchains alike to all catch up and define something for memory64. That being said if WASI were defined with the component model then defining the canonical ABI lowering from interface types to memory64 memories would be all that's necessary and bindings generators/engines would be updated appropriately to pick up support quickly.

In any case this is also somewhat of a pretty future-facing feature because of the relatively early stages of not only the memory64 proposal but also adoption in general. I figured it might be useful to keep in the back of our heads when defining the canonical abi though (e.g. the size of a type now needs to be parameterized on the size of memory in addition to the type itself)

[lukewagner]

Great points! It's not in #23 yet (and probably won't be added super soon because, as you said, memory64 is a bit farther out), but roughly the plan I was thinking about is using the idxtype of the memtype referred to by the (memory <memidx>) canonopt (of canon.lift/canon.lower) to determine whether flatten/lift/lower/etc all used i32s or i64s for pointers.

[alexcrichton]

I might actually propose that this may wish to be handled sooner-rather-than-later. I think that specifying this should ideally be pretty lightweight and basically just plumbing around the idxtype to more places in the canonical abi doc, and my thinking is that it would be good to get such refactorings in sooner rather than later ideally.

I agree though that the binary format probably doesn't change at all, only validation and how the rules are written up.

[lukewagner]

Fair enough, sounds good.

[alexcrichton]

As a minor note on this I wanted to give a heads up that I'm proposing to implement a new validation predicate in wasm-tools to reject components using 64-bit/shared linear memories/tables. This is inspired by turning memory64 on-by-default in Wasmtime coupled with the fact that components don't support 64-bit memories in most of the runtime, so this is one of the easier ways to ensure we don't uncover any accidental bugs by allowing memory64 on core wasm.