> Web is 32-bit. Your 64-bit structs will break. This was the root cause of most of my bugs. WASM is 32-bit address space, pointers are 4 bytes not 8.
2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific rules in JS to get reliable 32bit arithmetic (but impossible for 64bit).
Wasm64 is implemented and works in Chrome and Firefox.. Apple is lagging again with Safari.
1: True, although it also limits the addressable memory and the typical 4GB limit seems less these days. I’m thinking of large apps like Figma running in the browser.
2: Will existing 32-bit WASM binaries break on WASM64 engines or does the binary have a flag for compatibility?
2: Most runtimes are 64bit already, A runtime detecting a wasm32 binary will just continue to generate code with the current JIT compiler whilst WASM64 will require another JIT (and perhaps memory system since WASM32 runtimes are often based on "hacks" where 4gb of address space is reserved but not given real memory so that the JIT compiler gets an easier job without security implications).
the thing is in WASM "memory" is more or less a resizable ArrayBuffer
and while each has an effective 4GiB limit wasm does allow passing more then one such buffer to any specific wasm "execution/thread"(1) you can then reference them in load/store instructions to load/store from other "memories" then the default one
As general purpose languages tend to not model that this isn't that easy to take advantage of but it is still useful for all kind of "tricks", like (non exhaustive):
- working around 4GiB size limit
- persistent memory between otherwise clean restarts and/or software updates (like what you can get from systemds file descriptor store and other means)
- easier handling of pre-populated memory (think large perfect hashmaps, trie, or similar)
- memory isolation, WASM memory can be shared, but for security and fault tolerance reasons it is often preferable if different workers have their own memory array as well as an additional shared memory array.
- This also allows stuff like security proxies where A->B have a shared memory IPC mechanism and B->C have that too, but A->C can directly communicate at all. Not that relevant in the browser and more for server side WASM usage.
- and more
Anyway IMHO the main point for WASM64 is more the convenience benefits then the 32bit memory limitations. Like porting is easier, most software is 64bit today. Like it's what people are used to. There are a lot of ways where overflows can happen with 32bit but are practically impossible for 64bit. E.g. overflowing 0u64 with +=1 at 6e9 ops/s takes decades, but for 0u32 it's <1s. Stuff like that means you need far more sanity&safety checks in 32bit and it's easier to mess up edge cases.
https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
TL;DR: wasm64 requires explicit heap bounds checks, while in wasm32 the memory mapping hardware does it for free.
E.g. quote:
"The only reason to use Memory64 is if you actually need more than 4GB of memory.
Memory64 won’t make your code faster or more “modern”. 64-bit pointers in WebAssembly simply allow you to address more memory, at the cost of slower loads and stores."
The real mistake is requiring pointer to be 64 bit when most programs don’t use it.
For reference 4 GB is 8x more than a ps3.
It didn't. WASM has true 64 bit integers (or specifically, the base types of WASM are: i32, i64, f32 and f64 - where the integer types are 'sign agnostic' like CPU registers).