It became necessary to study in detail how the memory is arranged in a computer. A colleague on the forum has recommended this article on Habré , which will give the minimum that a software developer needs.

In the section “Address Space”, the author demonstrates by example in C that the virtual memory segments actually go in order: “code-heap-stack”.

I also ran this code:

#include <stdio.h> #include <stdlib.h> int main() { int v = 3; printf("Code is at %p \n", (void *)main); printf("Heap is at %p \n", malloc(8)); printf("Stack is at %p \n", (void *)&v); _getch(); return 0; }

and that's what happened to me:

Code is at 001B1299
Heap is at 00FF5168
Stack is at 00EFF87C

Using an online resource , I translated these addresses from hexadecimal to decimal and got:

Code is at 001B1299 => 1774233 (1)
Heap is at 00FF5168 => 16732520 (3)
Stack is at 00EFF87C => 15726716 (2)

If you rank these values, it turns out that the order (see the numbers in brackets) of the segments of the allocated virtual memory for the process is: “code- stack- heap”, and not as shown by the author in the illustration

code-to-pile address space

“Code- pile- stack”

Question

Where am I wrong? What did not understand?

I can not continue to read the article until I understand this piece).

  • You wrote further: "But all these three addresses are fake. The physical memory at 0x7ffe60a1465c does not store an integer variable with a value of 3. Never forget that all user programs manipulate virtual addresses, and only at the kernel or hardware drivers are allowed physical memory addresses. " - Harry
  • @Harry, yes, I learned this moment. I'm interested in order . Then it turns out that this order is relevant only on the physical level ? And yet I should note that no matter how many times I run the above C code, the order of the values ​​for the virtual addresses will be the same (code-stack-heap). This also torments me). - Adam
  • You see, by and large - what's the difference to you? I'm serious! If you are not writing super-system things like drivers, then sort out the memory model of the language. It's just that everyone lies here ... The operating system pretends that the program has such an address space, the program - which believes in it :) It’s just that different operating systems, not to mention solutions can be very different in different architectures. Well, in DOS it was still possible to bother with this - there was access everywhere and to everything, and now? You do not even know where your specific memory is real - maybe in RAM, maybe on disk ... - Harry
  • 2
    The order is generally not important, each OS has them in its own way. At the physical level, the order is also not specified, since the segments will be located where the segment registers point. And in x86-64 we got rid of the segments altogether, there is a flat memory model. The manual from AMD (Chapter 2) quite clearly describes the memory model in x86. - Flowneee
  • 2
    The best description about the memory "What Every Programmer Should Know About Memory" people.freebsd.org/~lstewart/articles/cpumemory.pdf it is also in Russian rus-linux.net/lib.php?name=/MyLDP/hard/memory /memory.html - vasily-vm

0