Ядро с 32 битами и виртуализацией

[blackmirror]

Bolt, по поводу разруливания заковыристых ситуаций основное соображение такое:
Прерывание нужно отправлять в конвейер как обычную инструкцию(запретив при этом другие), нет смысла ради него что-то бросать, поскольку быстрее в прерывание мы не попадём.
А вот при исключении конвейер нужно очистить, что сильно упрощается, если инструкции что-то записывают только на последней стадии. Всё, что меняется на предыдущих стадиях придётся тащить через конвейер, чтобы при исключении иметь возможность восстановить состояние.
А вот для доступа в запрещённые страницы придётся снабжать буферные регистры тегами, сигнализирующими о такой ситуации, чтобы исключение возникало, только если эти данные действительно потребуются.
Это всё соображения с точки зрения программирования. Не знаю как, видимо это случилось не сразу, но разработчики смогли заставить работать аппаратные циклы у монстра, выполняющего до 4 скалярных + 4 векторных инструкций за такт (векторные регистры по 64 байта, есть инструкции выполняющие по 32 умножения для double или 128 для float). Правда переставлять инструкции он не умеет и если хоть одна чего-то ждёт, тормозить будет весь конвейер, в общем программировать его тот еще ад.

[Smalovsky]

Мне понравилась ветка Ynicky.
https://zx-pk.ru/threads/31254-yadro...=1#post1041654
https://zx-pk.ru/threads/31254-yadro...=1#post1041762
Где он предложил для замены z80 новую RISC-архитектуру. Корнечно, я не настаиваю на этой идее, что она самая правильная, но считаю её хорошей альтернативой. Может, не цепляться за комманды z80,а сделать RISC-архитектуру наиболее подходящую для эмуляции z80? Что-то подобное было реализовано исторически в амиге, где на смену м680000 пришёл поверписи. Можно сделать такую RISC-архитектуру, которая напоминала бы своими подходами z80 для удобства программистов переходящих с z80, но не отягощённую повтором специфики z80 точь в вточь. Главное условие - хорошая эмуляция z80 и удобство перехода на неё программистов привыкших к z80.
Для начало можно обкатать процессор предложенный Ynicky. Посмотреть, что можно усовершенствовать, а что убрать. Хотя я заметил, что процессор Ynicky не имеет каких-то подходов общих с Z80. Это создаст трудность перехода на него у программистов привыкших к z80.

Прочёл док на процессор Ynicky. Недостаток - раздельня память комманд и данных. А для компьютера надо общую память для комманд и данных. Поэтому для использования этого процесса необходимо подкорректировать архитектуру в сторону общей памяти комманд и данных.

[Bolt]

Прерывание нужно отправлять в конвейер как обычную инструкцию

Во, точно.

Не знаю как, видимо это случилось не сразу, но разработчики смогли заставить работать аппаратные циклы у монстра, выполняющего до 4 скалярных + 4 векторных инструкций за такт (векторные регистры по 64 байта, есть инструкции выполняющие по 32 умножения для double или 128 для float). Правда переставлять инструкции он не умеет и если хоть одна чего-то ждёт, тормозить будет весь конвейер, в общем программировать его тот еще ад.

Вот именно, не сразу. А я только начал.
О какой архитектуре идёт речь?

Это всё соображения с точки зрения программирования.

С точки зрения программирования нафантазировать можно что угодно, а вот реализация этих фантазий может быть очень сложной.
Как получилось с eZ80 - а давайте по опкоду посчитаем длину инструкции. Простая вроде бы задача. Ага, щаззз! Кстати, можешь сам попробовать, там интересно

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

Мне понравилась ветка Ynicky. Где он предложил для замены z80 новую RISC-архитектуру.

Мне тоже понравилась, но не только сама идея, она прям напрашивается, а ещё то, что она была доведена до рабочего состояния.

Можно сделать такую RISC-архитектуру, которая напоминала бы своими подходами z80 для удобства программистов переходящих с z80, но не отягощённую повтором специфики z80 точь в вточь. Главное условие - хорошая эмуляция z80 и удобство перехода на неё программистов привыкших к z80.

Не надо удобства. Переходить на неё программистам не придётся.

Делаем RISC-архитектуру, которая способна работать как интерпретатор Z80. И пофиг на систему команд.
На эту архитектуру сверху наваливаем 32 бита. Как ни крути - получим нечто похожее на Z80. Пофиг на бинарную совместимость.
Пишем интерпретатор в командах этого RISC и запихиваем в ПЗУ.

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

Тут надо две картинки: "мы поставили процессор в процессор, чтобы ты мог программировать процессор, когда программируешь процессор" и "we need to go deeper..."

[Lethargeek]

Делаем RISC-архитектуру, которая способна работать как интерпретатор Z80. И пофиг на систему команд.

ничего не делаем, берём обычный арм, распределяем память на 8-битную спектрумовскую и 32-битную армовскую
каждому 8-битному опкоду в спековской памяти сопоставляем 32-битный опкод вызова процедуры в армовской
при перезаписи байта в спековской памяти (кроме одного спецзначения) изменяем и опкод процедуры
иии... всё, мы "расширили z80" на сколько нам угодно любых 32-битных команд

[Bolt]

Lethargeek, а потом в 128-м переключается страница иии... всё, надо копировать 64 килобайта?

А ещё перезапись байта меняет не только один опкод, а до четырёх инструкций сразу. Не знаю где об это можно споткнуться, но сам факт...

[Lethargeek]

а потом в 128-м переключается страница иии... всё, надо копировать 64 килобайта?

вот с чего бы? сопоставлены-то полные адреса

А ещё перезапись байта меняет не только один опкод, а до четырёх инструкций сразу.

ну и что? армопроцедуры могут это учитывать (они вообще всё могут лучше z80))

Не знаю где об это можно споткнуться, но сам факт...

ну вот, когда узнаешь, и приходи

[andrews]

Делаем RISC-архитектуру, которая способна работать как интерпретатор Z80.

она ценна сама по себе, потому что те ядра, которые бесплатно шли к Altera и Xilinx-ам как-то не пользовались особой популярностью для ретро-компов.

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

берём обычный арм

какой именно? 1-й, 4-й, 11-й. И разве разработчиков этих ядер волновала возможность реализации на них z80 и Spectrum-ов. Любое ненужное излишество это вентили, вентили, вентили. Вот люди в России не знают чем загрузить ранее приобретенную фабрику на 130 нм чипы и даже выбивают деньги на 65 нм под Эльбрусы. Так что если ASIC влезет в 130 нм то это низкая себестоимость. Потом я не согласен, что более сложная архитектура или архитектура "черного ящика" жизнеспособна. В любом случае это ограничит сферу ее применения. А так делать значит обрекать ее на жизнь недолгую и непопулярную. "Делай проще, дурашка" самый верный принцип! Можно и другие критерии для себя сформулировать и им следовать в разработке.

[blackmirror]

О какой архитектуре идёт речь?

Пока она находится на этапе изготовления опытных образцов и в интернете про неё кроме названия нифига нет. Что будет дальше тоже сложно сказать, может будет выпущена небольшая партия, а может примут решение перед этим что-то еще доработать. По частоте и пропускной способности памяти она конечно отстаёт от интела, по теоретической вычислительной мощности примерно сопоставимо, но всё зависит от задачи и степени её оптимизации. Кроме умножения матриц, которое очень полезно для нейронных сетей, там есть некоторые фичи присутствующие у видеокарт, к примеру внутренняя память делится на 32 банка и можно выполнять по 32 обращения каждый такт(элементы по 1, 2 или 4 байта). Интел в последних версиях процессора может читать по 8 независимым адресам, правда если будут кеш промахи это будет долго, у внутренней памяти в этом смысле есть плюсы. Реально данные поступят через 8 тактов, но если это учесть, то к примеру для ветвления по 3х уровневому дереву, можно получить среднюю производительность 1 дерево/такт. При этом для каждого узла читается по два весовых коэффициента и два индекса в массиве, затем читаются элементы массива, перемножаются и сравниваются, после чего выбирается левое или правое поддерево, ну а в финале выбирается лист с цифрой, которые должны суммироваться чтобы выяснить в какой момент нужно прервать цикл.

С точки зрения программирования нафантазировать можно что угодно, а вот реализация этих фантазий может быть очень сложной.

Нужно соблюдать баланс между возможностями аппаратуры и удобством программирования, последнее очень важный фактор для успеха любой архитектуры. У монстра к примеру DMA для полной загрузки шины требует выравнивания пересылок на 16 байт, а потом оказывается что нужно сдвинуть строки во внутренней памяти, чтобы избежать конфликтов банков и это удваивает объём кода и учетверяет время для его отладки.

Как получилось с eZ80 - а давайте по опкоду посчитаем длину инструкции. Простая вроде бы задача. Ага, щаззз! Кстати, можешь сам попробовать, там интересно

У меня был написан на ассемблере дизассемблер инструкций реального и защищённого режимов X86 включая MMX, но когда началось SSE2 с префиксами стало очень весело, и вот тут я это дело забросил. А для Z80 нам требуется пропустить все префиксы, те которые влияют на декодирование инструкции превратить в набор дополнительных бит, добавить опкод, после чего из таблицы мы должны получить длину. Можно решать эту задачу и параллельно, если число префиксов ограничено, то классифицируем все префиксы, при примеру 1, 2, 3 или 0 - "не префикс", собираем эти биты вместе, далее из таблицы вытаскиваем длину префиксов, и адрес таблицы длин для опкодов.

[Bolt]

она ценна сама по себе, потому что те ядра, которые бесплатно шли к Altera и Xilinx-ам как-то не пользовались особой популярностью для ретро-компов.

Не могу оценить её ценность, но скорее всего это в итоге будет специализированный микрокод. Для Z80 эмулятор с некоторыми допущениями сейчас занимает 2 килобайта.

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

А для Z80 нам требуется пропустить все префиксы, те которые влияют на декодирование инструкции превратить в набор дополнительных бит, добавить опкод, после чего из таблицы мы должны получить длину.

Да в Z80 всё просто, я про eZ80. У него не только префиксы меняют длину, но и внутренний режим. А режим переключается переходами с префиксом, уходом в обработчик прерывания, а ещё режим может восстанавливаться из стека. Вот на чтении из стека я сломался Не знаю, может и можно это отловить.

[andrews]

Для Z80 эмулятор с некоторыми допущениями сейчас занимает 2 килобайта.

а ядро сейчас в виде эмулятора или уже на fpga?

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

умножения матриц, которое очень полезно для нейронных сетей

все операции с матрицами и векторами используются и в манипуляциях с игровыми объектами и в 2d и в 3d, но это может быть и не внутри ядра, если игровое поле большое все-равно придется лазать по памяти. Тут "тяжелые" изображения сильно все усугубляют. Поэтому для "легких" нужно свой видеопроцессор разрабатывать, хоть с физикой, хоть без.