Здравствуйте.

Раньше никогда на C под железо не писал, только на ассемблере. Но жизнь показывает, что для ARM писать все на asm не актуально. Начал смотреть, какой код генерирует компилятор. Вот для примера две строки на C:



Обе эти строки эквивалентны с точки зрения выполнения программы на С (т.е. будет 2000 шагов). Компилятор генерирует следующий код:

\ main:
\ ??main_0:
\ 00000000 CF00A0E3 MOV R0,#+207
\ 00000004 700E80E3 ORR R0,R0,#0x700
\ 00000008 000000EA B ??main_1
\ ??main_2:
\ 0000000C 010040E2 SUB R0,R0,#+1
\ ??main_1:
\ 00000010 000050E3 CMP R0,#+0
\ 00000014 FCFFFF5A BPL ??main_2
19
20 //AT91C_BASE_PIOB->PIO_CODR = 1 << 22;
21 for(waiting_time = 0; waiting_time < 2000; waiting_time++) ;
\ 00000018 0000A0E3 MOV R0,#+0
\ ??main_3:
\ 0000001C 7D0E50E3 CMP R0,#+2000
\ 00000020 F6FFFFAA BGE ??main_0
\ 00000024 010080E2 ADD R0,R0,#+1
\ 00000028 FBFFFFEA B ??main_3



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

Поиграйтесь с настройками оптимизации. При различном уровне - будет различный код.

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

Забавно, а у меня комилятор в обоих случаях сгенерил одно и то же:


Это IAR 4.40, С++, максимальная оптимизация на скорость. Надо сказать, этот компилятор оставляет хорошее впечатление.
А вообще лучше не лезть в дела компилятора, а заниматься более интересными вещами, то есть написанием программ. Проверять сгенерированный код надо только тогда, когда не хватает памяти или скорости. Иначе не останется времени на отдых :-)

Примерно о таком коде я и мечтал, если бы еще и NOP выкинуть... Если убрать пустую операцию, то весь цикл попадает под нож оптимизатора при максимальной оптимизации, во всех других режимах оптимизаци цикл сохраняет первозданное уродство с тремя переходами.

Вопрос в том, что при желании сделать например, функцию


Этот самый Delay будет прямо зависить от режима оптимизации, и вообще улетит при максимальной.

Следующий вопрос, а как-нибудь вообще можно объявить функцию на asm как inline? Или сделать макрос на asm для использования в C-коде?

Если писать правильно, то не попадает.
А если так:
При разном уровне действительно возможно различное время выполнения, но можно ведь для этой конкретной функции выставить желаемый уровень оптимизации с помощью #pragma.
В gcc вроде да, в IAR - точно нет. Про остальные не знаю.

Попробуйте так:

#define DELAY(N) __asm("mov R0,#" #N "\nSUBS R0,R0,#1\nBNE .-4");

И при использовании такого макроса компилятор гарантированно не будет использовать R0 в своих целях?
Что-то я ничего внятного в документации IAR по поводу INLINE ASSEMBLER не нашел, кроме того, что его лучше избегать.

Не будет и много чего другого не будет Верный способ угробить оптимизацию - посему действительно не стоит использовать такие вставки....

Похоже самый надежный способ, это тот, который рекомендовал Сергей Борщ, это принудительно задавать уровень оптимизации для некоторых функций, используя при этом volatile.

Еще вопрос, как нибудь в IAR можно узнать, за сколько тактов процессора выполнится кусок кода? А то в некоторых случаях это не совсем очевидно (некоторые команды asm заменяются двумя, обнуление конвеера и т.д.)

Если я правильно понял, нужно получить малые задержки. Предлагаю для этих целей написать функцию на ассемблере и вызывать её из Си. Если пытаться добиться этого при помощи компилятора, то результат будет зависеть от опций компилятора и, возможно, его версии, что не очень приятно (проапгрейдили компилятор - будьте готовы к тому, что старый код перестанет работать).
Время выполнения кода зависит от модели процессора и задержек при доступе к памяти. Для процессора ARM7TDMI времена выполнения инструкций указаны в "ARM7TDMI Technical Reference Manual":
http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf (2 MB)
О задержках при доступе к памяти: см. документацию на используемый микроконтроллер.

Просто для совсем маленьких функций накладные расходы по вызову и передаче параметров неприятны. Если бы можно было бы функцию на asm сделать inline, было бы здорово.

Так #pragma optimize не позволяет повысить уровень оптимизации, что это за лажа такая?

И наличия MAM и наличия Кэш и эффективности работы оных а еще DMA захватит шину . Короче, лучше навсегда выкиньте из головы желание узнать для более-менее современых контроллеров "точное" время исполнения чего-либо.


Изъясняйтесь конкретнее.

Я имел в виду, что любимой избранной функции нельзя задать жестко уровень оптимизации. Т.е. нельзя написать какую-нибудь простенькую функцию, определить для нее максимальную оптимизацию и наслаждаться, при условии, что остальной проект выполнен без оптимизации.