32-bit OS(all OS including Linux and windows) has a limit to directly allocte up to 4GB memory. But what is the max. derectly allocable memory limit for 64-bit ?
directly means without any software help.(PAE,AWE?!)
can you provide more info about 64-bit memory allocation?

According to Wikipedia:
= a lot.

See http://en.wikipedia.org/wiki/64_bit.

Saying "allocate" when you otherwise seem to mean "address" confuses the question. Maybe you don't mean "address", but I don't think anyone understands what you mean by "allocate".

It's also strange to call PAE "software help". PAE is a CPU feature in all recent CPUs that can run 32bit x86 kernels (some very old CPUs don't have it).

If you are asking how much virtual memory a a process can directly address, 4GB is correct for 32 bit and PAE is irrelevant.

If you are asking how much physical memory a kernel can give (in total) to multiple processes, PAE should not be ignored. PAE isn't some weird kludge. It is a direct subset of the memory mapping required by 64 bit. The people who say you should use a 64 bit kernel for over 4GB physical to avoid the overhead of PAE completely misunderstand the structure. All the overhead (plus some more) of PAE is in the standard 64bit mapping system. It just isn't called "PAE".

That is a missleading answer. Some hypothetical 64 architecture could support 16 exabytes of virtual memory (64 bit addressing) but the current x86-64 architecture can't (I don't think any other 64 bit architecture can either). The x86-64 architecture only supports 48 bit addressing (256 terabytes, with half of that typically reserved for the kernel).

Someday there may be a next version of the x86-64 architecture that supports more than 256 terabytes virtual, but actually using that would require a significantly bigger change to OS kernels than the change that was needed to 32 bit kernels to support PAE. It would be a pointless argument in semantics whether you would call that the "same architecture". The practical difference is that you couldn't use it with the same OS kernel. Similar to 32-bit with/without PAE, most of the difference is hidden from the application programs, so an application that is limited to 128 Terabytes on some OS without that new feature might have use of more than that on some new OS for that hypothetical "new" architecture, without even recompiling the application.

I opened a big number calculator applet and entered 2^64-1. The result is 18,446,744,073,709,551,615. Like brianL says, that's a lot.

Well, note that that number is currently "theoretical", so far the implementation doesn't live up:
http://en.wikipedia.org/wiki/Amd64#V..._space_details

Thanks for the update TexMex, but I'm a bit concerned about the wording of that quote. They are calling it a "virtual address space". I don't think this is correct; maybe john will chime in and correct me. But, to me, 64 bits is 64 bits, and there's nothing virtual about it, assuming the hardware is actually there. OTOH, who knows when the first real 64-bit CPU/motherboard will be sold, if ever.

Thsnks To johnsfine To correct some problems and all who answered. now i understand why different OS gives different answer.it is clear from last answer.

Special thanks to H_TeXMeX_H

Can you discuss this further? anyone? i am interested about this quote

That's a good question, I think this image sums it up:
http://commons.wikimedia.org/wiki/Fi...lationship.svg

Or just take the definition here:
http://en.wikipedia.org/wiki/Virtual_memory

It might also be helpful to read about PAE:
http://en.wikipedia.org/wiki/Physical_Address_Extension

I looked this stuff up some time ago before I switched to 64-bit, just so I knew a bit about what was going on. I know only what's in the wiki, ask johnsfine for more, he's the expert on these topics.

When we talk about the size (32 or 64) of an architecture, we are talking just about the storage required for a virtual address. Years ago, many other things (bus widths, register widths, etc.) might have been meant. But those are so varied within x86-64 and other modern architectures to be hopeless for comparison. So that number has come to mean just the number of bits needed for a virtual address.

But just because 64 bits are needed doesn't mean 64 bits are used. The x86-64 architecture only uses 48 bits of virtual address.

Just because the architecture uses 48 bits, doesn't mean the OS uses 48 bits. If I understand correctly, 64bit Windows uses fewer bits. The 44 mentioned earlier in this thread sounds right.

The number of physical address bits in an architecture is independent of the number of virtual address bits. If I remember correctly, 32bit x86 with PAE has 36 physical address bits. Then the number of physical address bits supported by a particular CPU chip may be less than the number in the architecture. In Intel x86-64 I think the number of physical address bits supported by the motherboard may be less than the number supported by the CPU chip. (I don't think that is possible with AMD designs).

It is also possible for the OS to limit the number of physical address bits below the hardware limit.

I think that all is needed is for the hardware to feed the CPU what it wants to see. So, given that, the AMD CPUs should work fine with any number of bits in hardware. Or are you speaking of AMD chipsets instead of CPUs?

As far as PAE is concerned, I believe they implemented that with the "segment register" concept that we saw in 16-bit Windows, didn't they?

Actually I was referring to the fact that the memory controller is part of the CPU chip in AMD systems, but is a separate component on the motherboard in Intel designs.

The "physical address" is primarily something communicated from the cpu to the memory controller, so it is possible to use an Intel CPU in a motherboard whose memory controller supports fewer physical address bits than the CPU. But it seems to be a meaningless concept to say an AMD memory controller supports a different number of physical address bits than the CPU.

Sorry, that is nonsense.

Allowing more than 32 bits in a physical address (as is done in both PAE and 64-bit mode) required doubling the size of a page table entry compared to the original 32bit architecture (as is done in both PAE and 64-bit mode). In some old designs, Intel did that by doubling the size of a page table block. But in both PAE and 64-bit mode they do it by halving the number of entries in a page table block, which reduces the number of virtual address bits supported by a two level page structure from 32 to 30.

Then to increase the number of virtual bits (back to 32 for PAE and up to 48 for 64-bit mode) they add layers to the page structure (gaining 9 bits virtual per layer). PAE adds one mini layer to gain 2 bits from 30 back up to 32. 64-bit mode adds two full layers to get from 30 up to 48.

The page table entries supported by 32-bit mode without PAE support virtual addresses of 12 bits plus 10 bits per layer (ultimately limited to 32 bits, so only two layers can be useful).

The page table entries supported by 32-bit mode with PAE and by 64-bit mode support virtual addresses of 12 bits plus 9 bits per layer. 32-bit with PAE is still fundamentally limited to 32 bits virtual so only two and a fraction layers are possible. 64-bit mode would be fundamentally limited to 64 bits virtual, but it is limited first by the fact that the architecture only supports four layers of page table.

The whole paging structure is inside the OS kernel and doesn't concern the application code. The exact same application code can run (no recompile) with or without PAE and even in 32 bit mode under a 64 bit kernel.

Segment registers require complex support at compile time for the application. PAE is much much cleaner than that.

John,

I guess I misread the following from wiki, then. I didn't mean to imply that application programs used the segment register, though - just the kernel. On rereading it, I see that it's not the segment register, but something else.

In a segmented addressing system you have translations from
A) Segmented to Linear
B) Linear to Physical
C) Physical to (column, row, channel, bank, etc.) in the memory controller.

In a non segmented addressing system, the Segmented to Linear step is eliminated or made one_to_one, and the Linear to Physical translation is renamed "Virtual to Physical".

The x86 CPUs in (kernel) 32 bit mode support both segmented and non segmented operation. But 32 bit Windows and Linux only supported non segmented.

The 16 bit modes were segmented and 16 bit Windows used segmented addressing.

IIUC, when the kernel is in 64 bit mode, even 32 bit application modes do not support the translation layer from Segmented to Linear. I think the kernel needs to be in 32 bit mode (and running some weird OS) for the application to use 32 bit mode Segmented addressing.

When the kernel is in 64bit mode and the application is in 32bit mode, the full 64bit four level paging system is used, including support for physical addresses of 40 bits or more (depending on which CPU chip you have).

BTW, the word "tricks" in the thing you quoted is biased and misleading. Because of the multi layer translation system, there was never a fundamental connection between the number virtual address bits and the number of physical address bits. Changing the number of physical address bits from 32 to 36 was a clean and isolated change and doesn't deserve the word "tricks".