Потратил день времени на вылавливание следующего бага:

short mamont[128];
char slon1;
char slon2;

void mamont_init(void)
{
mamont[0] = 1;
slon1 = 0;
slon2 = 0;
}
\ mamont:
\ 00000000 DS8 256
2 char slon1;
\ slon1:
\ 00000100 DS8 1
3 char slon2;
\ slon2:
\ 00000101 DS8 1
4
...
5 void mamont_init(void)
6 {
7 mamont[0] = 1;
\ ??mamont_init:
\ 00000000 10009FE5 LDR R0,??mamont_init_1 ;; mamont
\ 00000004 0110A0E3 MOV R1,#+0x1
\ 00000008 B010C0E1 STRH R1,[R0, #+0]
8 slon1 = 0;
\ 0000000C 0010A0E3 MOV R1,#+0x0
\ 00000010 B010C0E1 STRH R1,[R0, #+256]
9 slon2 = 0;

slon1 и slon2 располагаются в памяти рядом. Компилятор, начиная с уровня оптимизации 6, считает, что раздельное обнуление этих переменных через STRB можно соптимизировать в одно обращение через STRH сразу для обеих переменных. При этом несколько забывая, что для STRH максимальный оффсет задается 8 битами и не может превышать 255. Баг проявляется, если нужно смещение 256,
если оффсет нужен больше, то там все нормально. В 4.11a этого бага нет.
regexp для поиска этого бага в lst файлах :
STRH R.+,\[R.+, #\+256\]

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

bug report я отослал. вопрос в том, обратят ли они на него внимание, если он пришел от незарегистрированного пользователя.

Ответ IAR:

Thank for letting us know about this bug. The bug report have
been filed and the ID is EW16885. As we are going to make a
new version (4.30A) late in June, will we be able to correct this
bug quickly. Thank you once more.

-----

The Product Manager for EWARM got back to me and told
me that the work around is to turn of clustering when using
the higher optimizations.

Ну это понятно, но тогда код пухнет значительно.

Ну надо же, как повезло!
А вот мои сообщения о багах (их уже с десяток) иаровцы высокомерно игнорируют. Правда я им на их же форуме сообщал, и даже под разными никами. Ноль внимания. Они что, свой форум не читают?
А как Вы им сообщили о баге?

на support@iar.se

Проверил - в 4.30a этот баг исправлен

Так потому и релиз вышел, что весьма серьёзный баг обнаружили.
Хотя в релиз ноте пишут, что вдобавок ко всему, библиотеку плавающей точки ускорили вдвое. Это приятно, т. к. раньше мелькали посты, в которых именно по этому пункту народ отдавал предпочтение Кейлу.

Друзья. раз уж разговор о версии 4.30A
мне показалось, что есть баг в обработке FIQ
несмотря на модификаторы __fiq __arm void fiq_handler( bla-bla-bla...
он упорно генерит код для регистров irq, а не fiq
в моем случае в теле обработчика изменялся r8, а не r8fiq
времени было мало. я так и не понял, кто глючит, c-spay или сам компилятор

короче, FIQ я так и не запустил... ограничился векторными IRQ

кто сталкивался?

Может я ошибаюсь, но мне кажется, что компилятор тут не причем. То, будут ли использоваться FIQ регистры, зависит от источника прерывания - FIQ или IRQ.
Другой вариант, что в низкоуровневом обработчике прерываний меняется mode на User/Svc, чтоб пользоваться обычным стеком, так как FIQ очень мал (12 байт).
Посмотрел у себя, да, в стандартном Cstartup.s79 есть:

FIQ_Handler_Entry:
;- Switch in SVC/User Mode to allow User Stack access for C code
; because the FIQ is not yet acknowledged

Вообще, советую FIQ обработчики писать на ассемблере. Иначе толку от них никакого.

с этим всё в порядке.. я попадаю в обработчик FIQ по исключению 0x1C. в регистре VIC состояние фаст интеррапт. в слове состояния проца тоже. стек, ежу понятно, надо определить в *.xlc. в стандартном файле его вообще нет. .. со стартапом порядок, стек выделен и в r13 загружен, а больше ничего и не требуется

подозрения в 2х местах.
- в начале обработчика групповой push в списке которого, в частности r8 и r12. зачем? зачем тогда FIQ с его регистрами.
- в теле обработчика модифицируется r8. когда выполняется эта строка, то c-cpy отображает изменение r8, а не r8fiq. если я руками записываю тоже значение в r8fiq, то программа отрабатывает правильно...

я подозреваю всё же сам генератор кода... если я выключаю отладку и вписываю релиз во флешь, то с помощью JTAG точки останова я попадаю в обработчик по исключению 0x1C, но код работает ровно так же...


ассемблер ...
гы, - начальство не поймёт... сразу может не уволят, но ...

знашь, всё же посмотрю стартап на досуге, для себя... чёто засело как гвоздь в ботинке
спасибо!

Re: в начале обработчика групповой push в списке которого, в частности r8 и r12. зачем? зачем тогда FIQ с его регистрами.

Про эту фичу IARа была тема, автор писал, что написал "bug report", на что ему ответили: "приняли к сведению".

ЗЫ: Это не глюк, это фича. © народное.

Спасибо! вы меня успокоили...

гы,- насчёт фич...
сорри офтопик, но может кому пригодИтся
в текущем проекте я использую модемный чип подключённый к LPC2129 по SPI. смотрю описание. сигнал slave select, только ввод используется только в слйв мод. в мастер мод вы должны использавать возможности GPIO. ну замечательно. подключаю 3 ноги к модулю spi. ногу ss к gpio. бьюсь где-то 3 часа,- spi не работает. т. е. вообще... лезу в группу на яху. поиск даёт 200 или 300 совпадений,- у многих те-же грабли. наконец нахожу коммент филипса... примерно такой. у нашего проц-а имеется особенность в работе блока spi. бла- бла-бла... у вас нет другой возможности запуска мастер мод, как подпереть вывод ss с помощью пулап резистора к питанию, а для выборки ведомого использовать любой другой свободный пин в режиме gpio. ха-ха, забыли в пин селекшен блоке эту линию
вот и вся фича
з.ы. пулап резистор обязателен!