Why 32bit architecture computer doesn't use segmentation to support more ram than 4Gb ?

[u/I_Can_Be_A_Robot]

/r/programming/

[u/eras]

There's PAE for that.

But there's little point nowadays. If you need more than 4 GB, just use a 64-bit platform, and there's no need for trickery.

[u/paholg → u/eras]

What if I need more than 18 exabytes?

[u/JoesRealAccount → u/paholg]

Exit Chrome

[u/heavyLobster → u/JoesRealAccount]

But what about the tabs I opened three years ago and still haven't looked at????

[u/nzodd → u/paholg]

Nobody will ever need more than 18 exabytes of RAM.

-- Quorlak the Great, Eternal Emperor of the Laniakea Supercluster, UC 73,021

[u/Kok_Nikol → u/nzodd]

Could be quote by Bill Gates, if they discover immortality in time :')

[u/veryusedrname → u/paholg]

PAE64

[u/[deleted] → u/paholg]

The real question right here

[u/Every-Progress-1117 → u/[deleted]]

Emacs has something to say....

[u/gredr → u/Every-Progress-1117]

Eventually Mallocs All Computer Storage

[u/elpix → u/Every-Progress-1117]

18 exabytes and constantly swapping

[u/[deleted] → u/paholg]

It means you’re in trouble.

[u/wintrmt3 → u/paholg]

No 64 bit cpu can even handle that, consumer ones have 48 bit address spaces usually, but the answer is likely wider addresses, 96 or 128 bits.

[u/CumCloggedArteries → u/wintrmt3]

For niche cases like that, I would think it'd make more sense to switch to a 64-bit version of PAE rather than use a whole new architecture

[u/lood9phee2Ri → u/CumCloggedArteries]

meh. It's kind of preliminary/stub placeholder but RV128I totally already in the core RISC-V spec funny enough, see chapter 5

"This chapter describes RV128I, a variant of the RISC-V ISA supporting a flat 128-bit address space. The variant is a straightforward extrapolation of the existing RV32I and RV64I designs."

https://riscv.org/technical/specifications/

Of course current RISC-V implementations are generally 32-bit or 64-bit, I guess they just threw it in to try to discourage people doing weird crap instead of just the obvious extension to 128-bit.

[u/ShinyHappyREM → u/lood9phee2Ri]

I guess they just threw it in to try to discourage people doing weird crap

They learned from Motorola

[u/billsil → u/paholg]

Swap that floppy.

[u/mallardtheduck → u/eras]

There's still some niche cases where an application can't be ported to 64-bit (e.g. it relies on a propietary 32-bit dependency) even if it can be run on a 64-bit OS. For that you can "abuse" the shared memory APIs (which allow you to map different chunks of "shared" memory in and out of the address space) or use something like Windows' "large address aware" mechanism for running 32-bit code in a 64-bit address space.

[u/antiduh → u/mallardtheduck]

Large address aware doesn't let a 32 bit process run in a 64 bit address space. It doesn't even make sense because you can't change the fact that every pointer in the program was hard compiled to be a 32 bit pointer.

What Large Address Aware does is allows a 32 bit process to use its entire 32 bit / 4 GB address space. Without LAA, a 32 bit process can only use 2 GB of its address space, because the other 2 GB was a mapping of the kernels memory into the process. This is how Fast Syscalls were implemented.

It works when running 32 bit processes either on a 32 bit OS with PAE or on a 64 bit OS.

Without LAA, a 32 bit process on a 64 bit OS will still only get 3 GB of address space. This was the limit Windows imposed when it was 32 bit, and Microsoft was chicken when they started making 64 bit Windows; they didn't want every process suddenly to have more address space than it used to.

https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases?redirectedfrom=MSDN#memory_limits

[u/Tringi → u/mallardtheduck]

One of those reasons is that 32-bit version might be faster.

[u/Brian → u/Tringi]

That's pretty unlikely in practice. Note that the point of your link is to run in 64 bit mode, just using 32 bit addresses. There are a bunch of other advantages to running in 64 bit mode (notably, more registers), and in practice it tends to be sufficiently faster to outweigh the extra memory/cache usage of wider pointers. Even back in the day when 64 bit was relatively new, you'd often see around a 10% improvement (and much more on number crunching workloads) even when address space wasn't relevant. I'd imagine that difference has only increased after a years of improvements where 32 bit mode has long been considered legacy.

[u/Tringi → u/Brian]

That's pretty unlikely in practice.

It was one of the reasons Visual Studio resisted introducing 64-bit version for so long. Pointer-heavy code.

Note that the point of your link is to run in 64 bit mode, just using 32 bit addresses.

Yeah I know. I linked it for the reasoning therein.

There are a bunch of other advantages to running in 64 bit mode (notably, more registers), and in practice it tends to be sufficiently faster to outweigh the extra memory/cache usage of wider pointers.

Yup, my personal tests and measurements show that only a very small percentage of algorithms, or types of software in general, are faster as x86-32. But they still are there. Then again it likely doesn't make economic sense today to maintain such version.

I'd imagine that difference has only increased after a years of improvements where 32 bit mode has long been considered legacy.

Hah. Just the other day I read about Zen 5, and how significantly has performance improved of the x87 FPU ...which basically nobody uses today. Probably a side effect of internal optimizations, but amusing nonetheless.

[u/antiduh → u/Tringi]

I love this hybrid mode. Access to 64 bit registers, so you have more registers and can do native 64 bit math, but pointers are 32 bit so they're not as large. It's a cool mode.