Американский видеоблоггер 8-bit-guy давненько уже поднял и периодически ворошит такую тему как «какой мог бы быть 8-битный компьютер моей мечты» — со своим видением вопроса. Эти его видео напомнили мне что сама эта идея «а как бы я хотел чтобы было устроено нутро компьютера» сопровождает меня и, я верю, что и вас с самого детства. И так как мы тут рассуждаем в рамках ретро, то вопрос стоит именно как в заголовке.
Тему эту в вялотекущем режиме я уже обсуждал тут: gamedev.ru/flame/forum/?id=242499 (читать совсем необязательно) и раз уж здесь у нас возникло какое то летнее затишье, то решил немного перенести оттуда сюда уже в виде некоторых выжимок для «просто поболтать».


Сердцем «компьютера мечты» является процессор и я тут решил не размениваться по мелочам и прежде всего «изобрести» именно некую систему команд «8-битного процессора мечты» для 8-битного компьютера мечты, чтобы уж совсем рубить под корень. Да ладно — все мы наверняка в своё время и не раз задумывались над «идеальным процессором» так чего тянуть кота за хвост? Мечтать так мечтать!
Сразу обозначу — что в схемотехнике познания мои весьма скромны — на уровне институтского курса про триггеры, счётчики и сумматоры, так что всё это, повторюсь, лишь фантазии для помечтать, пообсудить и, возможно, придумать что-то своё.

Из последнего на меня произвел определенное впечатление Gigatron TTL в котором преследовалась цель простоты и минималистичности в ущерб всему. Но впечатление произвела совсем не эта цель (напротив, она мне тут неинтересна — не о том мечты), а довольно забавная концепция, когда команда LOAD является всего лишь частным случаем обобщенной арифметико-логической команды в которой при пересылке источника в приёмник попутно всегда проводится операция пропускаемого данного с аккумулятором, просто в случае с LOAD эта субоперация — NOP. Тем не менее в Gigatron есть разные форматы команд — STORE и переходы уже не подчиняются той же логике, а вот я подумал — а что если такой совмещенный с опциональными вычислениями «MOV» будет единственной командой в процессоре вообще?
Итак родилась и проэволюционировала из Simpleton 1.0 в Simpleton 3.0 следующая архитектура:
1. Все инструкции имеют один и тот же бинарный формат и декодируются совершенно одинаково
2. Команда берет аргумент1 и (опционально, если инструкция двухоперандная) аргумент2, проводит над ними операцию (возможно NOP) и записывает результат в аргумент2.
3. Все команды условные (включая условие always/всегда)
Т.е. суть одной команды Simpleton 3 можно выразить в языке Си такой строчкой:

if (cond) Y ?= X;

где знак? — это операция наподобие Y += X или Y <<= X в том числе и просто Y = X, а X и Y — это регистры или ячейки памяти.
например:

R0 = data1 ; непосредственное данное
[mem2] += R4 ; запись в память
R1 =+1 [R2] ; косвенная адресация, а =+1 - это операция инкремента аргумента

Когда в инструкцию нужно запаковать и два аргумента и код операции и код условия, то одного байта становится решительно мало. Бит в инструкции вообще решительно не хватало, поэтому чтобы уместить всё самое необходимое я наступил себе на горло и превозмог все 8-битные инстинкты и сделал еще одно ключевое решение:
Архитектура Simpleton 3 полностью 16-битная и не знает понятие 8-битного байта вообще.
Т.е. и регистры и ячейки памяти и адресное пространство Simpleton 3 — всё 16-битное.
И чем больше я об этом думаю тем больше восхищаюсь тем сколько удачна идея отказаться от 8 бит. 8-битные системы всегда стояли нараскоряку между 8-битными данными и 16-битным адресным пространством. Адресное пространство уже требовало 16-битных операций для вычислений адресов, да и сами 16-битные числа в вычислениях были зачастую востребованней — в результате всё это мялось с ноги на ногу какими то полухаками и расширениями, Z80 так вообще имел 16-битные сложения/вычитания с переносом — просто кишмиш какой то. Более того когда созрели 16-битные микропроцессоры уже даже 8-битки успели вылезть за рамки 64Кб и начались метания с банкингом, свитчингом и сегментацией памяти — всё это уродливо, напряжно и прочно ассоциируется с 16 битами.
Так вот нахрен. Нахрен 8-битный байт и всё тут. 16 бит адреса — значит и 16 бит данных. Без исключений. 16-битный процессор пусть будет 16 битным во всём. И но пасаран! Мы просто зашорили свой мозг 8-битным байтом как чем то безусловно обязательным и лежащим в фундаменте всей информации. Но это вообще не так.

Заранее еще напишу какие цели Simpleton 3 НЕ преследует:
— он не является сверхпростым как Gigatron — сложность на уровне Z80 или чуть выше
— он не пытается выполнить команду за такт в четырёхстадийном конвеере
— он не является сверхпроизводительным RISC-ядром с высоким потенциалом к реализации спекулятивного предсказания переходов, внеочередного исполнения команд и трёх уровней кеша для использования в качестве современного и актуального микроконтроллера для обработки изображения в нейронных сетях четвёртого поколения

Итак,

Архитектура Simpleton 3

Девиз: «не такой уж я и тупица!» (кстати, «simpleton» с английского — типа «недалёкий»)

Все шины и данные — 16 битные. Т.е. адресное пространство: 65536 16-битных ячеек. Байтов в системе в принципе нет.
В процессоре 7 регистров общего назначения R0-R6.
При этом R6 является счётчиком инструкций и имеет еще псевдоним PC.
R5 имеет особое поведение при косвенной адресации (автоинкремент при чтении и автодекремент при записи) и имеет псевдоним SP (стек).
R4 содержит флаги процессора и имеет псевдоним FLAGS.
При этом в нём же содержится такая штука как бит запрещения/разрешения прерываний поэтому команд типа EI/DI как в Z80 тоже нет, нужно просто произвести запись во FLAGS.
В FLAGS есть 4 бита арифметико-логических флагов:
— флаг нуля (zero)
— флаг переноса (carry)
— флаг знака (sign)
— флаг переполнения (overflow) (carry для знаковых)
Вполне себе стандартный набор.
Когда инструкция считывается из памяти сперва считывается её код по текущему PC и PC тут же инкрементируется. Т.е. на момент фазы парсинга инструкции PC уже указывает на следующую команду.
Если у инструкции есть непосредственные данные (от 0 до 2), то их считывание происходит в процессе выполнения команды с тем же эффектом — считывается данное по адресу PC и последний тут же инкрементируется.

У всех инструкций один и тот же формат:



Рассмотрим битовые поля в таком порядке в каком их обрабатывает логика микропроцессора после считывания инструкции:
SRC — код регистра-источника (R0-R6) или численное значение 7 для обозначения непосредственного операнда следующего за инструкцией. Первым делом процессор копирует это значение в во внутренний регистр X.
IS — (Indirect Source) признак косвенной адресации источника. Если равен 1, то значение в X замещается значением ячейки памяти по адресу X. При этом, если SRC является SP, то SP инкрементируется (аналог POP).
Флаг TI (two operand instruction) — признак двухоперандной инструкции. Если TI = 1, то данное DST, т.е. то куда будет в конце операции записан результат из АЛУ нужно перед выполнением операции еще поместить во второй промежуточный регистр Y. X и Y пойдут в АЛУ как раз как входы.
ID — (Indirect Destination) признак косвенной адресации приёмника. Если он включен и инструкция предполагает использование двух операндов (взведённый флаг TI), то значение Y вычисленное на предыдущем шаге помещается в регистр STORE_ADDR и замещается значением ячейки памяти с этим адресом. В конце инструкции именно в адрес STORE_ADDR запишется результат.
COND — (condition) — условие. Восемь возможных условий таковы:
Always — всегда
Z/NZ — ноль/не ноль
C/NZ — перенос/не перенос
G/GE — больше/больше или равно (знаковые сравнения)
восьмое пока не придумал куда кинуть
В общем на этом этапе, если условие не выполнилось, то остаток инструкции можно пропустить и перейти к следующей. Вообще по здравому размышлению условие надо проверять первым действием на входе в инструкцию и пропускать сразу всё, но не забывать инкрементировать PC на количество непосредственных данных, но по моему это усложнит логику и поэтому лучше поместить проверку условия технически в это место, где immediate-данные уже считаны и PC на них выправлен.
INSTR — код инструкции. Т.е. получается возможно 16 одноперандных инструкций и 16 двухоперандных.
Однооперандные: mov/neg/inc/dec/incf/decf/…
(incf/decf меняют флаги в то время как inc/dec — нет)
Двухоперандные: add/adc/sub/sbc/and/or/xor/cp/…
Пока лень обдумывать конкретику. Но, например, уже ясно, что инструкция сравнения должна принимая SRC и DST на входе и выставив флаги возвращать из АЛУ именно DST чтобы его не испортить по сравнению, как полагается.
На последнем шаге процессор сохраняет результат на выходе из АЛУ в DST и если это была индирекция через через регистр SP, то декрементирует его.

В общем как я и писал выше общая схема инструкций в этом процессоре это:
Y ?= X
где X может быть одним из 7 регистров R0-R6, непосредственным данным imm16 или ячейкой памяти по адресу любого из ранее перечисленного, т.е. [R0-R6] или [addr16]
тем же самым может быть Y, кроме варианта imm16 который не имеет смысла в операции записи
а знак? — это одна из арифметико-логических операций

Существует одна запрещенная комбинация инструкции когда DST является imm16, а бит индирекции ID не зажжён. Она зарезервирована под гипотетические будущие расширения команд.
Так же запрещено в рабочем коде использовать mov из регистра в него самого же, если это не R0 (т.е. явный NOP) тоже для возможности будущих расширений и префиксов.

Небольшой FAQ

Какие у Simpleton 3.x есть необычности или подводные камни:

1. Если простой переход (jump) это:

PC = addr16

а относительный переход как:

PC += offset16

то с вызовом процедуры (call) эта «однокомандная» система в одну команду не пролазит.
тут нужно делать примерно таким образом:

[SP] = адрес возврата
PC = адрес процедуры

и тут вот какая неприятность — адресы тут являются immediate-данными и таким образом эти две инструкции будут занимать целых четыре слова. не очень хорошо.
т.к. чаще всего мы хотим вернуться на код следующий за этими инструкциями, то в [SP] надо занести значение PC+2 (на момент выполнения первой инструкции PC указывает на следующую, а надо еще пропустить immediate-данное). И вот чтобы это стало возможным нужна двухоперандная инструкция не только inc, но и inc2. Тогда да — в две инструкции:

[SP] =+2 PC
PC = адрес процедуры

мы делаем вызов процедуры
А вот совершить возврат из неё очень просто:

PC = [SP]

тут уже всё делается в одно действие.
конечно в ассемблере call можно будет сделать макросом.

2. Как разрешить/запретить прерывания не затрагивая арифметико-логические флаги в FLAGS?
Да очень просто:

FLAGS &= константа ; для сброса 
FLAGS |= константа ; для взведения

Т.е. не просто перезаписью, а через логические операции с операндом-константой.

3. Что именно делают прерывания?
Как и в классических процессорах помещают в стек сперва PC, потом FLAGS и совершается переход по заранее определенному адресу.
Таким образом возврат из прерывания должен совершаться так:

FLAGS = [SP] ; заодно разрешаеются прерывания, т.к. восстанавливается старый FLAGS
PC = [SP]