Проектирование процессора

[i8088]

Alikberov, а NOP какой код у Вас? А переходы?

- - - Добавлено - - -

где взять не преклонного возраста людей, согласных кодить в кодах?))

Я работал в кодах для ВМ80 (тогда не было компьютера), но снова это повторять не особо хочется. И не из-за
кодирования инструкций, а из-за высчитывания адресов меток. При абсолютной адресации это неудобно из-за
того, что малейшее изменение кода - адрес метки меняется, а при относительной - утомительно само высчитывание.

В любом случае, автору темы желаю всяческих успехов!!

[Advertiser]

[Alikberov]

(где взять не преклонного возраста людей, согласных кодить в кодах?))

Изначально всё проектировалось, чтобы ПЗУ с программой заменить на макетные платы и шестнадцатеричные тумблеры (ссылка) в количестве от 512 штук (под табло механического дампа на ввод программы из 256 байтов).

Alikberov, а NOP какой код у Вас?

Очень любопытный вопрос!

С одной стороны, под NOP'ом может использоваться любая операция:

• коды A0..D9 (REG A0..D0) для активации левого операнда-приёмника могут повторяться много раз
• коды AA..DD (ARG A,A..D,D) для определения АЛУ-операндов могут повторяться много раз
• коды AE..DF (CLC/CMC и т.д.) могут повторяться много раз

Но, это - только в изначальном варианте. Так как сейчас работаю над "строгим дешифратором команд", который не допускает повторения однотипных инструкций:

• последовательность операций REG A7 и REG A5 составляются в одну - REG A75 (нужен регистровый файл побольше)
• последовательность операций CMC и CLC, так как CMC перед CLC бессмысленна, образует новую операцию
• последовательность операций CMC и CMC, так как двойная CMC бессмысленна, образует новую операцию

То есть, процессор хоть и не "нейросеть", но вполне способен в таком контексте выполнять "скрытые операции".

А переходы?

Выше я привёл пример же:

• код "CF" означал "NOT CF" (CMC), а с префиксом "54 CF" означает "JCF [D5+4]"

То есть, CMC с префиксом - условный переход.
Так как имеется 32 INT'а (коды E0..FF), в подпрограммах (в JavaScript-эмуляторе с "Гонками") реализованы "нормальные" JC/JNC на абсолютные адреса (или относительные).

МАРГИНАЛЫ
В знакомой всем IA-32 / x86 имеются механизмы вычисления абсолютного адреса:

• LEA EBX,[EBX+EBX*2+3] - эквивалент EBX += EBX * 2 + 3
• ADD EBX,[EBX+EBX*2+3] - а вот здесь такой указатель не сработает и выдаст исключение

Инженеры Intel переложили всю ответственность за использование подобных указателей на программиста. Хотя, можно было бы подправить их интерпретацию:

• ADD EBX,[EBX+EBX*2+3] мог бы работать как ADD EBX,(EBX+EBX*2+3) - EBX += EBX*3+3
• ADD [EBX+EBX*2+3],EBX - вот тут проблема, так как нельзя выполнить как EBX*3+3 += EBX

В таких случаях, так как "ADD EBX,[EBX+EBX*2]" использует адресацию "из ряда вон!", условно она стала обозначаться как "маргинальная".

Также в x86 инструкцию можно составить искусственно и так:

• MOV EAX,CS: DS: ES: FS: GS:[EBX] - указано целых пять префиксов, четыре из которых - игнорируются (маргинальные префиксы?)

Программе это ничего путного не даст, но внутреннему отладчику исключений может нести некую закодированную информацию (в зависимости от порядка префиксов).

И я много внимания уделил механизмам отлова "маргиналов", чтобы исключить вообще такие неприятные ситуации.

То есть, из таблицы выше, вот такие примеры:

• код "CB C1 2A" означал "ADD C1,B2", а с префиксом "CB C1 54_2A" означает "ADD C1,[D5+4],B2"
• код "CB C1 2A" означал "ADD C1,B2", а с префиксами "CB C1 54_58_2A" означает "ADD C1,[D5+D5+48],B2" с "маргиналом"
• код "BA B2 3E" означал "EOR B2,A3", а с префиксом "BA B2 54_3E" означает "EOR B2,[D5+4],A3"
• код "BA B2 3E" означал "EOR B2,A3", а с префиксами "BA B2 54_58_3E" означает "EOR B2,[D5+D5+48],A3" с "маргиналом"

То есть, количество префиксов перед инструкцией ничем не ограничивается и может достигать десятков и сотен. Правая тетрада префикса, как уже можно догадаться, как часть BCD накапливается в аккумуляторе смещения.
А вот левая - указывает на регистровую пару B:C под псевдонимом D. И если указывать нулевое смещение, можно "маргинализировать" адрес (подавлять его):

• код "CB C1 50_2A" работает как "ADD C1,[D5+0],B2"
• код "CB C1 50_50_2A" как "ADD C1,[D5+D5+0],B2" уже не работает: Цепочка "50_50" - "маргинальна" и указатель "подавлен". Операция работает как "ADD5 C1,B2"
• код "CB C1 50_50_50_2A" как "ADD C1,[D5+D5+D5+0],B2" уже не работает: Цепочка "50_50" - "маргинальна" и указатель "подавлен", но указан в третьем префиксе. Операция работает как "ADD5 C1,[D5+0],B2"

Думаю, основную суть уже уловить можно.
Но, что такое этот "ADD5"? Как работает эта "маргинализованная" инструкция?
Лично я пока ещё не определился. Формально - это команда "внешнего АЛУ#5". Обращение к сопроцессору.
То есть, технически код "80_80_70_70_0A" как "ADD87" можно использовать с сопроцессором i8087 как "FADD" - все "маргиналы" процессор (модель на Verilog) пока никак не обрабатывает, а лишь сигнализирует на выводе "MRG" для внешнего буфера, как "M1" - машинный цикл выборки операции.

То есть, масштабируемость архитектуры уже поддерживается на самом базовом уровне.

ДЕШИФРАТОР АЛУ
Обычно в процессорах допускаются бессмысленные операции, типа "MOV A,A", "CMP A" и т.д.
Так как у меня регистр A0 выполняет функцию PSW, операции типа "ADD A0,A0" как "ADD PSW,PSW" бессмысленны и на аппаратном уровне помечаются особыми признаками.
Всего получается восемь таких признаков:

• M - наличие "маргинала" перед инструкцией
• V - наличие "нормального указателя"
• A_rcv - используется A0/PSW как приёмник результата
• D_rcv - используется Порт (Device) как приёмник результата
• E - признак эквивалентности операндов ("приёмник" и "источник" - один регистр/порт)
• A_trs - используется A0/PSW как источник
• D_trs - используется Порт (Device) как источник
• F_bit - признак не АЛУ операции - FOR/MOV

На этом фоне, с учётом всех исключений, получается солидная таблица АЛУ-команд.
Изначально их было шесть - ADD / SUB / AND / OR / EOR и MOV. А стало:


Вот скриншот прогона отладки дешифратора команд на Verilog HDL:

Как можно заметить, многие инструкции (ситуации) ещё не определены и появились инструкции LEA, LEX (аналог XLAT) и ORD (аналог сортировочной перестановки регистров совмещённой с SHR).

Ознакомиться с кодированием инструкций, используя сложные "указатели" и "маргиналы", можно по ссылке.

P.S.: Нетрудно заметить, что с префиксами и "маргиналами" система команд стала значительно сложнее и серьёзнее. А как 8-битная архитектура уже близко подошла к i8086.

[vegapiratradio]

на всех прикрепленных изображениях, ничего не видно! разрешение крайне низкое и вникнуть в суть не удается.

[Alikberov]

на всех прикрепленных изображениях, ничего не видно! разрешение крайне низкое и вникнуть в суть не удается.

Как разместить картинку на форуме?

Хм...
Тогда я дам ссылки на мой github-ресурс (с кодовым именем "Койяанискацци" - трек на modarchive.org)...
Ссылка на Verilog-модель (сто раз устаревшую)

Дешифратор команд на комбинаторике (Logisim)

[свернуть]

Дешифратор команд на комбинаторике (Proteus)

[свернуть]

Полная схема (Logisim - Принстонский прототип с декодером команд на ПЗУ)

[свернуть]

Синтез схемы на Quartus

[свернуть]

Но, все эти схемы - чисто ради приличия: Редкий энтузиаст возьмётся воспроизводить эту схему из реальных номенклатурных ИМС.
(более 200 микросхем, по предварительным подсчётам)
Схемами в симуляции лично я просто убедился, что построить процессор с "дружественным машинным кодом" вполне реально.

Сейчас сосредоточился на Verilog HDL, чтобы уровень "воспроизводимости" в ПЛИС был самым доступным.

ИМХО, в эру всяческих нейросетей машинный код подавляющего большинства процессоров продолжает оставаться на уровне "эзотерических бинарных полей".
Потому, мои исследования сосредоточены на том, чтобы сделать хоть какой-то машинный код именно XXI века, с которым и "домохозяйка" разберётся.

Таблица исключений для АЛУ

[свернуть]

Калькулятор вектора - на ТТЛ и Verilog

[свернуть]

Прогонка декодера команд со всеми комбинациями префиксов, маргиналов и исключений

[свернуть]

Эзотерика бинарных полей
В i8080 инструкции MOV Rd,Rt кодируются бинарным полем 01dddttt.
Тем самым, хоть даже процессор официально - индустриальный и не эзотерический, эту самую эзотерику несут битовые поля в кодировке инструкций.
Позволю себе промолчать и про все остальные: IA-32, ARM и т.д.

Почти "Java-машина"
Выше дана ссылка на эмулятор процессора для РАДИО-86РК.
А если он достаточно легко эмулируется на РЛК, то можно написать эмулятор и на ZX-Spectrum, и на Yamaha-MSX.
То есть, получаем "подобие Java-машины", только с "гуманитарным машинным кодом", который не нужно выучивать и зубрить таблицу команд.

Как можно убедиться, аккумуляторов может быть 10 (A0..A9), так и 100 (A10..A99) или даже тысяча (A100..A999). На программном уровне это доступно.
В таком случае общее количество РОН становится не 30, а 300 и 3000 соответственно.
(Если браться собирать процессор "по военному" - на отдельных модулях, то нет никаких архитектурных ограничений на масштабируемость.)

При "прошивке FPGA" вполне можно указать размер Регистрового Файла, какой только способен уместиться на ПЛИС.
(Существовал вариант, где всё архитектурное состояние сохранялось непосредственно в ОЗУ, что могло обеспечить многозадачность, но требует до 10 Машинных Циклов на операцию - до 30 тактов.)

Конвейер
Теоретически, если бы инженеры Intel открыли бы доступ к микрокоду ядра своих процессоров, перешить его под исполнение программ данной архитектуры не составляло бы никакого труда.
А значит, производительность была бы на высочайшем уровне.

Некоторые проблемы "парадигмы"
Выше уже указывалось, что оп-коды E0..FF - это "заглушки" программных INT'ов, проще говоря - CALL E000..FF00.
Однако, так они работают только в "сухом виде" - без префиксов (указателей и "маргиналов").
До сих пор отсутствуют представления о том, как должны работать "указательные INT'ы" и "маргинальные INT'ы".
А ещё:

• Указательные-Маргинальные CLC/CMC
• Указательные/Маргинальные ARG
• Маргинальный HLT

Всё это указывается на "скрытый потенциал архитектуры", о котором я не подозревал в 2019 году на первых набросках схематики в Logisim.
Даже на высоком уровне - в JavaScript, просто не имеется никакого чёткого представления, как обрабатывать "маргинализацию" существующих команд.
(Пока она просто игнорируется или выполняет "действительно маргинальные операции" из ряда вон: Чертит линии и выводит спрайты, что никак не должно распространяться за пределы экспериментальной эмуляции.)

P.S.: Всё это - результат двадцатилетних исследований.