To use 36-bit PAE or not to use 36-bit PAE, that is the ques

[Perica]

..

[tom1000000]

Hi,

36 bit addressing is a complete waste of time.

The Intel x86 architecture is 32 bit and each application can only address 32bits (4GB virtual address space). The 36 PAE extension allows the operating system to support a computer with more than 4GB of RAM, but there are no benefits to the application itself. The only benefit is u can fit more applications into physical memory.

For an Intel x86 operating system you may as well stick to the 4GB limit for RAM. The vast majority of x86 computers have less than 4GB of RAM. If you want to support more than 4GB of RAM use the AMD64 instruction set. AMD64 gives each application a virtual address space of 2^64 bits.

[df]

who in their right mind would want to go back to a segmented addressing mode!! augh..

[Therx]

I'm planning on using it for my OS. The main reason being that commonly accessed files could be cached. This will offer a speed increase. But I must admit that I won't be able to test it probally as my PCs have just 128mb of RAM. Another advantage is that it will force me to use 64bit ints for the physical memory manager. Hopefully this will allow me to port it to 64bit more easily.

I'd go for the Intel design as AMD processors are compatible with Intel rather than the other way round. I think that AMD must just use the 'reserved' bits in the extra double word of the page table directories.

Pete

[Solar]

On the one hand, today's "standard" desktop motherboards don't support even the 4 GB RAM allowed by 32 bit addressing.

On the other hand, for "heavy iron" server applications, being able to address more than 4 GB would be beneficial.

But for the sake of caching files, be aware that most motherboards don't go further than ~ 1,5 GB.

Also, be notified that AMD created their very own 64 bit architecture. Yes, AMD is Intel compatible in the 32 bit sector - although AMD CPUs provide some interesting, non-compatible features of their own you shouldn't completely ignore in your OS.

But in the 64bit field, AMD64 and Itanium are two very different beasties.

[Therx]

Yeh my OS is designed for server. And is for IA32. I think Perica was suggesting that there is a AMD extension for IA32 which makes physical address space 64bit with the standard 32bit virtual address space.

[df]

i dont see the point of supporting pae. its a lot of hassle, segmented and you still cant address > 4gb. you still have 32bit pointers, etc.

its like the old dayds of EMS and XMS and copying pages in and out with EMS api.. ugh..

pae is really a waste of time. want more? get a cheapo amd 64bit box or old sun ultrapsarc 5...

[Candy]

i dont see the point of supporting pae. its a lot of hassle, segmented and you still cant address > 4gb. you still have 32bit pointers, etc.

its like the old dayds of EMS and XMS and copying pages in and out with EMS api.. ugh..

pae is really a waste of time. want more? get a cheapo amd 64bit box or old sun ultrapsarc 5...

You don't get the point of PAE. I didn't get it either, initally, but after a while I did.

My approach is to have a free page module that administers all free pages (if I change what I intend to change, all pages). It does so in a backlog that runs in its own address space. It uses 8 byte structures for each page (soon) so it will be able to map 2G/8b * 4k pages in its address space which is 1 terabyte. As for x86 computers, this is enough.

The free page backlog is accessed using two smaller buffers in kernel space that make a number of free pages freely accessible (and since I want all pages to be zeroed before returning them, there is a second buffer for the pages returned to the backlog). The rest of the kernel just asks for a free page and gets it, oblivious to where it actually is. The free page module is the only one that actually realises there is more than 4G available, and it's the one handling the trouble.

As for just supporting PAE for the heck of it, don't. There are only three main reasons to support it:

-Using AMD64 in your code (I intend to)
- Accessing more than 4G of memory
- using the NX bits should anybody care to implement them on 32-bit cpus.

As all three are on my goal list, see my code for an implementation that worked last time I checked (and since there was barely any change in PAE code, it should still work, no guarantees though).

Starting to think of it, you actually have a point with comparing it with EMS and XMS. Though, I would say, don't bother with mapping in any memory permanently since it will at some point be impossible no matter how hard you try.

As an aside, not doing it leaves you more address space

[Perica]

..

[Tim]

One example which springs to mind: Mapping a giant database into memory. Consider normal memory mapped files, which let you read and write a file as memory. The limit on the size of a file is the largest chunk of address space available, which depends on how the application has allocated memory so far. The bigger the address space, the bigger this maximum chunk is. So a 64-bit database engine could map many thousands of gigabytes at any time, whereas a 32-bit database engine would need to continually unmap and remap multi-megabyte views to access different parts of its file.