Чим відрізнятиметься процесор, призначений виключно для функціонального програмування?

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

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

Якщо хтось спроектував би процесор з нуля, знаючи, що він буде коли-небудь запускати програми, написані у функціональному стилі програмування, то як цей процесор буде розроблений інакше, ніж існуючі процесори?

Насправді це зроблено: https://en.wikipedia.org/wiki/Lisp_machine

Одним з аспектів розробки процесора для FP є збирання сміття. GC дуже важливий для функціональних мов. Загальні реалізації вимагають, щоб GC міг розрізняти покажчики та дані, що не вказують. Ефективно, це означає збереження зайвого біта вздовж даних. Це є причиною того, що, наприклад, цілі числа OCaml є лише 31 бітними для 32-бітових архітектур та 63-бітових для 64-розрядних архітектур. Арифметика цілочисельних значень передбачає незручні додаткові операції зсуву. Інші мови (або інші типи даних OCaml) можуть витрачати цілі машинні слова на цей додатковий біт, використовуючи таким чином 128 біт для 64-бітових цілих чисел. Центральний процесор, створений на основі GC, може мати 65-бітну шину даних, але 64-бітну арифметику.

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

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

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

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

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

Що може відрізнятись - це можливість завантажувати декілька функцій та запускати їх без фронтування кадрів - але додавання декількох одиниць для функцій створює безлад з доступом до пам'яті.

Якщо додати відповідь Kne, GC буде корисним для роботи як співпроцесора, це було б дуже акуратною особливістю.

1: PilGRIM правильно описаний у Boeijink A., Hölzenspies PKF, Kuper J. (2011) Представляючи PilGRIM: процесор для виконання лінивих функціональних мов. В: Хейдж Дж., Моразан MT (редакції) Впровадження та застосування функціональних мов. IFL 2010. Конспекти лекцій з інформатики, т. 6647. Спрингер, Берлін, Гейдельберг .

Спочатку трохи жарт: оскільки 100% функціональна програма ніколи не може зробити нічого корисного, достатньо мати лише інструкцію NOP. (Я відкриваю це для полум'яних воєн).

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

Інакше це частково залежить від фактично використовуваної мови. Думаю, що є на очах - Хаскелл і Ерланг.

Я вважаю, що Haskell може скористатися підтримкою списків і карт. Список може бути підтриманий конкретними відображеннями апаратної пам'яті, перетворивши пов'язаний список у послідовний набір адрес. Перший елемент може бути на адресі n, другий на адресі n + 1 тощо. Щоб видалити перший елемент зі списку, ви просто зміните вказівник n. Нарешті, при видаленні n вказівника вся пам'ять може бути звільнена. Карти можуть підтримуватися як асоціативні масиви - введіть значення пошуку, а система пам'яті поверне елемент. Не потрібно ітеративних пошуків.

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