What is the size of an address of a variable in memory on a 64 bit processor (Intel i3/i5/i7)

Question

Would it be 64 bit address or is are they still 32 bit or as I may have mistakenly read the addresses are 48bit ? Or does Intel use a 32 bit address of one cell and half of another 32 bit cell making 48 bit ? So using a single char pointer for a variable what would be the size of the address itself (0xFFEDEDAC) 4 bytes ?

Solution

If we're talking about virtual addresses, which are the addresses used by code running under any modern operating system.... and programs running in "long mode"... addresses are normally stored in 64 bits (eight bytes). But in the architectural specification only the low-order 48 bits are implemented. The remaining 16 bits (bits 48 through 63) must be a copy of bit 47, the highest-order of the implemented bits.

This results in an address space that, at first glance, runs from 0x00000000'00000000 through 0xFFFFFFFF'FFFFFFFF. But the only addresses that can actually be used are those in the following ranges:

0x00000000'00000000 through 0x00007FFF'FFFFFFFF
0xFFFF8000'00000000 through 0xFFFFFFFF'FFFFFFFF

This results in a theoretical address space of 2 to the 64 bytes (16 exbibytes, or about 18x10^18). Those numbers are of course the numbers for 32-bit processors, squared. But only 256^48 bytes are actually implemented, the latter being split into two equal-sized halves of 128 TiB each.

(User mode in Windows uses the first half, which is instantiated anew for every process. Kernel mode uses the latter half, which is largely common to all processes.)

Incidentally, in memory there are no 64- or 32-bit "cells". There are only bytes. x86/x64 are byte-addressable.

For your specific example, your pointer would occupy 8 bytes in memory... unless you were running a 32-bit program in compatibility mode, in which case it would occupy 4 bytes.

Comments

[Vikki]

thank you @Jamie. When you run under Visual Studios debugger it shows the address of the char pointer as 4 bytes and gives an address 0x00597df8. I'm thinking in real memory addresses not virtual. I might be confused quite a bit.

[Jamie Hanrahan]

Ah... you're probably building a 32-bit program. Such programs work in "compatibility mode" wherein VAs are 32 bits, just as they would be on a 32-bit processor (or a 64-bit CPU running 32-bit Windows). As for real (physical or RAM) memory addresses, you will never see them, not even in the VS debugger. Once virtual addressing is turned on - which it is very early in the OS boot - only the memory manager in the OS ever even thinks about physical addresses, and even there, it can't actually "assert" them - that is, it can't use them to address memory. Only virtual.

[Vikki]

@thank you Jamie. Yes it's likely a 32 bit test application I'm working with. Since these are VA then if I were to create a 64 bit application then the VA would be 8 byte addresses virtual of course ? what would be the real address conversion meaning what number of bytes if using the address I gave above address 0x00597df8 would it be in real memory addressing ?

[Jamie Hanrahan]

Yes. You can change your project properties to build a 64-bit version.

[Vikki]

Thanks again Jamie if one would build a 64 bit application what would be the number of bytes under the debugger in VA terms be 8 bytes ?

[Jamie Hanrahan]

Yes, e.g. any pointer in a 64-bit program occupies eight bytes (both virtual and physical size) - this is often cited as one of the costs of 64-bit code, that all the pointers take twice as much room as under 32 bits.