# How can a 32bit CPU have an addressable memory size of 16TB?

Frequently, on a 32-bit CPU, each page-table entry is 4 bytes long, but that size can vary as well.

A 32-bit entry can point to one of $$2^{32}$$ physical page frames.

If frame size is 4 KB (212), then a system with 4-byte entries can address $$2^{44}$$ bytes (or 16 TB) of physical memory.

The above statement is taken from the book "Operating System Principles" by Galvin.

If all 32 bits in a 32-bit CPU are used to refer to pages , then we can have $$2^{32}$$ pages. But then no more bits will be left to point to memory inside a page of size $$2^{12}$$ bits since all 32-bits have been used up.

How can we thus say that $$2^{44}$$ bytes are addressable?

• The extra 12 bits still must exist somewhere, they are just faked in a backwards-compatible way. Oct 16 '19 at 18:44
• Had they not been faked the CPU could have accessed the memory faster, right? There wouldn't have been a need to store the bits part by part and then work on it. Oct 16 '19 at 22:27
• Yes, which is one of the many reasons to go 64-bit. Also, usually PAE is limited to the OS and individual applications are still limited to 4 GB. Oct 16 '19 at 22:28
• Is there any specific reason to why would someone want a 32bit CPU to be able to address more than 4GB of memory? Even if swapping is taken into account, won't that degrade the performance a lot? Oct 16 '19 at 22:35
• The answer is that it was less work than going to 64-bit. And, yes, it was a complete disaster, requiring jumping through many hoops: cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae Oct 17 '19 at 9:54

The $$32$$ bit page frame address acts as a base address and will be typically stored in an index register.
An individual machine code instruction (e.g. a branch instruction) will then contain a $$12$$ byte bit offset. The offset is added to the base address to create the complete $$44$$ byte bit address.