[SII 0]

5 hours ago, Alex77 said:

мысли в слух...

Thumb2 это 2 байта на команду (если не склероз), а в microblaze 4 байта на команду.

В Тумбе-2 есть и 2-, и 4-байтовые команды, только 2-байтовые -- в чистой Тумбе (если BL рассматривать как две двухбайтовые, какой она изначально -- в ARMv4T -- и была). Насколько эффективно компилятор умеет этим пользоваться -- вопрос. В частности, для эффективного использования нужно отдавать предпочтение регистрам R0-R7, используя остальные лишь в крайнем случае, так как почти все 2-байтовые команды не имеют работать с "верхними" регистрами.

3 hours ago, makc said:

Только поскольку Cortex-M и микроб не суперскалярные

Поправочка: Cortex-M3 и большая часть других. Но, например, Cortex-M7 -- суперскалярный (две команды за такт, если звёзды сходятся).

[makc 192]

38 минут назад, SII сказал:

Поправочка: Cortex-M3 и большая часть других. Но, например, Cortex-M7 -- суперскалярный (две команды за такт, если звёзды сходятся).

Уточнение правильное, но в контексте темы мы говорили про M3, M7 это уже более сложная машинка, которой в синтезируемом виде для ПЛИС мне не попадалось. К тому же шины у М7 уже 64 бита, что для ПЛИС уже не так эффективно с точки зрения требований к ресурсам. А так и microblaze можно сделать 64-битным, да ещё и с предсказателем ветвлений:

Цитата

To improve branch performance, MicroBlaze provides a branch target cache (BTC) coupled with a branch prediction scheme. With the BTC enabled, a correctly predicted immediate branch or return instruction incurs no overhead.

The BTC operates by saving the target address of each immediate branch and return instruction the first time the instruction is encountered. The next time it is encountered, it is usually found in the Branch Target Cache, and the Instruction Fetch Program Counter is then simply changed to the saved target address, in case the branch should be taken. 

Unconditional branches and return instructions are always taken, whereas conditional branches use branch prediction, to avoid taking a branch that should not have been taken and vice versa.

Но этот вариант уже совсем за гранью вопроса этой темы.

[Lmx2315 2]

5 часов назад, sonycman сказал:

 (просто взял корку Cortex-M3 из армового DesignStart, и дело в шляпе)

 

Это свободно можно сделать? А можно ссылку на корочку?

[SII 0]

22 minutes ago, Lmx2315 said:

Это свободно можно сделать? А можно ссылку на корочку?

Ну, во-первых, можно с сайта АРМа и/или Хилинха скачать. А во-вторых, собственно дешифрованные исходники ядра я выкладывал в закромах.

 

Пы.Сы. Кстати, о корках. У АРМа вроде как и Кортех-А5 дают. Кто-нибудь пробовал?

[Alex77 4]

АРМы парочку ядер выкладывали

Arm Cortex-M1 Processor

Arm Cortex-M3 Processor

https://www.arm.com/resources/free-arm-cortex-m-on-fpga

[Raven 8]

9 hours ago, makc said:

Это было 2.5 года назад, поэтому могу ошибаться, но по-моему gcc был из серии 8.х для arm, а для микроба по-моему 7.х или вроде того.

Со времен GCC 8 поддержка в нем RISC-V улучшилась, так что сравнивать надо на чем-то более свежем.

[sonycman 0]

5 hours ago, SII said:

Ну, во-первых, можно с сайта АРМа и/или Хилинха скачать. А во-вторых, собственно дешифрованные исходники ядра я выкладывал в закромах.

Интересно, надо посмотреть в закромах.

А то у меня что-то инициализация памяти ITCM (файлом .hex или .mem) при синтезе в 2019 виваде не работает, и так и сяк пробовал - одни нули в итоге.

То ли вивада глючная, то ли корка такой опции не имеет, хотя в настройках ядра опция есть и в доках описана...

[SII 0]

3 hours ago, sonycman said:

о ли вивада глючная, то ли корка такой опции не имеет, хотя в настройках ядра опция есть и в доках описана...

У меня тоже какая-то проблема была, но не помню, как решил. Скорей всего, слепил свой проект без всяких там IP -- просто на уровне исходников впихнул (а может, вообще на Спартане-3Е делал в ИЗЕ...)

[makc 192]

5 часов назад, Raven сказал:

Со времен GCC 8 поддержка в нем RISC-V улучшилась, так что сравнивать надо на чем-то более свежем.

Согласен, нужно попробовать на 10ке. Но судя по https://github.com/riscv/riscv-code-size-reduction там ещё работы на несколько лет вперёд. Да к тому же потребуется модификация синтезируемых ядер, чтобы реализовать все эти нововведения для системы команд, и когда это будет и будет ли вообще не ясно. Поэтому выбирая RV32IMC нужно сразу быть готовым и заложить запас на память для кода. Кстати, вот презентация с очень сходными с результатами моих экспериментов данными: CARRV2020_slides_12_Perotti.pdf

[Raven 8]

2 hours ago, makc said:

Согласен, нужно попробовать на 10ке. 

.....

Кстати, вот презентация с очень сходными с результатами моих экспериментов данными: CARRV2020_slides_12_Perotti.pdf

Да, интересный материал. Они вообще проверяли на GCC 7.x, что для 2019-2020 уже несколько странно (вероятно, он был выбран из-за доступных метрик по ARM).

 

Но уже даже при таком раскладе многие компании сочтут плату в +11% code size вполне приемлемой при существенном уменьшении стоимости роялти за ядро. Да и вообще, разница в 11% не выглядит подавляющей. И это при том, что оптимизация по размеру влияет также почти на все остальные важные характеристики кода: производительность, потребление и т.п. (и в презентации тоже это отмечают). Так что надо, ко всему прочему, еще и общий системный баланс рассматривать.

[makc 192]

1 минуту назад, Raven сказал:

Да, интересный материал. Они вообще проверяли на GCC 7.x, что для 2019-2020 уже несколько странно (вероятно, он был выбран из-за доступных метрик по ARM).

С другой стороны я лично не заметил существенного уменьшения размера прошивки для Cortex-M0|M4 при переходе от gcc 7.x->8.x->10.x, поэтому предполагаю, что то же самое справедливо и для RISC-V. 

4 минуты назад, Raven сказал:

Да и вообще, разница в 11% не выглядит подавляющей. И это при том, что оптимизация по размеру влияет также почти на все остальные важные характеристики кода: производительность, потребление и т.п. (и в презентации тоже это отмечают). Так что надо, ко всему прочему, еще и общий системный баланс рассматривать.

В этой презентации нет оценки производительности получаемой в результате прошивки в сравнении с ARM, в то время как на моих тестах разница между временем выполнения теста реализации ГОСТ Р 34.13-2015 в режиме OMAC (имитовставка) достигала 25% по времени выполнения не в пользу RISC-V. Для теста использовалось открытое ядро SCR1 от Syntacore, хотя за давность лет могу и ошибаться. Причём кроме этого ядра пробовал ещё парочку и ни одно не дотянуло на равной частоте до microblaze и тем более до ситезируемого Cortex-M3. Наверное можно было это отставание скомпенсировать за счёт ассемблерной оптимизации, но в тот момент такой цели не стояло.

[Raven 8]

4 minutes ago, makc said:

С другой стороны я лично не заметил существенного уменьшения размера прошивки для Cortex-M0|M4 при переходе от gcc 7.x->8.x->10.x, поэтому предполагаю, что то же самое справедливо и для RISC-V.

GCC for ARM - вещь уже устоявшаяся, там особых улучшений ждать не приходится. Другое дело - GCC for RISC-V, тут еще большое пространство для улучшений, ведется работа, и каждый новый релиз добавляет что-то заметное. В общем, надо использовать свежатину.

10 minutes ago, makc said:

Для теста использовалось открытое ядро SCR1 от Syntacore, хотя за давность лет могу и ошибаться. Причём кроме этого ядра пробовал ещё парочку и ни одно не дотянуло на равной частоте до microblaze и тем более до ситезируемого Cortex-M3.

Супротив Cortex-M3 надо было выставлять SCR3, по крайней мере (а может - и SCR4, надо смотреть их микроархитектурные параметры), а не SCR1 - ядро начального уровня.

[makc 192]

2 минуты назад, Raven сказал:

GCC for ARM - вещь уже устоявшаяся, там особых улучшений ждать не приходится. Другое дело - GCC for RISC-V, тут еще большое пространство для улучшений, ведется работа, и каждый новый релиз добавляет что-то заметное. В общем, надо использовать свежатину.

На сколько я понимаю, основные доработки и оптимизации происходят во фронтенде gcc, а кодогенератор (бэкенд) относительно стабильная часть компилятора, его имеет смысл дорабатывать если появляются дополнительные расширения в системе команд, но в случае RV32IMC всё стабильно и каких-либо заметных стандартизированных изменений нет.

7 минут назад, Raven сказал:

Супротив Cortex-M3 надо было выставлять SCR3, по крайней мере (а может - и SCR4, надо смотреть их микроархитектурные параметры), а не SCR1 - ядро начального уровня.

В открытом доступе есть только SCR1, если у вас есть SCR3 или SCR4 я бы их с удовольствием попробовал.

[Raven 8]

27 minutes ago, makc said:

В открытом доступе есть только SCR1, если у вас есть SCR3 или SCR4 я бы их с удовольствием попробовал.

Мысль была лишь в том, что предъявлять претензии по производительности к SCR1 в сравнении с Cortex-M3 - это некорректно. Разные весовые категории.

[makc 192]

29 минут назад, Raven сказал:

Мысль была лишь в том, что предъявлять претензии по производительности к SCR1 в сравнении с Cortex-M3 - это некорректно. Разные весовые категории.

Я бы не назвал это претензией, скорее обмен опытом и результатами практических экспериментов. С другой стороны если сравнивать SCR1 и Cortex-M3, то они вполне похожи: длина конвейера сходна, есть аппаратное умножение. К тому же оба ядра доступны для использования, если вернуться к вопросу этой темы.