OSDev.org

...so I was checking out wikipedia.

32-bit gives you 4gb memory access.
64-bit gives you 16 exabytes

But according to the wiki most systems only use up to 48-bit addressing. So what does that give you? I think it's around 281terabytes.. am I right? Or did I mess up my math.

[edit]
My scientific calculator give 281 terabytes
Windows calculator gives me 288 terabytes
[/edit]

Erm... how do you calculate that?

2^48 = 281,474,976,710,656 bytes
= 274,877,906,944 KiB
= 268,435,456 MiB
= 262,144 GiB
= 256 TiB

The rest, I guess, are confusions of 2^x (Tebibyte, factor 1024) with 10^x (Terabyte, factor 1000)...

See Terabyte.

ahh.. i didn't factor in the 1024 thing.

Hi,

kubeos wrote:But according to the wiki most systems only use up to 48-bit addressing.

Most (all?) 64-bit 80x86 Intel CPUs only support 36-bit physical addressing (even though some of the earlier CPUs incorrectly report support for 48-bit physical addressing via. CPUID). The architectural maximum is 52-bit physical addressing. I don't think any CPU supports this (yet).

Also note that for AMD CPUs the "up to 52-bit physical addressing" is also supported in protected mode if you use PAE, so that (in theory) a 32-bit OS would be able to access (almost) 4096 TiB of RAM. I'm not sure if Intel have (or will?) do the same for PAE (if they don't, then PAE would still be limited to 36-bit addressing even if the CPU itself supports more). I'd assume Intel would also support "up to 52-bit physical addressing" with PAE (there's no reason not to), but assumptions suck.

For linear addressing, AFAIK all 64-bit CPUs support 48-bit linear addressing, which is also the (current) architectural limit. CPU manufacturers would need to add a fifth level to the paging structures (e.g. a "PML5") or create entirely different paging structures to allow more than 48-bit linear addressing.

When CPU manufacturers do increase the linear address space size (you know it'll happen eventually), OS developers would need update their linear memory management code, but the change would be entirely transparent to applications (in a well designed OS).


Cheers,

Brendan

Brendan wrote:When CPU manufacturers do increase the linear address space size (you know it'll happen eventually), OS developers would need update their linear memory management code, but the change would be entirely transparent to applications (in a well designed OS).

I was just thinking about this. In a well designed 64 bit kernel, it seems to me like the kernel should not even have to be changed to support the larger linear address code (I haven't actually tested this and may well be wrong!).

If you use canonical addresses (which you have to anyway) and your kernel is right at the top of virtual RAM, surely you can assign process address spaces dynamically depending on the particular values reported by CPUID?

Cheers,
Adam