ksoren

http://www.msfn.org/board/index.php?showto...40&start=40 This was thread was closed, So I cannot reply... cluberti, you are truly unbelievable. You meet a bit of resistance and then you close the thread? If you some day get over yourself and actually research this topic, you'll realize how foolish your statements looks like. You have not understood what the physical and virtual address space really is or how paging works. You know nothing about me or what I know, so how can you tell me that I know nothing about this subject? I can tell you this, I know more about it than you, obviously. Are you going to close/remove this thread also?

As I've said, AWE is not about addressing physical memory. "Paging" is how you go from the virtual to the physical address space. PAE changes the page table layout so there are more addressing bits. A process' virtual address space can be mapped anywhere in physical ram. This has nothing to do with the application, but is a job for the memory manager (and the cpu which translates the application's virtual addresses into physical ones when needed). The virtual address 0x1000 in a process can point to "0x1000 0000" or to "0x1 0000 0000", it doesn't matter, all the application sees is "0x1000". This is called paging (and is how the cpu handles memory). The VAS is fixed at 4GB and cannot be changed. 2GB is default for user space. If the application for some reason needs to allocate more physical ram than can be mapped into these 2GB, it can make use of AWE. It will allocate a AWE-window and ask the memory manager to map it onto a physical area (which doesn't have to be contiguous). Later it can ask the memory manager to move the window. In this way the application can use wast amount of physical ram even though the VAS is only 2GB. But again, this is not PAE, this is just a technique for a single application to address more memory. This I have never said. What I have said is: you intermix PAE and AWE, and that is wrong.

So, have you gotten the point? That your explanation of AWE and that it is required to address physical RAM located above 4G is wrong? That you cannot use AWE to explain what PAE is? That you can remove the existence of AWE and still use RAM above 4G?

Anyways, intel.com and amd.com have some very good developer manuals on how it works inside the cpu. Mark Russinovich is a popular guy. You could start with his Windows Internals book. He writes a bit about memory management in Windows. There are many other books on the subject.

Which part? AWE really has nothing to do with PAE. The PTE is 64 bit wide in PAE mode. Look in up. This doesn't mean all 64 bits are used for addressing memory (I didn't say that). Do you know what a PTE is? I'm not sure what you mean. Yes, of course the page table is mapped into the VAS, otherwise the OS couldn't address it. I think you are confused about how paging works. Last time I checked it was 52.

Yes, 32bit XP/Vista doesn't support >4G we can all agree on that. And yes, PAE is needed to address memory above 4G. But your explanation of what PAE is and how it involves AWE is very flawed. This is why I mentioned the number of layers earlier. In both PAE and in 64bit mode the PTE is 64 bit wide. In PAE mode (which is default) the page table is 3 layers and in 64bit it is 4. So what has the most translation-overhead?

Forget about AWE for a minute, okay? This has nothing to do with PAE. PAE just extends the PTE from 32 to 64 bits. Virtual address > physical address is done through the page table and has nothing to do with AWE. Yes, the OS manages the page table. But the actual translation when a machine code instruction requests data on a memory address is done by the CPU. 10 processes (with a 2GB user space) can potentielle make use of 20 GB RAM without ever touching AWE. Each process just points to different places in physical ram. Do you actually think I would come in here if I didn't know?

It manages the page table. The translation is done by the CPU. No. Technically, AWE has nothing to do with PAE. It is just a technique for a 32bit app to access very large armounts of RAM, but it is not PAE. I also don't like the name "PAE memory" very much. It is just one big chunk of memory. There was some confusion about a process' virtual address space couldn't point to to physical ram above 4G. This was my point. If the VA points >4G then you have executable code above 4G (you are not using AWE here).

There are some rather big misunderstandings about how this stuff works. Just to take the two above. 1) XP/SP2 and Vista runs in PAE mode by default (the DEP thinggy). So the overhead is there anyways. In PAE mode you have a 3 layer page table model. In 64bit mode it is not 3, but 4 layers - just to compare. 2) Applications/software/machine code instructions only sees virtual memory addresses. Virtual addresses are mapped onto the physical addresses via the page table (managed by the OS). AWE is used if an application needs to use more physical ram than can be mapped into its virtual address space at one time (it will then slide the AWE-window around). It is not a way to address RAM above 4G address line. AWE is NOT PAE. You don't even have to run in PAE mode to make use of AWE. A process' virtual address space can point to any place in the physical address space, below, above whatever. It doesn't matter one bit to the application since it only operates with virtual addresses. It doesn't have to be contiguous. There is no difference in ram below and ram above. Under normal operation, the page size is 4kB. So 4kB is the only contiguous ram you need to have. The OS does know about RAM >4G. Executable code can be wherever it sees fit, because of the virtual address space thing.