Я тоже заметил, что чем свежей компилятор, тем больше размер прошивки. Странная какая-то мура. По-идее, наоборот должно быть: оптимизатор лучше, следовательно, и кода вряд ли больше будет.
А то, что новый компилятор учитывает требование новых стандартов, ты учёл? Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.
Добавлено after 14 minutes 26 seconds:
VladislavS писал(а):
IAR, GCC и ARM v6 совершенно разные компиляторы со своими достоинствами и недостатками каждый и оценивать/сравнивать их по размеру прошивки - верх глупости.
Совершенно верно. Более того, есть даже рекомендации о стиле и программных конструкциях, которые лучше применять в программе в зависимости от используемого компилятора, чтобы получить максимально компактны и быстрый код. Местами разница в скорости и размере кода бывает внушительной, но, как обычно, выигрыш в одном оборачивается проигрышем в другом. Если уж так критичен каждый байт и такт, то, вне зависимости от используемого компилятора, придётся вдумчиво изучать рекомендации по повышению качества генерируемого кода конкретным компилятором. ИМХО, это проще и перспективнее, чем писать на ассемблере.
оценивать/сравнивать их по размеру прошивки - верх глупости
Ну смотри, я скрин сохранил, еще раз высунешься с тупым сравнением ассемблерного кода, я тебе его приляпаю.
Это я в stm не знаю ассемблер, но знаю хорошо в avr, и я сравнил эффективность создаваемого кода трех компиляторов, cvavr gcc и то что выплевывает iar, iar лидирует во всем. Я бы и сам перешел на iar, но 2 Гига мусора на жестком диске - это просто какой-то феномен, notepad и то куда лучше.
Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.
У тебя логика — прямо как деление на нуль! С чего бы тот же самый код чего-то новое порождал? Новые стандарты лишь позволяют дополнительные конструкции использовать, скажем, массивы переменного размера на стеке. Но с чего бы вдруг жирел код, который написан в соответствии с c79?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
оценивать/сравнивать их по размеру прошивки - верх глупости
Ну смотри, я скрин сохранил, еще раз высунешься с тупым сравнением ассемблерного кода, я тебе его приляпаю.
Мальчик, ты дурак? Я показываю ассемблерные листинги конкретных кусочков С/С++ кода, во что он компилируется. Как разные конструкции С++ порождают более или менее эффективный код. Ничего общего с размером прошивки это не имеет.
Ещё, потому что частенько приходится показывать, что "портянки непонятного С++ когда" не занимают всю флэшь, а компилируются в более эффективный код по сравнению с "ясным и понятным".
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
я сравнил эффективность создаваемого кода трех компиляторов, cvavr gcc и то что выплевывает iar, iar лидирует во всем.
си-компилятор? Странно... постоянно наблюдаю косяки его оптимизатора. Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции. Вобщем: отстойный оптимизатор у IAR for ARM. Впрочем: IAR for STM8 ещё хуже оптимизирует. Да и IAR for MSP430 - не фонтан.
Добавлено after 3 minutes 16 seconds: PS: Так что (имха): неоптимальность кода - как раз одна из главных слабых сторон IAR.
Последний раз редактировалось jcxz Вт янв 25, 2022 11:06:48, всего редактировалось 1 раз.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Могут быть внесены изменения в стандартные библиотеки. Какие-то UB-шки могут по другому обрабатываться. Да мало ли что ещё.
Какие "стандартные библиотеки" у STM32? Я даже флаг специально ставлю nostdlibs, чтобы уж точно gcc не захотел что-нибудь к моему бинарнику прилинковать!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
jcxz, чтобы размер бинарника вменяемым был, вестимо. А уж пихать printf в микроконтроллеры - вообще верх маразма!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
jcxz, чтобы размер бинарника вменяемым был, вестимо.
Достаточно просто не использовать эти функции и они не добавятся в ваш бинарник. Да и что такое "невменяемый размер" по вашему мнению? Такие функции весят десятки-сотни байт. Всего лишь. А если попытаетесь написать их аналоги, то результат будет скорее всего ещё хуже.
Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции.
Я тоже всегда удивлялся как можно проделать такую гору оптимизаций и вставить "вот это вот сюда". Но иногда у меня закрадываются сомнения, что это делается для учёта особенностей выполнения кода на конкретных ядрах. Ну просто я никогда не поверю, что он не может вот такое "оптимизировать"
Достаточно просто не использовать эти функции и они не добавятся в ваш бинарник.
Эх, наивность Тот же memcpy gcc умеет сам вставлять, где паттерны копирования встречает. Давно пора смириться, с оптимизирующим компилятором ваша программа вам не принадлежит
Но иногда у меня закрадываются сомнения, что это делается для учёта особенностей выполнения кода на конкретных ядрах. Ну просто я никогда не поверю, что он не может вот такое "оптимизировать"
Это сомнительно. Много раз наблюдал эту деоптимизацию (дублирование загрузок констант). И судя по контексту - явно это не подстройка под ядро. Это просто баг оптимизатора. Я даже в поддержу им как-то писал по этому поводу. Ответили что то типа: "Да, есть такое, но это маловажная особенность. Будет время - поправим. Но скорее всего его не будет". Ещё другая распространённая деоптимизация IAR:
На кой он тут впендюривает MVNS? Почему не использует BICS? Заметил: если в функции встречается y &= ~x только один раз -> используется BIC. Если >1 раза: вычисляется промежуточная переменная ~x, для неё занимается дополнительный регистр и используется AND. На кой - непонятно.
IAR совершенно не использует LDM/STM. Создавая портянки из LDR/STR там где можно поставить одну LDM/STM.
Очень часто IAR использует более длинные (4-байтовые) инструкции совершенно неоправданно. Там где можно использовать 2-байтовые. Есть и много других косяков оптимизатора. Постоянно наблюдаю.
И чё? Ну, вставил какой-то компилятор не самую короткую команду, чё случилось? Сделайте прогон вашей программы, собранной разными компиляторами и сравните время её выполнения и размер. Для вас эти 2-5% разнницы времени и размера так критичны? Вряд ли, ИМХО.
In section .text, align 2, keep-with-next ?Subroutine0: (+1) 0xF381 0x8810 MSR PRIMASK,R1 0x4770 BX LR ;; return
Вот накой там 3 инструкции перехода подряд??? Там же достаточно было сделать сразу: BNE ?Subroutine0 не создавая дополнительную метку OsTaskResume_2. OsTaskResume_2 больше никем не используется (можно было бы подумать, что она используется для удлинения переходов из каких-то дальних точек, но нет - на неё есть только один переход).
Так что - когда слышу восторги по поводу IAR-овского оптимизатора, у меня складывается мнение, что авторы этих восторгов просто никогда не заглядывают в листинги. Там же полный бардак.
И чё? Ну, вставил какой-то компилятор не самую короткую команду, чё случилось? Сделайте прогон вашей программы, собранной разными компиляторами и сравните время её выполнения и размер. Для вас эти 2-5% разнницы времени и размера так критичны? Вряд ли, ИМХО.
Ну вообще-то речь идёт об оптимальности кода. Если для вас это не важно - ну так это ваше дело.
Сомнительно. Потому как: 1) для выравнивания стандартно используется вставка NOP-ов, которые не выполняются к тому же; а не переходы, которые выполняются, да еще не один такт; 2) там лишние сразу 2 инструкции, а это полное 32-битное слово; т.е. - вставка этих двух переходов никак не влияет выравнивание на 4.
Возможно в микрокоде инструкции выполняются не в такой последовательности. LDR.W R4,??DataTable2 MOVS R0,#+2 STR R0,[R4, #+0] MOVS R1,#+2 STR R1,[R4, #+4] наблюдается шаг адр.регистра и шаг в памяти, может пишет за одно обращение
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения