Пластинка становится несколько заезженной. Вам не показалось?

Про заезженость пластинки вы расскажите кому либо другому, кто не переходил с ИАРа в середине проекта на АРМ Лтд. из-за неимоверной глючности первого и невозможности включить хоть малейшую оптимизацию...

Я с Вами лично не знаком и пожалуйста не принимайте это близко к сердцу. Но обычно такие проблемы возникают с ЛЮБЫМ компилятором в 99% только в случае, если программист не может ясно выразить свою мысль. В таком случае поведение компиляторов начинает отличаться, и отнюдь не факт,
что возлюбленный вами компилятор так-же удачно догадается о Ваших намерениях в другом проекте.
Ваши метания на другой компилятор только подтверждают в моих глазах тот факт, что понимание того, что Вы пишите, Вами пока невелико :-(. Огорчает то, что вместо анализа сложившийся ситуации во всем был обвинен компилятор и эти "обвинения" сейчас с упорством достойным лучшего применения широко разбрасываются Вами на просторах форума.
Ошибки встречаются в любом компиляторе.
Имея за плечами два десятка лет общения с разнообразными "C" компиляторами, я при активнейшем использовании в течении последних 9 месяцев IAR компилятора в том числе и при портировании на ARM платформу значительного числа своих предыдущих наработок с проблемами не встретился. Наступил только на одну явную ошибку компилятора, которая была локализована (вместо поиска другого компилятора) за, примерно, 20 минут. Причем в следующей версии компилятора эта ошибка (согласно честно ведущегося перечня исправленных ошибок) была устранена. Оптимизация всегда используется максимальная или по производительности или по размеру (для некоторых кусков кода). К качеству полученного кода у меня "претензии" минимальные:
- мог-бы шире пользоватся условным выполнением команд вместо JUMP;
- есть тяготение даже в ARM mode к использованию непосредственных значений в поле команды
в диапазоне характерном для Thumb mode.

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

P.S.
IDE от IAR (впочем, как и любаяя другая) меня не интересует в принципе и ее я обсуждать не собираюсь.

Имхо вы слишком категоричны в высказываниях. "глючности и невозможность" - звучит как то слишком фантастично.

За последние несколько лет активной работы с иарарм и иар430 в моем репозитории было всего 5 багов. В последних версиях осталось всего два. Оба связаны с шаблонами, которые практически никем не применяются. Да и то, одну ошибку и ошибкой назвать трудно - просто разночтения стандарта у ИАР и Мелкософта. Это приводит к неудобству ведения общих исходников и только.

Другое дело, что с ИАРом тяжело контачить по поводу багов, по крайней мере все мои обращения остались без ответа. Возможно, потому, что я у них ничего не покупал. Лицензионные кустомеры говорят, что суппорт работае вполне оперативно.

А почему бы вам не рассказать о том как IAR ARM страдал падучей болезнью при входе и выходе из режима отладки, которую поправили только в версии 4.3. А его знаменитое неубирающееся окошко "не могу прочитать R0-R14" от которого спасает только ЦТРЛ_АЛТ_ДЕЛ? Оно до сих пор еще не поправлено! При чем оно умудряется выскакивать даже при использовании ДЖЕЙЛИНКА! Конечно если писать программки типа "мама мыла раму" или лед блинк то ему равных нет, а вот предьявите пожалуйста хоть одну серьезную программу ну хотя-бы кил на 200-300 сделаную на ИАР АРМЕ! Тогда и поговорим...

"кил" чего, простите? исходников? так это совсем немного.

Использую EWARM 4.20 (+J-Link) для работы с SAM7S128, доволен вполне; пресловутые болезни обходят стороной.

Прерывание от TWI или от чего-то другого? Сколько у вас всего прерываний задействовано?
Может попробовать сделать тестовую программку с подкачкой без использования прерываний?
Если будет тот же эффект, значит прерывание тут не причём.

А потому, что я уже РАНЕЕ написал:

Растолковываю - меня интересуют только компиляторы. "родными" IDE не пользуюсь и пользоваться не буду ввиду cуществования более приспособленного для профессиональной работы инструментария. Мое мнение об IDE "компиляторов" вообще и об IDE IARа в часности Вы можете найти на этом форуме.
Внутрисхемным отладчиком пользуюсь крайне редко и переживу почти любой.
Только как соотносится IDE IAR с качеством РАНЕЕ критикуемой Вами генерации компилятором кода я
не понял.


Насколько я понимаю, это вариант бессмерного аргумента Паниковского: "А ты кто такой?".
Потом что будет? "Поезжайте в Киев и спросите, кем до революции был Паниковский, нет вы поезжайте и спросите!"?

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

Очень приятно иметь дело с человеком утруждающим себя подробным растолковыванием всяческих мелочей этим бестолковым ламерам. Так все-таки покажите пожалуйста реально работающую программу (особенно в реальном масштабе времени) обьемом 200 и более килобайт бинарного ВЫХОДНОГО кода компилятора ИАР.

А какая принципиальная разница 200K, или 2 по 100K, или 999 по 99K.
Если Вам любопытно, то суммарный объем наработанный за 9 месяцев по 6 девайсам много превосходит 200K СОБСТВЕННОРУЧНО написанного "реалтаймового" кода.

1. Если Вы полагаете, что хоть какой-то компилятор способен заниматься хоть какой-то разумной оптимизацией в пределах ОДНИМ куском написанного кода размером 200K, то это просто детская наивность.
2. Я находясь в здравом не писал, не пишу и не буду писать ничего ОДНИМ куском, что будет выливаться в ОБЪЕКТНЫЙ код более чем несколько десятков килобайт.
3. Или у Вас претензии к линкеру от IAR? Вроде нет - катятся бочки на оптимизацию...
4. Если о моей способности писать программы превышающий магический размер 200K embedded кода, то отвечаю - способен и писал под x86 платформу.

Надеюсь, я доходчиво и без "аргументов" типа:

объяснил, почему представление или не представление "программы" размером 200K просто ни о чем ни свидетельствует? И почему я ранее написал, что не могу могу воспринять сие "требование" иначе чем

Огромное спасибо за проявленное внимание, но компилятор абсолютно не виноват.
Была абсолютно ламерская ошибка человека (то бишь меня), 20 лет работавшего с 8-миразрядниками и впервые воспользовавшегося 32-х битником. Господин zltigo был абсолютно прав.

У меня был недавно глюк с IAR 4.20. Он гад константу, описанную через #define, в проге почему-то увеличивал на 16. Это я в отладчике выяснил, взглянув на асм-код. Приходилось в нескольких местах писать "константа-16".
Странный, да, глюк?

Ну раз недавно, значит не забыт :-) давайте сюда - посмотрим....

Пока неясно.

А вот это точно странное и совершенно ошибочное решение с Вашей стороны.
Подгонка под ответ нахудшее из всех возможных решений.

Да и число 16 какое-то... наводящее на мысли. Константа вычисляемая да?

Да, да! Я тоже так подумкал. Константа - простое число.

Подождите немножко, щас всё несущественное вырежу (типа коммерческая тайна), а чё останется - запостю.