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

[VladislavS]

[uquote="oleg110592",url="/forum/viewtopic.php?p=3932621#p3932621"]Мне лень[/uquote]Зато вывод сделать было не лень.

[oleg110592]

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

[iddqd]

iddqd, двоичные литералы через 0b в стандарте C++14 ещё ввели.

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

з.ы. для blink получается clang бинарник больше чем gcc

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

[Eddy_Em]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3932535#p3932535"]Eddy_Em, берёшь Keil и пользуешься Clang "из коробки".[/uquote]
Ты прекрасно знаешь, что я предпочитаю жить без анальных зондов!
Исключительно свободное ПО!
[uquote="iddqd",url="/forum/viewtopic.php?p=3932524#p3932524"]Гентушникам что, они к этому привычные, там вся система такая что может резко и внезапно помереть.[/uquote]
Бред-то какой! "Резко и внезапно" помереть разве что мастдайка может…

[VladislavS]

[uquote="iddqd",url="/forum/viewtopic.php?p=3933060#p3933060"]И вот как-то именно в сях - эти литералы ну вот не стандартизировали.[/uquote]Именно из-за таких мелочей и стоит даже С код компилировать С++ компилятором.

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3933205#p3933205"]Исключительно свободное ПО![/uquote]Исключительно свободное для STM32F0, дальше которых ты не ходишь. Просто ты такие восторги в соседней теме про Clang излучал, при том что люди давным давно им просто пользуются даже не подозревая.

[Eddy_Em]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3933258#p3933258"]Исключительно свободное для STM32F0, дальше которых ты не ходишь.[/uquote]
Вообще-то, все STM32 прекрасно компиляются при помощи gcc! Возможно, когда-нибудь еще в сторону Cortex-M4 посмотрю (просто пока что у меня нет таких задач, где нужно было бы использовать флоаты или просто более шустрое ядро).
Сейчас вот на досуге ковыряю CH552G (и тоже для работы с ними ничего анально огороженного использовать не нужно!). Занятные мелкоконтроллеры. Жаль только, оперативки мало и периферия небогатая. Но для применения в качестве элементарной управляемой розетки вполне сгодится.

[iddqd]

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

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

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

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

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

[VladislavS]

[uquote="iddqd",url="/forum/viewtopic.php?p=3933060#p3933060"]по соображениям портабельности,[/uquote]
[uquote="iddqd",url="/forum/viewtopic.php?p=3933731#p3933731"]И в этом месте я лучше формально признаю что юзаю "нестандартный" гнутый экстеншен[/uquote]С этого места предлагается либо крестик снять, либо трусы надеть. Вопрос то для вас, оказалось, религиозно-фанатичный.

[iddqd]

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

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

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

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

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

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

[VladislavS]

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

[iddqd]

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

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

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

[Reflector]

[uquote="iddqd",url="/forum/viewtopic.php?p=3935715#p3935715"]лично мне в сях нравится то что тонкая прослойка, минимум оверхеда, все просто и предсказуемо. Почти как асм, только читаемо лучше, структурировано, компактнее в разы. В ++ этого нет.[/uquote]
Глупости, С++ функционально значительно превосходит С, следовательно возможностей написать более компактные, в обоих смыслах, хорошо читаемые и т.д. программы тоже больше. Обратное также верно, если вместо массива притащить в проект std::vector который может динамически выделять память и бросать исключения, то понятное дело не получишь ни компактности, ни, вероятно, предсказуемости. Однако можно привести другой пример:

Код: Выделить всё

Menu<lcd, menuItems> menu(...)

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

[iddqd]

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

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

[VladislavS]

[uquote="iddqd",url="/forum/viewtopic.php?p=3935872#p3935872"]Но за этим зачастую стоит большая сложность "подложки", рантайма, нетривиальная кодогенерация, адовый полет мысли очередного креативщика и прочие чудеса, типа оверрайда операторов или чего еще. А какие конструкции когда компилер генерит становится сильно менее очевидно, стартап сложнее, конструкторы-деструкторы всякие, а низкоуровневый контроль над происходящим - утрачивается.[/uquote]Многократно замечал как С-программисты только увидят у файла расширение .cpp и давай сразу шпарить классами с виртуальными методами, вариативными шаблонами, приправляя всё это лямбдами, оператором "<=>" да концептами что аж профи позавидуют. Правда смешно звучит?

[uquote="iddqd",url="/forum/viewtopic.php?p=3935872#p3935872"]стартап сложнее[/uquote]С какой стати? Тот же стартап.

[uquote="iddqd",url="/forum/viewtopic.php?p=3935872#p3935872"]На сях я могу допустим лапками дергать с эффективностью практически ассемблера, неплохо понимая почему вон та конструкция должна быть достаточно эффективна.[/uquote]А в жизни, когда я показываю на плюсах более эффективное дёргание лапками чем на сях, то си-программисты обычно отбрехиваются "вот ещё я о таких мелочах не парился, проц и так всё успевает".

[uquote="iddqd",url="/forum/viewtopic.php?p=3935872#p3935872"]Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует.[/uquote]Причём тут язык? Вы либо понимаете как работает железка, либо нет.

[iddqd]

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

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

А в жизни, когда я показываю на плюсах более эффективное дёргание лапками чем на сях

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

Причём тут язык? Вы либо понимаете как работает железка, либо нет.

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

[Reflector]

[uquote="iddqd",url="/forum/viewtopic.php?p=3935872#p3935872"]На сях я могу допустим лапками дергать с эффективностью практически ассемблера, неплохо понимая почему вон та конструкция должна быть достаточно эффективна. Можете ли вы это сказать про вон тот класс - черт его знает.[/uquote]
Сравнивали много раз, C++ вариант ногодрыжной либы самый умный и эффективный, оптимизирует как на уровне пинов, так и на уровне работы с регистрами. В качестве иллюстрации, вот так выглядит одна из функций оптимизации:

Спойлер

Код: Выделить всё

	template<uint32_t Mask>
	static void _inline_ writeReg32(volatile uint32_t* reg, uint32_t value)
	{
		using vu8 = volatile uint8_t*;
		using vu16 = volatile uint16_t*;

		if constexpr (Mask == 0xFFFF'FFFF)
			*reg = value;
		else if constexpr (Mask == 0x0000'FFFF)
			*vu16(reg) = value;
		else if constexpr (Mask == 0xFFFF'0000)
			*(vu16(reg) + 1) = value >> 16;
		else if constexpr (Mask == 0x0000'00FF)
			*vu8(reg) = value;
		else if constexpr (Mask == 0x0000'FF00)
			*(vu8(reg) + 1) = value >> 8;
		else if constexpr (Mask == 0x00FF'0000)
			*(vu8(reg) + 2) = value >> 16;
		else if constexpr (Mask == 0xFF00'0000)
			*(vu8(reg) + 3) = value >> 24;
		else if constexpr (!(Mask & 0xFFFF'00FF))
			*(vu8(reg) + 1) = (Mask == value) ? *(vu8(reg) + 1) | value >> 8 : *(vu8(reg) + 1) & ~(Mask >> 8) | value >> 8;
		else if constexpr (!(Mask & 0xFF00'FFFF))
			*(vu8(reg) + 2) = (Mask == value) ? *(vu8(reg) + 2) | value >> 16 : *(vu8(reg) + 2) & ~(Mask >> 16) | value >> 16;
		else if constexpr (!(Mask & 0x00FF'FFFF))
			*(vu8(reg) + 3) = (Mask == value) ? *(vu8(reg) + 3) | value >> 24 : *(vu8(reg) + 3) & ~(Mask >> 24) | value >> 24;
		else if constexpr (!(Mask & 0xFFFF'0000))
			*vu16(reg) = (Mask == value) ? *vu16(reg) | value : *vu16(reg) & ~Mask | value;
		else if constexpr (!(Mask & 0x0000'FFFF))
			*(vu16(reg) + 1) = (Mask == value) ? *(vu16(reg) + 1) | value >> 16 : *(vu16(reg) + 1) & ~(Mask >> 16) | value >> 16;
		else
			*reg = *reg & ~Mask | value;
	}

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

Так наверное или можно? Допустим есть такой массив:

Код: Выделить всё

const int arr[] = { 10, 20, 30, 40, 50 };

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

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

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

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать.[/uquote]
У gcc есть атрибут section(".init"), помечая им сишную функцию можно заставить ее вызываться в начале выполнения программы, для чего используется тот же механизм, что и для конструкторов, т.е. типичный gcc стартап для С и С++ ничем не отличается. Естественно атрибут эмуллирующий деструкторы имеется тоже.

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]Интересно, а сколько для этого asm дампы читать пришлось? На сях то удобную процу конструкцию довольно тривиально размудрить [/uquote]
Семисегментник, где-то внутри класса есть такой код:

Код: Выделить всё

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

[VladislavS]

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать. А так то когда вам кто-то черный ящик прилинковал, конечно, поди там разберись есть ли разница.[/uquote]В 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 и они туда никогда не заглядывали. И он из коробки всё это поддерживает. Так что, вопрос яйца выеденного не стоит.

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]Интересно, а сколько для этого asm дампы читать пришлось?[/uquote]Ничуть не больше чем на Си.

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]На сях то удобную процу конструкцию довольно тривиально размудрить .[/uquote]А на плюсах нетривиально? На каком языке написано?

Код: Выделить всё

*(volatile uint8_t *)&GPIOA->ODR = x;

Надо смотреть дамп, чтобы сказать во что это компилируется? Мне нет.

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]Ну и вон serial.begin'щики этим редко могут похвастать.[/uquote]Заберите их себе. Чем HAL-воды в этом плане лучше?

[uquote="iddqd",url="/forum/viewtopic.php?p=3935985#p3935985"]При том что когда я на сях пишу мне более-менее понятно во что это скорее всего компилер трансформирует. Без всенепременного вштыривания в ассемблерный кусок каждый раз. С навороченной си++ штукой с какими-нибудь классами и прочими это как-то менее очевидно.[/uquote]А почему должно быть иначе, если вы не знаете язык?

Добавлено after 1 hour 46 minutes 42 seconds:
[uquote="iddqd",url="/forum/viewtopic.php?p=3935715#p3935715"]А зачем C++17?[/uquote]Сообщением выше Reflector показал простую оптимизацию, которая без C++17 не работает.

[Reflector]

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

Спойлер

Код: Выделить всё

const int arr[] = { 20, 40, 10, 50, 30 };

template<const auto& Arr>
struct Transform
{
	constexpr Transform()
	{
		std::copy(Arr, std::end(Arr), arr);
		std::sort(arr, std::end(arr));
	}

	int arr[std::size(Arr)]{};
};

constexpr Transform<arr> trfm;

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

С выключенной оптимизацией(с включенной тем более) следующий код дает абсолютно идентичный бинарник:

Код: Выделить всё

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.

[VladislavS]

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

[Eddy_Em]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3936150#p3936150"]Тут уже без С++20 не обойтись [/uquote]
Ну не маньяки ли?
Сишники как писали с 70-х годов на С, так и пишут. С минимальнейшими изменениями (но можно и вообще без изменений, в том же духе писать; и ничего, gcc соберет).
А вот крестовикам делать нехер, только каждые несколько лет считай заново новый ЯП учить!
С тем и хорош, что практически "надстройка над ассемблером". Очень простой язык (чуть сложней ассемблера, зато писанины поменьше, но при этом остается понимание). А С++ — это вообще дичь лютая!