Вложений: 3
Дешифратор команд в комбинаторике
Чтoбы быть последовательным и честным, решил развернуть дешифратор команд из прошивки ПЗУ в элементарную комбинаторику.
Так в полной мере можно оценить простоту разработанной мною системы команд.
Правда, перевод BCD в Hex потребует двух сумматоров и одним встроенным в АЛУ сумматором не обойтись… Может, придётся удлинить цикл на ещё один такт… Это дело конкретной реализации…
К сожалению, не знаю, к какому классу архитектуры можно отнести всё это.
Для CISC - всё слишком примитивно.
Для RISC - не все команды просты своей логикой: Комбинация «03 F8» переходит на адрес F800 и пропускает 3 инструкции до адреса F803. Логически, это понятно и просто. Но реализация через счёт пропускаемых операций с режимом пропуска - уже сложно для понимания и выходит за рамки технологии RISC.
С другой стороны и к MISC отнести в полной мере не получается из-за отсутствия стека как такового…
(Операции PUSH/POP реализуются программным способом с "танцами под бубен"!)
Доработки
Немного подправил схему и логику…
Теперь комбинация «03 F8» переходит на адрес F830 по логике «Строка #3 дампа по адресу F800»…
Программировать стало легче, но программная реализация стека реализуется чудовищным кодом, так как её нельзя оформить в подпрограмму.
Почему так выходит: По плану, как уже писал выше, данный процессор задумывался основанием на ядро к x80-CISC в версии, где CISC-инструкция считывается и разворачивается в RISC-подпрограмму. Потому, получается, что поддержка внутреннего стека в рамках RISC не нужна, так как внешний стек через порты «D0…D9» будет реализовываться в CISC на внешнюю память…
Это плохо и не удобно для построения самостоятельной системы на данном процессоре и требует введения отдельных команд через резервные линии дешифратора…
Примерка кода
Если строить мой CISC x80 на базе данного ядра с прошивкой всех 32768 команд, то сам RISC-код будет всегда начинаться с адреса 0000 в ПЗУ с Гарвардским доступом. Если прикинуть и развернуть одну из операций, то получится примерно следующее:
Код:
x80: 54 |MOV AL,BL ; Команда x80
========================================================================
0000 DD D1 1E 02 88|MOV D1,0xB0 ; Регистр адреса ячейки контекста
0005 AA A1 1E AD 2D|MOV A1,D2 ; Считываем содержимое
000A DD 1E 02 80|MOV D1,0xA0 ; Регистр переключаем с BL на AL
000F DA D2 1D |OR D2,A1 ; Записываем данные
0012 00 |HLT ; Итого - 19 команд / 19 тактов
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Вместе с выборкой MOV AL,BL - 22 такта
Ужасная производительность!!!
P.S.: Получается, строить внутренности x80 на данном процессоре слишком накладно и бесперспективно.
Работу над данной версией процессора в качестве ядра приостанавливаю, но не ставлю крест: Быть может, кому-нибудь пригодится как опытный образец…
Попробую посмотреть в сторону VLIW с длинной машинного кода под 32 бита.
Вложений: 1
Дорабатывать схему становится тяжелее: Нужно просто нарабатывать код
Цитата:
Сообщение от
hitomi2500
Проект с его участием далёк до завершения
B OpenCores имеется?
Цитата:
Сообщение от
hitomi2500
если есть желание посмотреть, могу поделиться.
Конечно есть!
Цитата:
Сообщение от
hitomi2500
всё-таки больше ориентировано на ПЛИС чем на дискретную логику.
В пост-апокалипсис не добыть…
Кстати, устранил мелкие ошибки в схеме:
Операции «BE»/«CE» считывали данные из памяти преждевременно, из-за чего в регистры «Bn»/«Cn» попадали хаотические данные, так как многократно считывался байта адреса, на который и указывал сам регистр. Вентиль «2-И» всё исправил…
Код:
B0 C0 BE|MOV B0,B0:C0 ;Ячейка считывалась многократно и рандомно…
Наконец-то добавил самостоятельную «MOV» операцию прямо в АЛУ-группу:
Код:
; было…
A1 AA 1E|EOR A1,A1
AC 3D|OR A1,C3
; стало…
A1 AC 3F|MOV A1,C3
Что мешало? Концепция! Думал сунуть команды битовых сдвигов в ту группу, но пришлось отдать её под «MOV», так как свистопляска достала…
Также и с префиксом «REP 2…9» не всё так гладко:
Код:
AC A1 07 2A|ADD A1,C2*7 ; Префиксом 07 (REP 7) сложение повторяется 7 раз
07 3B|SUB A1,C3*7 ; Вычитаение 7 раз
07 4C|AND (A1,C4) ; Чушь!!! Зачем маскировать 7 раз???
07 5D|OR (A1,C5) ; Чушь!!! Эти операции в повторе бессмысленны!
07 6E|EOR (A1,C6) ; Чушь!!! Чётное число повторов возвращают биты обратно!
07 7E|MOV (A1,C7) ; Чушь!!! Какой смысл в таком присваивании 7 раз?
B5 C5 07 AE|MOV A1,B5:C5; Чушь!!! Семь раз считывать из памяти???
07 AF|MOV B5:C5,A1; Чушь!!! Семь раз записывать в память???
07 A1|USE A1 ; Чушь!!! Семь раз выбирать индекс регистра???
07 AB|USE A1,B5 ; Чушь!!! Семь раз выбирать группу операндов???
Думаю, под повтором нужно подключать иную логику. Например, внедрить операции «SHL»/«SHR» или «BIT»…
В общем, хоть таблица команд вроде бы и забита вся, но резервных комбинаций очень много получается под префиксом повтора!
Хоть механизмы пре-/пост-инкремента/декремента вводи, как в 68k… В этом случае коды 02…09 будут уже не префиксом «REP n», а каким-нибудь «MODE x»…
Сделать инкремент/декремент - лишь заменить регистры B₀…₉ и C₀…₉ на счётчики. За часик управиться можно, в перспективе…
Но, это точно выдавит процессор из класса RISC!
В файле «cnd_lib.ram» наконец-то появился код с командами «CALL»/«RET»/«JMP»/«Jcnd» с привязкой к стеку. Теперь можно вызвать подпрограммы вложением до сотни раз.
Операции «PUSH»/«POP» пока не описаны, но это достаточно легко реализуемо.
P.S.: В схему добавил два десятичных счётчика: Один считает такты до операции «00-HLT» в оперативном режиме, второй - фиксирует последний максимум…
Вложений: 1
x80-дизассемблер в Logisim
Цитата:
Сообщение от
hitomi2500
Если возникнет желание разбираться с верилогом, то по нему очень много и справочного и образовательного материала в интернете, на русском в том числе.
Вoт частичная модель моего процессора…
Но она такая кривая, что нужно переписывать с чистого листа!
В самом начале темы я уже пояснил, что в перспективе данный процессор станет ядром того процессора: CISC с RISC-ядром.
И все архитектурные решения - свои: Никакой лицензионной зависимости ни от кого!
Кстати, ниже архив - пародия на целевой процессор: Частичный дизассемблер…
В схеме - как бы всё красиво и последовательно. А в Verilog - тихий ужас!
