Где бы взять исходники библиотек IAR 5.11 для ARM Опции

[savram]

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

[VAI]

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

[KRS]

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

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

Работаю с LPC2138 в IAR 5.11

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

[zltigo]

..возникла проблема: static переменным не присваивается ноль при инициализации.

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

Хотелось бы посмотреть как работает __iar_zero_init в библитеке rt4t_al.a.

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

[IgorKossak]

Хотелось бы посмотреть как работает __iar_zero_init ю...

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

[savram]

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

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

[VAI]

Подойдут!

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

md5:
1b69d69bc383c42c1bda53a02ecb1c51 *lib.rar

[IgorKossak]

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

Код

__iar_zero_init:
Region$$Table$$Limit:
  00000150  E3520000  CMP          R2, #0x0
  00000154  012FFF1E  BXEQ         LR
  00000158  E3A01000  MOV          R1, #0x0
  0000015C  E4801004  STR          R1, [R0], #+4
  00000160  E2522004  SUBS         R2, R2, #0x4
  00000164  1AFFFFFC  BNE          0x00015C
  00000168  E12FFF1E  BX           LR

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

Код

int main()
{
  static int MyVar;
  return MyVar;
}

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

[zltigo]

Вообще, это не единственная проблема с этой библиотекой....

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

[savram]

 icf.zip ( 706 байт ) Кол-во скачиваний: 111

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

С этим-то проблем совсем ни каких нет, это первая мысль, которая возникает. Конечно, наивно винить 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 прилагаю, там тоже вроде все чисто.

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

[zltigo]

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

[AndrewN]

2. bss инициализируется нулями, если только специально не постараться.

= 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

[zltigo]

Но не каждый транслятор так делает:

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

[IgorKossak]

Но не каждый транслятор так делает:

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

By default, the .bss section and sections defined with the .usect directive have no raw data (they are uninitialized). They occupy space in the memory map but have no actual contents.

Но, повторяю, у IAR с инициализацией полный порядок.

[zltigo]

Code Composer Studio от TI...

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

[aaarrr]

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

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

[zltigo]

Да и не такой уж и кривой.....

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

Зато отучает полагаться на "0" в bss...

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

... что, я считаю, правильно.

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

[aaarrr]

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

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

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

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

[zltigo]

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

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

И далеко не всегда нулями.

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

[aaarrr]

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

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

[zltigo]

Возможно, но трагедии здесь не вижу...

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

[aaarrr]

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

[AndrewN]

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

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

По существу, разумеется стандарт 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

Сообщение отредактировал AndrewN - Jul 8 2008, 22:46

[Alex03]

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

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

[zltigo]

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

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

[gladov]

..возникла проблема: static переменным не присваивается ноль при инициализации.

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

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

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

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

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

Код

"P2", part 1 of 5:                         0x3840
  .bss                zero     0x1000001c  0x3840  Array.r79 [1]
                             - 0x1000385c  0x3840

"P2", part 2 of 5:                         0x2480
  HEAP                         0x10003860  0x2000  <Block>
    HEAP              uninit   0x10003860  0x2000  <Block tail>
  CSTACK                       0x10005860   0x300  <Block>
    CSTACK            uninit   0x10005860   0x300  <Block tail>
  .iar.dynexit                 0x10005b60   0x180  <Block>
    .iar.dynexit      uninit   0x10005b60     0xc  cppinit.o [15]
    .iar.dynexit      uninit   0x10005b6c   0x174  <Block tail>
                             - 0x10005ce0  0x2480

"P2", part 3 of 5:                            0xc
  P2 s0                        0x10005ce0     0xc  <Init block>
    .data             inited   0x10005ce0     0x4  file1.r79 [4]
    .data             inited   0x10005ce4     0x4  file2.r79 [9]
    .data             inited   0x10005ce8     0x4  cppinit.o [15]
                             - 0x10005cec     0xc

"P2", part 4 of 5:                         0x217c
  .bss                zero     0x10005cec  0x1024  mem.r79 [9]

...

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

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

Код

place in RAM_region    { readwrite };
place in RAM_region    { block CSTACK, block HEAP };

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

[Alechek]

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

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

Код

*******************************************************************************
*** INIT TABLE
***

          Address     Size
          -------     ----
Zero (__iar_zero_init3)
    2 destination ranges, total size 0x674a:
          0x10000148  0x2e3a
          0x2007c000  0x3910

Copy/packbits (__iar_packbits_init3)
    1 source range, total size 0x33 (15% of destination):
          0x00013b78    0x33
    1 destination range, total size 0x144:
          0x10000004   0x144

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