4GB RAM

Beer28 wrote:

I thought most devices handled their own memory, and the OS interaction was doing IN/OUT to ports which the device is registered on through the driver ?

So you're saying some devices have their memory offboard on the ram sticks as virtual and it's shared by the OS?

Very little I/O is now done through explicit IN or OUT instructions - basically only legacy devices. These instructions are basically a novelty of the x86 architecture anyway, and are a lot slower than the memory copy commands (this is effect rather than cause - they're slower because they're used less frequently). The 68000, PowerPC, MIPS, SPARC, ARM, you name it, don't have IN or OUT. In those architectures, all devices are memory-mapped. That is, their control registers occupy space in the regular memory map.

Any given physical address can map to ROM, RAM, or a device's control registers (or nothing). You can see roughly what's where in your system by opening Device Manager and selecting the Resources By Type view, then expanding the Memory node. You'll see a number of items below 0x00100000 (640KB), then a big block allocated to 'System Board' between that address and some large number. On this system I have 512MB which is 0x20000000 in hex, so this block ends at 0x1FFFFFFF. Then there's a big gap - on this system - to 0xF2000000 which is where the graphics card's resources start.

The processor has special registers which tell it which areas of 'memory' space are cacheable. You don't want the processor to cache any device registers, nor try to combine writes, because the values of the memory locations can change without the processor noticing (DMA writes are 'snooped' by the processor to keep caches up to date), and the order in which writes to the registers occur may be significant.

You can't normally write directly to all of the video card's memory. AGP supports an 'aperture' of memory address space that can be mapped to areas of the video card RAM using the Graphics Address Remapping Table [GART]. The default configuration is normally 64MB, which may not be enough any more.

I'm surprised that the original poster indicated that only 3GB was available, but perhaps the address decoding logic on his motherboard can only cope with decoding to a whole bank of RAM.

Most I/O for modern devices is performed using Direct Memory Access transfers, where the device is instructed where to transfer the data from/to and how much to transfer. This happens directly by the device asking to become the Bus Master. Once it is the bus master, it drives the memory address and read/write lines directly (at least, logically - with HyperTransport and inter-hub transport the physical configuration is point-to-point with multiplexing, but you get the idea). On completion it returns the bus to the processor. In the meantime, the processor can get on with performing useful work.

The system software still has to tell the device where and how to transfer data. It does this by programming the device's registers, which as I said above are now often memory-mapped.

This is why Programmed I/O is so much slower than DMA. For Programmed I/O, the system software sets the values of device registers to indicate where to read - either with a memory write or an OUT, the difference is simply whether the IO/memory line is set or unset - then reads from the device registers into the CPU registers with a memory read or an IN. The software then writes the values read from the device into main memory. The data has to come further, the processor has to wait for the device registers to become ready, and this code often can't be interrupted.

In an earlier post, msemack mentioned PAE (Physical Address Extensions). It's worth saying that all Intel CPUs since the Pentium II and I think AMDs since the K6 support PAE. On the Intel family, this expands the CPU's physical address bus to 36 bits, giving a potential 64GB of physical address space.

However, it's not enough for the CPU to support it. The chipset has to support it also. Few - in fact, I think no - desktop/workstation chipsets do. Expensive server chipsets typically do.

For example, the venerable 440BX chipset's datasheet says this:

"The Pentium Pro processor family supports addressing of memory ranges larger than 4 GB. The 82443BX Host Bridge claims any access over 4 GB by terminating transaction (without forwarding it to PCI or AGP). Writes are terminated simply by dropping the data and for reads the 82443BX returns all zeros on the host bus."

The same is true for the 850E chipset in my home machine and the 925X in my new work system.

Enabling PAE has another side effect. Device drivers are, or may be, presented with 64-bit physical addresses. Many are not written to cope with this possibility and have problems. This had an interesting effect on XP SP2. The Data Execution Prevention [DEP] feature requires PAE to be enabled since the NX bit AMD added is bit 63 of a PAE-format page table entry [PTE]. There were no spare reserved bits in the 32-bit non-PAE PTE. To enable hardware DEP, the processor must run in PAE mode.

Incidentally, the use of bit 63 will prevent the x64 architecture from ever addressing a full 64-bits of address space (16 Exabytes or if you prefer the IEC's terminology for distinguishing binary from decimal units, 16 Exbibytes [yuch]). That's obviously not an issue at present! Indeed, in AMD's documentation bits 52 - 62 in the PTE are reserved for future use, limiting current implementations to 4 Petabytes (=4096 Terabytes).

To salvage the situation and only present 32-bit physical addresses to drivers and hardware, XP SP2 defines the /NoExecute switch. Only if both /NoExecute and /PAE are specified does it enable 64-bit physical addressing.