> I had no idea WASM is 32bit until I read your article!

WASM(32) is a hybrid 32/64 bit architecture. The address range (and thus pointer size) is 32 bits, but it has native 64-bit integers. E.g. it's similar to the Linux x32 ABI.

There is also a 'true' 64-bit wasm, but that's still too recent to be used in real-world code:

https://caniuse.com/wf-wasm-memory64

(but wasm64 doesn't really make sense unless you really need an address space greater than 32 bits, because the downside is slower performance)

▲

jltsiren 2 hours ago | parent [-]

> (but wasm64 doesn't really make sense unless you really need an address space greater than 32 bits, because the downside is slower performance)

Or unless you need to use integer types that depend on pointer size (such as size_t or usize), but your integers are too large to fit in 32 bits. That's a pretty common occurrence in bioinformatics. I've been waiting for years for Wasm to become usable, but it looks like Apple is still holding it back.

	▲	senfiaj 22 minutes ago \| parent [-]
		Actually, WASM32 usually runs in a 64-bit browser, so it can utilize most of the 64-bit instructions and general purpose registers. The problem is it's much harder to ensure that 64-bit pointer don't access browser critical data structures such as stack or heap contents. At least for WASM32, the pointer arithmetic is easily forced to be 32-bit in natively running JIT-ed code without dramatic performance loses. So, it's guaranteed that the WASM32 module won't access anything further than 4 or 8GiB (4GiB + 4GiB, when doing more complicated effective memory addressing instructions), thus, it's easy to cage a 4GiB memory block and surround it with guard buffers of comparable size inside a 64-bit virtual address space. With WASM64 you can't do this optimization because 64-bit pointers easily access your browser's memory, you have to add a lot of runtime bound checks if the compiler static checker can't guarantee landing inside the safe address range.