How is physical memory recognized by a 32-bit OS running on 64-bit hardware?

May 14, 2007 3:30 PM

How is physical memory recognized by a 32-bit OS running on 64-bit hardware?

(This was originally a comment on an older thread, but it went unanswered, so I'm asking a fresh question.)

Can someone explain how the murky 4GB barrier works in 32-bit Windows? To be more clear - currently, on a 32-bit CPU with a 32-bit OS, if you put 4GB of RAM in the machine, it doesn't recognize more than about 3.5GB because some is reserved by the PCI bus, and of that RAM, you can only allocate 2GB to any given process because the kernel reserves a bunch. What about on a 64-bit CPU (still with 32-bit Windows)? If you put 8GB into the machine, do you get 3.5GB for the kernel, 512M for the PCI bus, and a separately addressable 4GB physical RAM that can be allocated to a process? What happens if you have exactly 4GB of RAM? Does it behave just like a 32-bit OS on a 32-bit CPU?

posted by Caviar to computers & internet (8 comments total)

As I understand it, a 32-bit OS will behave the same with respect to memory addressing and limitations on either a 32-bit or a 64-bit CPU.
posted by musicinmybrain at 3:46 PM on May 14, 2007

The simple answer is no, a 32bit OS will run the processor in 32bit mode, which deals with 32 bits of address space; hence the 4gig limit.
The extra memory may be available through Address Windowing Extensions (on Windows, other OSes may call it something else), which are a hack to dynamically swap pieces of high (>4gig) memory with low memory on demand, but only applications specifically written to take advantage of AWE will use it.
posted by AndrewStephens at 3:58 PM on May 14, 2007

AndrewStephens provided a much better answer than I would have, but if you thirst for more, here's Microsoft's official white page on the topic.
posted by nilihm at 4:39 PM on May 14, 2007

When you run a 32 bit OS on a 64 bit CPU, everything works exactly the same as a 32 bit CPU running a 32 bit OS. To the OS, it *is* running on a 32 bit CPU.

And as to "reserving" space, that's not the best word. With 32 bits available, that means that only 4 GB can be addressed no matter what. And there are things that must be mapped into memory in place of RAM, commonly called memory mapped IO. The PCI bus and AGP aperature are two examples. Since they must be mapped into memory and there are only 4 GB possible bytes that the CPU can address, it means there is some RAM that is unaddressable. And with the 2GB limit, this stems from the fact that the operating system must partition virtual (not physical) memory space into user-mode and kernel-mode. The conventional splitting point is right down the middle, i.e. a process can access only 2GB of (again, virtual) user-mode memory. There is a boot.ini switch you can add that changes this split into 1GB /3GB but applications must be rebuilt with a special "3GB aware" bit set in the PE header in order to take advantage of this layout.
posted by Rhomboid at 4:55 PM on May 14, 2007

The above answers imply, but do not explicitly state, something that I think is important: all 64-bit x86 processors have the ability to run as if they were 32-bit processors.

When they do so, they have 32 bits of address space and can not access more than 4GB of RAM. (As you yourself say, actually less than that because some of the address space is reserved for other hardware.)

At boot time the OS chooses a mode. There are actually several; one of the reasons the x86 processors these days are so complex is that they have to emulate several obsolete hardware modes.

So the bootstrap software accesses a register and tells the hardware which emulation mode the processor should run in. 32-bit Windows tells the processor to run in 32-bit mode, and it does it in precisely the same way if it's on a 32-bit processor and on a 64-bit processor. And in that mode, the 64-bit processor acts exactly as if it was a 32-bit processor, in terms of the execution environment for the software.
posted by Steven C. Den Beste at 5:04 PM on May 14, 2007

Total derail: Its even worse than that! That expensive dual core duo2 you are using now actually starts up in 16 bit mode, just like the 80286s that were being used in PCs 25 years ago.
If you think the 4gig limit is a pain, you should see what convolutions people used to go through on 286s to access memory.
posted by AndrewStephens at 5:52 PM on May 14, 2007

Actually, they boot up in 8086 real mode. The protected mode flat memory model actually started with the 286.
posted by b1tr0t at 8:00 PM on May 14, 2007

There are also hardware limitations that come into play when accessing physical memory, in that on Intel chipsets, only server chipsets contain memory controllers able to access large memory arrays (generally more than 4 or 8 GB). These server chipsets have the logic to control and refresh large memory subsystems without loading the CPUs, and to manage memory buses that are heavily accessed by multiple processors and peripheral devices. Because of DMA and similar memory/peripheral management features, the CPU's of most modern computers do less than half the memory accesses in most systems built on Intel architectures. But without chipset silicon that can work efficiently with the processor cores in accessing memory, 64 bit systems are hamstrung, and even with Intel's versions of NUMA, the penalties for processor branch prediction failures and cache misses are prohibitive. The performance hit for dumping the pipeline on the Pentium 4 is one big reason that Intel finally abandoned the P4 architecture as a base for multi-core computing.

For AMD and PowerPC architectures, the memory management issues are different, as these product families take different approaches to memory utilization, reflected in their silicon.
posted by paulsc at 10:16 PM on May 14, 2007