На размышления по теме меня сподвигла статья aa-dav под заголовком 8/16-битный компьютер мечты (процессор Simpleton). Статья, без дураков, замечательная. Понравилась своим рассудительным изложением материала. Мой особенный интерес вызвали мысли автора, оказавшись близкими по духу. Множество раз размышляя на подобную тему “с карандашом в руках” очень похоже изводил себя вопросами озвученными автором. Процесс созидания чего бы то ни было итеративный, наблюдения и заключения меняются по времени, в силу приобретения дополнительного опыта и знаний. Иногда достаточно попробовать сложившуюся на бумаге архитектуру “на зуб” написав в ней десяток другой строк кода и, казалось бы, с железобетонных утверждений приходится слезать. Неизменным всегда остается то, что любой вопрос, касающийся архитектуры, содержит в себе массу противоречий. По большому счету выбор решения в итоге заключается в том какие же из них являются меньшим злом. Так и в случае разрядности появляется масса вопросов и проблем. Для меня в итоге, при решении вопросов разрядности в разработке архитектуры (архитектуры мечты), потеря байта как единицы оперативной информации, оказалась болезненной.

Главная неразрешимая проблема состоит в том что адресное пространство для 8-битного или 16-битного вычислительного устройства ограничено одним и тем же числом ячеек — 65536. Я не рассматриваю сейчас способы преодоления данного ограничения, важно что они есть и они достаточно разнообразны, но при этом неизменны для платформ любой разрядности. А вот что действительно важно это “узость” имеющегося пространства в 64К слов. Особенно для Фон Неймановской архитектуры, когда код и данные зависят от одного и того же 64К слов адресного пространства.
Выбор системы команд RISC способен это противоречие только усугубить. Эволюцию размена простоты декодирования инструкции, а значит и частотного потенциала вычислительного ядра, на плотность машинного кода можно прочувствовать на примере системы команд встраиваемых ядер ARM. Изначально довольно изысканная по своей непротиворечивости и складности 32-битная инструкция довольно быстро скатилась к многочисленной разновидности THUMB. Переход к THUMB и уплотнению инструкции, ломает внутреннюю красоту, описательность и простоту первичной системы команд. Такое можно стерпеть, при условии, что ассемблер и оптимизация это удел компиляторов. В случае появления THUMB в АРМ первую скрипку играет ограниченность ресурсов в накристальных системах, прежде всего в ПЗУ и ОЗУ, а использование кросс средств и ЯВУ вопрос давно решенный. Допустимо ли это для “архитектуры мечты”? В некотором смысле система команд PDP-11 произведение искусства, а программирование в ассемблере для него, многим доставляет эстетическое удовольствие. Возможно ли этим пренебречь?
В любой архитектуре вычислительного ядра отказаться от индеректной константы крайне сложно. В RISC такая боль непринужденно вылезая из головы проектировщика декодера, превращается в мигрень программиста. Посудите сами, как одной 16 битной инструкцией, загрузить 16 битную же константу? Можно грузить слова из памяти по укороченному смещению или адресу, но на индиректную загрузку константы это совсем не похоже. Можно грузить что то меньшее 16 бит и операцию расширяющую это число. Что называется оба метода хуже — в первом случае рыхлый код становится еще рыхлее на адрес и данные к нему, а во втором случае в один прекрасный момент понадобится константа для получения которой потребуются затратить две инструкции. Впрочем, можно пойти на игнорирование принципов RISC и допустить команду с операндом в следующем слове (прощай мигрень программиста), но плотность кода все еще страдает. Как только начнется адресная арифметика со смещениями чьи значения по разрядности находятся в районе 5-4 бит, а для адреса в 64К трудно представить себе смещения между соседними элементами массивов больше чем 16 байт, так рыхлый код не заставит себя ждать. И это пока только код, нужно ли говорить какими аппетитами на адресное пространство будут обладать сами массивы с 16-битной грануляцией данных в них? Достаточно показательно, в качестве иллюстрации, хранение PCM сэмпла, да и вообще любых данных, чье сжатие основанное на учете приращения к предыдущему отсчету. Конечно всегда можно воспользоваться практикой сдвигов и маскировок битовых полей, но стоит ли это отказа от байта?
В системе команд почти всегда имеется группа инструкций применяющихся наиболее часто, но в случае с RISC где инструкции одинаковы по разрядности, использовать такую особенность на увеличение плотности бессмысленно. Другое дело CISC. Взамен CISC одаряет разработчика ядра сногсшибательной головной болью. Нерегулярная система команд требует совсем непростого автомата декодера, секвенсера и микрокода. Впрочем можно и без микрокода. А если уж так, то почему бы не усугубить, ввести очень короткую команду размером в байт, в которую засунуть наиболее часто используемые инструкции? Все остальные пойдут через префиксное расширение, которым могут являться бессмысленные инструкции, например пересылка из одного и того же регистра MOV Ri,Ri.

Чем короче инструкция и плотней код, тем более сложные и пространные программы можно писать для 64К не прибегая к оверлеям. Идя по этой дороге можно добраться до разновидности OISC — с инструкцией в 4 бита и арифметическим стеком, где мы снова окажемся на развилке противоречий. Стек заменяя многочисленные регистры общего назначения (в архитектуре мечты их может быть и более 16) расшивает узкое горло полей для их представительства в машинной инструкции, взамен награждает неторопливостью при вычислениях на нем. Дарит реверсивную стековую нотацию и сильно упрощает разбор выражений, однако лишает оптимизации по скорости вычисления.

Еще один шаг по тропе OISC и мы в области тьмы :) в области архитектуры ТТА (transport triggered architecture) состоящей из действительно одной инструкции, инструкции перемещения MOV. Команда шириной 8-бит тут к месту.


Использовать индиректно 8-битную константу пересылкой из источника CODE8, #200 -> R0, где #200 это 8-битная константа следующая за 8-битной инструкцией. 16-битную, меняем источник на CODE16, #2000h -> IP. Само собой IP при чтении с CODE8/CODE16 смещается на 1/2 байта, и указывает на следующую за константой инструкцию к моменту исполнения. Кодируя 16 источников и 16 приемников, легко и непринужденно можно их префиксировать не меняя основы, например так #1 -> RPAGE. Где RPAGE указатель страниц регистров.
Максимально простой декодер, нет микрокода. Внутренняя архитектура — мультиплексор данных из источников, управляемый полем машинного слова “SRC” и дешифратор записи управляемый полем “DST”. Быстра. Взамен… Совсем не простое кодирование, ведь инструкция сложения ADD #4, R0 превращается в набор пересылок: #4 -> ALU.A, R0 -> ALU.B, ADD -> R0. Опять здравствуй, хоть и небольшая, рыхлость кода. Продемонстрирую некоторые варианты использования:

Условное исполнение:

; псевдокод
; ADD = R0 + 8;
; IF ADD == 0 THEN R0 = ADD;
; IF ADD != 0 THEN goto M1;

#8 -> ALU.A
R0 -> ALU.B
ADD -> IFZ#     ; передача Флагов сумматора в модуль условного исполнения по Z-флагу
ADD -> R0	; Z флаг подключен на разрешение записи в приемник, действует в течении текущей инструкции
ADD -> IFNZ#    ; передача Флагов сумматора в модуль условного исполнения по Z-флагу
IP  -> R0	; инверсия Z флага подключена на разрешение записи в приемник, действует в течении текущей инструкции

Авто инкремент и декремент адреса:

; addr = 2000
; mem[addr]  = R0 + mem[addr]; 
; addr += 100;

#100  -> OFFS
#2000 -> ADDR
DATA  -> ALU.A
R0    -> ALU.B
ADD   -> DATA+	; постинкремент адреса на OFFS

P.S. Пожалуй моделировать такой процессор в Digital, это идея для следующей статьи. :)