Вот и у меня на горизонте замаячил проектик, который видимо желательно реализовывать на MCU семейства ARM. Так что я приступил к их освоению.
Имею (вредную?) привычку после компиляции смотреть листинг, чтобы оценить насколько результат близок к тому, что я написал бы на ассемблере. И, как всегда, смотрю, и сердце кровью обливается. Это даже при том, что я в армовском ассемблере почти ничего не понимаю. Поначалу у меня была сравнительно старая версия иара - 4.40A, и я решил что неоптимальность связанна именно с этим. Поэтому скачал 5.11. Код действительно стал лучше, но не на много. Наиболее непонятны для меня некоторые операции со стеком, которые компилятор вставляет при входе/выходе из процедуры при компиляции в режиме THUMB. Вот достаточно простой пример:

Несмотря на то, что в функции не происходит вызова других функций, зачем-то в стек сохраняется LR. Более того, с ним за компанию сохраняется параметр, передаваемый в функцию, который потом восстанавливается в r3 Зачем????. Насколько я понимаю в данной функции все push/pop можно просто выбросить, без ущерба функциональности. Это у меня результат компиляции с максимальной оптимизацией по размеру. Если же оптимизировать по скорости, то меняется только PUSH {R0,LR} на PUSH {R3,LR}. Здесь R3 сохранили, и его же восстановили. Но зачем?
Это кривость компилятора? или я чего-то не так делаю? Пугает то, что даже такую простую функцию откомпилить нормально не получается. Это чтож будет на реальных программах. Так недолго довести производительность ARM до уровня AVR . Как заставить компилятор генерить более оптимальный код? Или переходить на другой компилятор? Переходить не хотелось бы, привык к ИАРу за годы работы с АВР-ками.

Вот и пишите реальные программы . А то взяли две строчки, где компилятору хорошо умеющему делать глобальные оптимизаци и развернутся негде. Зато вынужденному соблюдать определенные правила компилятотору дополнительно заморочили голову прямым приказом создать совершенно не нужную локальную переменую....
Уберите для начала вот эту хрень:
AT91PS_USART pUSART = AT91C_BASE_US0;
ну THUMB, зачем Вам сдался? Экономить Flash любой ценой? Тогда не жалуйтесь на "цену".

Конечно реальные программы я писать буду, никуда не денусь. Уже занимаюсь. Но согласитесь, что если бы я вам тут привел листинг на 1500 строк вам было бы сложнее его читать, и давать советы. Кроме того, будь функция побольше, вы бы сказали: "ой, ну три лишних инструкции из 100, че вы придираетесь!" и были бы в чем то правы. Но я хочу чтобы этих лишних команд не было! Согласитесь, в данном конкретном случае их быть не должно, более того, именно ТАКИЕ лишние команды совсем не к лицу хоть сколько-нибудь оптимизирующему компилятору. Ведь они СОВСЕМ ничего не делают!
"Хрень" можно убрать, это ничего не меняет. Вставлена она в результате попытки "подсказать" компилятору как сделать код короче. Чтоб он не грузил значение LDR-ом два раза, а использовал загруженное единожды. Правда все равно не помогло, ну да это я еще могу простить. А вот АБСОЛЮТНО ненужные команды меня просто бесят.
Flash я экономлю, но вовсе не "любой ценой". Очень часто, и в данном примере в частности, компиляция в ARM и THUMB дает одинаковое количество команд, иногда в тхумбе всего на пару команд больше. Так что экономия выходит не любой ценой, а "нахаляву". Кроме того атмеловские процы на высоких частотах ядра THUMB команды выполняют быстрее (не так проявляется ограничения из-за медленной флеши). Так что, на мой взгляд, использование THUMB инструкций во многих случаях очень даже уместно.

Повторятся трижды было уж слишком

Продолжайте хотеть .

Не пишите такие грандиозные "фунции", ползуйтесь inline.

Займитесь чем-нибудь другим , например, выращиванием капусты, говорят успокаивает.
Смотрим на аналогичную функцию:



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

... в ARM-режиме
Artem_Petrik в чём-то прав. Трудно объяснить такое поведение компилятора.

Ага, и без interwork. И без халявы.

Для этого наверное стоит смотреть более подробно, какие общие правила игры были навязаны компилятору.
Thumb:

Пардон, что то сегодня у меня инет жутко глючит. Пол часа ответ посылал. Кликаю отправить - думает пару минут, и выдает ошибку. Оказывается три раза все же прошло.
Надо отметить, что ваш пример выглядит красиво. А под какой это проц? Дело в том, что я обратил внимание на то, что атмеловские инклуды с описанием периферии радикально отличаются от инклудов других производителей. И пока у меня была версия 4.40А именно с этим были связаны многие проколы в оптимизации. Так при записи в регистры одной и той же периферии, вместо адресации со смещением компилятор грузил адрес LDR-ом каждый раз. Впрочем, вроде в версии 5.11 это прошло. Но может не совсем?
Кстати, нашол у себя древний (даже про SAM7X не знает еще) кейловский микровижн. Пока с инета (медленно )качается более новая версия, решил скомпилить под ним. CARM тоже генерит чертий-что, а вот real view выдал такое


Кажись покороче будет чем даже ваш пример! Так что при нормальном компиляторе "жаловаться на цену" не приходится.

Ну, это другое дело
А кто-нить знает, почему использована команда MOVS R1,#+64, а не MOV R1,#+64 ???

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

LPC2xxx. Хидеры обычно пишу/дописываю свои, дабы иметь переносимые не зависеть от компилятора.
Atmel-овский стиль, конечно максимально дебильный из всех возможных

Да я пока не очень то увлекаюсь выбором компиляторов. Есть сильное желание все-же пользоваться ИАР-ом. Просто он иногда меня сильно удивляет. Впрочем ваш LPC-шный пример выглядит прилично, так что возможно и впрямь проблема в неадекватном хидере. У меня AT91SAM7X256.
Правда идея самому писать хидер меня несколько пугает. На мой взгляд, более идиотсое занятие себе вообще трудно придумать. Но слегка подправить попробую, вдруг поможет.
Конечно соглашусь, что данный пример вовсе не является показателем. Просто на данном этапе освоения данного семейства контроллеров я пока пишу такие вот небольшие подпрограммки, не столько с целью их дальнейшего использования, сколько с целью выработать стиль написания, который не будет сильно запутывать компилятор, и позволит ему генерировать нормальный код, без маразмов. Вот это-то у меня пока и не получается

Пользуйтесь. V5 очень приличный. V4 часто немного проигрывал тому-же Keil (который АРМ ), особенно на библиотеках, то теперь идут практически ноздря в ноздрю. До кучи к ним GCC - тоже нормальный. Остальные явно отстают от этой троицы.

Почему? Все сразу писать не надо. А постепенно, да еше имея какую-никакую болванку пороблем не вижу, тем более, что читать все равно надо .

Насчет RealView советую серьёзно подумать. Особенно если нет стойкой привычки к IAR'у

Дело не столько в хидерах, сколько в стиле написания программы:







Это вполне нормальное занятие, к тому же довольно легко поддающееся автоматизации.
А у Atmel'а в хидерах и ошибки встречаются (не на SAM7X256).

Стоп! Что-то у меня лыжи не едут! Откомпилил у себя ваш вариант под ЛПЦ, (правда у меня не поняло выражение LSR_TEMT, пришлось заменить на 0x40) Сейчас у меня EWARM-EW-WEB 5.11


и получил тот же маразм:

Значит у меня все же что-то или с настройками компилятора, или одно из двух.
Подскажите какая у вас версия и настройки компилятора. Не успокоюсь, пока не получу у себя такойже код как у вас!

Оптимизация-то включена вообще?

Да, Level = High, все галочки стоят. От варианта Speed/size/balanced практически ничего не меняется.