Relationship between word-size and address size

[hhh3h]

Hello!  I have some assumptions in here that are probably incorrect.  I would appreciate some clarification.

I was reading a this article entitled "The reasons why 64-bit programs require more stack memory".

I had a question about this topic.  The stack on a 64-bit system is 64-bits wide.  But I don't know the size of the actual addresses that one normally uses when dealing with variables (memory locations) in an assembly program.

So for example, say you are on a x86_64:  The stack is 64-bits wide, and also say that of the items being passed in on the stack is an address to a variable (i.e. a reference to an array).  Is only the first half of the 64-bits used for that address, and the rest of it is zero padded?

The only reason I ask this is because I heard that, while the physical address size might be 64-bits, the addresses available for use by a program are only 32-bits because the OS caps the accessible memory at (I think) 4GB.  Therefore it would not make sense to use 64-bits for addresses if your application only has an accessible range of (2^32)-1.

Please let me know (1) what the address size is compared to whether it's a 32 or 64-bit system; and (2) if I am totaly off-base with my assumption of the memory cap for applications.

Thank you.

[Bryant Keller]

There is a 4GB cap with 32-bit processes. 64-bit processes are limited to 8TB on the x64 and 7TB on the Itanium for virtual addresses.

This link should give you a lot of information.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx

[Keith Kanios]

64-bit processes are limited to 8TB on the x64 and 7TB on the Itanium for virtual addresses.

This link should give you a lot of information.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx

Note that the 8TB limit is an artificial limitation imposed by Microsoft for Windows.

The current/latest virtual address space size/limit for the x86-64 is 48-bit, or 256TB. With a typical upper (kernel/OS) and lower (user process) half divide, that leaves 128TB for processes.

I had a question about this topic.  The stack on a 64-bit system is 64-bits wide.  But I don't know the size of the actual addresses that one normally uses when dealing with variables (memory locations) in an assembly program.

So for example, say you are on a x86_64:  The stack is 64-bits wide, and also say that of the items being passed in on the stack is an address to a variable (i.e. a reference to an array).  Is only the first half of the 64-bits used for that address, and the rest of it is zero padded?

Read up on Canonical form addresses at the Wikipedia link, below.

The only reason I ask this is because I heard that, while the physical address size might be 64-bits

The current/latest physical address space size/limit for the x86-64 is also 48-bit, or 256TB. The current architectural maximum is 52-bit, as imposed by how paging/PAE was extended for the AMD64 design. However, there's nothing to stop AMD or Intel from eventually reworking things for a full 64-bit (or more) physical address space as yet another (initially) optional extension akin to PAE... and with respect to the history of how the x86 has evolved, I would fully expect it (e.g. PAE2) at some point.

the addresses available for use by a program are only 32-bits because the OS caps the accessible memory at (I think) 4GB.  Therefore it would not make sense to use 64-bits for addresses if your application only has an accessible range of (2^32)-1.

Depends on the OS. Compatibility mode definitely "enforces" a 32-bit virtual address space for obvious reasons.

Other than that, with relative addressing, you can address +/-2GB from the current instruction pointer, thus alleviating the cost of using 64-bit addressing everywhere. A properly designed x86-64 program may be marginally larger than its 32-bit counterpart, but should definitely be faster on the same CPU due to greater throughput.

More thorough information can be found at Wikipedia, OSDev.org and within the AMD/Intel processor manuals.

[hhh3h]

Thank you gentlemen, and congratulations Keith on your 333rd post!

I appreciate the links and the explanations.  On the topic of canonical addresses:  Only after you mentioned that did it ring a bell in my head that I was researching this topic once before [in regards to privilege levels (ring 0, 1, etc) and protected memory vs userspace memory] and read that there is a large chunk of numbers in the middle of the set of possible 64-bit integers that are unused.

In addition to what you linked, I read these (1, 2) and I think I understand that addresses are in fact stored as 64-bit integers regardless.  (So if you had to grab the address to an array off the stack, you would have to put it into a 64-bit register).

(I am not an assembly programmer, I am just interested in reading assembly and trying to follow along.)