Кто любит RISC в жизни, заходим, не стесняемся.
Ответить

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 29, 2020 11:04:04

Мне лень
Зато вывод сделать было не лень.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вс ноя 29, 2020 11:08:00

там нет никаких выводов - есть результат компиляции

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 30, 2020 08:25:33

iddqd, двоичные литералы через 0b в стандарте C++14 ещё ввели.
Отлично, только я вот для микроконтроллера C99 (с некоторыми оговорками, типа отсутствия VLA) предпочитаю - по соображениям портабельности, предсказуемости и понятности мне того что компилер вытворять удумает. И вот как-то именно в сях - эти литералы ну вот не стандартизировали. И какая мне разнца что там в 14-х плюсах? Это другой ЯП, я им не пользуюсь, и он даже жуется другим бинарником компилера в случае gcc. Так что номинально грешок за мной водится, увы. И как угодно но свои огрехи в случае МК как мне кажется лучше знать. Чтобы понимать на что расчитывать.

з.ы. для blink получается clang бинарник больше чем gcc
Я gcc'ом LTO+GC секций научился делать, на более менее крупном (более ~4-5kb) коде добрая четверть кода нахаляву урезается. В том плане что логика не ломается, скорость не проседает - и все это просто потому что с LTO делается глобальная оптимизация, по всему коду. Это делает кодогенерацию довольно чудесатой, и иногда умеет прикалываться. Иногда даже перестановка statement местами меняет размер. Но работает круто. Особенно когда есть где развернуться. В этих примерах LTO + GC sections не используется и это соответствнено не максимум что можно извлечь из GCC. Может ли clang что-то сравнимое и насколько это (не)эффективно и (без)глючно пусть фаны clang исследуют. В силу природы оптимизаций оно может и поприкалываться.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 30, 2020 12:53:53

Eddy_Em, берёшь Keil и пользуешься Clang "из коробки".

Ты прекрасно знаешь, что я предпочитаю жить без анальных зондов!
Исключительно свободное ПО!
Гентушникам что, они к этому привычные, там вся система такая что может резко и внезапно помереть.

Бред-то какой! "Резко и внезапно" помереть разве что мастдайка может…

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 30, 2020 14:28:12

И вот как-то именно в сях - эти литералы ну вот не стандартизировали.
Именно из-за таких мелочей и стоит даже С код компилировать С++ компилятором.

Исключительно свободное ПО!
Исключительно свободное для STM32F0, дальше которых ты не ходишь. Просто ты такие восторги в соседней теме про Clang излучал, при том что люди давным давно им просто пользуются даже не подозревая.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пн ноя 30, 2020 15:08:43

Исключительно свободное для STM32F0, дальше которых ты не ходишь.

Вообще-то, все STM32 прекрасно компиляются при помощи gcc! Возможно, когда-нибудь еще в сторону Cortex-M4 посмотрю (просто пока что у меня нет таких задач, где нужно было бы использовать флоаты или просто более шустрое ядро).
Сейчас вот на досуге ковыряю CH552G (и тоже для работы с ними ничего анально огороженного использовать не нужно!). Занятные мелкоконтроллеры. Жаль только, оперативки мало и периферия небогатая. Но для применения в качестве элементарной управляемой розетки вполне сгодится.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вт дек 01, 2020 00:29:13

Eddy_Em пардон, у меня есть знакомые гентушники и у них оно вот так. Но это к сабжу не относится, лучше с этим завязать, наверное.

Именно из-за таких мелочей и стоит даже С код компилировать С++ компилятором.
Да меня и сишный устраивает, апгрейдить требования с C99 до C++14 я не планирую. Это бред сивой кобылы, что-то подобное я только у виндовых дев с студией, но они это потому что поддержка C99 в студиях лютое гэ, поэтому такой вот "си++", внутрях чистый си, а из ++ аж //целые. Не хочу уподобляться. И в этом месте я лучше формально признаю что юзаю "нестандартный" гнутый экстеншн чем скажу что это C++14. Настоящие плюсовики меня не поймут, а юзать полновесный C++14 в мк в мои планы не входит.

Исключительно свободное для STM32F0, дальше которых ты не ходишь. Просто ты такие восторги в соседней теме про Clang излучал, при том что люди давным давно им просто пользуются даже не подозревая.
Gcc и под F1xx вроде нормально работает, а то что он свободный - так это хорошо, не получится так что корп утащит в свое логово, а остальные обломятся. Под F4 тоже собирает, но у меня этих монстриков просто нет, не надо мне столько, да и на тех кто F4 на асме пойдет наворачивать я бы посмотрел :)

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Вт дек 01, 2020 06:51:34

по соображениям портабельности,

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

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт дек 03, 2020 06:37:24

С этого места предлагается либо крестик снять, либо трусы надеть. Вопрос то для вас, оказалось, религиозно-фанатичный.

А при чем тут крестик и трусы? Я разве где-то настаивал что МК можно программировать используя только стандартные элементы яп? :)

Мысль номер раз: микроконтроллеры невозможно программировать используя ТОЛЬКО средства C или C++ прописанные в стандартах ЯП! А хотя-бы потому что средства контроля лэйаута прошивки (конкретные секции, адреса, стэк и прочие линкерскрипты, ...) - в стандарты ЯП вообще не входят. То-есть программируя МК мы точно залетаем на использование нестандартных расширений. А, ну еще на ассемблере можно. Но большой вопрос насколько нужно. Меня на С не обламывает сказать что-то типа ... SECTION(".vector"). А то что дефайн где-то дальше компилерспецифично раскрывается - фу, конечно, но не фу-фу-фу. И для другого компилера можно это просто переделать, много усилий не займет.

Мысль номер два: лучше называть вещи своими именами и трезво оценивать последствия тех или иных решений. А юлить про стандарт GCC - здорово, конечно, но какой организацией "стандарт" ратифицирован?

Мысль номер три: я не хочу использовать 14-е плюсы. Особенно - ради одной мелкой плюшки, что является издевательством над здравым смыслом. А коли я и так попал на использование гнутых расширений, за 0b... меня никто явно не съест. Тем более что вот это жрали вообще все виденые мной компиляторы, статические анализаторы и прочее. К тому же я в курсе что выхожу за пределы стандарта, а не разглагольствую про "стандарты gcc".

Так что да, я в отличие от трусов и крестиков предпочитаю более рациональные подходы. Поэтому я не против асма - если это что-то дает, кроме лишней долботни. Ну вот уверенность что за конструкция там будет - дает. Лучше чем упование на кодогенератор и оптимизатор, как по мне. И расширение я могу использовать. Если плюсы (e.g. более адекватный вид битовых полей) перевешивают минусы (теоретически становится менее портабельно). А про крестик и трусы я скажу тому кто откровенно сишный сорец обзовет 14-ми плюсами за аж целые 0bXXXXX :)

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Чт дек 03, 2020 08:06:32

Всё это словоблудие, а в реальности стандарт на программирование микроконтроллеров ARM задают три основных компилятора плюс CMSIS для кортексов. А плюшки плюсов это далеко не только 0b или 0b0101'1010, но и более строгий контроль типов, более удобное объявление переменных, констант и типов и т.д. и т.п. даже практически не выходя за привычный синтаксис. И основные компиляторы для ARM давно C++17 поддерживают. Не задумывались зачем?

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 11:24:34

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

А высокие концепции и полухакерские фокусы - прекрасно. Кроме случая когда это после предшественинка досталось. У плюсовиков фирменная фича: каждый на своем диалекте жарит, найти двух одинаковых почти невозможно. Очень неприятно потом за любителем выпендрежа неделю вдуплять чтобы вообще начать думать как он. А тогда вы наконец сможете за 10 минут сменить те пару незначительных фиговин, которые хотелось. Но в результате на незначительную ерунду продолбано неделя + 10 минут. С сями это скорее экзотика, там обычно один програмер за другим код более-менее сразу может понять. Контрпримеры найти конечно тоже можно.

А зачем C++17? Наверное для вон тех монстров которым чуть не Qt embedded с чуть не оконной системой подавай.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 12:06:35

лично мне в сях нравится то что тонкая прослойка, минимум оверхеда, все просто и предсказуемо. Почти как асм, только читаемо лучше, структурировано, компактнее в разы. В ++ этого нет.

Глупости, С++ функционально значительно превосходит С, следовательно возможностей написать более компактные, в обоих смыслах, хорошо читаемые и т.д. программы тоже больше. Обратное также верно, если вместо массива притащить в проект std::vector который может динамически выделять память и бросать исключения, то понятное дело не получишь ни компактности, ни, вероятно, предсказуемости. Однако можно привести другой пример:
Код:
Menu<lcd, menuItems> menu(...)

Менюшка, menuItems - это массив структур во флеше, инитится он в виде удобном для человека, там нет никаких связей между Parent/Child/Next/Prev, как в микроменю. Внутри класса Menu этот массив передается в другой класс на полторы страницы который его трансформирует, там уже есть Next/Prev, но в виде индексов для которых автоматически выбирается минимально возможный тип, а Parent/Child по-прежнему нет, вместо них используются флаги типа Node. В итоге от простоты описания меню приходим к компактной и эффективной форме его хранения, а разместит компилятор этот новый трансформированный массив также во флеше, вместо старого, даже при отключенной оптимизации. Полторы страницы не самого простого кода, ведь нужно многократно обходить весь массив в поиске связей, в рантайме гарантированно не делает ничего потому что от языка программирования можно это явно потребовать, куда уж предсказуемее.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 14:13:29

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

Menu<lcd, menuItems> menu(...) - на си наверное тоже можно нечто сравнимое сделать. Но вот лично меня МК интересуют не отрисовкой меню. А жестко реалтаймным управлением всяким, измерениями и проч. И предсказуемость волнует не в менюхе. А где-нибудь на стыке координирования железок, и всем таком. Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует. Ну, если не понимать под таковыми только 0bXXXX, при сплошных сях вокруг :)

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 15:27:21

Но за этим зачастую стоит большая сложность "подложки", рантайма, нетривиальная кодогенерация, адовый полет мысли очередного креативщика и прочие чудеса, типа оверрайда операторов или чего еще. А какие конструкции когда компилер генерит становится сильно менее очевидно, стартап сложнее, конструкторы-деструкторы всякие, а низкоуровневый контроль над происходящим - утрачивается.
Многократно замечал как С-программисты только увидят у файла расширение .cpp и давай сразу шпарить классами с виртуальными методами, вариативными шаблонами, приправляя всё это лямбдами, оператором "<=>" да концептами что аж профи позавидуют. Правда смешно звучит?

стартап сложнее
С какой стати? Тот же стартап.

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

Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует.
Причём тут язык? Вы либо понимаете как работает железка, либо нет.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 16:12:05

С какой стати? Тот же стартап.
В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать. А так то когда вам кто-то черный ящик прилинковал, конечно, поди там разберись есть ли разница.
А в жизни, когда я показываю на плюсах более эффективное дёргание лапками чем на сях
Интересно, а сколько для этого asm дампы читать пришлось? На сях то удобную процу конструкцию довольно тривиально размудрить :). Ну и вон serial.begin'щики этим редко могут похвастать.
Причём тут язык? Вы либо понимаете как работает железка, либо нет.
При том что когда я на сях пишу мне более-менее понятно во что это скорее всего компилер трансформирует. Без всенепременного вштыривания в ассемблерный кусок каждый раз. С навороченной си++ штукой с какими-нибудь классами и прочими это как-то менее очевидно.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 16:45:37

На сях я могу допустим лапками дергать с эффективностью практически ассемблера, неплохо понимая почему вон та конструкция должна быть достаточно эффективна. Можете ли вы это сказать про вон тот класс - черт его знает.

Сравнивали много раз, C++ вариант ногодрыжной либы самый умный и эффективный, оптимизирует как на уровне пинов, так и на уровне работы с регистрами. В качестве иллюстрации, вот так выглядит одна из функций оптимизации:

Menu<lcd, menuItems> menu(...) - на си наверное тоже можно нечто сравнимое сделать.

Так наверное или можно? :) Допустим есть такой массив:
Код:
const int arr[] = { 10, 20, 30, 40, 50 };

Можешь попытаться на его основании создать реверсный массив который также будет размещен во флеше.

Но вот лично меня МК интересуют не отрисовкой меню. А жестко реалтаймным управлением всяким, измерениями и проч. И предсказуемость волнует не в менюхе. А где-нибудь на стыке координирования железок, и всем таком. Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует. Ну, если не понимать под таковыми только 0bXXXX, при сплошных сях вокруг :)

Какая разница менюшка или не менюшка, С++ умеет выполнять код на этапе компиляции, С не умеет, а в рантайме все примерно одинаково получается, периодически когда переделывал сишный код получал точно такой-же бинарник после компилятора C++, что не удивительно, зачем разрабам gcc делать два компилятора для языков один из которых фактически является подмножеством другого.

В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать.

У gcc есть атрибут section(".init"), помечая им сишную функцию можно заставить ее вызываться в начале выполнения программы, для чего используется тот же механизм, что и для конструкторов, т.е. типичный gcc стартап для С и С++ ничем не отличается. Естественно атрибут эмуллирующий деструкторы имеется тоже.

Интересно, а сколько для этого asm дампы читать пришлось? На сях то удобную процу конструкцию довольно тривиально размудрить :)

Семисегментник, где-то внутри класса есть такой код:
Код:
digits::clear();
segs::write(comAnodeTbl[ch]);
digits::write(1 << digit);

Насколько тривиально на С все размудрить для таких списков пинов?
Код:
using segs = PinList<PC7, PA4, PA10, PB10, PB11, PD3, PB9, PA11>;
using digits = PinList<PC0, PB8, PA3, PC6>;
Semiseg<digits, segs> semiseg;

Пины от реальной платки которая втыкается в разъем для LTDC :)
Последний раз редактировалось Reflector Пт дек 04, 2020 18:34:18, всего редактировалось 2 раз(а).

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 18:32:30

В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать. А так то когда вам кто-то черный ящик прилинковал, конечно, поди там разберись есть ли разница.
В IAR и Keil стартап по ResetHandler передаёт управление стандартной библиотеке. Она сама знает есть ли конструкторы и вызывает их. В GCC у большинства стандартных стартапов точно так же передаётся в __libc_init_array(); И лишь немногие используют ключ "-nostartfiles" и заменяют её двумя строчками
Код:
for(void(**fConstr)() = __preinit_array_start; fConstr < __preinit_array_end; (*fConstr++)());
for(void(**fConstr)() = __init_array_start;    fConstr < __init_array_end;    (*fConstr++)());
При том что у подавляющего большинства стартап вообще на asm и они туда никогда не заглядывали. И он из коробки всё это поддерживает. Так что, вопрос яйца выеденного не стоит.

Интересно, а сколько для этого asm дампы читать пришлось?
Ничуть не больше чем на Си.

На сях то удобную процу конструкцию довольно тривиально размудрить :).
А на плюсах нетривиально? На каком языке написано?
Код:
*(volatile uint8_t *)&GPIOA->ODR = x;
Надо смотреть дамп, чтобы сказать во что это компилируется? Мне нет.

Ну и вон serial.begin&#39;щики этим редко могут похвастать.
Заберите их себе. Чем HAL-воды в этом плане лучше?

При том что когда я на сях пишу мне более-менее понятно во что это скорее всего компилер трансформирует. Без всенепременного вштыривания в ассемблерный кусок каждый раз. С навороченной си++ штукой с какими-нибудь классами и прочими это как-то менее очевидно.
А почему должно быть иначе, если вы не знаете язык?

Добавлено after 1 hour 46 minutes 42 seconds:
А зачем C++17?
Сообщением выше Reflector показал простую оптимизацию, которая без C++17 не работает.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 19:54:33

Пример с реверсом пожалуй не самый удачный, лучше его заменить сортировкой. На C++ это может выглядеть так:

С выключенной оптимизацией(с включенной тем более) следующий код дает абсолютно идентичный бинарник:
Код:
const int arr[] = { 10, 20, 30, 40, 50 };

for(auto& v: arr)
{
   rtt.print<"{}, {}\n">(&v, v);
}

В первом случае в конструкторе вызываются две стандартных функции, насколько они тяжелые можно понять заменив в одной стоке constexpr, которого все равно в С нет, на const:
Код:
const Transform<arr> trfm;

Теперь имеем плюс 20 байт RAM, т.к. массив стал хранится именно там, и плюс 3КБ кода во флеше(для -O0), или +770 байт для -O2.

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 20:12:36

Небольшая ремарочка к предыдущему сообщению. Тут уже без С++20 не обойтись :)))

Re: Ассемблер для STM32. Сложно ли, стоит ли пытаться?

Пт дек 04, 2020 20:35:08

Тут уже без С++20 не обойтись :)))

Ну не маньяки ли?
Сишники как писали с 70-х годов на С, так и пишут. С минимальнейшими изменениями (но можно и вообще без изменений, в том же духе писать; и ничего, gcc соберет).
А вот крестовикам делать нехер, только каждые несколько лет считай заново новый ЯП учить!
С тем и хорош, что практически "надстройка над ассемблером". Очень простой язык (чуть сложней ассемблера, зато писанины поменьше, но при этом остается понимание). А С++ — это вообще дичь лютая!
Ответить