I was recently thinking about how 32-bit processors can only support up to 4 GBs of memory, and I couldn't understand why the amount of bits a processor has limits its memory. I understand, as other questions on here state, that a binary number with 32 digits can only address up to 4 GB. But why can't a computer use two variables to reference memory, and effectively 'act' like it's 64 bit (kinda like how 32-bit processors can use 64-bit integers)?

Is that possible and would it reduce performance? If it would reduce performance, what if the operating system used the 'fake' 64-bit memory references with certain programs, rather than system-wide?

  • 2
    Possible duplicate of Why is there RAM usage limitation in 32-bit Operating Systems? – Ramhound Nov 28 '15 at 3:56
  • @Ramhound not a duplicate of that. His question asks about why that limit exists in the first place, the answer being the limit of 32-bit integers. My question is asking about why that limit cannot be transcended by using 2, 32-bit variables to refer to memory and the reasons that may or may not work. – Oztaco - Reinstate Monica C. Nov 28 '15 at 4:01
  • 1
    Have you looked up Physical Address Extension? It works in a way that's very similar to what you described. – Larssend Nov 28 '15 at 4:14
  • @Larssend no, I didn't know that's what it was called. Thank you – Oztaco - Reinstate Monica C. Nov 28 '15 at 4:31
  • It is not so much a question of "two variables" but one of address translation. In a virtual memory environment RAM size is not limited by the size of the CPU's GPRs but rather by the size of the physical page number field in the page table entries. It is more or less coincidence that x86's designers chose to make this 20 bits, just like the virtual page number portion of a virtual address. Hence the RAM size limit was the same as the virtual size limit. PAE fixed that, initially supporting 24-bit instead of 20-bit physical page numbers, and larger in later implementations. – Jamie Hanrahan Apr 12 '16 at 16:06

Wikipedia's article on PAE: "The original releases of Windows XP and Windows XP SP1 used PAE mode to allow RAM to extend beyond the 4 GB address limit. However, it led to compatibility problems with 3rd party drivers which led Microsoft to remove this capability in Windows XP Service Pack 2." Some "versions of 32-bit Windows (Windows XP SP2 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility via the licensing limitation mechanism". "Microsoft Windows supports PAE if booted with the appropriate option, but according to Geoff Chappell, Microsoft may limit 32-bit versions of Windows to 4 GB as a matter of its licensing policy."

Blog attributed to Mark Russinov "32-bit Windows will continue to ignore memory above it because there is still some difficult to measure risk, and OEMs are (or at least should be) moving to 64-bit Windows where it's not an issue."

Windows 2000 DataCenter 32-bit supported up to 32GB, and newer versions up to 64GB.

Later on, the Wikipedia article discusses FreeBSD and says, "Not all drivers support more than 4 GB of physical memory; those drivers won't work correctly on a system with PAE." So the issue of driver compatibility has plagued more than Microsoft Windows.

So, in conclusion, there is no technical reason why it would be absolutely impossible for software to refer to more than 32 bits of address space. Advancements/workarounds, like what you theorize, could exist, but such support has not been widely deployed, apparently due to compatibility and concerns of stability.

| improve this answer | |
  • Thank you. Despite the compatibility issues, are there performance issues when it does work? i.e. does it slow down programs to use the larger addresses? – Oztaco - Reinstate Monica C. Nov 28 '15 at 4:43
  • Not noticeably. – davidgo Nov 28 '15 at 5:25
  • There is a performance penalty when running in PAE mode, due to the extra address translation step plus the fact that the translation buffer can only hold half as many entries as before. These are usually more than made up for by the performance gains that are allowed by being able to use more RAM. – Jamie Hanrahan Feb 25 '19 at 6:50

Why is the amount of RAM usable by a computer limited by the processor bits? It isn't. Historically it hasn't been with examples where address size was bigger or smaller than the "bitness" of the CPU.

Look at 8 bit CPUs like the 6502 & Z80 that addressed 64KiB. The 16 bit 8086 addressed 20 bits and the 16 bit 80286 24 bits.

On the flip side, the 32 bit Motorola 68000 had 32 bit addressing, but only ran 24 bits to wires limiting it to 16MiB. Which is the approach of the x64 chips I know of, they aren't running 64 lines to the outside world.

When the 32 bit architectures were being laid down, 4GiB of memory was pretty much beyond comprehension. The 80386 was introduced in 1985. In 1996 Microsoft releases MS-DOS 3.2, which still limits the maximum size of a hard drive partition to 32MiB. Very few people were thinking of GiB hard drives, let alone memory. SPARC was introduced 1987. PowerPC 601 in 1992, now we are getting close to GiB hard drives if not there yet. Unix workstations might have two digits worth of MiB RAM. The need for more than 4GiB was still a long ways off. Adding the hardware and complexity of supporting greater than 32 bit addresses was not worth it.

Once an architecture is laid down, and in use you can't easily change fundamentals, like the size of address. One can add on, like PAE on the x86, or external memory controllers on a 6502.

Edited to add And the reverse happened also. The IBM 360, introduced 1964, was a 32 bit machine with 24 bit addressing. The CRAY-2, introduced 1985, was a 64 bit machine with 32 bit addressing. (If I am reading this brochure correctly, See "Architecture and design" starting page 6.) Note, the CRAY-2 appears to be 64-bit word addressable, so 32 bit addressing would give an address space of 8 * 4 Gi or 32 GiB.

Another note

I've been talking about address space. The question title is about RAM. RAM, absent an external memory controller that remaps memory, is going to be limited by the number of address line wires coming from the CPU. Some CPUs had fewer address lines than bits in their address space. A famous example is the Motorola 68000 that had a 32 bit address space with only 24 address lines. Another example is Intel's 80386SX, again 32 bits of addressing and 24 address lines.

| improve this answer | |

The processor is engineered to use one variable for the instruction pointer and one variable for the stack pointer. All code is written assuming this, if you started playing with two variables you would break every bit of code out there.

What you can do is change around which 4gb of memory you are using at any one time. That is the PAE that TOOGAM is talking about. Any one program would still be limited to 4gb unless it jumped through a lot of hoops in order to access the extra memory (and no applications programmer would do this these days--if you're doing something that actually needs over 4gb you have a beefy enough task you can dictate terms to the user: 64 bits or I don't run) and you introduce headaches with interprocess communications. Sharing a chunk of pure data is fine, sharing a chunk of data containing a pointer will cause problems because the pointer will point to the wrong place in the address space of the second program. This is the cause of the driver headaches that TOOGAM mentions.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.