41–50 of 116 posts
The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
You don't need 4GB and it wastes memory to make pointers twice as big? Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.
I don't think that ever had much, if any, adoption and it looks like it will be removed in the next few releases.
Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > 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.
The real mistake is requiring pointer to be 64 bit when most programs don’t use it.
Earlier quoted context omitted.
1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization). 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 r…
Thanks! 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 memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.
Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > 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.
With regards to 1), do not write/read structs directly to/from files. Instead write a proper serializer/deserializer. Without it, you may encounter another breakage soon when a different compiler/compiler options insert different struct padding bytes, which will then once again make your data non-portable, and a maliciously crafted save file with no length/size field validation on the deserializer level can lead to a…
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
You really need a serializer for this sort of thing because it can also include forwards compatibility of your data structures.
Earlier quoted context omitted.
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
If you modify or even just move fields around the struct that also changes the way they are serialized... You really need a serializer for this sort of thing because it can also include forwards compatibility of your data structures.
Earlier quoted context omitted.
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
Specified by whom? Not the C standard for sure. It is indeed soecified by individual ABIs, and ABIs don't tend to do anything too weird, but that's another question.
Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again? > 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.
Because a web page shouldn’t use 4 GB of ram, and the win is that each pointer can be half the size (better for memory and cache). The real mistake is requiring pointer to be 64 bit when most programs don’t use it.