Evgeny_CD, Архитектор (08.11.2009 19:57, просмотров: 2427)
Быстродействущий симулятор: интересно, а так можно? Интерпретирующие симуляторы понятны, у них есть немало плюсов. Но, если нужно автоматически прогнать кучу тестов, да еще и с полной статистикой (например, число обращений к отдельным ячейкам ОЗУ, попытки обращения по невыровненным словам и пр.), то использование таких симуляторов затруднено. При сборе статистики и достоверной симуляции всяких шин их производительность - хорошо если 1 MIPS на современных писюках.
Причины этого понятны. Пусть у нас будет некий цикл. Из нескольких команд. Интерпретирующий симулятор берет команду, деводирует ее, и потом выполняет действия. С действиями все понятно, но вот повторение декодирования - несколько маразматично.
А что если сделать так:
Берем elf файл и парсим его, прежде всего находим все точки входа - куда может быть выполнен переход при нелинейном исполнении кода.
От этих точек разбираем содержимое памяти, составляем глобальную таблицу - адрес - последовательность С операторов, которые соответствуют действиям в этой ячейке. Причем сюда же включаем все действия по сбору статистики, отмечаем, в какие такты какие шины были блокированы и пр. Все генерится автоматом.
Делаем супер-файл, где имя функции - адрес ячейки, тело - та сама последовательность команд, и таблица перехода - с указателями на эти функции.
Делаем отдельный поток(и) - симулятор основной периферии: прерывания, таймеры, DMA. Этот поток учитывает данные от первого потока на тему блокировки шин и пр.
Делаем некий супервизор. PC на вектор сброса. Переход по таблице на выполнение кода в ячейке по адресу. Возрат. Проверяем состояние прерывание - если есть - идем на вектор, нет - по текущему PC. Отслеживание перехода на непонятные адреса, ексепшенов и пр.
Отдельный поток занимается логгингом. Статистика первым потоком сбрасывается в некий буфер в ОЗУ. Например, записями фиксированной длины. Логирующий поток записывает буфер в файл. Для такого дела не грешно выделить отдельный раздел на винче и форматировать его перед началом симуляции - чтобы писалось быстро. Потом это дело парсится и складывается в SQL базу для анализа.
Вся эта система автоматически сгенерированных файлов собирается в виде отдельного проекта - симулятор именно этой прошивки.
В моем понимании, несмотря на гигантский объем кода, который при этом получится, преимущества такого подхода будут очень даже:
* линейный код, с минимуом вызовов - должен хорошо обрабатываться современными процами
* скорость - думаю, для каких-нибуь 60 МГц ARM можно будет реальное время не только достичь, но и несколько превысить
* полнейшая статистика о работе программы - можно отпрофайлить вообще все: все времена, все ли куски кода выполнились, расход стека, глубины вложенности, ...
Скорость компиляции всех этих суперфайлов, конечно же, будет весьма низкая, но она производится один раз...
Кто что думает по теме?
)