Comments 20
не нашел как прикреплять файлы
Создайте репозиторий/гист на гитхабе и укажите ссылку. Или хоть на Яндекс.Диск директорию.
На первый взгляд возникает вопрос "а зачем?"... Но потом приходит осознание что автору нравится этим заниматься, а это главное) а теперь к конкретике: как я понял система команд реализована собственная и компиляторов разумеется нет? Если компилятора нет, то есть планы реализовать?
P.s. на первой картинке схема больше похожа на сердце)
Ассемблер использовался для отладки, а над СИшным компилятором ведется активная работа (компилятор пишет напарник, и да, в комментариях угадали - я больше по аппаратной части). Горизонт думаю пару +- месяцев.
Важно, что ядро разрабатывалось без претензий на ПК, это контроллерный проект)
А почему без преддекрементной адресации? По особенностям Гарвардовской архитиектуры: доступ к массиву констант как?
Почти все варианты адресации можно получить, работая с выходными (относительно ядра) регистрами адреса (первый блок ISA). Т.е. перед любым обращением куда-либо можно предварительно обработать и обновить регистр адреса шины, по которой последует обращение. Для этого и сделаны доступными из программы все «системные» регистры. Отчасти такой подход усложняет компилятор, но сильно расширяет возможности, иногда экономит время выполнения, а главное позволяет выполнить главное условие Т.З. уместиться куда надо. Второй блок, содержащий команды перемещения — это скорее частный случай первого для облегчения процедур единичных обращений.
Доступ к массиву констант? Т.е. получить массив данных из памяти программ?
Если да, то предполагается, что перед началом выполнения основной программы константы загружаются в РОН А (A255<=16'd65535 команда 29), можно блоками по 256 значений (255 – это максимальный адрес РОН блока А: доступные адреса от 0 до 255). А из РОН блока А данные можно отправить куда угодно, например в ОЗУ с предустановкой начальной области ОЗУ (ATR<=16'd65535 команда 3 / расширение 1), регистра адреса блока РОН (ATA<=8'd255 команда 1) и последующим копирование с инкрементами адресов (RAM+<=A+ команда 6 / расширение 3). Таким образом массив констант можно записать и в разные сектора ОЗУ, предварительно указав целевой сектор 0 - 31 (MEM<=5'd31 команда 111). Из ОЗУ данные можно отправлять в режиме пословно, как с явным, так и с косвенным, или со смешанным указанием адресов, а так же в потоковом режиме (R(65535)=>P команда 13).
Пример: Загрузили массив констант в Х-сектор ОЗУ, в процессе выполнения основной программы, получили массив данных который сохранился в другой области или секторе ОЗУ, потоково отправили в периферийное устройство оба массива (например сопроцессор, или уникальный модуль для выполнения какой-то конкретной обработки), и дали команду на выполнение, и вернулись к основной программе и ждем флага или прерывания, выполняя основную программу.
П.С. прощу прощения м.б. сумбурный немного ответ вышел, просто много хочется рассказать но нужно придерживаться адекватного регламента)
Интересная статья. Мы сейчас тоже делаем ядро для микроконтроллера. Только в нашем случае архитектура Неймана с общей памятью команд и данных. Прерывания пока не реализовали, да и в целом до работающего ядра далеко.
Спасибо!!! Нейман сложнее (м.б. чисто в моем восприятии), а мне хотелось именно уместиться в целевую ИМС.
П.С.: интересно будет почитать про Ваш проект!
П.П.С.: В любом случае я планирую довести проект до удобоваримого варианта чтобы можно было отдать на растерзание людям ядро (уже) и компилятор. Скорее всего и ошибки есть и придется еще править ISA (сейчас далеко не первый вариант), но считаю, что правки уже нужно вносить, когда будет компилятор что бы была быстрая отладка
Есть же RISC-V, их много реализаций на любой вкос. Для чего люди делают свою?
В создании процессора самое главное не процессор, а оптимизирующий компилятор. Компилятор хороший сделать гораздо труднее, чем процессор.
Создать свой проц - это Мечта творческого технического специалиста. Такая же, как - создать свою операционную систему. И если полететь на Марс ему не грозит даже в самых смелых грезах, то такая мечта выглядит осуществимой.
Однако, вы уже поняли к чему я веду. Реализовать даже одну мечту одному - очень сложно, об этом -ниже. Реализовать же вторую мечту ему же- практически невозможно. Допустим, вы сделали и отладили проц. Теперь под него нужно сделать операционную систему, компилятор и отладчик. Поскольку писать проги будете не на самом устройстве, нужен еще эмулятор устройства на ПК, совместимый с отладчиком. Ну, понятно, загрузчик программы в устройство, потому как флешка более подходит для финального варианта. а до того будет 100млн итераций отладки.
это я к чему? система команд мне кажется недостаточно проработана. лучше бы использовать какую-то из стандартных существующих процов. с одной стороны тогда можно было бы сравнивать промышленные образы с вашей поделкой с точки зрения производительности. с другой стороны, можно реиспользовать сущ. ПО. на низкой частоте работает куча процов арма. вот вариант.
стандартные битовые операции реализованы не все: нужно и, или, not, xor, битовый сдвиг влево, битовый сдвиг вправо. без этого криптографию - не реализовать. криптография нужна в ssl/tls, что в свою очередь сейчас нужно для всех сайтов в инете, потому как обычный http сейчас считается небезопасным.
не увидел выхода не то что на видеокарту, даже на обычный мини-дисплей. вы предлагаете под это дело занять все свободные gpio?
аппаратные прерывания любого современного проца - стандартны: деление на 0, ошибка доступа к памяти, прерывание отладки и др. не увидел поддерживаемого списка таких прерываний.
не увидел потуг на мультизадачность. зачем вам однопоточный проц? любой arm на 33мгц делает в этой части ваш проц.
я не убиваю вашу мечту. самому было бы интересно. но так понимаю, вы больше по аппаратной части и над программной составляющей (что надо то?) сильно не задумывались.
1. Так если посмотреть мое самое ТЗ я и хотел максимально странно все)) (Шутка)
2. Во-первых, Вы совершенно правы, как я и писал память программ и ОЗУ вполне конкретные +-, основной тезис: что доступна шина 16 бит (мало ножек ПЛИС + опять же по доступности ИМС памяти) и память медленная. Старался оптимизировать плотность, и это далеко не первый вариант ISA, и да, скорее всего можно много что улучшить в принципе, но пока вышло вот как вышло… эх
3. Это не баг это фича, идея и родилась от того, что бывают случаи, когда можно вообще копошиться в областях РОН (для несложных задач управления чем-либо с небольшой обработкой), а в ОЗУ вообще не лезть. В таких случаях можно отказаться и от внешней ИМС ОЗУ, и освободить внутреннюю память ПЛИСа для нужд периферии.
П.С.: кстати пытаемся реализовать в компиляторе – подход что он после анализа программы может влиять на ядро, отключая неиспользуемые команды области и тд.
С Регистрами не совсем так - они выглядят как РОН с точки зрения компилятора и программы, но по природе это сектора интегрированной в ПЛИС ОЗУ, реализовать 512 РОН в рамках целевой ИМС думаю невозможно.
ВАЖНО в таблицах системы команд, когда есть условная запись «A255 что то там B 254» действие 253, это условная запись необходимая что бы просто отразить числа в столбцах opr1, opr2 т.д.. Т.Е. регистры 253, 254, 255 ничем не особенные. И вообще в таблице индексы числовые просто указывают на максимальный доступный адрес, иногда адрес «типа» меньше на единицу или две, чтобы команду можно было представить в числовом формате. (Возможно непонятно, лучше дам комментарии по конкретной команде, если нужно)
4. Регистровый файл разбит именно по той причине, что физически он состоит их двух банков реальной ОЗУ ПЛИС и при операциях использует скрытые реальные регистры А, B и result, ведь все операции только на РОН.
5. В точку, спасибо попробуем добавить!
6. Про шины согласен, мультиплексирование можно добавить, но это будет внешняя структура, пока запустить хочется все на целевой микросхемке, да и в мелких проектах можно от много отказаться, как я и писал выше.
7. Да! сил тратится не меньше уж точно! Правда на разработчика компилятора свалился не супер-сырой проект железа, не первая итерация, плюс, что мог отлаживал своими силами ассемблером и простыми программками, а также море симуляций. Конечно, ОС кипит, да и пинаю его постоянно – что бы работал)
Все три приведённые мечты могут быть осуществимы, первые две даже коллективом меньше 10 человек.
Под х86 гайдов по написанию ос как грязи, есть COSMOS, который сразу загрузчик поставляет и позволяет писать на С#. Я за день написал простенький REPL для RTOS, жалко Космос компилируется только в х86, так как там используется такой ассемблер.
По написанию компилятора на LLVM тоже есть гайды и под свою архитектуру тоже. Он позволит компилировать сразу много языков в байт-код процессора.
Полететь на Марс, хоть и кажется сложным, но послать туда беспилотный зонд уже давно могут так что задача не совсем невыполнимая.
Кстати в RISK нет прерываний.
Для максимально простенького ядра некоторые вещи выглядят по меньшей мере странно.
Система команд плохо упакована, плотность кода на первый взгляд хуже чем у сопоставимых платформ. Для малых ядер обычно это важный фактор, только если ваше решение оптимизировано под конкретную внешнюю память, это можно считать несущественным.
Ко многим командам есть вопросы. Например почему длинный прыжок (up2M) с суммированием адреса? Для короткого это логично, но для длинного очень неудобно, указатели надо будет пересчитывать для каждого вызова.
Огромный регистровый файл, не очень понятно как компилятор должен его использовать? Только как регистры общего назначения великоват, как куча или стек маловат. Может быть просто как быструю память, но не проще ли тогда сделать малое число регистров и быструю память отдельно? Для регистров 253, 254 и 255 есть специальные инструкции, они прямо просятся в отдельный маленький файл регистров.
Регистровый файл разбит на 2 части, но не совсем понятно зачем. Они не работают как два контекста вне и внутри прерывания, они непонятно зачем раздувают систему команд, да ещё и не симметричны с её точки зрения.
Насколько я понял, есть скрытые регистры. Как минимум PC и LR. Добавьте их в регистровый файл, создатель компилятора скажет вам спасибо.
У вашего ядра наружу выходят целых 4 шины. Какие-то поменьше, какие-то больше 40 ног. Это отсекает огромное количество маленьких и средних ПЛИС с количеством выводов менее 100, для которых обычно такие архитектуры и используются. Если будете мигрировать на маленькие корпуса, попробуйте использовать мультиплексированную шину, либо перейти на QSPI/CSPI RAM или HyperRAM.
Не владею статистикой, но рискну предположить, что на написание компилятора под новую уникальную архитектуру обычно уходит больше усилий, чем на разработку железа. Будьте готовы поддерживать плотную обратную связь с вашим разработчиком компилятора и идти на архитектурные изменения по его просьбе.
Не владею статистикой, но рискну предположить, что на написание компилятора под новую уникальную архитектуру обычно уходит больше усилий, чем на разработку железа.
Как вариант задействования возможностей реализованого решения и его оценки можно предложить на первом этапе сделать вариант Forth (Форт) как лучшую "замену" ассемблера.
P.S. Процессор Forth J1 в FPGA плате M02mini https://habr.com/ru/articles/523348/
Forth CPU. Что это такое? (Часть 1) https://habr.com/ru/articles/133338/
Forth CPU. Что это такое? (Часть 2) https://habr.com/ru/articles/133380/
144-ядерный процессор Чарльза Мура поступил в продажу по $20 https://habr.com/ru/articles/133291/
Forth-процессор на VHDL https://habr.com/ru/articles/149686/
Тред обсуждения - Как сделать форт-процессор 2022
http://fforum.winglion.ru/viewtopic.php?f=3&t=3322
У автора этого топика сейчас в разработке компилятор из Си в код команд своего процессора (тема на этом форуме и упоминание на gamedev.ru)
Очень интересная статья. Спасибо. Кто из RTL-щиков не писал свое ядро по вечерам для фана))
Я в свое аремя правда не стал мучиться с новой системой команд и взял за основу ARM-овскую, что избавило меня от головной боли с изобретения комптилятора. Можно было брать готовый и сразу тестить. Но у меня и единомышленников не было на кого можно было возложить эту задачу.
В общем респект, держите в курсе своих успехов.
Простое CPU ядро на ПЛИС