> We now know that LP64 was the preferred choice and that it became the default programming model for 64-bit operating systems
That is incorrect, Windows never adopted the LP64 model. Only pointers were increased to 64-bit whereas long remained 32-bit. The long datatype should be avoided in cross-platform code.
> To support those needs, there were clutches like Intel’s PAE, which allowed manipulating up to 64GB of RAM on 32-bit machines without changing the programming model, but they were just that: hacks.
You can go look up how the 32-bit protected mode got hacked on top of the 16-big segmented virtual memory that the 286 introduced. The Global Descriptor Table is still with us on 64-bit long mode.
So, its not PAE that is particularly hacky, its a more broader thing with x86.
I find it weird that the convention to use char/short/int/long/long long has persisted so widely to this day. I would have thought that already back in the 16 -> 32 bit transition period people would have standardized and moved to stdint.h style types instead (i.e. int32_t etc).
Sure, that doesn't change pointer sizes, but it would have reduced the impact of the different 64-bit data models, like Unix LP64 vs Windows LLP64
x32 ABI support exists at least in the kernel of Debian (and Debian based) distributions, and I know because I've built Python versions (along with everything else needed for specific workloads) as x32 executables. The speed difference was minor but existing, but the memory usage was quite a lot decreased. I've worked with a similar ABI known as n32 (there was o32 for old 32, n32 for new 32 and n64 for fully 64-bit programs) on SGI systems with 64-bit capable MIPS CPUs; it made a difference there too.
Unfortunately I've read articles where quite-more-respected-than-me people said in a nutshell “no, x32 does not make a difference”, which is contrary to my experience, but I could only provide numbers where the reply was “that's your numbers in your case, not mine”.
Amazon Linux kernel did not support x32 calls the last time I tried, so you can't provide images for more compact lambdas.
Using indexes instead of pointers in data structures works well, and the cost of the base address + offset is negligible, as similar address calculation is already generated by the compiler when accessing into an element of a data structure. In addition to that, mention that indexes can be used as offsets, or as an actual indexes of the size of an individual element, i.e. in that case non-trivial data structures with e.g. >= 32-byte elements could address hundreds of gigabytes of RAM.
A practical use could be e.g. using bit fields can be convenient, e.g. having 32-bit indexes, with the higher bit for the color in a Red-black tree. And in case of requiring dynamic-sized items in the tree nodes, these could be in different 32-bit addressable memory pools.
armada651 ·74 days ago
That is incorrect, Windows never adopted the LP64 model. Only pointers were increased to 64-bit whereas long remained 32-bit. The long datatype should be avoided in cross-platform code.
Show replies
blueflow ·74 days ago
You can go look up how the 32-bit protected mode got hacked on top of the 16-big segmented virtual memory that the 286 introduced. The Global Descriptor Table is still with us on 64-bit long mode.
So, its not PAE that is particularly hacky, its a more broader thing with x86.
Show replies
zokier ·74 days ago
Sure, that doesn't change pointer sizes, but it would have reduced the impact of the different 64-bit data models, like Unix LP64 vs Windows LLP64
Show replies
tzot ·74 days ago
Unfortunately I've read articles where quite-more-respected-than-me people said in a nutshell “no, x32 does not make a difference”, which is contrary to my experience, but I could only provide numbers where the reply was “that's your numbers in your case, not mine”.
Amazon Linux kernel did not support x32 calls the last time I tried, so you can't provide images for more compact lambdas.
Show replies
faragon ·74 days ago
A practical use could be e.g. using bit fields can be convenient, e.g. having 32-bit indexes, with the higher bit for the color in a Red-black tree. And in case of requiring dynamic-sized items in the tree nodes, these could be in different 32-bit addressable memory pools.