Войти
ФлеймФорумПроЭкты

❌80: Тёплый ламповый (19 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 114 15 16 17 18 19
#270
17:00, 24 окт. 2019

Упс. Линк старый дал…

Вот верная ссылка.

Чтобы обойтись без ПЗУ под микрокод, модуль x80_cmd_decoder должен выдавать не абстрактный индекс под инструкцию, а конкретный широкий код. Это должно помочь избавиться от необходимости в явном RISC-внедрении.

Проблема в том, что предстоит разбираться с разработкой VLIW-кодирования.
Пока не известно, сколько бит в этом слове конкретно понадобится.
Например, «PUSH DI»…
Можно прокодировать вот так:

ADDR 0xA1   ; Выдача на шину адреса слова модуля контекста из смежных 0xA9:0xA1
USEP        ; Выдача на шину данных байта модуля контекста из префикса
DECW        ; Декремент целого слова с записью в контекст
SAVE        ; Генерация сигнала стробирования памяти на запись - WRITE
LOHI        ; Переключение триггера байта модуля контекста от ячейки 0xD9 на 0xD1
DECW        ; Декремент целого слова с записью в контекст
SAVE        ; Генерация сигнала стробирования памяти на запись - WRITE
Но это не RISC-команды, а имена флагов, которые выставятся примерно вот так:
10 10 1 10 10 0100 10100001
|| || | || || |||| \\\\////
|| || | || || ||||     \----> Ячейка контекста под адресную шину (SP)
|| || | || || |||+----------> USER - подставить адрес контекста приёмника (нет)
|| || | || || ||+-----------> USET - подставить адрес контекста транслятора (нет)
|| || | || || |+------------> USEP - подставить адрес контекста префикса (да)
|| || | || || +-------------> USEC - подставить адрес контекста счётчика (нет)
|| || | || |+---------------> INCW - первичный инкремент шины адреса (нет)
|| || | || +----------------> DECW - первичный декремент шины адреса (да)
|| || | |+------------------> LOAD - управление шиной под загрузку (нет)
|| || | +-------------------> SAVE - управление шиной под выгрузку (да)
|| || +---------------------> LOHI - переключение старший/младший байт
|| |+-----------------------> INCW - вторичный инкремент шины адреса (нет)
|| +------------------------> DECW - вторичный декремент шины адреса (да)
|+--------------------------> LOAD - управление шиной под загрузку (нет)
+---------------------------> SAVE - управление шиной под выгрузку (да)
Иными словами, нужно VLIW придумать оптимально так, чтобы в одно это слово влезло максимальное число необходимых операций.
А блок исполнения будет выполнять операции (справа-налево) и обнулять те биты, когда операция завершена. Выходит, что «PUSH DI» - уже 6 операций…
Но, для реализации «PUSH [DI-3]» (код 33 B0 FD) этих битов не хватает, так как нужно вычислить DI-3, выдать результат на шину адреса, считать оттуда слово и поместить в стек…
Тут то становится ясно, что потребуется VLIW длиннее, чем на 21 бит.
Легче действительно разработать набор RISC-инструкций, но с аппаратной поддержкой конвертации регистров в индексы ячеек контекста, чтобы не городить тысячи микропрограмм, а обойтись 60, как здесь.
(Даже мой LogiSim-дизассемблер - своеобразный RISC, как ни крути.)

P.S.: Так как модуль контекста (с прошлого года) уже есть, модуль шины - вроде бы работает, модуль выборки команды - вроде бы тоже работает… И АЛУ (прошлогодний) - есть.
Осталось продумывать исполнительный модуль.
То есть, эдак на годик проект снова надо подморозить и пассивно обмозговать.


#271
22:40, 24 окт. 2019

Alikberov
Какие преимущества по сравнению с уже имеющимися, для тех, кто не шарит?

#272
23:03, 24 окт. 2019

nes
> Какие преимущества по сравнению с уже имеющимися, для тех, кто не шарит?
Нe входит у меня в задачу догонять имеющиеся технологии по PIC, RISC, NIOS и т.д.
Просто в детстве я понимал, что i8080A уж слишком дубовый и мечтал придумать аналогичный, но красивее.
Потому:

(Это - авто-анти-реклама, если что…)

Вкратце: На некоторых RISC, да ещё и с VLIW, голыми руками не поработаешь и ассемблером не обойдёшься.
А с этим x80 - всё очень просто для набивания кода даже без заучивания всей системы команд прямо дампом. Портировать код со Специалиста, Ориона-128 и Микроши - достаточно легко. А так как ассемблер - в стиле x86, то я ассемблерный инлайн отлаживаю прямо в MSVC 6 и вставляю в x80-ассемблер почти как есть…
То есть, x80 - уже не i8080, но ещё не i8086. Получается, «фрактальная архитектура»…
Чисто на любителя.

Реально, если x80 в перспективе оформить пинами как процессор z80 и воткнуть в ZX-Spectrum, то никакое ПО от ZX не будет работать, но появятся новые фишки: Исключения, мультипоточность, микропрограммный ПДП, виртуальные порты и т.п.

Плюшки:

Всё это подробнее я здесь уже описывал.

P.S.:
#38 return [](){};
> Напиши простенький 8-битный проц с десятком инструкций на logisim
Тaк вот откуда пошёл этот LogiSim-набросок у меня! :-D

#273
0:30, 27 окт. 2019

Eсть, оказывается, ещё и Digital с возможностью экспорта схемы в Verilog/VHDL.
Однако, редактор схемы, после LogiSim, какой-то неудобный и даже, местами, дубовый. Пока эту схему нарисовал:
x80 CISC-Reader | ❌80: Тёплый ламповый
Запарился и руки заболели.
(Если сравнивать OrCAD и LogiSim, то в OrCAD много мелких детских глюков редактора схем, а в LogiSim нельзя давать имена отдельным проводниками шины.)

Есть ещё какой-то LogiSim Evolution с экспортом VHDL и с FPGA-симуляцией, с которым завтра начну разбираться.
Имеется возможность вставить VHDL-модуль как часть схемы и потыкаться в него щупами и кнопочками.
(К сожалению, он некорректно импортирует мои схемы x80-дизассемблера и придётся их перерисовывать, чтобы оценить новые плюшки симуляции.)

Демонстрация использования реальной платы с FPGA:

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

Кстати, здесь напрашивается малюсенькая коррекция системы команд.
Если вы хоть чуточку ознакомились с командами, то из кода

1234    BC FF|JC  $-1
следует, что при выполнении условия произойдёт переход на команду
1235    FF   |RET
и тем самым формально имеется инструкция
1234    BC FF|RET C
Ясно, что при выполнении условия процессор дважды будет топтаться на месте и тратить такты. И это было в JavaScript-эмуляторе, так как там пофиг на производительность.
Однако, так как аппаратно и в LogiSim, и в Verilog эту проблему я решил постфиксами, то сама надобность в команде RET в её чистом виде через код 0xFF уже отпадает, так как её может заменить код «E8 FF» команды «JMP $-1». В этом случае команда RET кодируется двумя байтами, так как она несколько реже используется и на размер кода в общем никак радикально не повлияет.
Но, в таком случае код 0xFF освобождается как симметричная противоположность коду 0x00 команды HLT. И если ОЗУ обычно обнуляется, то в ПЗУ зарезервированные ячейки имеют биты единиц и код 0xFF. И этому коду можно назначить какую-нибудь особенную команду.
Может, под команду непосредственной отладки - DBG (аналогично как x86 код 0xCC - «INT 3»).
Либо под команду ожидания - WAIT (аналогично HLT у z80, которая ожидает сигнала прерывания), так как HLT в x80 останавливает программу насовсем. А в комбинации с префиксами получим краткую запись «WAIT R8» или «NOP R8»…

P.S.: Здесь надо подумать…
Интересно то, что в JavaScript я об этом не думал, так как эмулятор мог переварить любую лабудень. А так как аппаратно на уровне комбинаторики появилась изящная возможность сэкономить такты схематически и в Verilog, то есть смысл пересмотреть назначение кода 0xFF…
(В этом плане с Verilog я бы просто портировал код с JavaScript. А вот с LogiSim нашёл лазейки!)

#274
5:00, 28 окт. 2019
Пoймал себя на том, что набиваю Verilog по JavaScript-шаблону с отключенными мозгами.
Тогда как прорисовка схемы - довольно кропотливое занятие и мозги работают лучше, как в школьные годы, когда я несколько суток тратил на прорисовку схем линейкой из лоскутков отдельных узлов. Тем самым, за графическим редактором схем чувствую себя моложе лет на 20!
Важнo
Так как LogiSim Evolution не читает схемы редактора предыдущей версии, пришлось начинать с чистого листа. А так как пользовательские элементы поддерживаются, то элемент «Исключающего ИЛИ» перерисовал в более узкий (и зачем они такой ящик нарисовали?), а также и свои регистры нарисовал (в Evolution они ужасно громоздкие!)…
А так как и модули памяти в Evolution зачем-то сделали в монстр-стиле, то избавился от искушения добавить ПЗУ в модуль выборки команд - «Читалку»…

Теперь «Читалка» функционально завершена и без всяких ПЗУ…
В ней - четыре регистра:

+ Схема
Схема относительно ровная в три ряда комбинаторики.
Главное в том, что эта версия «Читалки» сильно помогает дешифратору команд регистром IA тем, что записываемым в IA кодом отделяет инструкции друг от друга чисто на уровне комбинаторики без ПЗУ с таблицей.

А именно…
Теперь возможна лёгкая дешифрация таких команд, как:

+ Коды сложных и редких команд
Тем самым, так как код в IA заносится абсолютно синхронно с кодом команды, повышается эффективность дешифрации.
И удивительно то, что комбинаторно получается не так уж и сложно для полной выборки x80-команд. Вполне реализуемо привычными микросхемами ТТЛ номенклатуры.
Хотя (в неопубликованном) эмуляторе у меня целая свистопляска с декодированием этих команд.
(В том аппаратном дизассемблере я не мог дешифровать все эти операции.)
Надо ещё чуток протестировать и пересмотреть, может вентили можно некоторые выбросить.

Глаза боятся, а руки делают…
Теперь в Verilog нужно упростить case-блок с адаптацией под схему, так как я тупо его портировал с эмулятора не включая мозгов…

В итоге, для реализации x80 в концепции принципиально ничего не мешает.
Лишь добавить статусный регистр под режимы Loop-Wait-Skip.
В частности, в Verilog нужно построить полный case со всеми командами и не париться по поводу их дешифровки.
Основная проблема сейчас - регистровый файл и стековые операции.

P.S.: Фокус не в том, что гордость не позволяет мне довериться Verilog-синтезу. А просто интересно самому переварить всю комбинаторику. А то с тем JavaScript-эмулятором я наворотил столько, что даже отладчик еле помогал. Потому тупо copy-paste всё переношу.
А оказывается, сам эмулятор можно оптимизировать, выбросив ряд switch-case и упростив некоторые ленивые выражения местами, стоит лишь на логику посмотреть с уровня аппаратных вентилей…

#275
0:00, 29 окт. 2019

Правкa концепции
Если Вы помните, сам «x80» задуман как линейка от 8-битного до 32-битного процессоров.
Если Intel накостыляла своими «AX» -> «EAX» -> «RAX», то в «x80» имена регистров и указателей не меняются от разрядности к разрядности…
Долгое время я ломал голову над тем, как должен трансформироваться машинный код при переходе от 8 бит к 16 или 32 битам.
Схема «Читалки» способна считывать лишь 8-битную константу в ID и длина инструкции может иметь 1, 2 и 3 байта. А если идти терниями Intel, то константа должна тоже увеличиваться. А это сломает совместимость кода и осложнит его перенос между разрядностями!
Надо найти способ более гибкий и рабочий в любых условиях.

Эврика
В концепцию я ввёл указатель на параметры «PP» (Parameters Pointer), который должен адресовать таблицу параметров. Указатель поможет как переносить код, так и помогать его отлаживать…
Приведу набросок кода:

44 A4 4F      |MOV AL,[SP+79]  ; Регистр считывается из стека со смещением +79
44 A4 50      |MOV AL,[SP+80]  ; Если флаг использования параметров выключен, смещение +80
              |MOV AL,[SP+80_] ; Когда активен флаг параметризации, смещение считывается из таблицы
   A4 4F      |MOV AL,0x4F     ; Регистр загружается константой 79
   A4 50      |MOV AL,0x50     ; Если флаг использования параметров выключен, константа - 0x50
              |MOV AL,0x50_    ; Когда активен флаг параметризации, константа считывается из таблицы,
                               ; сгенерированной трансляторов автоматически из-за признака подчёркивания
   E9 4F      |CALL $+79       ; Вызов подпрограммы под относительному адресу
   E9 50      |CALL $+80       ; Если флаг использования параметров выключен, вызов произойдёт на IP+80
              |CALL Fn_80      ; Если активен флаг параметризации,
                               ; адрес подпрограммы может быть как абсолютным - для вызова API,
                               ; так и относительным - для внутренних вызовов

B8 FE 33 8F 61|MOV PP,0x3F61   ; Загрузка абсолютного адреса таблицы параметров в указатель PP
                               ; Инструкция довольно длинная и генерируется самим ассемблером
                               ; Так как PP выравнивается всегда до 16 байтов, последний ниббл
                               ; в адресации не используется и является набором флажков
                               ; для настройки самого PP. В частности, указывает разрядность самих
                               ; параметров и гранулярность адресуемой таблицы
Если в команде константа укладывается в диапазон ±79, то ничего особенного не происходит.
А вот при ±80…±99, если указатель PP активен, можно указать до ±19 - 40 параметров.
При этом, даже 8-битный x80 должен поддерживать и 16-битные параметры.

Естественно, классическое считывание параметра потребует некоторого времени. Внедрение кеша под параметры могло бы в перспективе решить проблему скорости чтения параметров. Однако, как я раннее уже заявлял, в рамках «классического x80» мною не предусматривается разработка и внедрение ни конвейера, ни кеша…
(С чего мне надрываться над узкими местами некоммерческого и исключительно любительского проЖекта?)

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

Так как предусмотрен Регистровый Файл (Контекст Процесса), то внедрение указателя PP абсолютно ничего не меняет принципиально и влияет только на концепцию общего плана с преданализом регистра ID и подстановкой значений…

Если у x86 код с разной разрядностью в узких местах содержит префиксы 0x66 и 0x67, он теряет обратную совместимость и раздувается в размерах.
Тогда как у меня, короче говоря, 8-битный и 32-битный варианты машинным кодом ничем не будут отличаться в размерах и командах принципиально. Лишь добавятся в «шапках» подпрограмм команды установки указателя PP и изменятся посредственные константы команд.
К тому же, иначе должна работать команда RET при активации параметризации и вместо непосредственного возврата из подпрограммы переходить в «хвост» подпрограммы для восстановления указателя PP…

На данном этапе саму поддержку Параметризации Машинного Кода в x80 вводить не буду.
Здесь лишь оставил заметку про возможную работу этих параметрических механизмов и кодирования команд, так как давно ломал голову над базовыми принципами портабельности кода в «линейке x80». И это - один из вариантов…

В #2 перечислены многие «Loop+» и «Wait+» комбинации, которые зарезервированы, но пока не имеют назначенной логики работы…
Таким образом, дополнительные архитектурные фишки процессора спокойно могут управляться через экзотические комбинации инструкций.
(Тот же вход готовности периферии Wait у контролера шины в остальное время может на программном уровне прослушиваться теми же экзотическими «Loop/Wait» комбинациями без обращения к какому-либо устройству…
Не знаю, для чего это может быть нужно, но так как x80 - именно CISC, то просто можно ввести эти фишки дополнительными инструкциями чисто ради прикола, так как те же SIMD в x86 своим набором и экзотикой по-любому кратную фору дадут где угодно!)

P.S.: Теперь можно снова заняться творческой работой и двигаться дальше, не отвлекаясь на проблемы переносимости кода.
Так как эта проблема могла бы перечеркнуть, в частности, всю архитектуру модуля выборки команд…

#276
0:08, 29 окт. 2019

Alikberov
> Parameters Pointer

А тебе не приходила идея вообще избавиться в процессоре от регистровой стопки, а считать регистровой стопкой последовательные ячейки памяти, адресуемой либо SP, либо дополнительным индексным регистром BP (Base Pointer)? То есть, чтоб любое обращение к регистру N фактически подразумевало обращение к ячейке [BP+N] или к ячейке [SP+N]  (в зависимости от какого-то бита-флага)?

#277
0:30, 29 окт. 2019

Dmitry_Milk
> А тебе не приходила идея вообще избавиться в процессоре от регистровой стопки,
> а считать регистровой стопкой последовательные ячейки памяти, адресуемой либо
> SP, либо дополнительным индексным регистром BP (Base Pointer)?
Этo уже было в 6502.
А так как я воспитывался на РАДИО-86РК, то придерживаюсь классики детства.

Вообще-то запустите эмулятор.
Он очень сырой и я им занимаюсь который год. В какой-то момент он перестал просто нормально работать.
Эмулятор долго запускается.

Сначала нажмите «Alt+T» для отображения регистров и дампа регистрового файла…
Понажимайте в нём последовательно «Alt+1»…«Alt+7» (цифры над алфавитом, не справа) и посмотрите на изменение в таблице команд…
«Alt+9» - режим «Loop», «Alt+0» - режим «Wait»…

Клавиша «F1» - пошаговое исполнение программы. Дизассемблер - справа. Розовое - метки отладки (клавиша «Break» их ставит/снимает) и если программа там застрянет, нажмите клавишу Break и продолжайте (F4 или F1)…
Клавиша «F4» - запуск на исполнение…

В общем, там представлена вся мощь идеи x80!
Правда, эмулятор гонет на чтении портов.
Система команд очень сложна (для меня).

P.S.: Там эти [BP+N] и [SP+N] в таблице просматриваются по нажатиям «Alt+1» и «Alt+4» соответственно…

#278
5:00, 29 окт. 2019
+ Основной набор системы команд x80
Видно, что и до z80, и до x86 далеко, так как не все команды имеются (концептуально).
Но сам x80 задумывался как промежуточный вариант между i8080 и i8086, исключая совместимость с z80.
Хотя, думаю, и этого набора из 122 команд вполне достаточно для реализации каких угодно программ в рамках отдельной платформы.
Страницы: 114 15 16 17 18 19
ФлеймФорумПроЭкты

Тема в архиве.