Bytes of data readily accessible to the processor are identified by a
memory address, which by convention starts at zero and ranges to the
upper limit addressable by the processor. 32-bit processors typically
use memory addresses that are 32 bits wide. The 32-bit wide address
allows the processor to address 2^32 bytes of memory, which is exactly
4,294,967,296 bytes, or four gigabytes. This is the direct source of
the four-gigabyte memory addressing limitation.
Further, all current 32-bit desktop and server versions of Windows
(that is, Windows XP Home, Windows XP Pro, Windows XP Media Center
Edition, and all non-embedded editions of Windows 2003 Server, all
editions of Windows 2000) support addressing four gigabytes of
physical memory.
Yet accessing four gigabytes of physical memory isn't possible on all
machines. Why is that?
While there's no limit in Windows beyond the four-gigabyte limit of
the address space, the address space might contain things other than
memory. Hardware designers frequently use a technique called memory-
mapped I/O. Memory-mapped I/O places memory which is visible to a
peripheral on the system bus, in the address space of the processor.
To communicate with the device, the processor simply writes data into
the range of memory the device has mapped into its address space. This
mechanism is significantly faster than using a specialized bus for I/O
access, and provides additional benefits the software and hardware
designers alike.
Windows will work with the hardware to map as much physical storage
memory as possible into the spaces around the device-provided memory
mapped features. While the total memory available to the operating
system will be less than four gigabytes, the system certainly is
capable of accessing four gigabytes of memory space. For applications
where memory is important, care must be exercised in selecting and
configuring peripherals in order to assure the maximum amount of
memory is available.
One easy way to see what memory mapping is happening is to use the
Device Manager on your system and have it show what mapping is
occurring. On a machine with three gigabytes of memory,
Right-click on the "My Computer" icon
Select "Properties" from the Context menu
In the resulting "System Properties" dialog, activate the "Hardware"
tab
Click on the "Device Manager" button
In the "View" menu, select the "Resources by Connection" command
select the "Memory" node in the tree
Press the "*" key on the numeric keypad to expand all the nodes in the
memory tree
When this system boots an xp virtual machine, it counts 3072 megabytes
of memory in the BIOS, and shows 3.0 GB in the general properties for
the computer. But using the "Performance" tab of Task Manager, this
machine reports 3,144,940 kilobytes of available physical memory. This
isn't quite enough, as 3072 megabytes of memory is 3,145,728 kilobytes
of memory. Where did the missing 788 kilobytes of memory go?
Addresses shown in the Device Manager window are in hexadecimal. We
don't care about many of them, but one of the important values we're
interested in is 0xC0000000, since that corresponds to three
gigabytes. We can see that Windows has allocated addresses 0x00100000
through 0xBFFFFFFF to the system board, and that totals 3,144,704
kilobytes of memory. There's also the range 0x000E0000 through
0x000FFFFF, which is another 128 kilobytes of memory. That brings us
within 788 kilobytes of our expected total.
One hole of memory is evident at 0x000A0000 through 0x000BFFFF; this
memory is mapped to the display adapter for its text mode and lower
graphics modes. These addresses have been used by the display adapter
by convention since the original IBM PC in the early eighties, and are
retained for compatibility. Adding the memory around it brings us
within a few kilobytes of our physical memory goal.
The hole the graphics adapter causes in physical memory is called its
aperture. This value is settable in the system BIOS, at the cost of
being able to access memory on the video card directly and rapidly.
With very large buffers on video cards, and the advent of SLI systems,
the memory aperture taken out of the system address space can be huge,
and reduces the usable general-purpose memory accessible by the
system.
Had this system four gigs of memory, the system would show at most
3.94 gigabytes of physical memory available after it booted with the
64 megabyte aperture. With the 256 megabyte aperture, the maximum is
3.75 gigabytes. The true maximum is substantially less, since the 256
megabyte card memory also comes from the physical address space, as
well as memory for other devices on the system.
Note that all the addresses in this section of the document are
physical. The OS is free to map a physical address range to a logical
address range in any way it sees fit, and that's important for
understanding the next section, where all the addresses described are
logical.
PAE extends the range of Windows memory mapping by adding another 4
bits to the address bus - meaning the system can now address 64GB of
memory - handy on a multicore 32-bit system, for instance a dual AMD
Athlon MP, on a board such as a Tyan Tiger, would turn into a real
powerhouse since the board can handle 8GB of physical memory (I know,
I have one). There is a slight problem though, since Windows tries to
load device drivers into high memory areas, it often ends up stuffing
them into areas of memory that don't physically exist. SP2 got around
this by simply switching off PAE. Back again to the hard 4GB memory
address space. I don't know if SP3 addressed this further by actually
attempting to /fix/ the PAE problem. Someone else'll have to answer
that one. What I do know is that my Athlon MP gets around it by
dividing the memory down the middle so the system (when it ran xp SP1,
and SP2 for about a year) reported 7.8GB RAM (with every RAM switch
tweak I could think of and a really small graphics aperture), and each
processor addressed and utilised 3.9GB between kernel and userspace -
what I ended up with was a whopping nearly 6GB of usable physical
memory. Windows xp SP1 used PAE to allow the application software to
address >4GB /virtually/, which kinda worked though there were odd
problems such as paging errors in memory spaces that didn't exist...
in the end, that machine got migrated to Linux and I've not looked
back and regretted the move, not once.
Sources: TechNet, MSDN, [H]ard|forum, IME
Similar Threads
