[Нетленка] Изящная идея по симуляции кода для любых процессорных структур. Быстрое исполнение (симуляция), быстрое создание framework. Пусть мы решили сделать новое процессорное ядро. Гениальное :) И мы даже уже придумали asm и мнемоники его гениальных команд. Надо бы написать прогу, и исполнить ее в каком-нибудь симуляторе.
Логично выглядит идея симульнуть HDL ядра. Это если он есть :) А унас его пока нет. Нет даже бинарных опкодов - мы пока не придумали как будем кодить наши мнемоники.
Можно сделать архиктурный симулятор. Но зачем? [буханка и троллебус].
Пишем кучу функций. Каждая равна мнемонике. В качестве параметров ей передают указатели на операнды мнемоники. В виде текстовых констант.
Есть оценка времени исполнения каждой команды в виде количества тактов. Возможно, переменная, в зависимости от операндов.
Делаем два массива памяти.
Один - типа FLASH - там элементами являются структуры
* казатель на функцию-мнемонику.
* указатели на ее операнды, по числу операндов.
Один - типа ОЗУ - байты, полуслова, слова.
Индексы массива = реальному адресу ячейки в адресном пространстве симулируемого ядра.
Еще могут быть служебные сруктуры по каждому адресу - счетчик обращений на чтение и на запись и т.д.
Все расчитано для симуляции на 64 битной машине, память не экономим в пределах разумного - как описано выше, можно и 100Мбайт памяти на целевом ядре насимулировать, отдав несколько гигов ОЗУ на инструментальной машине.
Берем asm сорцы. И "компилим" их
/* asm мнемоника, операнд, операнд, операнд */ __мнемоника (указатель на операнд, указатель на операнд, указатель....);
Есть счетчик тактов. Который инкременится по результатам отработки каждой функции-мнемоники.
Есть PC, который указывает - какой индекс массива FLASH выбираем. Есть SP.
Есть высокоуровневый поведенческий симулятор контроллера прерываний и DMA. Можно и другой периферии. Есть таблица соотвествия - как вариант: каждый второй "такт" - такт работы DMA. каждый третий - контроллер прерываний. Так досигаеся некоторая синхронность работы блоков.
Код симулятора лучше сразу разложить на потоки - чтобы ОСька могла исполнять параллельно.
В результате очень быстро создаем среду для симуляции ядра и некоторого набора периферии. Достаточно точную для этого шага.
Нашей системе можно скормить elf код после компилера и линкера. Разборщик elf и дизасм.
В итоге можно отлаживать код хоть для уже существующийх архитектур, хоть для свежепридуманных. Хоть ручного происхождения, хоть "компиляторного".
После обкатки свежепридуманной архитектуры на тестовых примерах, ее допиливают и повторяют цикл сонова.
По итогам выбираем набор команд под целевую задачу и занимаемся HDL кодингом.
По равнению с лобовым бинарным симулятором получаем значительное ускорение - команды декодировать не надо.
Вообще получаем невероятную гибкость и легкость на этапе верхнеуровневого проектирования.
Для всех существующх архитектур и их тулчейнов подходит без проблем.
Аналоги подхода мне неизвестны.
Критика?
-
- Версия 2.0 идеи. Упрощенная и улучшенная. Evgeny_CD(522 знак., 03.02.2017 02:32)
- Есть, конечно, один нюанс :) Если компилеру подсунуть файл с 100м строк (по 1 элементу массива в строке), то это может превысить формальные лимиты единицы компиляции, да и собирать такой проект компилер будет непонятно какое время :) Но мы не Evgeny_CD(379 знак., 30.01.2017 23:40, ссылка, ссылка)