lukewagner
commented
7 months ago I think you're right that the component model opens up some new opportunities to move endianness support into the runtime (and the auto-generated host bindings, e.g., by wit-bindgen).
First, just to be very clear, we can't do anything about the endianness of the core wasm being executed (which is fixed by the core wasm standard to be little-endian) or the Canonical ABI as exposed to core wasm (which must match core wasm). However, in theory host bindings generation (which takes care of all the low-level details of reading these little-endian bytes out of core wasm and presenting it in the host impl language) could indeed automatically do the necessary endian conversions so that the manually-written host code could be written in an endian-agnostic manner.
To support this, I'm not aware of anything we need to additionally do at the component-model spec level (just by clearly specifying the semantics of lifting and lowering, we've already given the host bindings generator all it needs to Do The Right Thing(tm)). Rather, I'd imagine you'd try out existing host-bindings generator tools on a big-endian platform and see if anything breaks and submit feedback on the appropriate tooling repos.
SoniEx2
sunfishcode
rossberg
WebAssembly has so far pretty much refused to consider questions related to the interoperability between little-endian guest (wasm) code and a big-endian host. For example, the current approach to wasm-c-api expects values in the wasm memory to be seen as little-endian by the host, requiring an endian swap on every load and store as well as emulation of atomics using compare-and-swap/compare-and-exchange. In other words, wasm-c-api simply ignores the existence of host endianness. However, the component model is in a different position, from what we can understand of it, the component model is effectively trying to be an ABI schema, which is something much more malleable than the wasm-c-api.
We would appreciate if the component model took into consideration wabt's slightly unusual (in the wider space of big-endian-supporting wasm engines) implementation approach. In particular, it'd be really cool if the component model enabled writing host-endian-agnostic host interface implementations, like WASI, thus moving any necessary endian and/or memory layout conversions into the wasm engine and out of the WASI implementation.