Да, в принципе, какой угодно. С таблицами и параметризацией команд OISC-процессор достаточно быстро можно превратить в обычную RISC-архитектуру. Проблема разбухания кода решается введением виртуальной машины (внутри виртуальной машины :) Другой вопрос, если у нас серьезные ограничения по быстродействию, как в случае BytePusher, где требуется реальное время.
Начинающим иногда предлагают написать эмулятор NES или Atari 8-bit (как у Вас на картинке), но это большая работа, особенно когда речь идет об эмуляции тех же спецчипов Atari. К тому же, для исторически значимых "бытовых компьютеров" уже написана куча программ и игр. Другое дело -- BytePusher. Всего 12 (теперь) простеньких демонстраций. Каждый может войти в историю с чем-то хоть немного нетривиальным :)
Для первых двух примеров я бы предложил написать учебный интерпретатор на уровне питоновского AST. Учитывайте при реализации отсутствие в Питоне явных объявлений переменных.
По третьему примеру могу сказать только, что код перед публикацией надо бы проверять на корректность :)
Это неплохая вводная книга, но выбор для издания именно Racket-версиии -- сомнительное решение. Код в версии учебника для Python вместе с match/case выглядит, местами, даже изящнее Scheme. Да и читательский охват был бы шире.
Я, кстати говоря, вовсе не против разработки компиляторов на Racket, это замечательный диалект Scheme, но в рассматриваемом учебнике нет какой-то особенной специфики теории компиляции функциональных языков или LOP (Language-Oriented Programming).
P.S. А если вас интересуют прикладные аспекты разработки DSL-компиляторов на Python, то могу порекомендовать посмотреть мой недавний доклад: https://www.youtube.com/watch?v=h-TzDPL2nDE
Любопытный проект! Очень хорошо, что нацелились на простоту, минимализм и не используете LLVM.
От постоянных isinstance в коде можно было бы отказаться с помощью match/case (эту конструкцию для компиляторщиков и придумали, я почти не шучу). В этом докладе я агитирую за нее: https://github.com/true-grue/python-dsls
Время трансляции не сравнивалось, это любопытный момент. Есть известные унивесальные приемы в духе супероптимизации, позволяющие получить хороший результат SBT-трансляции ценой весьма длительного времени работы транслятора.
Поддерживаю! На мой взгляд, одно из самых серьезных произведений в жанре, с точки зрения проработки технологий будущего. Очень достоверно показано, как люди будут жить при AR. Любопытно, что большинство моих знакомых "ценителей жанра" прошло мимо Dennou Coil, а жаль.
Согласен, на самом деле это весьма важные сегодня вопросы статического параллелизма. Если отвлечься от спецпроцессоров, то в современных процессорах общего назначения статически распараллеливаются операции команд SIMD-расширений и скоро, судя по всему, придется статически учитывать задержки при межядерных коммуникациях, как на картинке ниже:
Со времен работ Карцева технологии компиляции и, в частности, статического анализа, интенсивно развивались. Но Карцев отметил в своем учебнике, что наиболее радикальным решением было бы "создание принципиально новых языков программирования". Вообще, еще раз замечу, что в книге очень много интересных положений.
По поводу 2-6 процессоров. В книге, говоря современным языком, речь идет о функциональных узлах в составе одного VLIW-ядра. Интересно, что Карцев весьма консервативен в своей оценке. В этом смысле любопытно вспомнить, что в VLIW-проектах Фишера фигурировало до 30 параллельных RISC-операций!
Что же касается организации современной многоядерной системы, то здесь ограничивающую роль играет, скорее, не архитектура одного ядра (VLIW, OoO, ...), а то, как организованы коммуникации, работа с общей памятью.
В целом, речь идет об ограничениях для двух разных типов параллелизма. Если воспользоваться терминологией Карцева, то это параллелизм смежных операций (внутри ядра) и параллелизм независимых ветвей (на уровне системы ядер).
По поводу "не реализуемо в принципе". Цитата из учебника верна не только для VLIW, так работают in-order процессоры. Я с Вами согласен, что для специализированных процессоров такие решения наиболее применимы.
Кстати говоря, я добавил в статью некоторые подробности о комбинированной архитектуре Карцева. Надеюсь, это тоже будет интересно!
Индуктивный синтез программ, в сущности, представляет собой поиск в пространстве возможных программ по заданной спецификации (состоящей из примеров входов и выходов, различного рода ограничений). В супероптимизаторах предпочтение отдается самому короткому решению, поэтому синтез начинают с программы длиной 1, затем 2 и так далее.
Любопытная заметка! Спасибо Вам за ссылку на статью, послужившую вдохновением. Странно только, что Вы поместили свой текст в "компиляторы", но ни словом не обмолвились, что техника, которую Вы применяете, относится к известному и весьма сегодня популярному направлению -- синтезу программ. Опять же, если обращаться к компиляторным технологиям, хотел бы поинтересоваться, почему в своих решениях Вы не пошли по пути традиционной супероптимизации?
Жаль разочаровывать, если Вы ожидали увидеть там скрытый намек на "Эльбрус" или Itanium.
Авторы RISC-V не верят в перспективы VLIW в области GPP, об этом они неоднократно заявляли. Как и большинство специалистов сегодня, Хеннесси с Паттерсоном разделяют мнение, что VLIW-архитектуры замечательно себя показывают в области предметно-ориентированных ускорителей и в этом отношении RISC/CISC им, в целом, не конкуренты.
Перед авторами RISC-V стояла непростая задача обеспечения точек роста новой архитектуры. Поэтому в RISC-V стандартизированы возможности расширения команд, добавления специализированных ускорителей. Естественно, речь не идет о "каких угодно расширениях" (это самое "что угодно" добавляется в отдельные ускорители) и, в частности, вы не найдете в документе ничего о TTA, Dataflow или каких-нибудь CGRA.
По какой причине возник небольшой, укладывающийся в одну страницу, раздел VLIW-расширения? Думаю, авторы предполагали возможность реализации простых компактных вариантов в духе 2-issue in-order.
Вообще-то, OISC — вовсе не такая уж непрактичная вещь. TTA формально относится к OISC, но имеет свою нишу в области встраиваемых систем.
P.S. Спасибо @vkniза напоминание о TTA.
Да, в принципе, какой угодно. С таблицами и параметризацией команд OISC-процессор достаточно быстро можно превратить в обычную RISC-архитектуру. Проблема разбухания кода решается введением виртуальной машины (внутри виртуальной машины :) Другой вопрос, если у нас серьезные ограничения по быстродействию, как в случае BytePusher, где требуется реальное время.
А еще, к примеру, для этой архитектуры разработали ОС :)
Потому что одного тега тут мало, вместо него есть целый хаб "Ненормальное программирование" :)
Спасибо за такой приятный отзыв от ветерана демосцены!
У Форта, все-таки, будут накладные расходы на выполнение. Но, действительно, почему бы и нет?
Сокобан вспомнился? Видимо, это судьба -- придется Вам написать Сокобан на Форте для BytePusher! :)
Начинающим иногда предлагают написать эмулятор NES или Atari 8-bit (как у Вас на картинке), но это большая работа, особенно когда речь идет об эмуляции тех же спецчипов Atari. К тому же, для исторически значимых "бытовых компьютеров" уже написана куча программ и игр. Другое дело -- BytePusher. Всего 12 (теперь) простеньких демонстраций. Каждый может войти в историю с чем-то хоть немного нетривиальным :)
Для первых двух примеров я бы предложил написать учебный интерпретатор на уровне питоновского AST. Учитывайте при реализации отсутствие в Питоне явных объявлений переменных.
По третьему примеру могу сказать только, что код перед публикацией надо бы проверять на корректность :)
Это неплохая вводная книга, но выбор для издания именно Racket-версиии -- сомнительное решение. Код в версии учебника для Python вместе с match/case выглядит, местами, даже изящнее Scheme. Да и читательский охват был бы шире.
Я, кстати говоря, вовсе не против разработки компиляторов на Racket, это замечательный диалект Scheme, но в рассматриваемом учебнике нет какой-то особенной специфики теории компиляции функциональных языков или LOP (Language-Oriented Programming).
Если вы знакомы с английским, то Python-версию книги можно совершенно свободно скачать здесь: https://github.com/IUCompilerCourse/Essentials-of-Compilation
P.S. А если вас интересуют прикладные аспекты разработки DSL-компиляторов на Python, то могу порекомендовать посмотреть мой недавний доклад: https://www.youtube.com/watch?v=h-TzDPL2nDE
Любопытный проект! Очень хорошо, что нацелились на простоту, минимализм и не используете LLVM.
От постоянных isinstance в коде можно было бы отказаться с помощью match/case (эту конструкцию для компиляторщиков и придумали, я почти не шучу). В этом докладе я агитирую за нее: https://github.com/true-grue/python-dsls
Отечественная версия «Змейки» (хотел сказать, как на телефоне Nokia, но тогда на телефонах еще не было игр)
Ага, а еще -- одна из самых оригинальных российских игр за всю историю.
В Rosetta 2, насколько я знаю, гибрид SBT/DBT, это учитывалось при сравнении?
Время трансляции не сравнивалось, это любопытный момент. Есть известные унивесальные приемы в духе супероптимизации, позволяющие получить хороший результат SBT-трансляции ценой весьма длительного времени работы транслятора.
Извините, что встреваю, но в подобных случаях полезно посоветовать классику :) https://norvig.com/21-days.html
Поддерживаю! На мой взгляд, одно из самых серьезных произведений в жанре, с точки зрения проработки технологий будущего. Очень достоверно показано, как люди будут жить при AR. Любопытно, что большинство моих знакомых "ценителей жанра" прошло мимо Dennou Coil, а жаль.
Согласен, на самом деле это весьма важные сегодня вопросы статического параллелизма. Если отвлечься от спецпроцессоров, то в современных процессорах общего назначения статически распараллеливаются операции команд SIMD-расширений и скоро, судя по всему, придется статически учитывать задержки при межядерных коммуникациях, как на картинке ниже:
Со времен работ Карцева технологии компиляции и, в частности, статического анализа, интенсивно развивались. Но Карцев отметил в своем учебнике, что наиболее радикальным решением было бы "создание принципиально новых языков программирования". Вообще, еще раз замечу, что в книге очень много интересных положений.
Спасибо за комментарий!
По поводу 2-6 процессоров. В книге, говоря современным языком, речь идет о функциональных узлах в составе одного VLIW-ядра. Интересно, что Карцев весьма консервативен в своей оценке. В этом смысле любопытно вспомнить, что в VLIW-проектах Фишера фигурировало до 30 параллельных RISC-операций!
Что же касается организации современной многоядерной системы, то здесь ограничивающую роль играет, скорее, не архитектура одного ядра (VLIW, OoO, ...), а то, как организованы коммуникации, работа с общей памятью.
В целом, речь идет об ограничениях для двух разных типов параллелизма. Если воспользоваться терминологией Карцева, то это параллелизм смежных операций (внутри ядра) и параллелизм независимых ветвей (на уровне системы ядер).
По поводу "не реализуемо в принципе". Цитата из учебника верна не только для VLIW, так работают in-order процессоры. Я с Вами согласен, что для специализированных процессоров такие решения наиболее применимы.
Кстати говоря, я добавил в статью некоторые подробности о комбинированной архитектуре Карцева. Надеюсь, это тоже будет интересно!
Индуктивный синтез программ, в сущности, представляет собой поиск в пространстве возможных программ по заданной спецификации (состоящей из примеров входов и выходов, различного рода ограничений). В супероптимизаторах предпочтение отдается самому короткому решению, поэтому синтез начинают с программы длиной 1, затем 2 и так далее.
Вот, к примеру, уже классическая работа по синтезу линейных RISC-подобных программ: Synthesis of Loop-free Programs.
Любопытная заметка! Спасибо Вам за ссылку на статью, послужившую вдохновением. Странно только, что Вы поместили свой текст в "компиляторы", но ни словом не обмолвились, что техника, которую Вы применяете, относится к известному и весьма сегодня популярному направлению -- синтезу программ. Опять же, если обращаться к компиляторным технологиям, хотел бы поинтересоваться, почему в своих решениях Вы не пошли по пути традиционной супероптимизации?
Жаль разочаровывать, если Вы ожидали увидеть там скрытый намек на "Эльбрус" или Itanium.
Авторы RISC-V не верят в перспективы VLIW в области GPP, об этом они неоднократно заявляли. Как и большинство специалистов сегодня, Хеннесси с Паттерсоном разделяют мнение, что VLIW-архитектуры замечательно себя показывают в области предметно-ориентированных ускорителей и в этом отношении RISC/CISC им, в целом, не конкуренты.
Перед авторами RISC-V стояла непростая задача обеспечения точек роста новой архитектуры. Поэтому в RISC-V стандартизированы возможности расширения команд, добавления специализированных ускорителей. Естественно, речь не идет о "каких угодно расширениях" (это самое "что угодно" добавляется в отдельные ускорители) и, в частности, вы не найдете в документе ничего о TTA, Dataflow или каких-нибудь CGRA.
По какой причине возник небольшой, укладывающийся в одну страницу, раздел VLIW-расширения? Думаю, авторы предполагали возможность реализации простых компактных вариантов в духе 2-issue in-order.