Lattice Mico8 Soft Processor, поделитесь опытом Опции

[sonycman]

Доброго времени суток!

Недавно начал осваивать ПЛИС, и потихоньку добрался до имплементации простенького софт процессора.
Остановился на лэттисовском Mico8, как наиболее доступном, как мне показалось.

Несколько удивил некоторый аскетизм среды разработки, в том смысле, что по умолчанию я не нашёл возможности посмотреть получившийся код, который будет исполнять процессор.
Так ещё до кучи оказалось, что и отладка JTAG для Мико8 отсутствует как класс.

В общем - чёрный ящичек такой, никому не покажу, что и как

Порылся в доках (с компилятором GCC я практически не знаком) и нашёл таки, как включить файл карты памяти линкера (опция -Map) и ассемблерных файлов, которые генерирует компилятор (опция -save-temps).
Стало немного понятно, как выглядит код и чем будет заниматься процессор.

Ещё научился запускать утилиту objdump.exe, с помощью которой можно дизассемблировать исполняемый файл проекта целиком и увидеть машинные коды полностью вместе с библиотечными функциями.
Правда, без библиотек Cygwin эта утилита не запускается, пришлось закинуть её в директорию Cygwin... а причём тут последний, зачем он мне нужен под Windows, не понимаю?
Это что получается, компилятор и все его утилиты работают под эмулятором?

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

Ещё пара не очень приятных впечатлений.
У процессора отсутствуют коды команд нецикличного сдвига битов.
Соостветственно для выполнения операций сдвига >> и << (даже на единичку) генерируются вызовы функций, где операция выполняется в цикле с помощью команд цикличного сдвига.
Неужели не хватило места для имплементации простейшего сдвига?

Стек прерываний почему то у процессора отдельный от общего стека. Причём нигде не нашёл задание его размера.
К примеру, при выборе средней модели памяти (64к) стек прерываний задаётся равным 512 байтам, и точка.
Кто так решил, и почему я должен отводить под него львиную долю памяти?
Слава богу, что есть галочка MICO_NO_INTERRUPTS, где вместе с прерываниями удаляется и этот стек...

[yes]

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


1) если интересуетесь процессорами, то нужно освоить софт для хоста - это линуксные утилиты gcc, gdb, llvm, qemu и т.д. так как виндовс это убогая система для офисных работников, то ни в проф. сообществе не в среде опенсорсников оно не используется и соответственно код для винды не разрабатывается (некоторые уже готовые продукты портируются). чтобы как-то скрасить убогую виндовзную жизнь были придуманы костыли типа cygwin, msys и т.п. но в родной среде все это работает гораздо лучше

2) также советую посмотреть opencores.org (например проект openrisc). а если VHDL не вызывает нервного тика, то LEON3 от GAISLER-а

3) аппаратные стеки у минималистических процессоров - весьма частое дело (про микрочип pic12 pic14 pic16 слышали?).
это делается чтобы ресурсы ПЛИС сэкономить. а отсутствие некоторых инструкций может вызвано отсутствием свободного места в формате команды - я так понимаю, что для тех сдвигов понадобится второй операнд на 3 бита? видимо, на этом авторы сэкономили - опять же таких сдвигов я так сразу ни в одном коммерческом 8-ми битнике не припомню

[sonycman]

1) если интересуетесь процессорами, то нужно освоить софт для хоста - это линуксные утилиты gcc, gdb, llvm, qemu и т.д. так как виндовс это убогая система для офисных работников, то ни в проф. сообществе не в среде опенсорсников оно не используется и соответственно код для винды не разрабатывается (некоторые уже готовые продукты портируются). чтобы как-то скрасить убогую виндовзную жизнь были придуманы костыли типа cygwin, msys и т.п. но в родной среде все это работает гораздо лучше

2) также советую посмотреть opencores.org (например проект openrisc). а если VHDL не вызывает нервного тика, то LEON3 от GAISLER-а

3) аппаратные стеки у минималистических процессоров - весьма частое дело (про микрочип pic12 pic14 pic16 слышали?).
это делается чтобы ресурсы ПЛИС сэкономить. а отсутствие некоторых инструкций может вызвано отсутствием свободного места в формате команды - я так понимаю, что для тех сдвигов понадобится второй операнд на 3 бита? видимо, на этом авторы сэкономили - опять же таких сдвигов я так сразу ни в одном коммерческом 8-ми битнике не припомню

1. Это да, придётся осваивать помаленьку, хотя не сказал бы, что различного софта под винду мало и есть какая-то необходимость ставить Линукс.
2. Ну пока что остановлюсь и поработаю на одном - Мико8. Но спасибо за совет.

3. По аппаратному стеку (call stack) вопросов нет - от у мико маленький и задаётся при конфигурации.

Там ещё существует два софтовых стека - общий (стандартный) для локальных переменных и для передачи параметров - устанавливается на последний адрес памяти данных.
И второй - irq stack - выделенный стек прерываний, располагается в отдельном сегменте bss и размер прописан, похоже, жестко и зависит только от выбранной модели памяти.
К примеру, для малой модели памяти (scratchpad memory = до 256 байт) он устанавливается в 32 байта, для средней и для большой моделей (до 64 килобайта или до 4 гигабайт) его размер выставляется 512 байт.

Весьма странное решение, на мой взгляд, не находите?
К примеру, не уложился я в 256 байт памяти данных - нужно 512. Опа - а компилятор взял, и отхватил ВСЕ 512 байт для этого самого irq_stack...
Весело, правда?

Раньше, судя по найденному в сети, для Мико8 существовал симулятор инструкций для проверки\отладки проекта.
Сейчас об этом нигде нет даже упоминания...

[iosifk]

Весьма странное решение, на мой взгляд, не находите?

Да нет, я тоже так делал. Это дает возможность заносить в стек что угодно и не думать о том, что там делается при возвратах... Например передавать данные в подпрограмму через стек.
Так же как в Форте... Стек данных и стек возвратов...

[sonycman]

Да нет, я тоже так делал. Это дает возможность заносить в стек что угодно и не думать о том, что там делается при возвратах... Например передавать данные в подпрограмму через стек.
Так же как в Форте... Стек данных и стек возвратов...

Вы, наверное, не поняли - для передачи данных служит простой stack, который растёт от вершины памяти данных.

Я же говорю про другой - выделенный стек прерываний irq_stack.

Это разные вещи.

И больше всего меня бесит, что влиять на размер irq_stack я никак не могу...

[iosifk]

Вы, наверное, не поняли - для передачи данных служит простой stack, который растёт от вершины памяти данных.

Я же говорю про другой - выделенный стек прерываний irq_stack.

Это разные вещи.

И больше всего меня бесит, что влиять на размер irq_stack я никак не могу...

Так это же я и написал. Два стека. И можно данные передавать в подпрограммы или в прерывания через стек данных... А "влиять" не имеет смысла. Потому как такие процессоры мы делаем не для "вычислений", а как "стрелочники" для предварительной обработки данных и управления вводом-выводом...
Для справки - у меня на сайте - статьи "Микропроцессор своими руками"...

[sonycman]

Так это же я и написал. Два стека. И можно данные передавать в подпрограммы или в прерывания через стек данных... А "влиять" не имеет смысла. Потому как такие процессоры мы делаем не для "вычислений", а как "стрелочники" для предварительной обработки данных и управления вводом-выводом...
Для справки - у меня на сайте - статьи "Микропроцессор своими руками"...

Не совсем.
Ещё раз.

В Мико8 три стека.
1. Аппаратный call stack - размер выбирается между 8, 16 и 32 байтами.
Используется для хранения адреса возврата из подпрограмм.

2. Стек данных, про который вы говорите.
С ним всё нормально - вершина находится на последнем адресе памяти данных и растёт вниз.
Размер задавать смысла нет - может занимать всю свободную память.

3. Стек прерываний irq_stack - выделенный стек прерываний, располагается в отдельном сегменте bss и размер прописан, похоже, жестко и зависит только от выбранной модели памяти.
К примеру, для малой модели памяти (scratchpad memory = до 256 байт) он устанавливается в 32 байта, для средней и для большой моделей (до 64 килобайта или до 4 гигабайт) его размер выставляется 512 байт.

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

[iosifk]

Не совсем.
Ещё раз.

В Мико8 три стека.
1. Аппаратный call stack - размер выбирается между 8, 16 и 32 байтами.
Используется для хранения адреса возврата из подпрограмм.

2. Стек данных, про который вы говорите.
С ним всё нормально - вершина находится на последнем адресе памяти данных и растёт вниз.
Размер задавать смысла нет - может занимать всю свободную память.

3. Стек прерываний irq_stack - выделенный стек прерываний, располагается в отдельном сегменте bss и размер прописан, похоже, жестко и зависит только от выбранной модели памяти.
К примеру, для малой модели памяти (scratchpad memory = до 256 байт) он устанавливается в 32 байта, для средней и для большой моделей (до 64 килобайта или до 4 гигабайт) его размер выставляется 512 байт.

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

Реализация совсем не грубая, а аппаратно-зависимая...
Для того, чтобы с этим разобраться, посмотрите, какая память реализуется в этих ПЛИС. И смотрите на латентность. Если для вызова подпрограмм латентность не важна, то для возврата из прерываний - наверное важна, а потому там стек для возвратов скорее всего сделан на триггерах. А их и интерконнектов много не бывает. И я так и делал...
Ничего сомнительного не вижу. Просто ПЛИС имеют свои особенности, только и всего...

[sonycman]

Реализация совсем не грубая, а аппаратно-зависимая...

Так причём тут аппаратно-зависимая?
Когда оба софтовых стека - общий и прерываний - находятся в одной и той же области памяти данных (scratchpad) и аппаратно реализованы абсолютно одинаково!
И латентность тут совсем не при чём...

Ничего сомнительного не вижу.

Сомнительное здесь вот это, как пример: не уложился я в 256 байт памяти данных - нужно 512. Опа - а компилятор взял, и отхватил ВСЕ 512 байт для этого самого irq_stack...
Весело, правда?