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
Gravity only works on Wasm32 right now because I took a shortcut in migrating to new versions of our WIT dependencies. We should support all architecture sizes.
How do you imagine the architecture size being passed down through the codegen? Would it be something passed as a CLI flag, or should we try and figure it out from the Wasm file?
I did a bit of digging into a wasm32 vs a wasm64 module and there are significantly more i64 globals and function parameters in the wasm64 module, so we could use that as a heuristic.
If we ever want to generate bindings that can be instantiated with any module bytes and are agnostic to architecture though, we would need to do runtime checks for the architecture size, then use different generated code for each branch. I'll throw together a PoC at some point because I'd like this to work!
I tried to tackle this in sd2k@df65772. It's based off a branch which is quite far ahead of main but I could easily backport it if it's an approach you'd consider. The easiest way to figure out what's going on is probably to look at the generated code, but basically we generate an Architecture type with a PointerSize method, store an instance on the factory and instance, allow the user to customise it at factory-creation time using an option, and use that field in the generated imports/exports to calculate the required pointer/length offsets, rather than hardcoding to size_wasm32().
Happy to add a wasm64 test and backport it if you like, I'm probably going to maintain it in my fork if not because I want to support components coming from big Go too!
Activity
sd2k commentedon Oct 16, 2025
How do you imagine the architecture size being passed down through the codegen? Would it be something passed as a CLI flag, or should we try and figure it out from the Wasm file?
sd2k commentedon Oct 16, 2025
I did a bit of digging into a wasm32 vs a wasm64 module and there are significantly more i64 globals and function parameters in the wasm64 module, so we could use that as a heuristic.
If we ever want to generate bindings that can be instantiated with any module bytes and are agnostic to architecture though, we would need to do runtime checks for the architecture size, then use different generated code for each branch. I'll throw together a PoC at some point because I'd like this to work!
feat: handle both Wasm32 and Wasm64 architectures
sd2k commentedon Oct 17, 2025
I tried to tackle this in sd2k@df65772. It's based off a branch which is quite far ahead of
mainbut I could easily backport it if it's an approach you'd consider. The easiest way to figure out what's going on is probably to look at the generated code, but basically we generate anArchitecturetype with aPointerSizemethod, store an instance on the factory and instance, allow the user to customise it at factory-creation time using an option, and use that field in the generated imports/exports to calculate the required pointer/length offsets, rather than hardcoding tosize_wasm32().Happy to add a wasm64 test and backport it if you like, I'm probably going to maintain it in my fork if not because I want to support components coming from big Go too!