No dudes en divulgar nuestra página y códigos en tus redes sociales, ayúdanos a hacer crecer esta comunidad.
Solución:
Primero, depende de la plataforma. En algunas arquitecturas, la pila se asigna desde la parte inferior del espacio de direcciones y crece hacia arriba.
Asumiendo una arquitectura como x86 que se acumula hacia abajo desde la parte superior del espacio de direcciones, la idea es bastante simple:
=============== Highest Address (e.g. 0xFFFF)
| |
| STACK |
| |
|-------------| <- Stack Pointer (e.g. 0xEEEE)
| |
. ... .
| |
|-------------| <- Heap Pointer (e.g. 0x2222)
| |
| HEAP |
| |
=============== Lowest Address (e.g. 0x0000)
Para hacer crecer la pila, disminuiría el puntero de la pila:
=============== 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)
Como puede ver, para hacer crecer la pila, tenemos disminuido el puntero de la pila de 0xEEEE a 0xAAAA, mientras que para hacer crecer el montón, debe aumentar el puntero del montón.
Obviamente, esta es una simplificación del diseño de la memoria. El ejecutable real, la sección de datos, ... también se carga en la memoria. Además, los hilos tienen su propio espacio de pila.
Puede preguntarse, ¿por qué la pila debería crecer hacia abajo? Bueno, como dije antes, algunas arquitecturas hacen lo contrario, haciendo que el montón crezca hacia abajo y la pila crezca hacia arriba. Tiene sentido colocar la pila y el montón en lados opuestos, ya que evita la superposición y permite que ambas áreas crezcan libremente siempre que tenga suficiente espacio de direcciones disponible.
Otra pregunta válida podría ser: ¿No se supone que el programa debe disminuir/aumentar el puntero de la pila? ¿Cómo puede una arquitectura imponer una sobre la otra al programador? ¿Por qué no depende tanto del programa como de la arquitectura? Si bien puedes luchar contra la arquitectura y de alguna manera escapar de tu pila en la dirección opuesta, algunas instrucciones, en particular call y ret que modifican el puntero de la pila directamente van a asumir otra dirección, haciendo un lío.
Hoy en día es en gran parte porque se ha hecho de esa manera durante mucho tiempo y muchos programas asumen que se hace de esa manera, y no hay una razón real para cambiarlo.
Sin embargo, cuando los dinosaurios vagaban por la tierra y las computadoras tenían 8kB de memoria, si tenías suerte, era una importante optimización del espacio. Pones la parte inferior de la pila en la parte superior de la memoria, creciendo hacia abajo, y colocas el programa y sus datos en la parte inferior, con el malloc área de crecimiento. De esa forma, el único límite en el tamaño de la pila era el tamaño del programa + montón, y viceversa. Si, en cambio, la pila comenzara en 4kB (por ejemplo) y creciera, el almacenamiento dinámico nunca podría superar los 4kB (menos el tamaño del programa), incluso si el programa solo necesitara unos pocos cientos de bytes de pila.
Man CLONE: El argumento child_stack especifica la ubicación de la pila utilizada por el proceso secundario. Dado que el proceso secundario y el que llama pueden compartir memoria, no es posible que el proceso secundario se ejecute en la misma pila que el proceso que llama. Por lo tanto, el proceso de llamada debe configurar el espacio de memoria para la pila secundaria y pasar un puntero a este espacio para clonar(). Las pilas crecen hacia abajo en todos los procesadores que ejecutan Linux (excepto los procesadores HP PA), por lo que child_stack generalmente apunta a la dirección superior del espacio de memoria configurado para la pila secundaria.
Más adelante puedes encontrar las notas de otros usuarios, tú incluso puedes dejar el tuyo si te apetece.