october upd. SKIM, NORMA

compilers.md

@@ -46,6 +46,11 @@
     - [Этого имени я не слышал уже давно](#этого-имени-я-не-слышал-уже-давно)
   - [Ржавый пояс](#ржавый-пояс)
     - [Машины освобождения](#машины-освобождения)
+    - [Норман и NORMA](#норман-и-norma)
+      - [Small](#small)
+      - [SKIM](#skim)
+      - [SKIM II](#skim-ii)
+      - [NORMA](#norma)
 - [Литература](#литература)
 
 
@@ -1495,10 +1500,169 @@ innerproduct = foldr1 (+) . map (foldr1 (*)) . transpose
 Худак утверждает [Huda89], что реклама ФП от автора Фортрана - это "лучшее, что могло случится с ФП". Мы же в этом совсем не уверены. Потому, что вместе с функциональным программированием Бэкус популяризировал и не самую полезную для функционального программирования идею. Для некоторых ФЯ она оказалась даже смертельной.   
 Если своему свободному от проклятья Фон-Неймана языку Бэкус уделяет много внимания в своей версии лекции для публикации на сто страниц, то машинам, которые должны поддержать это освобождение уделяется гораздо меньше внимания. Бэкус отмечает как перспективные и анти-Фон-Неймановские машину Маго и работы Арвинда, к которым мы еще вернемся. Но читателям Бэкуса было достаточно общей идеи, машины они изобретут самостоятельно.   
 Идея о том, что плохие свойства языков программирования обусловлены неправильной машиной и для того, чтоб использовать хорошие языки нужны специальные правильные машины, не выглядит такой уж обоснованной из наших дней. Не выглядела она такой и для некоторых современников [Dijk78]. Но в конце 70-х она овладела умами многих функциональных программистов.   
-Во времена лекции Бэкуса Пейтон Джонс учился в Кембридже вместе со своим знакомым еще со школы Томасом Кларком (Thomas J. Clarke), и уже поучаствовавшими в нашей истории Хьюзом и Джоном Фейрберном.   
+Во времена лекции Бэкуса Пейтон Джонс учился в Кембридже вместе со своим знакомым еще со школы Томасом Кларком (Thomas J. Clarke), и уже поучаствовавшим в нашей истории Джоном Фейрберном.   
 Программы нужно писать в функциональном стиле, пересказывает Пейтон Джонс [SPJ18] послание Бэкуса, более того, нужно создавать новые компьютеры для исполнения таких программ.   
 И, может быть, это не самая лучшая идея, которую можно принести из 70-х в 80-е. В десятилетие, когда массовое железо, благодаря масштабам этой самой массовости, будет с каждым годом становиться все быстрее, дешевле и, следовательно, еще более массовым.   
 
+### Норман и NORMA
+
+> Хотя я не понимал математики, изложенной в Тьюринговской лекции Бэкуса, ее введение звучало смело и захватывающе: именно такая работа, в которой я хотел бы принять участие!   
+> Уильям Стой, Имплементация функциональных языков с использованием специального аппаратного обеспечения [Stoy85].   
+
+Пришла пора рассказать, чем же занимался Тернер все эти годы. Но сначала об еще одном функциональном проекте в Кембридже. Как обычно, началось все с системы компьютерной алгебры.   
+
+#### Small
+
+Артур Норман (Arthur Charles Norman) защитил диссертацию в 73-ем году в Кембридже и остался там преподавать. Но не только.   
+С 60-х годов в Кембридже разрабатывалась система компьютерной алгебры CAMAL [Fitc09], которую сначала напрасно надеялись переписать на CPL, а потом смогли переписать на Algol 68C и, наконец, переписали на BCPL. Это выделяет её из ряда систем компьютерной алгебры, с которыми мы сталкивались до сих пор. MACSYMA, REDUCE и SCRATCHPAD разрабатывались на Лиспах, иногда слегка замаскированных под Алгол. И пришедшие им на смену системы написаны на языках, которые больше похожи на BCPL и Algol 68, чем на LISP. Так что можно сказать, что CAMAL опередила свое время. Но опережение своего времени редко заканчивается чем-то хорошим и определенно не закончилось хорошо в случае CAMAL. Эти неудачи, однако, не помешали Кембриджу шагнуть навстречу новым, еще большим неудачам. Во второй половине 70-х, в Кембридже захотели написать собственную систему компьютерной алгебры на Лиспе.   
+К 77-ому году Норман, вместе с одним из основных разработчиков CAMAL Джоном Фитчем (John P. Fitch), разработали и имплементировали Лисп для её написания - Cambridge Lisp [Norm77] [Padg88], родственный Standard Lisp. Интерпретатор написали на BCPL и использовали его для бутстрапа компилятора на основе ранней версии компилятора Standard Lisp Хирна и Грисса.   
+Этот Лисп не стал особенно популярным, но написание интерпретатора на портируемом BCPL, вместо чего нибудь более специфичного для машины и низкоуровневого, не осталось незамеченным авторами одного из самых популярных Лиспов - Franz Lisp - написавшими его интерпретатор на C [Fode81].   
+В богатом на события нашей истории 79-ом году новая система компьютерной алгебры, называемая обычно "vector-based algebra system", разрабатывалась Норманом и Муром (P.M.A. Moore) уже шесть месяцев [Norm79] [Norm82] и существовала уже кое-как работающая версия. Не беспокойтесь, поворот к такой обычной для системы компьютерной алгебры того времени истории был скомпенсирован необычностью в другом. Ведь Артур Норман, не смотря на такую обычную для лиспера биографию, обладал необычными для лиспера предпочтениями.   
+Норман не хотел использовать в качестве командного и скриптового языка системы Лисп, даже и слегка замаскированный под Алгол. Он хотел более "плавный переход" из "мира алгебраических выражений" в программирование. Такое желание само по себе не очень необычно. Как мы выяснили, такие устремления были и у авторов ALGOL 60. Так что важнее, какой "переход" в данном случае посчитают достаточно "плавным". И тут Норман пошел даже дальше авторов SCRATCHPAD: для скриптования своей системы Норман выбрал функциональный язык Тернера SASL. ФЯ чистый и позднее еще и ленивый.   
+Пока что "SASL" предназначался для пользователя системы, но в перспективе хотелось сделать язык подходящим для её расширения и разработки.   
+Как обычно, это не какой-то из многочисленных вариантов SASL Тернера, а немного отличающийся от SASL 75. Того, который уже без явного `rec`, но еще без уравнений [Norm79].   
+
+```
+LET map f l = 
+    l=() -> ();
+    f (HD l) , map f (TL l)
+LET y = 1
+LET add x = x + y
+IN map add (1,2,3); 
+```
+
+Уже в следующем году язык получит название Small и синтаксические конструкции из Algol 68, которые сделают его похожим на Ponder [Clar80] [Norm82]:
+
+```
+Let map f l = 
+    If l Is x . xs Then f x . map f xs
+    Else Nil Fi
+In
+map add (1 . 2 . 3)
+   [ y = 1
+     And add x = x + y ] Ni;
+```
+
+Разработчики новой системы решили, что могут себе позволить чистый ФЯ. Раз уж это _скрипт_ для системы компьютерной алгебры и предназначен для склеивания процедур, которые исполняются заметной время и сами написаны на другом языке. И сначала посчитали, что эффективная имплементация этого скрипта не потребуется. Так что можно позволить себе работающую имплементацию функций и ленивости, которые в Лиспах того времени, как правило, отсутствовали.   
+Возможно, мечтал Норман, когда-нибудь в будущем свойства чистого ФЯ пригодятся для трансформации кода, доказательства его свойств и распараллеливания.   
+Но, как это часто бывает, нашлись пользователи скрипта, которые не стали ограничиваться склеиванием готовых процедур, а стали писать более интересный код. И оказалось, что писать программы на чистом и ленивом ФЯ легко и приятно. Есть, правда, проблема: производительность.  
+Small имплементирован как интерпретатор. К тому же, как не особенно быстрый интерпретатор. Производительность интерпретаторов ФЯ оставляла желать лучшего еще до появления в них поддержки ленивости. И поддержка ленивости еще больше осложнила ситуацию.   
+Но в 79-ом году умы студентов Кембриджа вроде Фейрберна и Пейтон Джонса будоражили свежие идеи, которые могли показаться решением для этих проблем: комбинаторный интерпретатор Тернера и лекция Бэкуса о специальном железе для ФЯ.   
+Фейрберна больше заинтересовало первое и чем он занялся после этого мы уже рассказали. Пейтон Джонс если и заинтересовался, то пока что без особых практических последствий для нашей истории. Получив диплом компьютерных наук, он не остался в Кембридже работать над диссертацией, а ушел работать в индустрии [SPJ18]. Одним из главных героев нашей истории он станет еще не скоро. А вот его приятель Том Кларк, сыграл одну из главных ролей в построении специальной машины для интерпретации Small.   
+
+#### SKIM
+
+Машина была инициативой студенческой "Процессорной Группы" (Cambridge University Processor Group) и не имела официальной поддержки университета [Stoy85]. Над ней работали Артур Норман и Кембриджские студенты Томас Кларк (Thomas James Woodchurch Clarke), их соавторы по первой статье [Clar80] о машине Гладстон (P. J. S. Gladstone) с МакЛином (C. D. MacLean) и только упоминающиеся в статье Билл Уорцел (Bill Worzel) и Иан Китчинг (Ian Kitching), написавший эмулятор машины. Разработку финансировала Оксфордская компьютерная компания Research Machines Ltd. при некотором содействии от Кембриджской компании Acorn Computers Ltd. Позднее проект потерял большую часть из этих участников, за исключением ядра Норман-Кларк, но привлек новых. И бросается в глаза, что этот проект существенно больше проектов, разрабатывающих первые компиляторы ФЯ, которые обычно ограничивались одним - двумя участниками. Но создание специального железа и требует больше участников.   
+Проблема производительности не в аппликативном программировании, решили Норман и Кларк, а в том, что существующие машины более "предрасположены" для выполнения существующих языков. И нужна машина, которая "предрасположена" уже к выполнению ФЯ.   
+Что означает "предрасположена" к исполнению ФЯ? Наиболее очевидным примером Норман и Кларк называют поддержку параллелизма. Но они пока что не собирались делать параллельную машину. Они хотели продемонстрировать как очень небольшой объем изменений окажет существенный эффект на производительность ФЯ.   
+Простота комбинаторного интерпретатора Тернера дала им надежду на то, что они смогут сконструировать редуцирующую машину. Первые ФП-машинисты посчитали комбинаторный интерпретатор Тернера элегантным, и в статье 80-го года, еще называют эффективным. Так что они решили проверить, насколько хорошо Тернеровские идеи можно воплотить в железе. Так что машина имплементировала комбинаторный интерпретатор Тернера и, соответственно, называлась SKIM (the S, K, I Reduction Machine).   
+Разработчики SKIM, в отличие от предыдущих героев этой части, приняли и смирились с тем, что имплементация ФЯ требует интерпретатор. Решение проблемы производительности они видели в том, чтоб сделать интерпретатор быстрым. Насколько быстрым? Цель - производительность программ на ФЯ как на миникомпьютере по цене микрокомпьютера. И это не особенно высокие требования. Как оказалось, для этого и делать ничего не надо, вскоре появились достаточно быстрые микрокомпьютеры. Но разработчики специального железа обычно не ожидали такого.   
+Насколько специальное железо они делали? На самом деле не такое уж и специальное. SKIM была больше похожа на Лисп-машину, чем на анти-Фон-Неймановские машины, которые продвигал Бэкус, вроде машины Маго.   
+Машина делалась настолько простой, насколько это возможно для машины, машинным языком которой является тернеровский набор комбинаторов. Так что вся функционально комбинаторная специфика была микрокод-программой, а не специальным железом. 
+И минимальные изменения обычной машины для поддержки ФЯ те же самые, что и изменения для поддержки Лиспа в Лисп-машинах 70-х (в 80-е были и более значительные, к ним мы еще вернемся). Как и в случае Лисп-машин особенность железа заключалась в поддержке большего объема микрокода, чем позволяли в это время машины обычные. Как и в случае Лисп-машин, поддержка железа заключается в том, что для проверки тегов и арифметики не требуется манипуляций для отделения тегов от данных.   
+Разработчики считают SKIM достаточно универсальной. С другим микрокодом она может быть Лисп-машиной.   
+В каком-то смысле SKIM бОльшая Лисп-машина, чем современные ей Лисп-машины. Потому, что пользователь машины видит только память из пар. Объекты у которых больше (или меньше) двух полей она не поддерживает. Лисп-машины же заработали уже после того, как лисперы поняли, что такая память их не устраивает, нужны рекорды и массивы.   
+У SKIM есть существенные отличия от Лисп-машины. Её пользователь не имеет доступа ко всяким низкоуровневым фичам вроде регистров и стека. Машинный язык ФП-машины - чистый фя, Тернеровский набор комбинаторов.   
+Отсутствие доступа к стеку и регистрам, по замыслам авторов SKIM, должно спасти имплементатора языка следующего уровня для неё от соблазна как-нибудь "оптимизировать" имплементацию видимости и получить неправильные лямбды, как это сделали лисперы.   
+Одной из важнейших, если не самой важной причиной создания Лисп-машин было желание Лисперов получить машины с большим адресным пространством и виртуальной памятью. Но в SKIM 14бит указатели на пары, так что она не поддерживает больше 64Кб памяти. Что не позволяет запустить на ней хоть сколько-нибудь серьезную программу.   
+В результате SKIM - это не "недорогой" миникомпьютер как Лисп-машина, а более-менее обычный микрокомпьютер, на порядок дешевле. Сотня микросхем на двух платах.   
+Они обошлись создателям SKIM в 500 фунтов [Stoy85], приблизительно в 4.5 тысячи долларов 24-го года. Конечно, в это время микрокомпьютер, компоненты которого стоят столько же, работал намного быстрее и поддерживал мегабайты виртуальной памяти.   
+Итак, вся ФП-специфика SKIM - программы. Машина поддерживает 4 тыс. слов микрокода. Из-за простоты тернеровского комбинаторного интерпретатора он - наименьшая часть микрокода SKIM. Разбор комбинаторного кода больше, принтер еще больше и сборщик мусора - больше всего остального. В 80-ом создатели SKIM посчитали, что объем микрокода оказался гораздо меньше, чем они боялись. И раза в два меньше того, который поместится в память SKIM для микрокода.   
+Сборщик мусора нерекурсивный, использует разворот указателей. Эту же технику для обхода графа объектов в памяти использует и комбинаторный интерпретатор. Разворот указателей позволяет ему обнаружить что он уже обходил какую-то часть и так определить зацикливание.   
+Для передачи параметров в строгую функцию, например арифметическую операцию, стек все еще нужен. Но SKIM не поддерживает стек, и если делать его самостоятельно, то нужно использовать односвязный список - машина же в принципе не поддерживает никакие объекты памяти кроме пар.  
+Работа над SKIM началась в 79-ом году и не позднее августа 80-го она уже работала.   
+На момент написания статьи 80-го года авторы SKIM еще как следует не знают, насколько быстро она работает, потому что работает она еще только месяц.   
+Они сравнивают в основном скорость работы сборщика мусора SKIM имплементированного в микрокоде с его имплементациями на ассемблере микрокомпьютеров с Z80 и M68K (работают помедленнее SKIM) и мэйнфрейма IBM 370/165 (работает побыстрее SKIM). Обращение к памяти сборщика мусора SKIM занимает процентов 60 времени работы.   
+Ленивый язык, по первым оценкам авторов, исполняется на SKIM со скоростью, сравнимой с интерпретатором LISP на IBM мэйнфрейме. Ну или сравнимым со скоростью BASIC на 8-бит микрокомпьютере. Раза в два побыстрее байткод-интерпретатора BASIC и раза в полтора медленнее компилятора. Раза в два медленнее, чем интерпретируемый Лисп и раз в десять медленнее, чем скомпилированный Лисп на на IBM 370/165 [Clar80].   
+SKIM редуцировал комбинаторный код с примерно той же скоростью, что и комбинаторный интерпретатор, написанный на машкодах мэйнфрейма IBM 370/165 [Stoy85].   
+Написанный на микрокоде комбинаторный интерпретатор работал достаточно быстро, чтоб скорость редукции определялась скоростью работы с памятью, что авторы SKIM посчитали успехом.  
+Да, это именно то, с чем Бэкус в своей лекции призывал бороться как с главной проблемой программирования. И с чем авторы компиляторов из остальных глав этой части боролись уменьшая обращения к памяти. Пока что вместо анти-Фон-Неймановской машины имплементаторы ФЯ делали машину анти-Бэкусовскую.   
+Создатели SKIM посчитали свои результаты вдохновляющими. Заключают, что довольно скромное аппаратное обеспечение способно предоставить хорошую поддержку для ФЯ. Они надеялись, что простота комбинаторного интерпретатора тернера позволит сделать простую, но достаточно быструю машину. И в 80-ом посчитали, что эти надежды, в основном, оправдались. Решили, что SKIM продемонстрировала, что специальное железо может хорошо помочь в имплементации необычных языков программирования. По крайней мере, для языков работы со списками даже простой компьютер может обеспечить "достойную уважения" производительность.   
+Авторы поздравляют себя с победой: аппликативное программирование теперь может быть практичным решением, а не только интересной, но непрактичной идеей.   
+Правда, создатели SKIM отмечают, что если б они начали разрабатывать SKIM еще раз и с нуля, они сделали бы машину немного посложнее и побыстрее. Посчитали, что производительность микробенчмарков страдает, в основном, от минимального АЛУ, которое не поддерживает даже умножение для целых чисел.   
+Какие у них планы на будущее? Помимо усложнения поддержки арифметики, машину можно существенно ускорить только ускорив работу с памятью (с чего и началась вся эта специально-аппаратная история). Можно, например, удвоить пропускную способность шины памяти. В SKIM хоть и можно адресовать только пары - дотащить пару через Фон-Неймановское бутылочное горлышко можно только в два приема.   
+Можно поддержать стек аппаратно или даже добавить для него специальную, более быструю память.   
+Создатели SKIM предполагают, что имплементировав все это, можно будет увеличить производительность раза в четыре. Ценой увеличения размера процессора в два раза.   
+Чтоб все-таки запускать на машине какие-то программы, хорошо бы увеличить размер слова и адресное пространство.  
+Еще одно очевидное авторам направление развития - имплементация комбинаторной машины на одном чипе.   
+Из того что напишут работающие на SKIM позднее, правда, мы знаем о том, что у SKIM были серьезные проблемы не упомянутые в статье 80-го года. SKIM падает в среднем после 20 минут работы. К тому же, с течением времени, разработчики SKIM изменили свое мнение о том, что 4K слов для микрокода хватает с запасом. У них появилось больше идей о том, что можно перенести в микрокод. Правда, от изменения микрокода до его запуска обычно проходит день, так что работать над микрокодом не особенно удобно.   
+Но первоначальная команда разработчиков SKIM "рассеялась" и к решению этих проблем приступили только через годы [Stoy85].   
+
+#### SKIM II
+
+Летом 82-го года Томас Кларк закончил проектирование SKIM II. Никакие изменения для ускорения работы в новый проект не попали. Так что ни поддерживающего умножение, ни кеша не было. Главной целью было создать более надежную платформу для экспериментирования и ослабить ограничения на размеры поддерживаемой памяти и микрокода [Stoy85].   
+Так что главными отличиями SKIM II от SKIM I были увеличенное адресное пространство, больше тег-бит в каждом слове и упрощение отладки микрокода, дла которого есть и больше места в памяти. Вместо 16-бит слов теперь 24-бит слова, в которых 4 бита для тегов [Stoy83].   
+Микрокод может занимать до 64K слов.   
+Если SKIM I была экспериментальной машиной, то SKIM II задумывалась как более стабильная платформа для экспериментирования с функциональным программированием.   
+И функциональное программирование теперь в принципе возможно, адресного пространства теперь хватает на миллион пар, что соответствует 6Мб памяти. Виртуальная память, правда, не поддерживается.   
+SKIM больше не студенческий проект, Кларк уже не студент и новый участник проекта работает над диссертацией.   
+Уильям Стой (William Robert Stoye) прочел лекцию Бэкуса и идея о том, что с обычными машинами не все в порядке произвела на него впечатление. Так что он решил участвовать в проекте создания машины необычной. Да, Бэкус, скорее всего, посчитал бы, что в этой необычной машине не в порядке все то же самое, что и в обычной. Но на практике лекция Бэкуса вдохновляла смело делать необычные машины, а не исправлять конкретные проблемы, которые описывал Бэкус. В детали его рассуждений Стой, по собственному утверждению, особо не вникал.   
+Стой приступил к воплощению идей Кларка в октябре 82-го и в июне 83-го SKIM II заработала [Stoy85].   
+SKIM II это 230 микросхем на четырех платах, из них 92 - память. Машина не использует все адресное пространство, установленной памяти хватает на 256 тыс. пар [Stoy83], т.е. полтора мегабайта. Машина может быть расширена еще тремя платами с памятью, но не расширена.   
+SKIM II, в отличие от SKIM I не падает каждые двадцать минут, исполняет тесты сутками без проблем.  
+Весь ввод-вывод осуществляет обычный компьютер (BBC micro), соединенный со SKIM II, который используется и для отладки микрокода.   
+И писать и отлаживать микрокод теперь легко, и места для него хватает. Так что оптимизации и идеи по развитию машины теперь связаны с изменениями микрокода, а не железа. И микрокода для SKIM II написано в два раза больше, чем для SKIM I. Стой занимался совершенствованием микрокода со второй половины 83-го.   
+Стек-список в куче и рекурсия теперь не используется и для вызова строгих комбинаторов. Это улучшило производительность на 10%.   
+Более важной оптимизацией была идея Кларка о разгрузке сборщика мусора. Сборка мусора занимает больше половины времени редукции, даже если занято меньше половины кучи. Объекты, обычно, короткоживущие, но алгоритм сборки не может это использовать для уменьшения времени обхода.   
+В ходе редукции комбинаторов часто нужно аллоцировать пары, на которые есть только одна ссылка, пока они не станут мусором. И в новом микрокоде имплементированы однобитные счетчики ссылок в указателях, которые позволяют определять такие объекты и освободить место немедленно или даже немедленно переиспользовать его, существенно уменьшая работу для сборщика мусора и аллокатора.   
+В микрокоде также реализованы операции, которые в ранних версиях имели наивную имплементацию. Например, структурное сравнение объектов. И микрокодовое сравнение не только сравнивает, но и переписывает дерево объектов в куче. Убирая дублирующиеся поддеревья и заменяя их на ссылки на одно и то же поддерево. После того, как сравнение установило, что поддеревья действительно одни и те же.   
+До оптимизации микрокода SKIM II редуцировала примерно 80000 комбинаторов в секунду [Stoy83], а в результате оптимизации микрокода производительность SKIM II увеличилась примерно в полтора раза [Stoy85].   
+Насколько хорошо помогают однобитные счетчики ссылок, конечно же, зависит от того, как много свободной памяти осталось и Стой даже приводит [Stoy85] соответствующие измерения
+
+|      | tak 50%  |  tak 5%  | sort 50% | sort 20% |
+| :--- | :------: | :------: | :------: | :------: |
+| v1   |   1.23   |   2.28   |   1.35   |   2.09   |
+| v2   |   1.15   |   1.06   |   1.24   |   1.17   |
+| v3   | **1.00** | **1.00** | **1.00** | **1.00** |
+
+Здесь v1 - первоначальная версия микрокода, v2 - оптимизация применения строгих комбинаторов и v3 - это все, что в v2 плюс однобитные счетчики. Процент рядом с бенчмарком - это процент свободной памяти.  
+
+```
+v1
+░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░
+v2
+░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░
+v3
+░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░
+```
+
+Также SKIM II сравнивают с комбинаторным интерпретатором, работающим на более актуальной для функциональных программистов 80-х машине - микрокомпьютере с MC68K. Описания этого интерпретатора не просто не дошли до нас, но не существовали даже в виде отчета в Кембридже, потому что Стой ссылается только на разговор со Стюартом Рэем о нем. И SKIM II работает в 30 раз быстрее этого интерпретатора. С суперкомбинаторным компилятором, над которым работали в Кембридже Рэй с Фейрберном, сравнения, правда, почему-то нет.   
+Параллельно с развитием микрокода Стой пишет первые функциональные программы для ФП-машины. Разработчики SKIM больше не пишут собственный компилятор ФЯ в комбинаторы и Стой не использует Small для написания программ для SKIM II. Он использует наработки другого Кембриджского функционального проекта - Ponder, компилятор которого может производить Тернеровские комбинаторы. Но функциональное программирование - тема для другой части нашей истории, к этому мы еще вернемся.   
+Совершенствование ПО для "простой машины" - это, конечно, хорошо. Но жаль, что создатели SKIM не нашли сил и средств сделать машину посложнее. К счастью, в августе 84-го Стой посетил Остин (Техас), где подходила к концу разработка как раз такой ФП-машины.   
+
+#### NORMA
+
+С 1973 года Роберт Бартон (Robert Stanley Barton), известный разработчик мэйнфреймов, работал в исследовательском центре Burroughs в Ла-Холье (Burroughs Systems Research in La Jolla, San Diego, California) над новым компьютером той разновидности, которую Бэкус считал анти-Фон-Неймановской. Увлечение около-функциональным анти-Фон-Нейманизмом захватило Бартона под впечатлением от теоремы Черча-Россера. Но в 78-ом году, примерно тогда же, когда Бэкус рассказывал, что за такими как у Бартона машинами будущее, проект Бартона закрыли. Участники этого проекта, вроде Гамильтона Ричардса (Hamilton Richards), нашли себе занятие в новом исследовательском центре Burroughs в Остине (Burroughs Austin Research Center, (B)ARC). Где стали работать над компьютером еще более около-функциональным, но существенно менее анти-Фон-Неймановским [Hoar22].   
+Функциональным языком, который имплементировали в ARC был диалект SASL, называющийся ARC SASL [Rich84]. Отличие ARC SASL от SASL 83 было, наверное, минимальное из тех, что потребовали бы изменить чуть ли не каждую строку кода при переводе с одного SASL на другой. Если бы было что переводить, конечно. В ARC SASL скобки в синтаксисе списков были квадратными, как в KRC.   
+В отличие от большинства других имплементаторов SASL, в ARC могли себе позволить нанять Тернера консультантом в январе 80-го года. И в ARC могли многое себе позволить. Помните о том интерпретаторе SASL, который в Сент-Эндрюсе начинали писать на микрокоде мэйнфрейма, который так и не смогли купить? В ARC был и мэйнфрейм и соответствующий микрокодовый интерпретатор ARCSYS [Rich84], с помощью которого там экспериментировали с SASL, пока не была готова его основная имплементация - ФП-машина. ФП-машину делали долго, начали еще в 79-ом году, как и SKIM но заработала только в декабре 84-го [Stoy85]. Но эта машина была воплощением в жизнь многого из того, что для создателей SKIM так и осталось мечтой.   
+Остинская ФП-машина NORMA (Normal Order Reduction MAchine), как и SKIM была "софт-машиной" с поддержкой большого объема микрокода, тэгов и сборки мусора, а не какого-то конкретного способа реализации ФЯ. Но на микрокоде был написан все тот же комбинаторный интерпретатор Тернера. Правда, интерпретировал он не совсем тот же Тернеровский набор. Сотрудник ARC Марк Шивел (Mark Scheevel) обнаружил, что комбинатор `B'` и получающая его трансформация из этого набора не то что не улучшают, а даже ухудшают производительность и придумал комбинатор `B*`, который используется вместо `B'` в NORMA и позднее Тернером в интерпретаторе его следующего языка [SPJ87].   
+NORMA не поддерживала виртуальную память, как и SKIM. Как и в SKIM, специальное железо соединено с обычным компьютером. В случае NORMA - это микрокомпьютер с на 8086. Но обычный компьютер используется не только для ввода-вывода, сборщик мусора использует его память для сохранения корней [Sche86].   
+Чаще всего отличия NORMA от SKIM демонстрируют, что может позволить себе лаборатория при коммерческой компании в США, по сравнению с университетским проектом в Великобритании. В NORMA больше памяти: два блока по
+512K слов DRAM и 512K слов SRAM, быстрой памяти для отметок маркирующего сборщика, в каждом. Слова 64-битные, в каждом пара из 24-бит полей и тегов. В NORMA есть быстрый кэш для "стека", вернее для заменяющего его "хребта", потому что используется тот же метод избегания рекурсии в интерпретаторе, что и в SKIM.   
+Сам процессор тоже больше, исполняющий большие инструкции в 370 бит для параллелизма на уровне команд. NORMA не собирает аргументы для очередного комбинатора в стек или какую-то заменяющую его структуру в памяти как SKIM, а использует регистры. Сборщик мусора в NORMA той же маркирующей и очищающей разновидности, что и в SKIM, но очистка происходит одновременно с редукцией.   
+SKIM была собрана из обычного ассортимента ТТЛ микросхем. В отличие от нее, NORMA использует помимо стандартных ТТЛ чипов и специальные чипы (ULA ASIC) [Stoy85] [Sche86].   
+Над железом работали Гэри Логсдон (Gary Logsdon), Брент Болтон (Brent Bolton), Фрэнк Уильямс (Frank Williams) и Майк Уинчелл (Mike Winchell). Над системным ПО, помимо Марка Шивела, работали Боб Бетке (Bob Bethke), Том Крокетт (Tom Crockett), Курт Хирн (Curt Hern) и Дэвид Доу (David Dow). Помимо непосредственных имплементаторов были еще консультанты вроде Тернера и даже Дейкстры, работавшие над доказателем для проверки свойств SASL кода Боб Бойер (тот самый, из части про уравнения) и Мэтт Кауфман (Matt Kaufmann), описавший ARC SASL Ричардс. Над SKIM работало больше, чем над отдельными компиляторами ФЯ, но над NORMA работало больше людей, чем над всеми первыми компиляторами ФЯ вместе взятыми.   
+В результате всего этого NORMA работала быстрее, чем SKIM II, которая с первой версией микрокода редуцировала 80 тыс. комбинаторов в секунду [Stoy83], а с последней - 100 тыс. согласно Шивелу [Sche86] или примерно 120 тыс. согласно Стою [Stoy85]. NORMA редуцировала 250 тыс. комбинаторов в секунду.   
+Но насколько это хорошо по сравнению с теми, кто не собирал специальное железо и не заказывал специальные чипы? В 50 раз быстрее, чем микрокодовый интерпретатор для мэйнфрейма Burroughs и в 25 раз быстрее, чем интерпретатор SASL для VAX-11/780 на C. Успех по ускорению интерпретации, конечно, впечатляющий. Но что насчет сравнения с компиляторами? В отличие от разработчиков SKIM II, разработчики NORMA сделали такое сравнение.   
+
+|           | 7queens  |  primes  |  fib20   |   tak    |
+| :-------- | :------: | :------: | :------: | :------: |
+| NORMA     | **1.00** |   1.00   | **1.00** | **1.00** |
+| LML (VAX) |   1.60   | **0.71** |   1.14   |   2.50   |
+
+```
+NORMA
+░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░
+LML (VAX)
+░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░░░
+```
+
+Получается, что NORMA немного побыстрее LML на VAX-11/780. Но принципиальной разницы нет, как признает Шивел. Правда, не известно, какая разница была бы не на микробенчмарках, продолжал надеяться он, а на серьезных программах. Которые могут работать на VAX-11, но едва ли на NORMA. Виртуальной памяти-то нет.   
+И это сравнение со скомпилированным кодом, который работает на машине конца 70-х. В момент публикации этих результатов уже продавались микрокомпьютеры, на которых этот код будет работать в 2-4 раза быстрее.   
+Так что в это время даже и самые упорные ускорители комбинаторного интерпретатора делали вывод, что шаг у него слишком мелкий. К счастью, отмечают создатели SKIM [Stoy85] и NORMA [Sche86], машины не имплементируют Тернеровский интерпретатор в железе и для них можно написать микрокод, который имплементирует редукцию более крупных комбинаторов. В Остине, правда, нет своего суперкомбинаторного компилятора. А вот разработчики SKIM экспериментировали с компиляцией прямо в микрокод, что позволило бы достигнуть ускорения на десятичный порядок [Stoy85].   
+Но дела у создателей SKIM, видимо, пошли не очень хорошо. У разработчиков же обычного железа дела шли отлично. Так что позднее Норман пишет уже не про специальные ФП-компьютеры, а про имплементацию ФЯ на компьютерах обычных [Norm88].   
+А как шли дела у создателей NORMA? Дело в том, что у исследовательской работы в лабораториях при коммерческих компаниях есть и недостатки. В 86-ом году в Burroughs, во время поглощения Sperry решили, что ARC не нужен и закрыли его [Hoar22].   
+
 ПРОДОЛЖЕНИЕ СЛЕДУЕТ
 
 Литература
@@ -1537,6 +1701,7 @@ innerproduct = foldr1 (+) . map (foldr1 (*)) . transpose
 [Card12]: Luca Cardelli, Scientific Biography. May 2012 http://lucacardelli.name/indexBioScientific.html   
 [Card21]: Luca Cardelli, Curriculum Vitae. 2021 http://lucacardelli.name/indexBio.html   
 [Clac85]: Clack, C., Peyton Jones, S.L. (1985). Strictness analysis — a practical approach. In: Jouannaud, JP. (eds) Functional Programming Languages and Computer Architecture. FPCA 1985. Lecture Notes in Computer Science, vol 201. Springer, Berlin, Heidelberg. doi:10.1007/3-540-15975-4_28   
+[Clar80]: T. J. W. Clarke, P. J. S. Gladstone, C. D. MacLean, and A. C. Norman. 1980. SKIM - The S, K, I reduction machine. In Proceedings of the 1980 ACM conference on LISP and functional programming (LFP '80). Association for Computing Machinery, New York, NY, USA, 128–135. doi:10.1145/800087.802798   
 [Cousot]: Cousot, Patrick. “The Contributions of Alan Mycroft to Abstract Interpretation.”   
 [Dama84]: Luís Damas. “Type assignment in programming languages.” (1984).   
 [Data83]: Datapro report M11-075-10 8311 http://bitsavers.informatik.uni-stuttgart.de/pdf/datapro/datapro_reports_70s-90s/Apollo/M11-075-10_8311_Apollo_Domain.pdf   
@@ -1550,6 +1715,8 @@ innerproduct = foldr1 (+) . map (foldr1 (*)) . transpose
 [Fair86]: Jon Fairbairn, A new type-checker for a functional language, Science of Computer Programming, Volume 6, 1986, Pages 273-290, doi:10.1016/0167-6423(86)90027-4   
 [Fate81]: Fateman RJ. Views on transportability of lisp and lisp-based systems. InProceedings of the fourth ACM symposium on Symbolic and algebraic computation 1981 Aug 5 (pp. 137-141).   
 [Fate2003]: Souza, Paulo Ney de, Richard J. Fateman, Joel Moses and Clifford W Yapp. “The Maxima Book.” (2003). https://maxima.sourceforge.io/docs/maximabook/maximabook-19-Sept-2004.pdf   
+[Fitc09]: Fitch, J. (2009). CAMAL 40 Years on – Is Small Still Beautiful?. In: Carette, J., Dixon, L., Coen, C.S., Watt, S.M. (eds) Intelligent Computer Mathematics. CICM 2009. Lecture Notes in Computer Science(), vol 5625. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-02614-0_8   
+[Fode81]: Foderaro JK, Fateman RJ. Characterization of VAX Macsyma. InProceedings of the fourth ACM symposium on Symbolic and algebraic computation 1981 Aug 5 (pp. 14-19).   
 [Franz38]: Franz Lisp Opus 38.93 https://github.com/krytarowski/Franz-Lisp-Opus-38.93-for-4.3BSD-Reno   
 [Gabr96]: Gabriel, Richard P. Patterns of software. 1996.   
 [Gris82]: Martin L. Griss, Eric Benson, and Gerald Q. Maguire. 1982. PSL: A Portable LISP System. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 88–97. doi:10.1145/800068.802139   
@@ -1559,6 +1726,7 @@ innerproduct = foldr1 (+) . map (foldr1 (*)) . transpose
 [Gord2000]: Gordon M. From LCF to HOL: a short history. In Proof, language, and interaction 2000 Jul 24 (pp. 169-186).   
 [Hear79]: J. Marti, A. C. Hearn, M. L. Griss, and C. Griss. 1979. Standard LISP report. SIGPLAN Not. 14, 10 (October 1979), 48–68. doi:10.1145/953997.953999   
 [Hear2005]: Hearn, Anthony C.. “REDUCE: The First Forty Years.” Algorithmic Algebra and Logic (2005).   
+[Hoar22]: Krzysztof R. Apt and Tony Hoare (Eds.). 2022. Edsger Wybe Dijkstra: His Life,Work, and Legacy (1st. ed.). ACM Books, Vol. 45. Association for Computing Machinery, New York, NY, USA. https://doi.org/10.1145/3544585   
 [HOL88]: HOL88 https://github.com/theoremprover-museum/HOL88   
 [Holm98]: Holmevik, Jan Rune. "Compiling Simula: A historical study of technological genesis." (1998) https://staff.um.edu.mt/jskl1/simula.html   
 [Huda83]: Paul Hudak and David Kranz. 1984. A combinator-based compiler for a functional language. In Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '84). Association for Computing Machinery, New York, NY, USA, 122–132. doi:10.1145/800017.800523   
@@ -1604,6 +1772,10 @@ SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction
 [Mycr16]: Alan Mycroft, Mini CV https://www.cl.cam.ac.uk/~am21/minicv.txt   
 [Nebe83]: Nebel, B. (1983). Ist Lisp Eine ‘Langsame’ Sprache?. In: Neumann, B. (eds) GWAI-83. Informatik-Fachberichte, vol 76. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-69391-5_3   
 [NIL85]: Jon L White et al. VAX NIL source code, Release 0.286. Massachusetts Institute of Technology. Provided by Josh Dersch. https://www.softwarepreservation.org/projects/LISP/MIT/nil.zip   
+[Norm77]: Fitch, J. P., & Norman, A. C. (1977). Implementing LISP in a high-level language. Software: Practice and Experience, 7(6), 713–725. doi:10.1002/spe.4380070606   
+[Norm79]: Norman, A.C., Moore, P.M.A. (1979). The initial design of a vector based algebra system. In: Ng, E.W. (eds) Symbolic and Algebraic Computation. EUROSAM 1979. Lecture Notes in Computer Science, vol 72. Springer, Berlin, Heidelberg. doi:10.1007/3-540-09519-5_78   
+[Norm82]: Norman, A. C. (1982). The development of a vector-based algebra system. Computer Algebra, 237–248. doi:10.1007/3-540-11607-9_28   
+[Norm88]: A. C. Norman. 1988. Faster combinator reduction using stock hardware. In Proceedings of the 1988 ACM conference on LISP and functional programming (LFP '88). Association for Computing Machinery, New York, NY, USA, 235–243. doi:10.1145/62678.62716   
 [Nuprl94]: Nuprl 3.2 (26-MAY-94) https://github.com/owo-lang/nuprl-3 https://web.archive.org/web/20220630143027/http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/reasonng/atp/systems/nuprl/0.html   
 [Padg88]: Padget, Julian. "Three Uncommon Lisps." In First International Workshop on Lisp Evolution and Standardization. 1988.   
 [Paul22]: Lawrence Paulson. Memories: Edinburgh LCF, Cambridge LCF, HOL88 https://lawrencecpaulson.github.io/2022/09/28/Cambridge_LCF.html   
@@ -1612,16 +1784,21 @@ SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction
 [Phil99]: Phillips, Eve Marie. "If it works, it's not AI: a commercial look at artificial intelligence startups." PhD diss., Massachusetts Institute of Technology, 1999.   
 [Rees82]: Jonathan A. Rees and Norman I. Adams IV. 1982. T: a dialect of Lisp or LAMBDA: The ultimate software tool. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 114–122. doi:10.1145/800068.802142   
 [Rees2004]: Jonathan Rees, The T Project http://mumble.net/~jar/tproject/   
+[Rich84]: H. Richards. 1984. An overview of ARC SASL. SIGPLAN Not. 19, 10 (October 1984), 40–45. doi:10.1145/948290.948294   
 [Sain84]: Emmanuel Saint-James. 1984. Recursion is more efficient than iteration. In Proceedings of the 1984 ACM Symposium on LISP and functional programming (LFP '84). Association for Computing Machinery, New York, NY, USA, 228–234. doi:10.1145/800055.802039   
 [Sait82]: N. Saito. ML System on Vax Unix. README for Saito’s Unix port of VAX ML, March 1982.   
 [SERC83]: DISTRIBUTED INTERACTIVE COMPUTING NOTE 781 https://www.chilton-computing.org.uk/acd/pdfs/dic/dic781.pdf   
+[Sche86]: Mark Scheevel. 1986. NORMA: a graph reduction processor. In Proceedings of the 1986 ACM conference on LISP and functional programming (LFP '86). Association for Computing Machinery, New York, NY, USA, 212–219. doi:10.1145/319838.319864   
 [Shiv2001]: Olin Shivers, History of T https://paulgraham.com/thist.html   
 [Slom89]: Sloman, Aaron. "The Evolution of Poplog and Pop-11 at Sussex University." POP-11 Comes of Age: The Advancement of an AI Programming Language (1989): 30-54.   
+[SPJ87]: Peyton Jones, Simon L. The implementation of functional programming languages (prentice-hall international series in computer science). Prentice-Hall, Inc., 1987.   
 [SPJ18]: People of Programming Languages. An interview project in conjunction with POPL 2018. Interview with Simon Peyton-Jones http://www.cs.cmu.edu/~popl-interviews/peytonjones.html   
 [Stal2002]: Richard Stallman. My Lisp Experiences and the Development of GNU Emacs. https://www.gnu.org/gnu/rms-lisp.html   
 [Stee82]: Guy L. Steele. 1982. An overview of COMMON LISP. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 98–107. doi:10.1145/800068.802140   
 [Stee96]: Guy L. Steele and Richard P. Gabriel. 1996. The evolution of Lisp. Uncut draft.   
 [Stee96b]: Guy L. Steele and Richard P. Gabriel. 1996. The evolution of Lisp. History of programming languages---II. Association for Computing Machinery, New York, NY, USA, 233–330. doi:10.1145/234286.1057818   
+[Stoy83]: Stoye, William. “The SKIM microprogrammer’s guide.” (1983).   
+[Stoy85]: Stoye, William. “The implementation of functional languages using custom hardware.” (1985).   
 [Thom76]: Christopher Mark Thomson. The Run-Time structure of an ALGOL 68 Student Checkout Compiler. Master's thesis, Department of Computing Science, University of Alberta, 1976.   
 [Thom78]: C. Thomson. ALGOL 68 Compiler for IBM S/370. Announcement. SIGPLAN Notices, Volume 13, Number 11 (November 1978), page 11.   
 [TMail]: T mailing list archive. http://people.csail.mit.edu/riastradh/t/tmail.tar.bz2   

index.md

@@ -12,6 +12,8 @@
 
 ---------------------------
 
+[Обновление 2024-11-01](compilers.md#норман-и-norma)
+
 [Обновление 2024-09-30](compilers.md#ржавый-пояс)
 
 [Обновление 2024-08-31](compilers.md#true--false)