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

[Lethargeek]

Внутрь тела перейти сложнее, потому что надо получить адрес нужной итерации.

а что сложного в его получении? из таблицы адресов, например

[Advertiser]

[Bolt]

а что сложного в его получении? из таблицы адресов, например

Можно и так, конечно.

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

Bolt, с аппаратными циклами сбрасывать конвейер вообще не требуется, поскольку видя совпадение PC с адресом последней инструкции цикла, мы уменьшим на 1 счётчик и если он не нулевой, просто загрузим в PC из другого регистра адрес его начала, а не PC+1.

Вариант нулевой. Конвейер как бы есть, но прогоняем по нему инструкции по одной. Самый наипростейший вариант, но и самый медленный.

Вариант первый. Грузим в конвейер с одной стороны, забираем с другой, на каждом переходе ждём N тактов для заполнения. Вариант простой, но потеряется много тактов, особенно на коротких циклах.

Вариант второй. Делаем быструю djnz для коротких циклов, которая будет работать без дополнительных тактов. Вариант чуть сложнее в реализации.

Вариант третий. Делаем предсказание переходов. Плюс один блок памяти, сотня-другая ячеек в ПЛИС, но выигрываем в скорости на переходах. Вариант достаточно сложный, если заморочиться с алгоритмом предсказания. Но djnz так же выполняется, как и раньше, пусть даже за один-два такта.

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

[andrews]

Но что делать с прерываниями внутри цикла? Какой адрес возврата сохранять в стек? Какое значение читать из регистра-счётчика (оно будет меньше, чем должно быть для текущей выполняемой инструкции)? Как перегружать поток при выходе из цикла?

на прерывание завести что-то параллельное, запретив вложенные прерывания? Конечно не полный параллелизм, а до завершения циклов. Или делать останов до завершения обработки прерывания. Если только нет недопустимых инструкций и прерывания при недопустимом обращении к памяти(порту).

[Bolt]

Так...

Вот смотри. Есть у нас "конвейер". Допустим, на 5 тактов. Я понимаю как это сделать, и как сделать LoopCnt, но я не понимаю как выгребать из разных заковыристых ситуаций.

Выполняем длинный кусок без ветвлений.
Когда на выходе PC, на входе PC+4.
Если прилетело прерывание - что сохранить в стек?

Цикл из одной инструкции. Или из двух. Когда выполняем PC, на входе PC или PC-1. Что сохранять в стек?
В теле цикла используется счётчик. Выполняется инструкция на выходе конвейера, но счётчик-то уже на 4 уменьшился.
А тут ещё и прерывание. Что сохранять в стек? А что делать с тем, что уже выбрано? Что делать с счётчиком, который уже уменьшен?
Сохранять в стек адрес следующей инструкции, то есть которая на предпоследнем этапе? А если счётчик ушёл в ноль и выбрана ещё одна инструкция после цикла?
Ну сохранили адрес предпоследней, то есть инструкции в цикле, которая единственная, а счётчик уже обнулён. Куда возвращаться и что делать? Прокрутить цикл ещё 2^32 раз? Предусмотреть ещё один флаг?

Не, ну можно, например, доделать что уже попало в конвейер, потом уходить в прерывание. А в конвейере уже начался новый цикл.
И теперь это всё на HDL, плз.

Я, наверное, тупой, раз не понимаю как такие очевидные вещи делаются.

Регистрам Loopcnt - нет.

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

Тут другая проблема актуальна.
Выбираем 5 инструкций. Но 3 выбраны, и это джамп, а 2 уже уползло в запретную страницу, и они уже не понадобятся. Это как разруливать? Запретить программисту располагать код ближе, чем на 5 байт к концу страницы?

[b2m]

Если прилетело прерывание - что сохранить в стек?

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

[blackmirror]

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

[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-битных команд

[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 - "не префикс", собираем эти биты вместе, далее из таблицы вытаскиваем длину префиксов, и адрес таблицы длин для опкодов.