Плюсы ИАР Опции

[FormatCft]

Всем здравствуйте.
===
Я смотрю в основном люди пользуют иар. Даже ветка выделена специальная.
Особо интересно мнение тех, кто пользовался другими компиляторами. В чем его основные достоинства и недостатки?
===
Всем заранее спасибо за ответы.

[Baser]

Плюсы в том, что ИАР - это один из лидеров в своей области. Поэтому:
- его компиляторы, во-первых, работают,
- а во-вторых, работают достаточно хорошо

Ну, а если серьезно, то компилятор многоплатформенный, поддерживает множество семейств МК.
Денег у фирмы много, что позволяет быстро выпускать новые версии, достаточно активно реагировать на новые веяния и т.д. И что немаловажно, не жлобиться на хорошие демо-версии.

Но, если взглянуть шире (ширее ), то можно обнаружить достаточно много семейств МК, для которых самыми популярными (и лучшими) компиляторами являются отнюдь не продукты от ИАР...

[FormatCft]

Плюсы в том, что ИАР - это один из лидеров в своей области. Поэтому:
- его компиляторы, во-первых, работают,
- а во-вторых, работают достаточно хорошо

Ну, а если серьезно, то компилятор многоплатформенный, поддерживает множество семейств МК.
Денег у фирмы много, что позволяет быстро выпускать новые версии, достаточно активно реагировать на новые веяния и т.д. И что немаловажно, не жлобиться на хорошие демо-версии.

Но, если взглянуть шире (ширее ), то можно обнаружить достаточно много семейств МК, для которых самыми популярными (и лучшими) компиляторами являются отнюдь не продукты от ИАР...

===
Мне много не нужно. АРМы от NXP и всё пожалуй на данный момент моей жизни.
===
Для армов, я так понял, лучшим является кейл (код получается более компактным и быстрым + некоторые удобные фишки для работы).
[С моей точки зрения Кейл слегка неудобен в использовании (может непривычней).
Поэтому решил с него вернуться обратно на CW (который собственно не без глюков, хотя и незначительных. Но спать спокойно не дают)]
-----
Но эта быстрота в пару процентов никуда не упирается как правило.
Да и флеши всегда остается с большим запасом.
===
Так что главным является удобство работы в среде:
-удобство интерфейса;
-удобный поиск;
-удобный мониторинг состояние процессора;
-возможность смотреть что с переферией;
-что с памятью и как и что в ней лежит;
-удобная отладка с возможностью налету просматривать состояние переменных;
===
Еще плюсом ИАРа является то, что на нем сидит основная толпа разработчиков, поэтому есть у кого спросить.
===
В CW есть полезная функция Symbol Browser, в котором:
1) показываются все сегменты;
2) показываются константы в флешке с адресами и размером;
3) статические переменные в озу с адресами и размером;
4) ...
Есть ли такая в ИАР?
===
Плюс к тому некоторые изменения CW крайне редки, ИМХО. Чувствуется некоторая запущенность в свободное плавание.
===
Вопросы к тем кто имеет опыть пользования и того и другого:
1) Может на счет кейла сильно ошибся?
2) Что лучше: кейл или иар?
===

[MALLOY2]

Для армов, я так понял, лучшим является кейл (код получается более компактным и быстрым + некоторые удобные фишки для работы).

тут еще спорный вопрос

написал я небольшой тестовый код посммотреть какой IAR и Keil делают код для Cortex

Код

volatile int z = 1000;
volatile int i;
  
int testA(int za)
{
  if (za>= 500)
  {
     z = z /13;
     return(-10);
  }
else return(za+10);  
}

  
int main(void)
  {
    int tz;
    tz = 1000;
    while(tz--)
      {
        i = testA(tz+z);
            if (i) z = 1;
            else z = 0;
      };
  }

Код полный боред. Код использует переменные volatile в коде и в функции. Рузультат IAR ~18000 циклов Keil ~26000, это лучшие показатели при выборе параметров компиляции.

[MrYuran]

С кейлом не сравнивал, но по сравнению с GCC код у IARа получается более компактным.
Но есть по-моему у ИАРа жирный минус - откровенно слабая ИДЕ, по нынешним временам и за такие бабки можно бы и поднавернуть немного.

[Rst7]

Но есть по-моему у ИАРа жирный минус - откровенно слабая ИДЕ, по нынешним временам и за такие бабки можно бы и поднавернуть немного.

У гнуся IDE нет вообще, так что те, кому не нравится иаровская среда могут прикрутить IARBuild к любому понравившемуся редактору (их масса, на любой размер и глубину )

[zltigo]

Но есть по-моему у ИАРа жирный минус - откровенно слабая ИДЕ...

Не видел ее уже года полтора , а компилятор пользую ежедневно....

[Proton]

Не видел ее уже года полтора , а компилятор пользую ежедневно....

Можно поинтересоваться в какой среде Вы выполняете отладку программ? Для написания кода действительно лучше использовать специализированые редакторы типа SourceInsight, однако альтернатив отладчика IARа я не знаю.

[zltigo]

однако альтернатив отладчика IARа я не знаю.

Сложность программ начиная с некоторого уровня делает внутрисхемную отладку практически бесполезной. Более того, и достаточно простые программы начинающих отладчик провоцирует писать заплаточным методом - вот тут x + y получилось 3, хотели 4, так сейчас допишем + 1, потом ежели где вылезет там отнимем -1..... В результате макроме получаем. Самый мощный отладчик это голова - ее и надо использовать прежде всего.
Набор отладочных внутрисхемных отладочных средств на все свои контроллеры имею, но не пользуюсь. Консоль много информативнее. Если речь идет об отладке куска сишного кода, так его можно и на кроссплатформе отлаживать. Ну а если припрет, то, как здесь уже неоднократно писалось - создать IAR проект содержащий только объектники с отладочной информацией и отлаживайтеcь...

[FormatCft]

Сложность программ начиная с некоторого уровня делает внутрисхемную отладку практически бесполезной. Более того, и достаточно простые программы начинающих отладчик провоцирует писать заплаточным методом - вот тут x + y получилось 3, хотели 4, так сейчас допишем + 1, потом ежели где вылезет там отнимем -1.....

Закон сохранения гвоздей называется )) Код не доска или можно сказать и доска, но только в 10ти мерном пространстве, поэтому не так просто иногда понять в чем дело. Поэтому и нужны дополнительные инструменты, которые преобразуют эту страну чудес в обычный почти объективный мир (чем больше таких инструментов, тем лучше).
===
К тому же программист это не столяр, который может 100 раз измерить своим трезвым глазом и один раз отрезать кому-нибудь (чего-нибудь). Поэтому чаще всего программа даже у людей с опытом, хочешь не хочешь, похожа на ежа из гвоздей если не видеть что происходит в области inside.
===
И не отрицаю, что у некоторых голова как глобус (с масштабом 1:1), который может предсказания давать для этого причудливого мира. С джидаями начального и среднего уровня всё иначе (к числу их собственно и относится основная толпа).
===
И прошу не счесть, что: одна таблетка помогает от бессоницы, но плохо. Две помагают хорошо. А три помагают навсегда...
Просто хочется иметь очень широкий спектр инструментов: начиная от пилки для ногтей и кончая пилой "дружбой" для особо-запущенных случаев.
===
!ИМХО!
===
Дак всё же. Кейл или Иар?

[scout]

Сложность программ начиная с некоторого уровня делает внутрисхемную отладку практически бесполезной. Консоль много информативнее.

zltigo, а можете пояснить свою мысль? Чем принципиально консоль от окна отладчика отличается?
К тому же Uart-ы бывают все заняты...

Сообщение отредактировал scout - Dec 18 2008, 14:03

[MALLOY2]

Чем принципиально консоль от окна отладчика отличается?

Тем что консоль работает в контексте программы и не влияет на работу остальных модулей программы, если конечно правильно написана и требования к скорости вывода отладочной информации соответствуют скорости вывода консоли. Консоли разные бывают необязательно для этого использовать уарт, но как правило используется он из за его простоты, но у него есть ограничения по скорости, хотя если применять USB переходник то скорость можно поднять и выше 115200. Если в устройстве есть изернет можно его как консоль использовать, если конечно не идет отладка самого стека .

Что косается отладчика внутрисхемного, так он сбивает работу устройства, отладчик останавливает процессор! а не время, по этому когда вы смотрите информацию время идет большая часть периферии продолжает работать, сеть шлет вам пакеты, и т.д. в общем реалтайм уже отсутствует, из за этого некоторые вещи невозможно отладить!. да и скорость у него низкая попробуйте посмотреть 2 -килобайта массив ? мало - того что среда тормозить начинает, так еще и с программой непонятно что творится будет, а через консоль это раз и файл записан и смотрите на него как хотите. Еще отладчик накладывает жесткие требования к выводу информации, в консоли выводите так как вам нужно или на сколько позволяют ресурсы.

[zltigo]

Добавлю одно из важных отличий - ведется лог событий той или иной заказанной степени детализации и видны причинно следственные связи. Причем все это и без подключенного отладчика в реальных объектовых условиях эксплуатации.

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

Так я, если внимательно читали, их и имею. Только ногти не запускаю так сильно, что-бы бензопила потребовалась . Реально, мне пригодился-бы отладчик один раз - когда изучал, например, ARM, писал порт операционки. Вот тогда она у меня разок зациклилась намертво и пришлось искать проблему откатами и делением пустыни пополам. Но тогда в эту первую неделю отладчик мне еще не привезли. А когда уже системка поднялась, консольнормальная буферизированая, обработчик exceptions... отладчик и не нужен практически. Для AVR пользовался (кроме загрузки)тоже один раз для совсем мелюзги. PIC - только для загрузки. Больше всего пользовал BlackFin-овский.

[scout]

MALLOY и zltigo спасибо за информацию.
Сейчас как раз настало то время, когда надо отладить пару девайсов, а отладчика нет.
Попробую написать универсальный модуль для вывода отладочной информации...

Кстате, а в качестве терминальной программы что пользуете? Hyper Terminal?

[FormatCft]

MALLOY и zltigo спасибо за информацию.
Сейчас как раз настало то время, когда надо отладить пару девайсов, а отладчика нет.
Попробую написать универсальный модуль для вывода отладочной информации...

Кстате, а в качестве терминальной программы что пользуете? Hyper Terminal?

GemorTerminal на самом деле это. Совершенно не удобен. Лучше использовать что-нибудь по лучше. Или лучше написать самому (лично сам своё использую).

[zltigo]

Кстате, а в качестве терминальной программы что пользуете? Hyper Terminal?

Упаси бог! Если универсальный на максимальное количество случаев в жизни и с возможностью чего-нибудь добавить, то при всем богатстве выбора он только один действительно хороший - ZOC http://www.emtec.com/zoc/
В большинстве случаев максимально удобны самописные заточенные под конкретику. Два из своих используемых для таких целей Loader+Terminal в одном флаконе под LPC2xxx и MSP430 я на этом форуме выкладывал - можете поискать AT200 и AT430

[Legotron]

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

А я иного мнения о внутрисхемной отладке
Наверное в силу недостающего опыта...

ИМХО Аспекты в "+" внутрисхемной отладке:

1 - когда работаешь с чужим кодом(особенно большим!, мой пример uC-GUI), не очень-то хочется лазить внутрь и дописывать консольные вещи... я собирал его на Infineon порядка недели, при этом активнейшим способом устранял ЕГО нестыковки с моей архитектурой с помощью внутрисхемной отладки..

2 - порой хочется попользоваться SFR безо всякой писанины (например померять время выполнения процедуры с помощью таймера).. делается влёт только с внутрисхемной отладкой.

3 - порой хочется модифицировать память или переменные в ходе процесса, чтобы быстро посмотреть реакцию... тоже делается быстрее с JTAG

4 - если вы еще не знаете, что сначала нужно написать ISR, а потом сделать IE куда вы уйдете по пустому вектору?.....правильно... в лес тоже по-неопытности бывали такие проблемы

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

Резюме:
Для малоопытного разработчика внутрисхемная отладка позволяет хорошенько пощупать железо на практике и узнать о нем побольше тонкостей!
Для профи, когда простых ошибок уже почти не делаешь это ни к чему...
Сам еще "зелененький", поэтому кайфую от внутрисхемной отладки и в ПЛИСах в том числе

P.S. Совсем забыл сказать: в IARе отличнейший отладчик
Вот бы такой в SlickEdit вместо тамошнего GDB!! эх.. мечты

[FormatCft]

Упаси бог! Если универсальный на максимальное количество случаев в жизни и с возможностью чего-нибудь добавить, то при всем богатстве выбора он только один действительно хороший - ZOC http://www.emtec.com/zoc/
В большинстве случаев максимально удобны самописные заточенные под конкретику. Два из своих используемых для таких целей Loader+Terminal в одном флаконе под LPC2xxx и MSP430 я на этом форуме выкладывал - можете поискать AT200 и AT430

Спасибо, ZltIgo. Но можете дать прямые ссылки? Не гуглится почему-то.

[zltigo]

Не гуглится почему-то.

Не верю:
http://www.google.com/search?hl=en&cli...amp;btnG=Search

[FormatCft]

Не верю:
http://www.google.com/search?hl=en&cli...amp;btnG=Search

Наверное букву в названии сайта по невнимательности не ту влепил.
Спасибо.

[defunct]

тут еще спорный вопрос

Код полный боред. Код использует переменные volatile в коде и в функции. Рузультат IAR ~18000 циклов Keil ~26000, это лучшие показатели при выборе параметров компиляции.

Да именно очень спорный вопрос, т.к. среда Keil нативно поддерживает три абсолютно разных тулчейна под ARM:
1. RVDS
2. CA (Keil)
3. GCC.
Каким из них Вы получили этот результат (подозреваю, что третим)?

Вопросы к тем кто имеет опыть пользования и того и другого:
1) Может на счет кейла сильно ошибся?
2) Что лучше: кейл или иар?

Пользую и Keil и IAR, вот мое субъективное мнение:

IAR априори - вне конкуренции для AVR и MSP430.
Keil - вне конкуренции для ARM, к тому же сейчас Keil - это подразделение ARM Ltd.

Еще плюсом ИАРа является то, что на нем сидит основная толпа разработчиков, поэтому есть у кого спросить.

Среди ARM разработчиков - толпа сидящих на RVDS'е и пользующих Keil ничуть не меньше.

Если присмотреться попристальнее к темам этого подфорума, можно также заметить, что большинство из той самой основной толпы на которую Вы ссылаетесь, пользуют IAR под MSP430 и AVR.

[MALLOY2]

Да именно очень спорный вопрос, т.к. среда Keil нативно поддерживает три абсолютно разных тулчейна под ARM:
1. RVDS
2. CA (Keil)
3. GCC.
Каким из них Вы получили этот результат (подозреваю, что третим)?

Все может быть...

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

[zltigo]

Keil - вне конкуренции для ARM...

C появлением V5 ARM компилятора у IAR это утверждение стало совсем уже не однозначным.

[defunct]

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

Выбирать в Setup File Extentions, Books and Environment.
см скришот (если обе галки сняты - будет Keil CA, иначе то, что написано).

Эскизы прикрепленных изображений

 

[Lelikk]

C появлением V5 ARM компилятора у IAR это утверждение стало совсем уже не однозначным.

Я успел немного попользоваться 4-ой версией IAR и соглашусь, что 5ая намного зачетней.
С ней хотя бы поставляется больше заголовочных файлов (например есть некоторые отсутствовавшие ранее описания регистров ADC для LPC21xx)
К компиляторам Keil у меня неприязнь с того момента, как их компилер собрал бинарник для x51 от Atmel с ОТСУТСТВУЮЩИМИ функциями (забыл добавить необходимый .c к проекту). При этом он это расценил как малозаметное "предупреждение".

[Rst7]

Я успел немного попользоваться 4-ой версией IAR и соглашусь, что 5ая намного зачетней.

Не знаю, не знаю. Я не заметил особой разницы в качестве кода при переходе от 4.4x на 5.x, собирая проекты под ARM9. Как всегда - качество кода высокое. Последний 5й еще и очень хороший код начал делать под Cortex, с использованием всех фичей (раньше он просто тумбу собирал, без использования возможности генерации полновесных 32хбитных инструкций).

А мерить длины пиписек по количеству .h-файлов, поставляемых с компилятором - извините за прямоту, бред.

[zltigo]

Не знаю, не знаю. Я не заметил особой разницы в качестве кода при переходе от 4.4x на 5.x, собирая проекты под ARM9.

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

А мерить длины пиписек по количеству .h-файлов, поставляемых с компилятором - извините за прямоту, бред.

Это действительно смешно, тем более, что у IAR они с использованием собственных ненужных фич и ими вообще не стоит пользоваться из соображений переносимости.

[Lelikk]

Это действительно смешно, тем более, что у IAR они с использованием собственных ненужных фич и ими вообще не стоит пользоваться из соображений переносимости.

Смешно как раз сравнивать компиляторы из соображений длины их ....
Не заметил в заголовках с описанием периферии сильно ненужных фич. Может быть конечно вы предпочитаете сами битовые поля расписывать под каждый регистр - вольному-воля.
Кстати, переносимость между чем и чем - между платформами (невозможно, так как речь идет о Platform-specific) или компиляторами (непонятно зачем)

[zltigo]

Не заметил в заголовках с описанием периферии сильно ненужных фич.

Со временем заметите , когда поймете, что переносимость между

...компиляторами (непонятно зачем)

таки нужна.

[Lelikk]

Со временем заметите , когда поймете, что переносимость между

таки нужна.

Ну кому как

По-моему опыту на PC - все переносы оборачиваются как ни крути кучей правок кода.
Хотя может это у меня руки кривые

[sergik_vrn]

C появлением V5 ARM компилятора у IAR это утверждение стало совсем уже не однозначным.

есть проект под STR710, в собранном виде с максимальной оптимизацией по размеру на IAR 4.42 еле-еле укладывается в существующие там 256+16К (то есть, свободного места порядка сотен байтов). Это с оптимизацией типов данных, выравнивания, временных переменных и прочей ерунды. После портирования его под IAR 5.20 сборка того же кода с максимальной оптимизацией по размеру дает превышение допустимого объема примерно на 0x400 байт. Следует ли полагать, что я чего-то недоучел/недопортировал/недовключил? Расширять проект еще хочется, так что вопрос весьма актуален

[Кононов Василий]

Давно пользуюсь IAR для AVR. Поэтому для нового проекта для LPC2103 выбрал компилятор от IAR 4.31. Первое что бросается в глаза - отсутствие поддержки многих слов, таких как __noreturn, __task и прочих... Создается впечатление сырой разработки. Кроме того не могу добиться условного выполнения инструкций ни при каких настройках оптимизации. Хотя оптимизация по размеру - на высоте.

[Rst7]

Кроме того не могу добиться условного выполнения инструкций ни при каких настройках оптимизации.

Условное выполнение инструкций возможно только в ARM-режиме. В тумбе этого нет.

Первое что бросается в глаза - отсутствие поддержки многих слов, таких как __noreturn, __task

Для ARM'а это не актуально.

Да и компиллер не стыдно взять посвежее... 5.30 уже на дворе.

[Кононов Василий]

Специально закачал 5.30 - так же не использует условного выполнения, в ARM режиме то же. __noreturn полезно при использовании многозадачности - компилятор не выполняет сохранения контекста, размер которого достигает 40 байт, при 4 задачах - уже 160 не так много для ARM'а, но все же...

[Rst7]

так же не использует условного выполнения, в ARM режиме то же.

Быть того не может. Наглядный пример

CODE

536 if (coef<0)
\ 0000001C A260A0E1 LSR R6,R2,#+1
\ 00000020 000055E3 CMP R5,#+0
\ 00000024 0700005A BPL ??z_and_q_0
537 {
538 unsigned int tmp;
539 tmp = -coef;
540 tmp += __q>>1; /* for rounding */
\ 00000028 005065E2 RSB R5,R5,#+0
\ 0000002C 055086E0 ADD R5,R6,R5
541 #ifdef USE_MUL
542 coef = -(tmp>__q?MUL_U16(tmp, __iq):0);
\ 00000030 050052E1 CMP R2,R5
\ 00000034 94050230 MULCC R2,R4,R5
\ 00000038 2228A031 LSRCC R2,R2,#+16
\ 0000003C 0020A023 MOVCS R2,#+0
\ 00000040 002062E2 RSB R2,R2,#+0
\ 00000044 040000EA B ??z_and_q_1
543 #else
544 coef = -DIVIDE_(tmp, __q);
545 #endif
546 }
547 else
548 {
549 unsigned int tmp;
550 tmp = coef;
551 tmp += __q>>1; /* for rounding */
\ ??z_and_q_0:
\ 00000048 055086E0 ADD R5,R6,R5
552 #ifdef USE_MUL
553 coef = tmp>__q?MUL_U16(tmp,__iq):0;
\ 0000004C 050052E1 CMP R2,R5
\ 00000050 94050230 MULCC R2,R4,R5
\ 00000054 2228A031 LSRCC R2,R2,#+16
\ 00000058 0020A023 MOVCS R2,#+0
\ ??z_and_q_1:
\ 0000005C 54449FE5 LDR R4,??z_and_q_2 ;; z_q + 780
\ 00000060 004094E5 LDR R4,[R4, #+0]
\ 00000064 044052E0 SUBS R4,R2,R4
554 #else
555 coef = DIVIDE_(tmp, __q);
556 #endif
557 }

И переходы есть, и условное выполнение. Все по необходимости.

__noreturn полезно при использовании многозадачности

Кстати. Только что глянул в хелп. Есть __noreturn.

Что-то Вы совсем не то делаете.

[Кононов Василий]

Говорю про подобные моменты:

Код

//  890     if (bit)
        CMP         R0,#+0
        BEQ         ??korsumcount_5
//  891         dword0 |=1;
        ORR         R1,R1,#0x1
//  892
//  893     databuffshift[0]=dword0;
??korsumcount_5:
        STR         R1,[R2, #+0]

а мог бы сделать так:

Код

//  890     if (bit)
        CMP         R0,#+0
//  891         dword0 |=1;
        ORRNE         R1,R1,#0x1
//  892
//  893     databuffshift[0]=dword0;
        STR         R1,[R2, #+0]

GCC выполняет подобную оптимизацию и без включения оптимизации...

__noreturn в 4.31 ARM - еще отсутствует, хотя в 4.11 для AVR есть.

[Rst7]

Говорю про подобные моменты:

Вот Ваш код. Собран 5.20

CODE

###############################################################################
# #
# 02/Mar/2009 12:31:04 #
# IAR ANSI C/C++ Compiler V5.20.0.20892/W32 EVALUATION for ARM #
# Copyright 1999-2008 IAR Systems AB. #
# #
# Cpu mode = arm #
# Endian = little #
# Source file = E:\JPEGcoder\CoderARM\t.c #
# Command line = E:\JPEGcoder\CoderARM\t.c -lC #
# E:\JPEGcoder\CoderARM\Debug\List\ -o #
# E:\JPEGcoder\CoderARM\Debug\Obj\ --no_unroll #
# --no_inline --debug --endian=little --cpu=ARM920T -e #
# --fpu=None --dlib_config D:\IAR_ARM520\ARM\INC\DLib_Conf #
# ig_Normal.h -I D:\IAR_ARM520\ARM\INC\ --interwork #
# --cpu_mode arm -Ohs #
# List file = E:\JPEGcoder\CoderARM\Debug\List\t.lst #
# Object file = E:\JPEGcoder\CoderARM\Debug\Obj\t.o #
# #
# #
###############################################################################


\ In section .text, align 4, keep-with-next
E:\JPEGcoder\CoderARM\t.c
1 void foox(unsigned long bit, unsigned long dword0, unsigned long *databuffshift)
2 {
3 if (bit)
\ foox:
\ 00000000 000050E3 CMP R0,#+0
4 dword0 |=1;
\ 00000004 01108113 ORRNE R1,R1,#0x1
5 databuffshift[0]=dword0;
\ 00000008 001082E5 STR R1,[R2, #+0]
6 }
\ 0000000C 1EFF2FE1 BX LR ;; return

Maximum stack usage in bytes:

Function .cstack
-------- -------
foox 0


Section sizes:

Function/Label Bytes
-------------- -----
foox 16


16 bytes in section .text

16 bytes of CODE memory

Errors: none
Warnings: none

Где криминал?

[zltigo]

__noreturn в 4.31 ARM - еще отсутствует, хотя в 4.11 для AVR есть.

А вот 19 веке, ни фирмы Atmel, ни AVR не существовало. Ну и что? __noreturn есть и в 4 и в 5 ветках EWARM, возможно, что его когда-то не было, ну и что?

Вот Ваш код. Собран 5.20

Четверка, естественно, генерит такой-же.

[Кононов Василий]

Спасибо за подсказку! Моя ошибка была в попытке использования директивы "#pragma optimize=s 9" для изменения параметров компиляции одной функции. Максимальная оптимизация для всего проекта исправила код.
Не понятно только одно - почему компилятор не использует важной особенности процессора (условное выполнение инструкций) без максимальной оптимизации? Сделано для того что бы поставить галочку - убрал условный переход, значит хорошо выполнил оптимизацию? Разработчики софта считают использование инструкции оптимизацией?

[Rst7]

Не понятно только одно - почему компилятор не использует важной особенности процессора (условное выполнение инструкций) без максимальной оптимизации?

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