Printable View
Can someone please explain why the memory addresses are getting lower in the below code.
Code:int main(void)
{
int num1 = 1;
int num2 = 2;
int num3 = 3;
int num4 = 4;
// this outputs
cout << &num1 << '\n' // 006AFF4
<< &num2 << '\n' // 006AFF0
<< &num3 << '\n' // 006AFEC
<< &num4 << '\n'; // 006AFE8
return(0);
}
It's because your program's stack is growing downward.
Does anyone know of a good link that explains the inner workings of the pc , explaining how the Stack , Cpu , registers and what not work together .
An easy explanation if possible.
Thanks froggy.
if you want to understand such stuff well, you need to learn assembly IMO.
I think all of this depends on the particular compiler implimentation. As far as I know, the C++ standard only specifies that arrays are stored sequentially, etc.
With a PC, you never know where the data is physically... With virtual memory and casching, it could be anywhere! The address-of operator will always work within your program because the operating system knows the real address, or where to find it in a disk file being used for virtual memory.
:confused: PC HARDWARE INFO: :confused:
I have an old out-of-date & out-of-print book (pre-Pentium, maybe even pre-386) that has a lot of hardware info... including a memory-map. I haven't found a similar up-to-date book. Reciently, I was able to find the one bit of PC-hardware info I was looking for by patiently searching the net.
Of course, you can find-out more than you want to know about the Pentium, from Intel. I think Intel has "typical" and "suggested" PC design information too.
To actually access the hardware with C++, you have to get-thru the operating system, and maybe the BIOS. All of the newer Windows versions restrict access to the hardware in "user mode". You have to get into the kernel mode to directly read & write hardware. And, I think the only to get into the kernel mode is with the DDK (Driver Development Kit) compiler.
It seems odd to me that there are all these open source OSs out there, but no one has bothered to write it all down in a readable form. It must be out there somewhere.
Physically data is either in the cache, in the second cache, in the memory or on the disc. You can guess when it is in the cache by reading the Intel doc. but for the virtual memory, it is OS-dependant but I think Widnows usually lock some parts of the memory for an application. (I've read something about that but cannot remember)Quote:
Originally posted by DougDbug
I think all of this depends on the particular compiler implimentation. As far as I know, the C++ standard only specifies that arrays are stored sequentially, etc.
With a PC, you never know where the data is physically... With virtual memory and casching, it could be anywhere! The address-of operator will always work within your program because the operating system knows the real address, or where to find it in a disk file being used for virtual memory.
What do you mean by "typical" & "suggested"? Really, Intel gives us great documentation.Quote:
Originally posted by DougDbug
Of course, you can find-out more than you want to know about the Pentium, from Intel. I think Intel has "typical" and "suggested" PC design information too.
It's the ring privilege thing some people speak of that makes you have all rights but under Widnows, I doubt you can access it, I think, only the kernel has it, even drivers has the 1.Quote:
Originally posted by DougDbug
To actually access the hardware with C++, you have to get-thru the operating system, and maybe the BIOS. All of the newer Windows versions restrict access to the hardware in "user mode". You have to get into the kernel mode to directly read & write hardware. And, I think the only to get into the kernel mode is with the DDK (Driver Development Kit) compiler.
For a complete and up to date reference on processors, check the Intel developers site, it explains about all you want to know about the IA-32 architecture work. (probably what you have so...)
A very good explanation can be found in Computer Organization and design. It uses the MIPS processer which is much easier to use than intel. Pretty much all processors have a stack with the convention that it grows downward. This seems backward, abnormal or crazy but that's the way they do it. In software(with no error checking) it would look something likeQuote:
Does anyone know of a good link that explains the inner workings of the pc , explaining how the Stack , Cpu , registers and what not work together .
An easy explanation if possible.
As you can see, the stack grows downward into lower memory address. Every time you push, top is subtracted one word(just 1 index in this case) and then the new top of the stack is assigned to the item. The pop does this basically in reverse.Code:int stack[MAX_SIZE];
int top = MAX_SIZE;
void push(int item)
{
stack[--top] = item;
}
int pop()
{
return stack[top++];
}
Main is a function so it's variables are local to it. What most compilers will do is write something likeQuote:
int main(void)
{
int num1 = 1;
int num2 = 2;
int num3 = 3;
int num4 = 4;
// this outputs
cout << &num1 << '\n' // 006AFF4
<< &num2 << '\n' // 006AFF0
<< &num3 << '\n' // 006AFEC
<< &num4 << '\n'; // 006AFE8
return(0);
}
Code:int main(void)
{
// make room for 4 stack variables with word size of 1
// a=>stack[top]
// b=>stack[top + 1]
// c =>stack[top + 2]
// d=>stack[top+3]
top -= 4;
// assign a, b, c, d to some values...
// several calls to operation<<
// The usual operation is that the variables are
// pushed on to the stack right to left and then the callee
// is able to look at the stack and get the varibables
// printf is easier to use
push(stack[top + 3]);
push(stack[top + 2]);
push(stack[top + 1]);
push(stack[top]);
// this would be a constant string stored in the data
// section somewhere
push("a = %d, b = %d, c = %d, d = %d");
// this would push the current instruction
// pointer + WORD_SIZE onto the stack and then jump to
// the location of the global printf routine.
// Then when printf returns it would jump to the
// current instruction pointer + WORD_SIZE on the stack
call printf;
return 0;
}