Comments 19
Давно, лет 20 назад, была мысль написать скриптовый язык, который бы рендерил картинку в GDI/GDI+ попиксельно, но что-то кроме мыслей дальше не пошло, а сейчас вполне достаточно играться с 6502.
Начинающим иногда предлагают написать эмулятор NES или Atari 8-bit (как у Вас на картинке), но это большая работа, особенно когда речь идет об эмуляции тех же спецчипов Atari. К тому же, для исторически значимых "бытовых компьютеров" уже написана куча программ и игр. Другое дело -- BytePusher. Всего 12 (теперь) простеньких демонстраций. Каждый может войти в историю с чем-то хоть немного нетривиальным :)
но имеет ли смысл создать для BytePusher компилятор языка высокого уровня?
Forth?
ЗЫ: а вообще, название статьи и приставки сразу напомнили незабвенный Sokoban :)
Читал про OISC много лет назад, кажется ещё на форуме nedopc, и всё думал, реально ли что-то сделать на основе этой идеи. Наконец-то, наглядное практическое воплощение. Круто!
Спасибо за такой приятный отзыв от ветерана демосцены!
Про subleq есть игра в стиме даже - SIC-1
А еще, к примеру, для этой архитектуры разработали ОС :)
Не хватает тега "Ненормальное программирование" :-D
Upd Пардон, в хабах он есть!
Я написал ассемблер, но имеет ли смысл создать для BytePusher компилятор языка высокого уровня?
Наверное да, но не очень понятно какой. Мой знакомый жаловался, что его OISC процессор программируется на ассемблере, который мало кто понимает.
Да, в принципе, какой угодно. С таблицами и параметризацией команд OISC-процессор достаточно быстро можно превратить в обычную RISC-архитектуру. Проблема разбухания кода решается введением виртуальной машины (внутри виртуальной машины :) Другой вопрос, если у нас серьезные ограничения по быстродействию, как в случае BytePusher, где требуется реальное время.
Процессоры с одной командой - очень красивая идея, но как следствие код сильно распухает и требует много памяти. Если рассмотреть конкретную задачу (например вычисление первой сотни чисел Фибоначчи), реализовать решение на базе процессора с одной командой и посчитать количество гейтов, которое требуется для построения всего вычислителя (включая память), число будет достаточно большим. Если усложнить процессор и реализовать больше команд, то процессор потребует больше гейтов, но будет нужно меньше памяти и возможно количество гейтов сократится. Было бы очень интересно найти систему команд, при которой количесво гейтов всего вычислителя было бы минимальным.
Вообще-то, OISC — вовсе не такая уж непрактичная вещь. TTA формально относится к OISC, но имеет свою нишу в области встраиваемых систем.
P.S. Спасибо @vkniза напоминание о TTA.
можно попросить вас раскрыть вашу мысль?
Есть так назваемая Transport Triggered Architecture, где помимо вот этого простейшего ядра, написанного в 3 строчках выше, есть ускорители всевозможных вычислений.
Т.о. процессор имеет одну единственную команду mov, но у вас есть сопроцессоры, подключённые по разным адресам. Например, чтобы сложить 2 числа, вы просто их копируете в определённые адреса, а по третьему адресу получаете сумму.
Это как мы модифицировали процедуру get3 в
def get3(mem, i):
if i == 0: # Ускоритель сложения
return int.from_bytes(mem[3:3 + 3], 'big') + int.from_bytes(mem[6:6 + 3], 'big')
else:
return int.from_bytes(mem[i:i + 3], 'big')
И вот эта штука уже очень практична.
Понятно, спасибо. Но мне кажется подобную архитектуру не совсем корректно называть oisc даже несмотря на то, что фактически реализуется только одна команда. Мне кажется расширение функционала за счет добавления шин и обработчиков в какой-то момент приведет к более сложной архитектуре, чем при использовании процессора с многими командами, декодером и алу. Или я не прав? Сколько гейтов надо использовать для реализации простого процессора используя TTA и обычный подход?
Мне кажется расширение функционала за счет добавления шин и обработчиков в какой-то момент приведет к более сложной архитектуре, чем при использовании процессора с многими командами, декодером и алу. Или я не прав?
Ну это же инженерная задача. Разумеется, если взять очень простую идею, а потом усложнять очень долго, то со временем получится что-то, что сложнее современных Интелов.
Хорошо границы области применимости OISC и традиционных RISC/CISC, наверное, знают считанные люди в мире. И я совершенно не уверен, что даже ув. @YuriPanchul может нас просветить.
Но люди используют, очень удачно, надо сказать.
Толкаем байты, или Простейший эмулятор своими руками