Форум РадиоКот

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167409#p4167409"]Я тоже заметил, что чем свежей компилятор, тем больше размер прошивки. Странная какая-то мура. По-идее, наоборот должно быть: оптимизатор лучше, следовательно, и кода вряд ли больше будет.[/uquote]
А то, что новый компилятор учитывает требование новых стандартов, ты учёл? Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.

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

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

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

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

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

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

[uquote="tonyk",url="/forum/viewtopic.php?p=4167524#p4167524"]Ведь вполне логично (но не обязательно), что требования новых стандартов порождают генерацию дополнительного кода.[/uquote]
У тебя логика — прямо как деление на нуль!
С чего бы тот же самый код чего-то новое порождал? Новые стандарты лишь позволяют дополнительные конструкции использовать, скажем, массивы переменного размера на стеке. Но с чего бы вдруг жирел код, который написан в соответствии с c79?

[uquote="Dimon456",url="/forum/viewtopic.php?p=4167541#p4167541"]

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

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

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

Добавлено after 6 minutes 54 seconds:
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167545#p4167545"]Но с чего бы вдруг жирел код, который написан в соответствии с c79?[/uquote]Могут быть внесены изменения в стандартные библиотеки. Какие-то UB-шки могут по другому обрабатываться. Да мало ли что ещё.

[uquote="Dimon456",url="/forum/viewtopic.php?p=4167541#p4167541"]я сравнил эффективность создаваемого кода трех компиляторов, cvavr gcc и то что выплевывает iar, iar лидирует во всем.[/uquote]си-компилятор?
Странно... постоянно наблюдаю косяки его оптимизатора. Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции. Вобщем: отстойный оптимизатор у IAR for ARM.
Впрочем: IAR for STM8 ещё хуже оптимизирует. Да и IAR for MSP430 - не фонтан.

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

[uquote="VladislavS",url="/forum/viewtopic.php?p=4167555#p4167555"]Могут быть внесены изменения в стандартные библиотеки. Какие-то UB-шки могут по другому обрабатываться. Да мало ли что ещё.[/uquote]
Какие "стандартные библиотеки" у STM32? Я даже флаг специально ставлю nostdlibs, чтобы уж точно gcc не захотел что-нибудь к моему бинарнику прилинковать!

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167574#p4167574"]Какие "стандартные библиотеки" у STM32?[/uquote]Например memcpy(), memset(), sprintf() и т.п.

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167574#p4167574"]Я даже флаг специально ставлю nostdlibs, чтобы уж точно gcc не захотел что-нибудь к моему бинарнику прилинковать![/uquote]А зачем?

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

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167577#p4167577"]jcxz, чтобы размер бинарника вменяемым был, вестимо.[/uquote]Достаточно просто не использовать эти функции и они не добавятся в ваш бинарник.
Да и что такое "невменяемый размер" по вашему мнению? Такие функции весят десятки-сотни байт. Всего лишь. А если попытаетесь написать их аналоги, то результат будет скорее всего ещё хуже.

Добавлено after 1 minute 1 second:
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4167577#p4167577"]А уж пихать printf в микроконтроллеры - вообще верх маразма![/uquote]Ну тогда я - маразматик.

[uquote="jcxz",url="/forum/viewtopic.php?p=4167572#p4167572"]Когда он даже не оптимизирует, а скорее наоборот - деоптимизирует(!) код, добавляя совершенно ненужные инструкции.[/uquote]Я тоже всегда удивлялся как можно проделать такую гору оптимизаций и вставить "вот это вот сюда". Но иногда у меня закрадываются сомнения, что это делается для учёта особенностей выполнения кода на конкретных ядрах. Ну просто я никогда не поверю, что он не может вот такое "оптимизировать"

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

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

Добавлено after 2 minutes 29 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=4167578#p4167578"]Достаточно просто не использовать эти функции и они не добавятся в ваш бинарник.[/uquote]Эх, наивность

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

[uquote="VladislavS",url="/forum/viewtopic.php?p=4167579#p4167579"]Но иногда у меня закрадываются сомнения, что это делается для учёта особенностей выполнения кода на конкретных ядрах. Ну просто я никогда не поверю, что он не может вот такое "оптимизировать"

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

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

[/uquote]
Это сомнительно. Много раз наблюдал эту деоптимизацию (дублирование загрузок констант). И судя по контексту - явно это не подстройка под ядро. Это просто баг оптимизатора. Я даже в поддержу им как-то писал по этому поводу. Ответили что то типа: "Да, есть такое, но это маловажная особенность. Будет время - поправим. Но скорее всего его не будет".
Ещё другая распространённая деоптимизация 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?

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

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

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

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

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

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

 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-овского оптимизатора, у меня складывается мнение, что авторы этих восторгов просто никогда не заглядывают в листинги. Там же полный бардак.

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

[uquote="tonyk",url="/forum/viewtopic.php?p=4167598#p4167598"]И чё? Ну, вставил какой-то компилятор не самую короткую команду, чё случилось? Сделайте прогон вашей программы, собранной разными компиляторами и сравните время её выполнения и размер. Для вас эти 2-5% разнницы времени и размера так критичны? Вряд ли, ИМХО.[/uquote]Ну вообще-то речь идёт об оптимальности кода. Если для вас это не важно - ну так это ваше дело.

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

Добавлено after 1 minute 49 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=4167601#p4167601"]Там же полный бардак.

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

[uquote="VladislavS",url="/forum/viewtopic.php?p=4167606#p4167606"]jcxz, Там какая-то возня с выравниванием.[/uquote]Сомнительно. Потому как:
1) для выравнивания стандартно используется вставка NOP-ов, которые не выполняются к тому же; а не переходы, которые выполняются, да еще не один такт;
2) там лишние сразу 2 инструкции, а это полное 32-битное слово; т.е. - вставка этих двух переходов никак не влияет выравнивание на 4.

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

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

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

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

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

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

Форум РадиоКот

CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.

Re: CUbeide 1.8 глючит.