На мой взгляд, Don Priestley и его творения заслуживают отдельной большой статьи.
Продолжая список самобытных игр, в тексте была упомянута Knight Lore, а для меня венцом изометрических аркадных приключений стала The Great Escape. Как же она здорово сделана! Что с внешней стороны, что с точки зрения игрового дизайна!
Спасибо за монументальное пижамарамное исследование!
"Во времена оны" купил на кассете Sceptre of Bagdad тоже в русском переводе. Тогда переводы спектрумовских игр были настолько редким явлением, что я даже посчитал игру сделанной в России. Игра, к слову, очень симпатичная, одна из немногих игр этого жанра, которую я прошел без всяких подсказок и обмана и сделал это с удовольствием.
Но знали ли вы, что Sceptre of Bagdad -- на самом деле финская игра? И, судя по всему, это единственный случай коммерческого успеха спектрумовской игры, разработанной в Финляндии. Сделали ее три очень молодых человека, им было не более 18 лет на момент выпуска игры. Здесь можно прочесть некоторые подробности на эту тему: https://frgcb.blogspot.com/2016/12/twofer-14-finnish-special.html
P.S. Мне, кстати говоря, очень нравится самобытное аркадное приключение The Trap Door. Игра явно выбивается из Pyjamarama-канона в значительно большей степени, чем столь беззаветно любимая нашими спектрумистами серия про Dizzy.
Да, в принципе, какой угодно. С таблицами и параметризацией команд 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 и так далее.
На мой взгляд, Don Priestley и его творения заслуживают отдельной большой статьи.
Продолжая список самобытных игр, в тексте была упомянута Knight Lore, а для меня венцом изометрических аркадных приключений стала The Great Escape. Как же она здорово сделана! Что с внешней стороны, что с точки зрения игрового дизайна!
Спасибо за монументальное пижамарамное исследование!
"Во времена оны" купил на кассете Sceptre of Bagdad тоже в русском переводе. Тогда переводы спектрумовских игр были настолько редким явлением, что я даже посчитал игру сделанной в России. Игра, к слову, очень симпатичная, одна из немногих игр этого жанра, которую я прошел без всяких подсказок и обмана и сделал это с удовольствием.
Но знали ли вы, что Sceptre of Bagdad -- на самом деле финская игра? И, судя по всему, это единственный случай коммерческого успеха спектрумовской игры, разработанной в Финляндии. Сделали ее три очень молодых человека, им было не более 18 лет на момент выпуска игры. Здесь можно прочесть некоторые подробности на эту тему: https://frgcb.blogspot.com/2016/12/twofer-14-finnish-special.html
P.S. Мне, кстати говоря, очень нравится самобытное аркадное приключение The Trap Door. Игра явно выбивается из Pyjamarama-канона в значительно большей степени, чем столь беззаветно любимая нашими спектрумистами серия про Dizzy.
Вообще-то, 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.