PC memory map

Why do PC's have memory-mapped I/O below 3GB? I have 3GB and 2.75 is usable. The top GB should be big enough to map all the hardware.

--

Reply in group, but if emailing remove the last word.
Reply to
Tom Del Rosso
Loading thread data ...

because it is backwards compatible with older versions of PC hardware. Mind you they could have made more effort to remap the memory so you can use it all.

Reply to
David Eather

in 1980 people running DOS wanted to look at text on their screens etc.

maybe that missing 265M is being used by the onboard graphics chipset?

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

i meant "256"

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

It's common for 1 GiB to be allocated to PCI (and PCIe) regardless of whether you actually have any PCI devices installed. This may be configurable via the BIOS.

Once you go above 2 GiB of RAM, you really need to consider using a

64-bit OS. 32-bit "desktop" versions of Windows (anything which isn't called "Windows Server") don't support a physical address space larger than 4 GiB, and some of that 4 GiB (quite a lot of it, in fact) is allocated to things other than system RAM.
Reply to
Nobody

That was 384k, not 256M.

Obviously it is, but the question is why do they assign so much space for I/O. The I/O space is scattered all over, so the RAM is remapped, but I see no reason why it should add up to1.25GB.

--

Reply in group, but if emailing remove the last word.
Reply to
Tom Del Rosso

Are you talking about virtual address space or physical address space?

The x86 virtual address space is based on 32 bit addresses, thus theoretically capable of addressing 4 GiB _per_segment_.

Yes, the 32 bit segment registers are still there, but in practice, the CS:, DS:, SS:, ES: etc. registers are mapped to the same addresses.

Anyway, by stupid design, the generated segmented virtual addresses are truncated to 32 bits, before applying to the virtual to physical address translation :-(.

At least since the Pentium II days, the internal physical address has been 36 bits wide, potentially capable of addressing 64 GiB of memory, However, the older chips did not bring out the highest address bits to output pins of the chip, thus, the maximum physical memory was less than 64 GiB.

Reply to
upsidedown

There is a good article over on TechNet, during Xp development they tried using memory above 4G but found out that most drivers truncated the addresses as you say. So in keeping everything reliable they kept the I/O below 4G. That why x64 has no problem, the drivers are written for a larger memory map.

Cheers

Reply to
Martin Riddle

I'm just asking about the size of the I/O space. If I/O takes 0.25GB out of my 3GB of physical RAM, then it must not fit in 1GB. The video card is

256MB so I don't understand why I/O has to take so much. The minimum assigned to I/O depends on the motherboard, but 1.25GB is a big minimum. AFAIK it's never less than 500MB.

Yeah, almost forgot that.

All set to zero I assume.

So the segment registers stick out 4 bits just like they did when they were all 16 bit.

--

Reply in group, but if emailing remove the last word.
Reply to
Tom Del Rosso

Go to device monitor and View->Resources by Type

You'll see your video card is probably listed twice for dual monitor support, hence 500MB

Cheers

Reply to
Martin Riddle

I am confused as well. Normally it is getting 3.25 or 3.5 GiB out of 4 GiB that is the issue. BIOS written to a bungled translation? Video cards typically use one or two 128 MiB windows, mostly for texture maps;

2 megapixels times 32 bit color needs only 8 MiB. NICs (including 1000base-x) rarely use more than 1 MiB, the OS allocates disk buffers out of available ram, and what other peripheral uses anything like that kind of bandwidth?

?-/

Reply to
josephkk

To the OP:

I assume that you are saying that you have 3 GiB of _physical_ memory on your PC.

Then you claim that only 2.75 GiB of _virtual_ memory is usable.

Your computer is fully capable of using the whole 3 GiB of physical DRAMs, see below.

Old 1970's 32 bit virtual memory operating systems, such as VAX/VMS had the 4 GiB virtual address space divided in two sections, the lower

2 GiB was process private address space and the upper 2 GiB was fixed kernel address space. The user mode code could not access the upper 2 GiB and the kernel mode code had to remap the lower 2 GiB to the currently active user mode process.

This structure was carried over to Windows NT (same designer), but on some server versions, user mode could be extended to 0-3 GiB and kernel 3-4 GiB.

Starting with Windows NT 4.0, the display handling routines and screen memory was moved to user mode to improve performance, by avoiding the user/kernel/user mode switching for each video memory update.

From the OP's posting, it appears that the user mode _virtual address_ memory extends from 0-2.75 GiB, 2.75-3 GiB is some peripherals, including video-RAM and 3-4 GiB of virtual memory is kernel (of which

100-300 MiB is actually used).

Thus, a single process can't use the whole 3 GiB _physical_ memory, however assuming 200 MiB for kernel code, there would still be 2800 MiB available for user processes and it could accommodate two user mode processes with 1400 MiB each or four 700 MiB, without page file.

In a real system with multiple processes the 3 GiB or even large _physical_ memory will be utilized. The internal architecture of x86-32 processors allow 64 GiB of physical RAM (all chip models do not export all address lines, so the actual size is less). To fully utilize that 64 GiB physical memory, you need at least 30 processes with 2 GiB each, not an unrealistic demand for a server machine.

Reply to
upsidedown

No, Windows reports 2,883,052k of physical RAM. This depends on the hardware and it varies, but all PC's that I've seen have at least a few dozen MB missing. The 286 had 16 MB addressable and those PC's must have had a chunk taken out in addition to the 384k of the original PC, but the big chunk missing from 32 bit PC's suggests that much more address space was allocated to I/O in this generation of the PC standard, and that a lot of it was allocated below 3GB.

That's starting to make sense. But if the OS maps video RAM to below 3GB, then can't it map the RAM at the physical addresses below 3GB to above 3GB? Even if the user processes can't use it, it could be disk cache etc.

--

Reply in group, but if emailing remove the last word.
Reply to
Tom Del Rosso

< It's common for 1 GiB to be allocated to PCI (and PCIe) regardless of < whether you actually have any PCI devices installed. This may be < configurable via the BIOS.
< Once you go above 2 GiB of RAM, you really need to consider using a < 64-bit OS. 32-bit "desktop" versions of Windows (anything which isn't

I was just gonna say something about ramdisks. but the pc (program counter) would probably have to be 48 bits for effecient lookups without using a window ?

< called "Windows Server") don't support a physical address < space larger than 4 GiB, and some of that 4 GiB (quite a lot of it, in < fact) is allocated to things other than system RAM.

Yeah, 4 gigs is a lot of memory to me. The 64 bit cpu might make some operations slower (guessing like 8 bit searches unless you pack the registers for a full 64 bit compare?). Anyways, I just wonder why the PC (program counter can't be a bit larger - like 48 bits... dunno this is abit out of my league...

I have another machine running a gnu/linux system that is 32 bit CPU that can access all 4 gigabytes of ram. I usually map 2 gigs to a memory mapped IO database.

Reply to
Steve Gonedes

On hardware supporting virtual memory, there is not much point of using RAM disks in the traditional sense, instead memory mapped files are used to store huge data bases. The main memory RAM is effectively just the L3 (or L4) cache.

48/64 bit virtual address space and data registers are needed for easy memory mapped file access, but a 32 bit program counter is quite sufficient.

Even a 32 bit program counter is capable of accessing 4 GiB (in the data segment in the x86 case). That is a huge amount of code, in practice with lots of bugs, potentially doing damage within the huge virtual address space. Any sensible application design will divide a huge problem into multiple processes, each in a separate address space, so a single bug does not take down the whole application.

However a very wide data access is definitively needed in many applications in order to access huge physical RAM or using huge memory mapped files, distributed around a large disk farm.

Reply to
upsidedown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.