Skip to content

Add memory64 and table64 support to the Canonical ABI#624

Draft
adambratschikaye wants to merge 1 commit intoWebAssembly:mainfrom
adambratschikaye:abk/memory64
Draft

Add memory64 and table64 support to the Canonical ABI#624
adambratschikaye wants to merge 1 commit intoWebAssembly:mainfrom
adambratschikaye:abk/memory64

Conversation

@adambratschikaye
Copy link

Parameterize the Canonical ABI to handle 32-bit or 64-bit memory addresses and table indices. This is done by adding two new fields to LiftOptions to indicate if the memory64/table64 feature is being used in a core module.

Parameterize the Canonical ABI to handle 32-bit or 64-bit memory
addresses and table indices. This is done by adding two new fields to
`LiftOptions` to indicate if the `memory64`/`table64` feature is being
used in a core module.
Copy link
Collaborator

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for helping to pick this up! We chatted a bit on Zulip but for posterity I'll mention here about table-related index types how most of them want to remain 32-bits. I'll take a closer look once that's been passed over here, and in the meantime I skimmed over things and noted a few things here and there. I'm sure though that @lukewagner will have thoughts on this too!

(param $originalSize i32)
(func (param $originalPtr $addr)
(param $originalSize $addr)
(param $alignment i32)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this I might recommend making alignment have type $addr as well for consistency, and I think that matches the signature in Rust/C/etc as well.

| -------------------------- | ------------------------ |
| Approximate WIT signature | `func<T>(t: T) -> T.rep` |
| Canonical ABI signature | `[t:i32] -> [i32]` |
| Canonical ABI signature | `[t:$idx] -> [i32]` |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This'll be a bit subtle, but this'll actually want to be a mapping of i32 as an argument (I talked with you a bit about this already, but the input here is a host-side index so always 32-bit), but the output here should be something variable. Resource "rep"s are generally pointers in linear memory so 64-bit components are going to want 64-bit storage values. In the component model resources are defined with (rep i32) and validation currently requires that i32 is the only one listed there, but this PR will relax that meaning that the resource type itself stores the lowered type which'll get plumbed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants