Why does the stack address grow towards decreasing memory addresses?

by

First, it’s platform dependent. In some architectures, stack is allocated from the bottom of the address space and grows upwards.

Assuming an architecture like x86 that stack grown downwards from the top of address space, the idea is pretty simple:

===============     Highest Address (e.g. 0xFFFF)
|             |
|    STACK    |
|             |
|-------------|  <- Stack Pointer   (e.g. 0xEEEE)
|             |
.     ...     .
|             |
|-------------|  <- Heap Pointer    (e.g. 0x2222)
|             |
|    HEAP     |
|             |
===============     Lowest Address  (e.g. 0x0000)

To grow stack, you’d decrease the stack pointer:

===============     Highest Address (e.g. 0xFFFF)
|             |
|    STACK    |
|             |
|.............|  <- Old Stack Pointer (e.g. 0xEEEE)
|             |
| Newly       |
| allocated   |
|-------------|  <- New Stack Pointer (e.g. 0xAAAA)
.     ...     .
|             |
|-------------|  <- Heap Pointer      (e.g. 0x2222)
|             |
|    HEAP     |
|             |
===============     Lowest Address    (e.g. 0x0000)

As you can see, to grow stack, we have decreased the stack pointer from 0xEEEE to 0xAAAA, whereas to grow heap, you have to increase the heap pointer.

Obviously, this is a simplification of memory layout. The actual executable, data section, … is also loaded in memory. Besides, threads have their own stack space.

You may ask, why should stack grow downwards. Well, as I said before, some architectures do the reverse, making heap grow downwards and stack grow upwards. It makes sense to put stack and heap on opposite sides as it prevents overlap and allows both areas to grow freely as long as you have enough address space available.

Another valid question could be: Isn’t the program supposed to decrease/increase the stack pointer itself? How can an architecture impose one over the other to the programmer? Why it’s not so program dependent as it’s architecture dependent?
While you can pretty much fight the architecture and somehow get away your stack in the opposite direction, some instructions, notably call and ret that modify the stack pointer directly are going to assume another direction, making a mess.

More Related Contents:

  1. What and where are the stack and heap?
  2. What are the differences between virtual memory and physical memory?
  3. Tricks to manage the available memory in an R session
  4. Why doesn’t my program crash when I write past the end of an array?
  5. Is it necessary to use autoreleasepool in a Swift program?
  6. What is the direction of stack growth in most modern systems?
  7. Global memory management in C++ in stack or heap?
  8. Does Rust free up the memory of overwritten variables?
  9. Proper stack and heap usage in C++?
  10. Explanation of strong and weak storage in iOS5
  11. bds 2006 C hidden memory manager conflicts (class new / delete[] vs. AnsiString)
  12. iPhone OS Memory Warnings. What Do The Different Levels Mean?
  13. memory limit in Node.js (and chrome V8)
  14. MATLAB’s Garbage Collector?
  15. Does calling free or delete ever release memory back to the “system”
  16. gfortran for dummies: What does mcmodel=medium do exactly?
  17. Are these objects’s references on the Stack or on the Heap?
  18. How does the stack work in assembly language?
  19. How can I initialize View Again in SwiftUI?
  20. What is the behavior of “delete” with stack objects? [duplicate]
  21. How does the Garbage Collection mechanism work? [closed]
  22. Linux memory overcommit details
  23. Determining Stack Space with Visual Studio
  24. Does this type of memory get allocated on the heap or the stack?
  25. How to get memory size of variable?
  26. How to implement Memory Pooling in Golang
  27. Tensorflow : Memory leak even while closing Session?
  28. Difference between local allocatable and automatic arrays
  29. CUDA : How to allocate memory for data member of a class
  30. Allowed memory size of X bytes exhausted

Leave a Comment