Чи є стеки єдиним розумним способом структурування програм?

Більшість архітектур, яких я бачив, покладаються на стек викликів для збереження / відновлення контексту перед викликами функцій. Це така загальна парадигма, що операції push та pop вбудовані в більшість процесорів. Чи є системи, які працюють без стека? Якщо так, то як вони працюють, і для чого вони використовуються?

Деякою популярною альтернативою стеку викликів є продовження .

Наприклад, папуга VM заснована на продовженні. Це повністю безрезультатно: дані зберігаються в регістрах (наприклад, Dalvik або LuaVM, Parrot заснований на регістрі), а потік управління представлений з продовженнями (на відміну від Dalvik або LuaVM, які мають стек викликів).

Інша популярна структура даних, яку зазвичай використовують VM Smalltalk та Lisp, - це стек спагетті, який схожий на мережу стеків.

Як зазначав @rwong , стиль передачі продовження є альтернативою стеку викликів. Програми, написані у (або перетвореному) стилі продовження передачі, ніколи не повертаються, тому немає необхідності в стеці.

Відповідаючи на ваше питання з іншої точки зору: можна мати стек викликів, не маючи окремого стека, виділивши кадри стека на купу. Деякі реалізації Lisp та Scheme роблять це.

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

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

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

Між продемонстрованою виконанням інструкцій послідовного доступу та вигідною кешируючою поведінкою стеку викликів у нас, принаймні, на даний момент, виграшна модель продуктивності.

(Ми можемо також кинути змінні структури даних також у твори ...)

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

TL; DR

• Стек виклику як механізм виклику функції:
  1. Зазвичай моделюється обладнанням, але не має принципового значення для побудови апаратних засобів
  2. Є основним для імперативного програмування
  3. Не є принциповим для функціонального програмування
• Стек як абстракція "останнього, першого виходу" (LIFO) є основоположним для інформатики, алгоритмів і навіть деяких нетехнічних областей.
• Деякі приклади організації програми, які не використовують стеки викликів:
  • Стиль продовження руху (CPS)
  • Державна машина - гігантська петля, з усім накресленою. (Створюється натхнення архітектурою прошивки Saab Gripen і приписується комунікації Генрі Спенсера та відтворено Джоном Кармаком.) ^{(Примітка №1)}
  • Архітектура потоку даних - мережа акторів, з'єднаних чергами (FIFO). Черги іноді називають каналами.

Решта цієї відповіді - випадковий збір думок і анекдотів, а отже дещо неорганізований.

Стек, який ви описали (як механізм виклику функцій), характерний для імперативного програмування.

Нижче необхідного програмування ви знайдете машинний код. Машинний код може імітувати стек виклику, виконавши невелику послідовність інструкцій.

Нижче машинного коду ви знайдете обладнання, відповідальне за виконання програмного забезпечення. Хоча сучасний мікропроцесор занадто складний, щоб описати тут, можна уявити, що існує дуже проста конструкція, яка повільна, але все ще здатна виконувати той же машинний код. Такий простий дизайн дозволить використовувати основні елементи цифрової логіки:

1. Комбінаційна логіка, тобто з'єднання логічних воріт (і, або, ні, ...) Зауважте, що "комбінаційна логіка" виключає зворотні відгуки.
2. Пам'ять, тобто шльопанці, засувки, регістри, SRAM, DRAM тощо.
3. Державна машина, яка складається з деякої комбінаційної логіки та деякої пам’яті, достатньо, щоб вона могла реалізувати «контролер», який управляє рештою обладнання.

Наступні дискусії містили велику кількість прикладів альтернативних способів структурування імперативних програм.

• http://number-none.com/blow/john_carmack_on_inlined_code.html
• https://news.ycombinator.com/item?id=8374345

Структура такої програми буде виглядати приблизно так:

void main(void)
{
    do
    {
        // validate inputs for task 1
        // execute task 1, inlined, 
        // must complete in a deterministically short amount of time
        // and limited to a statically allocated amount of memory
        // ...
        // validate inputs for task 2
        // execute task 2, inlined
        // ...
        // validate inputs for task N
        // execute task N, inlined
    }
    while (true);
    // if this line is reached, tell the programmers to prepare
    // themselves to appear before an accident investigation board.
    return 0; 
}

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

Ні, не обов’язково.

Прочитати стару паперову колекцію Appel Збір сміття може бути швидше, ніж виділення стека . Він використовує стиль проходження продовження і демонструє безладну реалізацію.

Зауважте також, що в старих архітектурах комп'ютерів (наприклад, IBM / 360 ) не було реєстру апаратних стеків. Але ОС і компілятор зарезервували реєстр покажчика стека за умовами (пов'язаний з умовами викликів ), щоб вони могли мати стек програмного виклику .

В принципі, цілий компілятор програми та оптимізатор програми C могли виявити випадок (дещо поширений для вбудованих систем), коли графік викликів є статистично відомим і без рекурсії (або функціональних покажчиків). У такій системі кожна функція могла зберігати свою зворотну адресу у фіксованому статичному розташуванні (саме так Fortran77 працював у комп’ютерах епохи 1970 року).

У ці дні процесори також мають стеки викликів (і інструкції з виклику та повернення машини), відомі про кеші процесора .

Ви отримали кілька хороших відповідей поки що; дозвольте навести вам непрактичний, але високоосвічений приклад того, як ви могли б спроектувати мову без поняття стеки чи «контрольного потоку». Ось програма, яка визначає фактичні факти:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = f(3)

Ми ставимо цю програму в рядок і оцінюємо програму за текстовою підстановою. Отже, коли ми проводимо оцінку f(3), ми робимо пошук і замінюємо 3 на i, наприклад:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = if 3 == 0 then 1 else 3 * f(3 - 1)

Чудово. Тепер ми виконуємо ще одну підстановку тексту: ми бачимо, що умова "якщо" - хибне, і замінюємо інший рядок, виробляючи програму:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(3 - 1)

Тепер ми робимо ще одну заміну рядків для всіх підвиразів, що включають константи:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(2)

І ви бачите, як це йде; Я не буду більше працювати. Ми могли б продовжувати робити ряд підстановок, поки не дійшли до let x = 6нас, і ми не закінчилися

Ми використовуємо стек традиційно для локальних змінних та інформації про продовження; Пам'ятайте, стек не говорить вам, звідки ви прийшли, він говорить вам, куди ви йдете далі, з цією поверненою вартістю в руці.

У моделі підстановки рядків програмування на стеці немає "локальних змінних"; формальні параметри замінюються на їх значення, коли функція застосовується до її аргументу, а не поміщається в таблицю пошуку на стеці. І немає "йти кудись далі", тому що оцінювання програми - це просто застосування простих правил підстановки рядків для створення іншої, але еквівалентної програми.

Звичайно, насправді робити заміну рядків - це, мабуть, не шлях. Але мови програмування, які підтримують «екваціональне міркування» (наприклад, Haskell), логічно використовують цю методику.

З часу публікації Парнасом у 1972 р. Про критерії, які слід використовувати при розкладанні систем на модулі , було прийнято вважати, що інформація приховується в програмному забезпеченні - це добре. Це випливає з тривалої дискусії протягом 60-х про структурну декомпозицію та модульне програмування.

Модульність

Необхідний результат взаємозв'язку між модулями, реалізованими різними групами в будь-якій багатопотоковій системі, вимагає механізму, що дозволяє перезавантажитись, і засоби для відстеження динамічного графіка виклику системи. Контрольований потік виконання повинен переходити як у кілька модулів, так і виходити з них.

Динамічне оцінювання

Як тільки лексичного обстеження недостатньо для відстеження динамічної поведінки, то для відстеження різниць потрібні певні облікові записи.

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

Винятки

Отже, поки модель продовження не підтримує структуру даних явно для стека, все ще є вкладене виклик модулів, який треба десь підтримувати!

Навіть декларативні мови або підтримують історію оцінювання, або навпаки вирівнюють план виконання з міркувань ефективності та підтримують прогрес якось іншим чином.

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

Кілька одночасних нескінченних циклів не вимагають жодної структури для утримання зворотних адрес, оскільки вони не викликають функції, що робить запит запитом. Якщо вони спілкуються за допомогою загальних змінних, вони можуть легко перерости у застарілі аналоги зворотної адреси у стилі Fortran.

Усі старі мейнфрейми (IBM System / 360) взагалі не мали поняття про стек. Наприклад, на 260, параметри були побудовані у фіксованому місці в пам'яті, і коли викликалася підпрограма, вона викликалася з R1вказівкою на блок параметрів і R14містить зворотну адресу. Викликана програма, якби вона хотіла викликати іншу підпрограму, повинна була б зберігатись R14у відомому місці перед тим, як здійснити цей виклик.

Це набагато надійніше, ніж стек, тому що все може зберігатися у фіксованих місцях пам'яті, встановлених під час компіляції, і це може бути на 100% гарантовано, що процеси ніколи не закінчуються. Немає жодного з "Виділіть 1 МБ і схрестіть пальці", що ми маємо робити сьогодні.

Рекурсивні виклики підпрограми були дозволені в PL / I, вказавши ключове слово RECURSIVE. Вони означали, що пам'ять, яка використовується підпрограмою, динамічно, а не виділяється статично. Але рекурсивні дзвінки були настільки ж рідкісними, як і зараз.

Експлуатація без стоків також значно спрощує масивні багатопотокові нитки, саме тому часто робляться спроби зробити сучасні мови безслідними. Наприклад, немає жодної причини, наприклад, чому компілятор C ++ не міг бути модифікований на зворотній частині для використання динамічно розподіленої пам'яті, а не стеків.