Understanding Memory Addresses and Variables

[zb0S216C]

I'm confused. When I read about how variables are stored into memory, they said that the memory location, where the variable was stored, was assigned a memory address. For example:

// iVar is stored into memory as a 4-byte block with the address: 0020F78c.
int iVar( 10 ); 

Now, an int type allocates 4 bytes of memory. Each byte consists of 8 bits. So, 4( bytes ) * 8( bits ) = 32( bits ). That's 32 address.

So when I create iVar, do all of the bits used in the allocation of iVar group and make one single address( 0020F78c )?

I'm sorry if it's unclear but I can't really explain it any better than that.

_Wazzak

[Moschops]

That's 32 address.

That is not true.

The following is common, but not by any means true in all cases. I reckon it's probably true on your (and my) system, though.

Your system is (unless you're running some way cool crazy system) not capable of addressing individual bits. Individual bits do not get separate addresses. By definition of the C++ language, char is the smallest possible addressable size, and thus is of size one byte (which may or may not be 8 bits - that's common, but not required). Each byte gets an address.

A variable's address is (usually) the address of the first byte it occupies. If that variable is a single object spread across many bytes, it doesn't matter.

I stand by to be corrected on any of this; my practical knowledge of this comes from the embedded world, where examining individual memory addresses is standard practice during development, but SHARC processors and the like are not x86 processors.

There is the added issue that memory is often aligned into chunks of defined size to make it easier for the processor to handle memory quickly, but nonetheless each byte is addressable.

[Athar]

So when I create iVar, do all of the bits used in the allocation of iVar group and make one single address( 0020F78c )?

They make the value 10 and nothing else. The variable's address is not stored anywhere directly.

[zb0S216C]

Moschops wrote:

Individual bits do not get separate addresses

That's put a twist on things after reading an article just now^[1].

Also, I've just read another PDF document that specifies that each cells has a unique integer address^[2].

Still, even if a single byte has it's own address, why is there only one address between 4 bytes?

References:
^[1]http://computer.howstuffworks.com/ram1.htm
^[2]http://www.utdallas.edu/~cantrell/ee2310/memaddr.pdf


_WazzaK

[webJose]

Variables require memory. When you declare a variable of certain type, the compiler makes sure that an appropriate piece of the PC's memory is used to store the value of that variable.

You normally don't care about "where" in the vast PC's memory banks your particular variable stores its value, right? You just know that the value is "somewhere" and that you can read such a value by just referring to your variable.

Now, IF you wanted to know "where" in the memory your value is stored at, then you would request the variable's address. That is the hex number you usually see. Why a number? Why in hex format? Simple: There are no street names in the PC's memory world. Actually, there are no streets. :D So what did you expect as an address? To further elaborate:

Think of the memory world as a world with just one street, with houses on the left side only. The address of the first house (byte) is address 0 (zero); the second house (byte) is address 1, etc.

Why in hex format? Because hex is more compact than decimal notation, but nothing prevents you from displaying addresses in decimal notation.

Why 32-bit addresses? Well, that depends on your hardware. If your processor is capable of handling 64 bits as a single unit (number), then the addresses in that PC can be 64 bits in width. Same goes for other sizes.

[zb0S216C]

webJose wrote:

You normally don't care about "where" in the vast PC's memory banks your particular variable stores its value, right?

I do.

webJose wrote:

Now, IF you wanted to know "where" in the memory your value is stored at, then you would request the variable's address. That is the hex number you usually see. Why a number? Why in hex format? Simple: There are no street names in the PC's memory world. Actually, there are no streets. :D So what did you expect as an address?

I already know this. Addresses are represented in hexadecimal.

webJose wrote:

Why 32-bit addresses? Well, that depends on your hardware. If your processor is capable of handling 64 bits as a single unit (number), then the addresses in that PC can be 64 bits in width.

My version of the Core 2 Quad is 64-bit enabled.

_Wazzak

[Moschops]

#include <iostream>

int main()

{

  char a[2];
 

  std::cout << (int*)&a[0] << std::endl;
  std::cout << (int*)&a[1] << std::endl;

return 0;
}

This code demonstrates the two elements of the char array in two adjacent memory addresses. Clearly, there is no memory address between the two memory addresses; each char occupies one complete addressable memory address. The char is known to be eight bits in this implementation; clearly, each bit does not have its own address.

Still, even if a single byte has it's own address, why is there only one address between 4 bytes?

There is not. Each byte has a unique address. 4 bytes have one address each; 4 addresses. Your processor may have a preference for fetching 4 bytes at once (i.e. 32 bits) or perhaps 8 bytes at once (i.e. 64 bits) but that's just how the processor works and it's not relevant to the addressing of the bytes. Perhaps you have a variable spread across four bytes; the address of the variable is the address of the first byte it occupies. The fact that it spreads across three more bytes doesn't mean those bytes don't have an address.

The compiler may well decide to optimise and make the processor's life easier by being clever, knowing that the processor likes to work in batches of 4 or 8 bytes. That's just the compiler being clever. One byte - one address.

[zb0S216C]

Moschops wrote:

Each byte has a unique address. 4 bytes have one address each; 4 addresses.

So when I print the address of a variable, I'm actually printing the address of the first byte^[1]?

So, to summarize, bits don't have memory address, only bytes do. Also, a byte contains 8 bits of information, which is the binary representation of the data in that byte. Finally, when printing the address of a given variable to the screen, the address of the first byte allocated is usually the address that appears on the screen.

I know about wordlines, bitlines, and sense amplifiers, but it was the addressing of the data that was troubling me.

References:
^[1]

Moschops wrote:

A variable's address is (usually) the address of the first byte it occupies.

_Wazzak

[Moschops]

I think the only part of that actually mandate by the C++ standard is that a byte is the smallest possible addressable unit of memory; the actual size of that memory is up to the hardware, so if you had hardware capable of addressing individual bits, presumably each bit would be a byte and would have a unique address.

The address of a multi-byte variable; it's been the address of the first byte it occupies on every system I've played with the memory of, but presumably you could write a compiler that kept track of the last byte of each variable, and used that as the address. So long as it was internally consistent, it would still work. Presumably, you could come up with all sorts of crazy ways of doing it, so long as the processor's instruction set was capable of it. The C++ standard leaves that to the implementation, as indeed it should.

So when I print the address of a variable, I'm actually printing the address of the first byte[1]?

That's all I've ever seen it as, but I can imagine (crazy) alternative implementations that would still work.