ТЕМА: Аппаратный трассировщик для Марсохода

Неприятная ошибка в устройстве - everest.l4os.ru/sdram_test_failed/
Я уверен на 99,9% что ошибка моя, но хочется отбросить все сомнения.
Если кто-нибудь найдёт пару свободных минут и проверит, сто процентная ли повторяемость ошибки, то буду очень признателен.
Ну и не совсем понятно как отлаживать такое - похоже ошибка не в контроллере SDRAM а где-то в другом месте.

Удалено Автором

Удалено Автором

Удалено Автором

Вышла новая версия процессора с системой команд "Эверест" для платы Марсоход2.

О расширении системы команд можно почитать здесь - everest.l4os.ru/0xd0_second_edition/
О программе, с помощью которого тестировали расширение системы команд здесь - everest.l4os.ru/uptime/

SOF-файл с прошивкой, исполняемые файлы ассемблера для Windows и Linux, а так же несколько библиотечных функций и прмиеров можно найти в прилагающемся файле (Прошивка в директории firmware, там же небольшая подсказка о том как залить прошивку из командной строки).


Избегайте использования функции "7 - Show current task ID" - иначе придётся нажимать кнопки на плате для сброса устройства. Извините за неудобства - будет исправлено в одной из следующих версий.

Ну и конечно сделайте скидку на то, что предлагаемое устройство общается с внешним миром только посредством виртуального RS232, прокиного через USB - ни VGA разъём, ни плата расширения, в данной прошивке не задействованы. Проблема с нестабильной работой SDRAM тоже присутствует. Т.е. цель этой прошивки - исключительно тест расширения семантики инструкций из диапазона 0xd0-0xd7

Ну, кажись пока всё. Задействовано 66% ресурсов ПЛИС. Если ничто не помешает, то планирую в следующей версии прошивки показать некоторые элементы микроядра, например, поддержку многозадачности.

Спасибо уважаемому Ynicky за "Исходники компилятора lcc" .

Не могу сказать что компилятор уже готов, но что-то начинает вырисовываться. Наиболее близким процессором к моей системе команд мне показался PDP11, его и взял за основу. Задача по генерации кода оказалась совсем не простой. Даже приблизительно не уверен сколько займёт времени доведения компилятора до состояния, способного пройти тесты, которые идут вместе с компилятором.

Предлагаю следующее - в обозримом будущем устроить соревнование архитектур на Марсоходе. Используем несколько стандартных тестов и каждый автор предложит по одному тесту, который, на его взгляд, покажет преимущества именно его архитектуры. Результаты соревнований поместим в таблице. Уверен, это было бы круто и пошло бы на пользу всем.

p.s. Если моя версия компилятора заработает, то создам новую тему, а эту тему попрошу закрыть.

А тесты должны быть для компилятора?
Анализироваться будет плотность кода или ассемблерный текст?
А как насчет занимаемого объема аппаратуры, частоты работы процессора
и разрядности?

Николай.

Ynicky пишет: А тесты должны быть для компилятора?

Для начала тесты из папки \lcc\tst
Хотя, можно сделать отдельный тест - простая задача, которую каждый разработчик вручную оптимизирует под свою архитектуру.
Т.е. изначально задача показать все лучшие стороны своих разработок. Создадим отдельную тему для этого и там совместно согласуем условия "соревнования". Может быть ещё кто-то присоединится.

Ynicky пишет: Анализироваться будет плотность кода или ассемблерный текст?

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

Ynicky пишет: А как насчет занимаемого объема аппаратуры, частоты работы процессора и разрядности?

Обязательно и по этим параметрам тоже будем соревноваться. Правда Leka тут внёс коррективы. Поначалу я хотел предложить конкурировать на разных полях - я делаю 32 бита, Ваш процессор 16-битный, а Leka поначалу собирался сделать минималистическкий 8-битный процессор. Теперь всё поменялось. Например, по количеству используемых логических элементов я уже проиграл, но всё равно готов участвовать в таком соревновании.

Думаю что здоровая конкуренция при взаимоуважении может пойти на пользу всем. Во первых, таким образом мы можем заявить о своих проектах и привлечь внимание. Во вторых, это будет дополнительным стимулом развивать свои разработки. Логично?

Предлагаю следующее - в обозримом будущем устроить соревнование архитектур на Марсоходе.

Я за, из "спортивного интереса".

Компилятор lcc это нечто, что трудно описать простыми словами. Несмотря на некоторую схожесть моей архитектуры с PDP11, отличий намного больше, поэтому пришлось глубоко разбираться с принципами построения md-файла и долго долго отлаживать. В общем, пришлось с чистого листа писать свой md-файл, используя другие md-файлы в качестве справочников и источника вдохновения.

Отдельно стоит сказать о передаче параметров в функции. В каждой архитектуре своё соглашение о передаче параметров и это очень важный момент. Например, параметры могут передаваться через стек или в регистрах или через стек с использованием фрейма вызова. Я до конца не определился как лучше и оптимальнее передавать параметры. Пока склоняюсь к тому, чтобы первые три аргумента передавать в регистрах, а остальные в фрейме вызова. Но вопрос ещё не решённый. Некоторую пикантность добавляет факт, что архитектура не поддерживает индексацию с отрицательным смещением. Т.е. повторить как в x86-32 не получится - там указатель стека в определённый момент копируется регистр BP, а затем BP используется для обращения и к аргументам функции (положительное смещение), так и к локальным переменным (отрицательное смещение). Поскольку инструкций с отрицательным смещением у меня нет, то придётся как-то выкручиваться. В самом худшем случае, если ничего оптимального не придумаю, придётся расширять систему команд с добавлением отрицательных (со знаком минус) смещений.

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

Пока что lcc делает это так (альфа версия, которую нельзя показывать):

И вот это всё надо оптимизировать оптимизировать оптимизировать путём исправления MD файла.