RZ80 - ZX RISC( POWER ZX) на спектруме

Выношу обсуждение ядра rz80 от Ynicky из темы https://zx-pk.ru/threads/31254-yadro...lizatsiej.html
Вообще, ядро rz80 это 32-битный риск-процессор, который на прямую не совместим с z80, так как имеет другую систему команд. Но есть возможность поддержки для кода z80. Это достигается тем, что часть регистров процессора может рассматриваться как регистры z80( с 32-го по 58 регистр), также младшее слово регистра флагов rz80 повторяет и расширяет регистр флагов z80, но система команд z80 эмулируется. Такой подход с эмуляцией команд z80 имеет свои плюсы:
- Не надо тащить реализацию старой восьмибитной системы команд в новое 32-битное ядро, что экономит хардварные ресурсы. (Пример для размышления: до сих пор поддержка старой 16 битной системы команд в новых процессорах Интел является головной болью, так как увеличивает стоимость и энергопотроебление)
- Отказ от кодов операций восьмибитной системы расширяет пространство кодов операций для 32-битной.
Примерное соответствие регистров z80 и rz80 в спойлере:

Скрытый текст

r32 ;B
r33 ;C
r34 ;D
r35 ;E
r36 ;H
r37 ;L
r38 ;F
r39 ;A
r40 ;I
r41 ;R
r42 ;IXh
r43 ;IXl
r44 ;IYh
r45 ;IYl
r46 ;SP
r47 ;PC
r48 ;B'
r49 ;C'
r50 ;D'
r51 ;E'
r52 ;H'
r53 ;L'
r54 ;F'
r55 ;A'
r56 ;IFF1
r57 ;IFF2
r58 ;IM

[свернуть]

Регистры флагов:
- z80 по битам s,z,-,h,-,p/v,n,c;
-rz80 младшее полуслово по битам s,z,y,h,x,v,n,c.

Видно, что в rz80 младшее полуслово регистров флагов повторяет флаги z80 с точностью до бита и расширяет неиспользуемые биты z80 новыми флагами.
Что мы имеем - новый 32-битный риск-процессор максимально приспособленный для выполнения кода z80, новые возможности с новой системой команд и расширенной разрядностью, устранение головной боли с реализацией железной совместимости.

Описание процессора в файлах в этом сообщении https://zx-pk.ru/threads/31254-yadro...=1#post1041654
Демонстрация кода эмуляции z80 в сообщении https://zx-pk.ru/threads/31254-yadro...=1#post1041762

ДЛЯ КОГО ЭТОТ ТОПИК

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

быстрый процессор и быстрый видеоадаптер в каком нибудь окне портов... но это получится не спектрум а какой-то другой компьютер... это как из "Запорожца" пытаться делать мерседес. отстаньте уже от него.

Не надо отставать! Раз он попал к нам в руки - надо экспериментировать. Тем более если за это нас никто не осудит и не засудит. Из "Запорожца" делать ничего не надо. Есть другие "заброшки" среди компьютеров. Из них надо делать. Это интересно и разработчикам и потенциальным пользователям. Аналогии с авто не уместны! Компьютеры могут существовать в различных формах - от чисто программных(классических эмуляторов) до разнообразных железных. Автомобили нет.

Цитата:

---

Сообщение от Smalovsky

Демонстрация кода эмуляции z80 в сообщении https://zx-pk.ru/threads/31254-yadro...=1#post1041762

---

даже сходу не придумаю, чем код эмуляции будет отличаться, если взять какой нить arm/mips/risc-v на мифический процессор

Цитата:

---

Сообщение от Smalovsky

Вообще, ядро rz80 это 32-битный риск-процессор, который на прямую не совместим с z80, так как имеет другую систему команд. Но есть возможность поддержки для кода z80. Это достигается тем, что часть регистров процессора может рассматриваться как регистры z80( с 32-го по 58 регистр), также младшее слово регистра флагов rz80 повторяет и расширяет регистр флагов z80, но система команд z80 эмулируется. Такой подход с эмуляцией команд z80 имеет свои плюсы:
- Не надо тащить реализацию старой восьмибитной системы команд в новое 32-битное ядро, что экономит хардварные ресурсы. (Пример для размышления: до сих пор поддержка старой 16 битной системы команд в новых процессорах Интел является головной болью, так как увеличивает стоимость и энергопотроебление)
- Отказ от кодов операций восьмибитной системы расширяет пространство кодов операций для 32-битной.

---

Плюсы мнимые и не стоят неудобства для программиста. Сам по себе дополнительный декодер восьмибитный будет копейки стоить, когда есть уже все нужные команды в какой-то другой кодировке и флаги обрабатываются корректно. В интелях не так было, а тут вполне сработает аналог армовской тумбы.

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

Цитата:

---

Сообщение от s_kosorev

даже сходу не придумаю, чем код эмуляции будет отличаться, если взять какой нить arm/mips/risc-v на мифический процессор

---

да хотя бы скоростью (в основном из-за аппаратной поддержки флагов)
хотя скорости кмк заведомо хватает и у "какого-нибудь arm/mips/risc-v"
даже на эмуляцию турбированных

И кто будет делать 32 битный комп на risc-v c эмуляцией z80? А здесь люди "уже в процессе".

Цитата:

---

Сообщение от s_kosorev

даже сходу не придумаю, чем код эмуляции будет отличаться, если взять какой нить arm/mips/risc-v на мифический процессор

---

Будет отличаться значительно. Например, регистры с 32 по 58 могут быть постоянно забронированы для кода z80, а с 0-г0 по 31 для 32 битного кода. Такое решение не потребует постоянного сохранения в стек регистров z80 при переключении с 8-битной программы на 32-битную. Ну и регистры флагов, опять же, аппаратно совместимы. Всё это позволяет на лету выполнять переход от 8-битного кода на 32-битный, и обратно. Новый процессор будет удобен для запуска 8-битных программ под управлением 32-битной ОС.

Цитата:

---

Сообщение от Smalovsky

Будет отличаться значительно. Например, регистры с 32 по 58 могут быть постоянно забронированы для кода z80, а с 0-г0 по 31 для 32 битного кода. Такое решение не потребует постоянного сохранения в стек регистров z80 при переключении с 8-битной программы на 32-битную. Ну и регистры флагов, опять же, аппаратно совместимы. Всё это позволяет на лету выполнять переход от 8-битного кода на 32-битный, и обратно.

---

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

Цитата:

---

Сообщение от Smalovsky

Будет отличаться значительно. Например, регистры с 32 по 58 могут быть постоянно забронированы для кода z80, а с 0-г0 по 31 для 32 битного кода.

---

Смотри, много регистров у процессора это как правило плохо, при реализации в желез плохо да и в целом, для сохранения контекста к примеру.
Специализированные регистры свободно заменяются ячейками памяти, а время доступа к онным, нивелируется кешами процессоров. Конечно время доступа не 0t (на простых ядрах, на сложных с спекулятивным исполнением может быть и 0t), но не при тех частотах, которые дают ширпотребные процессоры, вполне можно совладать с эмуляцией 3.5мгц процессора.

Цитата:

---

Сообщение от s_kosorev

Смотри, много регистров у процессора это как правило плохо, при реализации в желез плохо да и в целом, для сохранения контекста к примеру.
Специализированные регистры свободно заменяются ячейками памяти, а время доступа к онным, нивелируется кешами процессоров. Конечно время доступа не 0t (на простых ядрах, на сложных с спекулятивным исполнением может быть и 0t), но не при тех частотах, которые дают ширпотребные процессоры, вполне можно совладать с эмуляцией 3.5мгц процессора.

---

Тут всё норм. Этот процессор работает на 50Мгц и не должен быть слишком сложным и дорогим для реализации в ПЛИС. Надо понимать, что процессор не будет работать с ОС типа Виндовс и Линукс, с их процессами и квантами времени. Процессор, я так понимаю, рассчитан но ОС типа мс-дос, фридос или pq-dos. Это значит, что программе в 32-битном режиме будет дан полный контроль, в 8-битном режиме будет запускаться что-то типа среды выполнения, но она будет как отдельная программа. В общем тут ориентир на однозадачные ретро-ОС и ретропрограммирование без процессов и квантов времени.
Вообще, это всё для тех кто хочет что-то типа Амиги или 486-го под простой ОС но с уклоном в спектрум. Никакими современными Виндовс и Линукс тут не пахнет.