Чому ми все ще вирощуємо стек назад?

Під час компіляції коду C і перегляду складання у нього все стек відростає так:

_main:
    pushq   %rbp
    movl    $5, -4(%rbp)
     popq    %rbp
    ret

-4(%rbp)- це означає, що базовий покажчик або покажчик стека насправді рухаються вниз по пам'яті, а не піднімаються вгору? Чому так?

Я змінив $5, -4(%rbp)до $5, +4(%rbp)підбиралася і побіг код , і не було ніяких помилок. То чому ми мусимо ще йти назад на стеці пам'яті?

Чи означає це, що базовий вказівник або покажчик стека насправді рухаються вниз по пам'яті, а не вгору? Чому так?

Так, pushінструкції зменшують покажчик стека і записують у стек, тоді як popроблять зворотний, читають із стека та збільшують покажчик стека.

Це дещо історично, оскільки для машин з обмеженою пам’яттю стек був розміщений високо і зростав вниз, тоді як купа була розміщена низько і виросла вгору. Існує лише один проміжок "вільної пам'яті" - між купою та стеком, і цей проміжок розділяється, або кожен може перерости в проміжок за потреби індивідуально. Таким чином, програма втрачає пам'ять лише тоді, коли стек і купа стикаються, не залишаючи вільної пам'яті. 

Якщо і стек, і купа ростуть в одному напрямку, тоді є дві прогалини, і стек не може реально перерости в проміжок купи (навпаки, також проблематично).

Спочатку процесори не мали спеціальних інструкцій з обробки стеків. Однак, оскільки підтримка стека була додана до апаратного забезпечення, вона взяла цю схему зростання вниз, і процесори досі слідують цій схемі і сьогодні.

Можна стверджувати, що на 64-бітній машині є достатній адресний простір для дозволу декількох прогалин - і як доказ, кілька прогалин обов'язково мають місце, коли процес має декілька потоків. Хоча це не є достатньою мотивацією для того, щоб змінити ситуацію навколо, оскільки при кількох системах розриву напрямок зростання, мабуть, довільний, тому традиція / сумісність підказує шкалу.

Ви повинні були б змінити інструкції по обробці стеки CPU для того , щоб змінити напрямок стека, або відмовитися від використання виділеного штовхаючи і вискакують інструкції (наприклад push, pop, call, retта інших).

Зауважте, що архітектура набору інструкцій MIPS не має виділених значень push& pop, тому практично вирощувати стек в будь-якому напрямку - ви все одно можете мати розклад пам’яті з одним розривом для одного потокового процесу, але може збільшити стек вгору та купу вниз. Якщо ви це зробили, однак, деякий код varargs C може потребувати коригування в джерелі або при проходженні параметра під кришкою.

(Насправді, оскільки на MIPS не існує спеціальної обробки стека, ми можемо використовувати приріст до або після збільшення або попередній чи після публікації для натискання на стек до тих пір, поки ми використовуємо точний зворотній бік для вискочення стека, а також припускаючи, що Операційна система поважає обрану модель використання стека. Дійсно, у деяких вбудованих системах та деяких освітніх системах стек MIPS збільшується вгору.)

У вашій конкретній системі стек починається з високої адреси пам’яті і «зростає» вниз до низьких адрес пам'яті. (симетричний випадок від низького до високого також існує)

А оскільки ви змінилися з -4 і +4, і він пробіг, це не означає, що це правильно. Макет пам’яті запущеної програми складніший і залежить від багатьох інших факторів, які можуть сприяти тому, що ви не враз потрапили в аварію над цією надзвичайно простою програмою.

Вказівник стека вказує на межу між виділеною та нерозподіленою пам'яттю стека. Зростання його вниз означає, що він вказує на початок першої структури у виділеному просторі стеку, а інші виділені елементи слід за більшими адресами. Якщо вказівники вказують на початок виділених структур, це набагато частіше, ніж навпаки.

Зараз у багатьох системах існує окремий реєстр стеків кадрів, який можна дещо надійно розкрутити, щоб з'ясувати ланцюг викликів, з локальною змінною пам’яттю змінних. Шлях цей стек регістр кадрів встановлюється на деяких архітектурах означає , що він закінчує наведення за зберігання локальної змінної , на відміну від покажчика стека перед ним. Тож використання цього регістра кадру стека вимагає негативної індексації.

Зауважте, що кадри стека та їх індексація є побічним аспектом компільованих комп'ютерних мов, тому саме генератор коду компілятора повинен мати справу з "неприродністю", а не поганим програмістом мови складання.

Тож, хоча існували вагомі історичні причини вибору стеків для зростання вниз (а деякі з них зберігаються, якщо ви програмуєте на мові збірки і не переймаєтеся налаштуванням належного кадру стека), вони стали менш помітними.