NASM - The Netwide Assembler
NASM Forum => Using NASM => Topic started by: hhh3h on August 14, 2012, 08:35:16 PM
-
Hello! I have some assumptions in here that are probably incorrect. I would appreciate some clarification.
I was reading a this (http://www.viva64.com/en/b/0069/) 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.
-
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
-
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 (http://en.wikipedia.org/wiki/X86-64), OSDev.org (http://wiki.osdev.org/X86-64) and within the AMD/Intel processor manuals.
-
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 (http://www.amd64.org/fileadmin/user_upload/pub/64bit_Linux-Myths_and_Facts.pdf), 2 (http://www.sandpile.org/x86/can_addr.htm)) 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.)