CUbeide 1.8 глючит.

tonyk

Я тоже заметил, что чем свежей компилятор, тем больше размер прошивки. Странная какая-то мура. По-идее, наоборот должно быть: оптимизатор лучше, следовательно, и кода вряд ли больше будет.

А то, что новый компилятор учитывает требование новых стандартов, ты учёл? Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.

Добавлено after 14 minutes 26 seconds:

VladislavS писал(а):

IAR, GCC и ARM v6 совершенно разные компиляторы со своими достоинствами и недостатками каждый и оценивать/сравнивать их по размеру прошивки - верх глупости.

Совершенно верно. Более того, есть даже рекомендации о стиле и программных конструкциях, которые лучше применять в программе в зависимости от используемого компилятора, чтобы получить максимально компактны и быстрый код. Местами разница в скорости и размере кода бывает внушительной, но, как обычно, выигрыш в одном оборачивается проигрышем в другом. Если уж так критичен каждый байт и такт, то, вне зависимости от используемого компилятора, придётся вдумчиво изучать рекомендации по повышению качества генерируемого кода конкретным компилятором. ИМХО, это проще и перспективнее, чем писать на ассемблере.

Реклама

Dimon456

VladislavS писал(а):

оценивать/сравнивать их по размеру прошивки - верх глупости

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

Это я в stm не знаю ассемблер, но знаю хорошо в avr, и я сравнил эффективность создаваемого кода трех компиляторов, cvavr gcc и то что выплевывает iar, iar лидирует во всем.
Я бы и сам перешел на iar, но 2 Гига мусора на жестком диске - это просто какой-то феномен, notepad и то куда лучше.

Реклама

Eddy_Em

tonyk писал(а):

Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.

У тебя логика — прямо как деление на нуль!
С чего бы тот же самый код чего-то новое порождал? Новые стандарты лишь позволяют дополнительные конструкции использовать, скажем, массивы переменного размера на стеке. Но с чего бы вдруг жирел код, который написан в соответствии с c79?

Реклама

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

VladislavS

Dimon456 писал(а):

VladislavS писал(а):

оценивать/сравнивать их по размеру прошивки - верх глупости

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

Мальчик, ты дурак? Я показываю ассемблерные листинги конкретных кусочков С/С++ кода, во что он компилируется. Как разные конструкции С++ порождают более или менее эффективный код. Ничего общего с размером прошивки это не имеет.

Ещё, потому что частенько приходится показывать, что "портянки непонятного С++ когда" не занимают всю флэшь, а компилируются в более эффективный код по сравнению с "ясным и понятным".

Добавлено after 6 minutes 54 seconds:

Eddy_Em писал(а):

Но с чего бы вдруг жирел код, который написан в соответствии с c79?

Могут быть внесены изменения в стандартные библиотеки. Какие-то UB-шки могут по другому обрабатываться. Да мало ли что ещё.

Реклама

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

jcxz

Dimon456 писал(а):

я сравнил эффективность создаваемого кода трех компиляторов, cvavr gcc и то что выплевывает iar, iar лидирует во всем.

си-компилятор?
Странно... постоянно наблюдаю косяки его оптимизатора. Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции. Вобщем: отстойный оптимизатор у IAR for ARM.
Впрочем: IAR for STM8 ещё хуже оптимизирует. Да и IAR for MSP430 - не фонтан.

Добавлено after 3 minutes 16 seconds:
PS: Так что (имха): неоптимальность кода - как раз одна из главных слабых сторон IAR.

Реклама

Реклама

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Eddy_Em

VladislavS писал(а):

Могут быть внесены изменения в стандартные библиотеки. Какие-то UB-шки могут по другому обрабатываться. Да мало ли что ещё.

Какие "стандартные библиотеки" у STM32? Я даже флаг специально ставлю nostdlibs, чтобы уж точно gcc не захотел что-нибудь к моему бинарнику прилинковать!

Реклама

jcxz

Eddy_Em писал(а):

Какие "стандартные библиотеки" у STM32?

Например memcpy(), memset(), sprintf() и т.п.

Eddy_Em писал(а):

Я даже флаг специально ставлю nostdlibs, чтобы уж точно gcc не захотел что-нибудь к моему бинарнику прилинковать!

А зачем?

Реклама

Eddy_Em

jcxz, чтобы размер бинарника вменяемым был, вестимо.
А уж пихать printf в микроконтроллеры - вообще верх маразма!

Реклама

jcxz

Eddy_Em писал(а):

jcxz, чтобы размер бинарника вменяемым был, вестимо.

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

Добавлено after 1 minute 1 second:

Eddy_Em писал(а):

А уж пихать printf в микроконтроллеры - вообще верх маразма!

Ну тогда я - маразматик. :)))

Реклама

VladislavS

jcxz писал(а):

Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции.

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

Код:

  LDR.W    R4,??DataTable2
  MOVS     R0,#+2         
  STR      R0,[R4, #+0]   
  MOVS     R1,#+2         
  STR      R1,[R4, #+4]   

Добавлено after 2 minutes 29 seconds:

jcxz писал(а):

Достаточно просто не использовать эти функции и они не добавятся в ваш бинарник.

Эх, наивность

Тот же memcpy gcc умеет сам вставлять, где паттерны копирования встречает. Давно пора смириться, с оптимизирующим компилятором ваша программа вам не принадлежит

jcxz

VladislavS писал(а):

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

Код:

  LDR.W    R4,??DataTable2
  MOVS     R0,#+2         
  STR      R0,[R4, #+0]   
  MOVS     R1,#+2         
  STR      R1,[R4, #+4]   

Это сомнительно. Много раз наблюдал эту деоптимизацию (дублирование загрузок констант). И судя по контексту - явно это не подстройка под ядро. Это просто баг оптимизатора. Я даже в поддержу им как-то писал по этому поводу. Ответили что то типа: "Да, есть такое, но это маловажная особенность. Будет время - поправим. Но скорее всего его не будет".
Ещё другая распространённая деоптимизация IAR:

Код:

void Bug1(OsEvent *pe, u32 j)                           
{                                                       
  pe->waitMap &= ~j;                                    
        _Z4Bug1P7OsEventm: (+1)                         
 0x6802             LDR      R2,[R0, #+0]               
 0x43C9             MVNS     R1,R1                      
 0x400A             ANDS     R2,R1,R2                   
 0x6002             STR      R2,[R0, #+0]               
  os.rdyMap &= ~j;                                      
 0x.... 0x....      LDR.W    R0,??DataTable16_1         
 0x6842             LDR      R2,[R0, #+4]               
 0x4011             ANDS     R1,R1,R2                   
 0x6041             STR      R1,[R0, #+4]               
}                                                       
 0x4770             BX       LR               ;; return 

На кой он тут впендюривает MVNS? Почему не использует BICS? :dont_know:

Заметил: если в функции встречается y &= ~x только один раз -> используется BIC. Если >1 раза: вычисляется промежуточная переменная ~x, для неё занимается дополнительный регистр и используется AND. На кой - непонятно.

IAR совершенно не использует LDM/STM. Создавая портянки из LDR/STR там где можно поставить одну LDM/STM.

Очень часто IAR использует более длинные (4-байтовые) инструкции совершенно неоправданно. Там где можно использовать 2-байтовые.
Есть и много других косяков оптимизатора. Постоянно наблюдаю.

tonyk

И чё? Ну, вставил какой-то компилятор не самую короткую команду, чё случилось? Сделайте прогон вашей программы, собранной разными компиляторами и сравните время её выполнения и размер. Для вас эти 2-5% разнницы времени и размера так критичны? Вряд ли, ИМХО.

jcxz

Или такое например:

Код:

 if (!(i & OS_STAT_PEND_ANY | ptcb->dly)) { //задача готова исполняться?    
0xF002 0x0207      AND      R2,R2,#0x7                                      
0x6803             LDR      R3,[R0, #+0]                                    
0x431A             ORRS     R2,R3,R2                                        
0xD100             BNE.N    ??OsTaskResume_2                                
   os.rdyMap |= OS_TASK_PRIOMAP(ptcb->prio, ptcb->prioMap);                 
0x....             B.N      ?Subroutine2                                    
   EXIT_CRT_SECTION();                                                      
   OsSched();                                                               
 } else EXIT_CRT_SECTION();                                                 
       ??OsTaskResume_2: (+1)                                               
0x....             B.N      ?Subroutine0                                    
                                                                            
                                                                            
                   In section .text, align 2, keep-with-next                
       ?Subroutine2: (+1)                                                   
0x.... 0x....      LDR.W    R2,??DataTable16_1                              
0x6900             LDR      R0,[R0, #+16]                                   
0x6853             LDR      R3,[R2, #+4]                                    
0x4318             ORRS     R0,R0,R3                                        
0x6050             STR      R0,[R2, #+4]                                    
                   REQUIRE ??Subroutine7_0                                  
                   ;; // Fall through to label ??Subroutine7_0              
                                                                            
                   In section .text, align 2, keep-with-next                
       ??Subroutine7_0: (+1)                                                
0xF381 0x8810      MSR      PRIMASK,R1                                      
0x....             B.N      _Z7OsSchedv                                     
                                                                            
                   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-овского оптимизатора, у меня складывается мнение, что авторы этих восторгов просто никогда не заглядывают в листинги. Там же полный бардак. :dont_know:

VladislavS

tonyk, не говорите нам что делать и (дальше сами знаете)...

jcxz

tonyk писал(а):

И чё? Ну, вставил какой-то компилятор не самую короткую команду, чё случилось? Сделайте прогон вашей программы, собранной разными компиляторами и сравните время её выполнения и размер. Для вас эти 2-5% разнницы времени и размера так критичны? Вряд ли, ИМХО.

Ну вообще-то речь идёт об оптимальности кода. Если для вас это не важно - ну так это ваше дело.

VladislavS

jcxz, Там какая-то возня с выравниванием.

Добавлено after 1 minute 49 seconds:

jcxz писал(а):

Там же полный бардак. :dont_know:

А где не бардак? При всём этом код из-под IAR таки быстрее.

jcxz

VladislavS писал(а):

jcxz, Там какая-то возня с выравниванием.

Сомнительно. Потому как:
1) для выравнивания стандартно используется вставка NOP-ов, которые не выполняются к тому же; а не переходы, которые выполняются, да еще не один такт;
2) там лишние сразу 2 инструкции, а это полное 32-битное слово; т.е. - вставка этих двух переходов никак не влияет выравнивание на 4.

a797945

Возможно в микрокоде инструкции выполняются не в такой последовательности.
LDR.W R4,??DataTable2
MOVS R0,#+2
STR R0,[R4, #+0]
MOVS R1,#+2
STR R1,[R4, #+4]
наблюдается шаг адр.регистра и шаг в памяти, может пишет за одно обращение

VladislavS

a797945, вы преувеличиваете возможности Cortex-M.

Код:

        LDR.W    R4,??DataTable2
        MOV      R0,#+256       
        STR      R0,[R4, #+0]   
        STR      R0,[R4, #+4] 

Константу 256 уже дороже загружать и тут уже всё как ожидается.

a797945

я предположил, поскольку чтение/запись блока регистров базовая "железка" в обслуживании прерываний

CUbeide 1.8 глючит.

Кто сейчас на форуме