You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to support wasm64, with 64-bit wide pointers, we need to relax the constraint in the Component Model and Canonical ABI that pointer types fit in 32 bits.
Ideally the generated Go code for a component can handle pointer widths of either 32 or 64 bits without baking assumptions into the precise memory layout of structures into the lifting and lowering code.
Tasks
Reconcile this with proposed wasm64 support in the Component Model spec.
Introduce "integer pointer" type (e.g. uintptr) with size/alignment that varies based on arch. For instance, when flattening a variant type with a string or list<T>, the flattened pointers resolve to a uintptr in Go.
Thread this flexible width concept through the ABI, lifting, and lowering code in wit and wit/bindgen.
The text was updated successfully, but these errors were encountered:
In order to support
wasm64
, with 64-bit wide pointers, we need to relax the constraint in the Component Model and Canonical ABI that pointer types fit in 32 bits.Ideally the generated Go code for a component can handle pointer widths of either 32 or 64 bits without baking assumptions into the precise memory layout of structures into the lifting and lowering code.
Tasks
wasm64
support in the Component Model spec.uintptr
) with size/alignment that varies based on arch. For instance, when flattening avariant
type with astring
orlist<T>
, the flattened pointers resolve to auintptr
in Go.wit
andwit/bindgen
.The text was updated successfully, but these errors were encountered: