[fpga_dev 11]

Не ну эмулятор PDP-11 на ФОРТЕ это сильно. Для полноты картины над всем этим не хватает ЛИСПа 🙂 Но все конечно можно сделать, не очень понятно только зачем.

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

[RobFPGA 93]

32 minutes ago, fpga_dev said:

Но все конечно можно сделать, не очень понятно только зачем.

Зачем?   Это основной вопрос в строительстве своих процессоров в FPGA ...

[fpga_dev 11]

47 minutes ago, RobFPGA said:

Зачем?   Это основной вопрос в строительстве своих процессоров в FPGA ...

Справедливости ради, свои процессоры бывают нужны. Например я знаю конкретный продукт который можно купить в магазине в котором стоит самодельный RISC-V со слегка  расширенной системой команд и крутит там ядро системы и делает это лучше чем MicroBlaze. Или другой продукт в котором весьма экзотический проц ускоряет TLS handshake. Итд.

Основной вопрос это про шашечки или ехать. В большинстве случаев есть готовые решения и грех ими не воспользоваться.

[yes 23]

On 12/2/2025 at 10:30 AM, Alex163 said:

Кто-то где-то заметил что хорошо бы в стек возвратов так же автоматически прятать другие регистры, вместе со счётчиком команд... но он не упоминал SPARC

В системе Risc-V счётчик команд при вызове подпрограммы ведь не загоняется сразу в стек, а сохраняется в одном из регистров, это выглядит более разумно и это навеяло идею переключать при вызове половинки набора регистров а не скрывать сразу половину.

 

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

а для прерываний всегда держится одно свободное окно, то есть 16 регистров

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

оно конечно развлекает, но практически скорее гемор, чем ускорение

--------------

RISC-V как раз решили на такое вот все забить сделать все тупо, как в старых МИПСах (я не знаю, что там в новых - может сохраняется). а уж быстродействие пусть выжимает разработчик микроархитектуры, что куда прятать и какие теневые регистры заводить - ISA не про это.

ведь если сравнивать не то что с PPC, а даже с ARM-ом - RISC-V-тошная ISA выглядит тупой и примитивной, но тем не менее ядра RISC-V вполне на уровне Cortex-A7x работают...

---------------

btw: классические CISC-и начиная с 8080 (?) 8086 прячут на стек не только PC но и флаги

[Alex163 0]

On 12/2/2025 at 5:48 PM, fpga_dev said:

эмулятор PDP-11 на ФОРТЕ это зачем я имел в виду простенькую FSM

- там в "j1" ведь не такой уж настоящий Форт, просто инструкции очень быстро оперируют со "своим" небольшим стеком данных, применяя АЛУ

в FPGA много всяких самодельных FSM ведь будет в любом случае... так что и для выборки (из внешней памяти) и разборки PDP-обрАзной команды конечно будут автоматы низшего уровня

[RobFPGA 93]

5 hours ago, fpga_dev said:

Справедливости ради, свои процессоры бывают нужны. Например я знаю конкретный продукт который можно купить в магазине в котором стоит самодельный RISC-V

Справедливости ради "самодельный RISC-V" это не свой процессор,  а своя реализация  "чужого" процессора ...

Я не спорю что процессоры в FPGA нужны.  У самого наберётся с полтора десятка различных реализаций.
Но надо различать application specific soft programing FSM  и  универсальный проц. общего применения. 
В втором случае основная сложность это не реализация самой "железки", а  наличие/реализация всего то что вокруг проца, в частности софт и дебаг.   

[0608 0]

Мне довелось за последние 10..15 лет сделать 8 версий своих софт процессоров. Разработка каждой версии заняла от полутора до двух месяцев. Это проектирование CISC-архитектуры, создание системы команд, аппаратная реализация в FPGA на verilog, разработка анализатора синтаксиса и транслятора на Python (или C++) с выпуском mif-файла, а также программирование на C# обмена данными с ПК. Чтобы вести этот обмен к софт процессору добавлен аппаратный узел UART на 115200 бит/с с прямым доступом к памяти. У меня крайняя версия получилась небольшой, с 8-разрядным данными и  с 12 mips при генераторе 50 МГц.  Для многих задач хватает, а для сложных использую NiosII. Свои софт процессоры проектировал в перерывах между основными проектами.

При разработке системы команд предварительно моделируйте её вручную с карандашем и резинкой на тестовом алгоритме, например, на алгоритме пузырьковой сортировки или другом, близком к целевому.

[yes 23]

а кто-нибудь LLVM осилил? чисто из любопытства спрашиваю. я в личных проектах пытался, но так, чтобы не мелкий патч, а свою систему команд, разобраться не смог.

в начале карьеры gcc патчил - но там старшие товарищи показали, как исправлять и я тупо копи-пастил. и опять же не своя архитектура, а чтобы замазать ошибки в RTL 

------------

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

[RobFPGA 93]

3 hours ago, yes said:

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

Именно так что немного.  А  вписывается по серьёзному в компилятор/софт требует немалых ресурсов и в большинстве случаев не оправданно ни по времени ни по деньгам.