32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit x86 only up to 64 GB. Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.
But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.
32-bit x86 linux will typically support 3GB per process, with 1GB kernel address area, I think? (Windows did 2GB / 2GB split by default, custom boot options can change it to 3GB / 1GB, but only some 32-bit apps fully supported it, like photoshop).
Also, FWIW, security people can get real bothered that ASLR doesn't do much in 32-bit systems.
So, I think starting around 2GB DRAM, it's probably a "big enough" system to justify a 64-bit OS.
On 32 bit you can of course make the kernel higher half, but yes AFAIK most mainstream kernels chose higher quarter to grant more vaddr space to processes.
> But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.
There is the x32 ABI - 32-bit pointer length, but the AMD64 ISA. I don’t think it ever saw significant adoption though.
32 bit gave you that much with PAE, which has its own set of unfortunate problems.
I still think it's pretty safe to say 64 bit is the future, and will be for a long time (if I live long enough for 128 bit processors to become defacto or even widely necessary I'll be truly shocked).
But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.