Работаю с LPC2138 в IAR 5.11, возникла проблема: static переменным не присваивается ноль при инициализации. Хотелось бы посмотреть как работает __iar_zero_init в библитеке rt4t_al.a. У меня evaluation версия с iar.com, там исходников нет... Говорят они есть в full версии, но где ее взять?

есть исходники библиотек от 4.20a и 4.11a.
Подойдут?

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


А вы отключите штатную инициализацию сегментов.
В своем ICF файле и инициализируйте сегменты сами.
типа
do not initialize { section .bss };

Не верю. Совсем не верю.

А там смотреть нечего - несколько команд в цикле обнуляющие заданную область памяти. Весь вопрос в том, находится-ли переменная в этой области, а к этому "библиотеки" ни сном ни духом.

Запустите симулятор и посмотрите пошагово по дизассемблеру.
В библиотеке этой функции может не быть (по крайней мере в версии 4.42 нет), т. к. это intrinsic функция, т. е. генерится инлайново самим компилятором, а в стартапе только вызывается, исходного текста там нет.

Подойдут! Надо узнать, что это за функция и написать ее самому.
Вообще, это не единственная проблема с этой библиотекой. Изначально не работали прерывания IRQ, пришлось внести изменения cstartup.s (исходник есть) и подключить файл к проекту. Заработало. Правда полностью отключить библиотеку не могу, ругается, что нет __iar_zero_init (она как раз в библиотеке и лежит). На этом фоне не работает инициализация staticов... вот такая ерунда!

http://www.rapidshare.ru/723273
http://slil.ru/25962831
заархивировал последним winrar-ом.
Пароль на архив Без пароля.
Кому не понятно, смотреть пароль под моей кошкой http://www.v572028.narod.ru/

md5:
1b69d69bc383c42c1bda53a02ecb1c51 *lib.rar

По дизассемблеру там, в частности, следующее:

Программа такая:

Оптимизация выключена, инициализация происходит как надо.

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

Нажмите для просмотра прикрепленного файла

С этим-то проблем совсем ни каких нет, это первая мысль, которая возникает. Конечно, наивно винить IAR в своих бедах. Но проблема-то не исчезает...

IgorKossak - спасибо, буду разбираться.

Я вынужден не использовать static переменные, вместо этого инициализирую глобальные переменные в mainе. Все работает, но это не красиво как-то.

Вот пример:

В main.c есть такая строка

static int static_variable1[10];

Потом в main делаю проверку - массив не инициализирован, содержит случайные значения.

Вот что написано в *.map:

Section Kind Address Size Object
------- ---- ------- ---- ------
.bss zero 0x40002468 0x28 main.o [1]

Из чего делаю вывод, что переменная лежит в bss по адресу 0x40002468 (это RAM).
Делаю предположение, что "zero" - директива линкеру инициализировать область нулями.
Это только мое предположение, если я не прав, пожалуйста, дайте мне знать.

ICF прилагаю, там тоже вроде все чисто.

Буду очень признателен, если кто-нибудь даст совет где еще покопать.

1. static или не static по любому неинициализированвнные переменные попадают в bss
2. bss инициализируется нулями, если только специально не постараться.
3. с дуру у V5 даже проверил.
3. точка.

= IAR (стр 43 (67) ODARM_1.pdf). Но не каждый транслятор так делает:

\begin{excerpt:link=http://focus.ti.com/lit/ug/spnu151d/spnu151d.pdf}
5.12 Initializing Static and Global Variables in TIABI and TI ARM9 ABI Modes

The ANSI/ISO C standard specifies that global (extern) and static variables without explicit initializations
must be initialized to 0 before the program begins running. This task is typically done when the program is
loaded. Because the loading process is heavily dependent on the specific environment of the target
application system, the compiler itself makes no provision for preinitializing variables at run time. It is up to
your application to fulfill this requirement.
\end{excerpt}

--
AN

Каждый, который отвечает стандарту "так делает". Не отвечающие стандарту компиляторами не являются и меня не интересуют в принципе .
Возможность намеренно отключть (полностью или частично)у компилятора может быть (в том числе и у IAR они есть), но по умолчанию, без специальных телодвижений, "неинициализированные данные" инициализированы 0.

Подтверждаю, не каждый.
Code Composer Studio от TI в своё время подвёл меня этим
Но, повторяю, у IAR с инициализацией полный порядок.

Этот "компостер" и сейчас совершенно сырой компилятор , даже странно, что TI c мрачным упроством продолжает его продвигать в массы, правда наряду с вполне рабочим IAR

А что же им еще продвигать для своих DSP? Да и не такой уж и кривой. Зато отучает полагаться на "0" в bss и заставляет внимательнее писать программы, что, я считаю, правильно.

Плавали в части MSP430...

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

Спасибо, я пешком постою

MSP430 - единственный процессор, под который я писал в IAR'e Но не по причине глючности студии, а просто так получилось.


Ну, во-первых, не каждой. А во-вторых, я уж лучше руками проинициализирую именно то, что мне нужно. И далеко не всегда нулями.

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

Про не нули речь не идет, но тем не менее в большинстве случаев 0 это нормальное значение, а остальные переменные просто доинициализировать через data или явно нужными зачениями при необходимости.

Возможно, но трагедии здесь не вижу - ничто не мешает проинициализировать эту память самостоятельно.

Я, например, не вижу ни малейшей трагедии в ручной инициализации динамически выделенной памяти, по тому, что знаю, что она не будет инициализирована согласно принятому стандарту языка. А вот в необходимости инициализировать память, которая должна быть согласно стандарту инициализирована, напротив, я вижу банальное свинство и не намерен пользоваться такими "продуктами".

Для свинства это все же слишком мелко. Продукт уникальный, так что не пользоваться не получится.

Кхм... Не очень я люблю цитировать Шекспира, но - "Much ado abouth nothing" - по моему строчка
вполне подходит. Ну это шутка.



По существу, разумеется стандарт ANSI C (если речь шла о нем) никто не отменял; я не уточнил,
что есть опция -fill в линкере TI, которая восстанавливает "инициализационное" поведение
предусмотренное ANSI C; правда инициализирующая константа может отличатся от нуля. Этакий
суперсет.

С другой стороны, ANSI C вовсе не застывшая и всеопределяющая формулировка - ещё есть
K&R и K&R 2nd ed., и embedded C, и GNU C и вероятно еще что-нибудь, о чём я и не подозревал,
и все они в чём-нибудь да отличаются от "девственого" ANSI C, который кстати тоже насчитывает
пару редакций (или уже больше?).

Отсюда с необходимостью следует, что любой код на С - это код на подмножестве С, и
портируемость кода на С это скорее миф а реальность - это строки #ifdef (ARCH_XXXX) или
ifdef (COMPILER_XXXX) - наподобие __STDC__ и __GNU_C__ и так далее.

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

Я, собственно, только это изначально и отметил, а вовсе не собирался затевать очередную священную войну за веру.

Маленькая поправка: набор компиляторов TI генерирует машинный код для самых разных архитектур
(от CISC-like С2000 до RISC ARM и multiple-issue C6000) - он совсем уже не сырой а вполне
прожаренный, well-done, говоря кулинарным языком ANSI.

--
AN

ИМХО
1. Компилятор обязан поместить явно неинициализированные переменные в bss (или подобный сегмент)
2. Обнуление сегмента bss (также как и инициализация data) может быть как в самом коде программы (стартапе), так и где либо ещё (загрузчик некоего формата файла в ОС).
3. По приходу в main() явно неинициализированные переменные обязаны быть нулевыми.

Т.е. всё дело в п.2. А это уже линкеры, способы сборки, загрузки, стартапы и т.д., т.е. специфика конкретных target-ов.

По личному общению с его попытками генерить код под MSP430 - впечатления не радужные. Для специфичных применений, например, их DSP - сойдет, но там где есть альтернативы, лучше не связываться.

Такая проблема есть. Сегодня наткнулся. Исследования показали следующее:

Допустим, есть массив:
static int BigArray[QuiteLargeValue] = 0;
Можно "=0" и убрать, разницы никакой.

В конфиге ICF имеем строку:
place in RAM_region { readwrite, block CSTACK, block HEAP };

Однозначно видно, что линкер пытается разложить блоки в регионе по убыванию размера. Так вот если массив оказывается большего размера, чем CSTACK или HEAP, то видим такую картину:


Наш блок Array попал в сегмент .bss, чего мы и хотели, однако, код для его инициализации не был сгенерирован линкером! Линкер начал забивать нулями область, начиная в данном случае с адреса 0x5cec. Если же уменьшить размер массива так, чтобы он оказался меньше кучи и стека, то он попадет к "остальным" членам .bss и все переменные проинициализируюутся.

Конечно, уменьшать массив это не выход, поэтому есть другой вариант обхода проблемы в конфиге линкера:


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

Советую просто поставить последнюю версию IAR
В 6.10 у меня тоже была проблема с инициализацией.

В *.map надо смотреть на содержимое INIT TABLE



В 6.1 Создавался только один диапазон инициализации.