Question

I’m programmer-beginner, but I want to understand the things a bit more deeply. I did some research and read quite a lot of text, but I’m still yet to understand some things..

When coding a basic thing (in C):

int myNumber;
myNumber = 3;
printf("Here's my number: %d", myNumber);

I found out that (mainly on 32-bit CPU) integer takes place of 32 bits = 4 bytes. So at first line of my code CPU goes into the memory. The memory is byte-addressable, so CPU chooses 4 continuous bytes for my variable and stores the address to first (or last) byte.

On the second line of my code CPU uses his stored address of the MyNumber variable, goes to that address in the memory and finds there 32 bits of reserved space. His task now is to store there the number “3”, so he fills those four bytes with the sequence 00000000-00000000-00000000-00000011.
On the third line it does the same – CPU goes to that address in memory and loads the number stored in that address.

(First question – Do I understand it right?)

What I don’t understand is this:
The size of that address (pointer to that variable) is 4bytes in 32-bit CPU. (Thats why 32-bit CPU can use max 4GB of memory – because there are only 2^32 different addresses of binary length 32)
Now, where the CPU stores these addresses? Does he have some sort of its own memory or cache to store that? And why it stores the 32 bit long address to 32 bit long integer? Wouldn’t it be better to simply store in its cache that actual number than the pointer to that when the sizes are the same?

And last one – if it stores somewhere in its own cache the addresses to all those integers and the lenghts are the same (4 bytes), it will need exactly the same space for storing the addresses as for the actual variables. But variables can take up to 4GBs of space so CPU must have 4GB of its own space to store the addresses to those variables. And that sounds strange..

Thank you for help!
I’m trying to understand that but it’s so tough.. :-[

Answer 1

(First question – Do I understand it right?)

The first thing to recognise is that the value might not be stored in main memory at all. The compiler might decide to store it in a register instead, as this is more optimal.¹

The memory is byte-addressable, so CPU chooses 4 continuous bytes for my variable and stores the address to first (or last) byte.

Assuming that the compiler does decide to store it in main memory, then yes, on a 32-bit machine, an int is typically 4 bytes, so 4 bytes will be allocated for storage.

The size of that address (pointer to that variable) is 4bytes in 32-bit CPU. (Thats why 32-bit CPU can use max 4GB of memory – because there are only 2^32 different addresses of binary length 32)

Note that the width of an int and the width of a pointer don’t have to be the same, so there’s not necessarily a connection with the size of the address space.

Now, where the CPU stores these addresses?

In the case of local variables, the address is effectively hardcoded into the executable itself, typically as an offset from the stack pointer.

In the case of dynamically-allocated objects (i.e. stuff that’s been malloc-ed), the programmer typically maintains a corresponding pointer variable (otherwise there would be a memory leak!). That pointer might also be dynamically-allocated (in the case of a complex data structure), but if you go back far enough, you’ll eventually reach something that’s a local variable. In which case, the above rule applies.

But variables can take up to 4GBs of space so CPU must have 4GB of its own space to store the addresses to those variables.

If your program consists of independently malloc-ing millions of ints, then yes, you’d end up with just as much storage required for the pointers. But most programs don’t look like that. You typically allocate much bigger objects (like an array, or a big struct).

cache

The specifics of where stuff is stored is architecture-specific. On a modern x86, there’s typically 2 or 3 layers of cache sitting between the CPU and main memory. But the cache is not independently addressable; the CPU cannot decide to store the int in cache instead of main memory. Rather, the cache is effectively a redundant copy of a subset of main memory.

Another thing to consider is that the compiler will typically deal with virtual addresses when allocating storage for objects. On a modern x86, these are mapped to physical addresses (i.e. addresses that correspond to physical storage bytes in main memory) by dedicated hardware, along with OS support.

---

_{1. Alternatively, the compiler may be able to optimise it away entirely.}