[aaarrr 63]

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

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

[zltigo 0]

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

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

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

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

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

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

[aaarrr 63]

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

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

 

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

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

[zltigo 0]

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

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

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

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

[aaarrr 63]

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

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

[zltigo 0]

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

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

[aaarrr 63]

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

[andrewn 0]

Кхм... Не очень я люблю цитировать Шекспира, но - "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

Изменено 8 июля, 2008 пользователем AndrewN

[Alex03 0]

ИМХО

1. Компилятор обязан поместить явно неинициализированные переменные в bss (или подобный сегмент)

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

3. По приходу в main() явно неинициализированные переменные обязаны быть нулевыми.

 

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

[zltigo 0]

Маленькая поправка: набор компиляторов TI генерирует машинный код для самых разных архитектур

(от CISC-like С2000 до RISC ARM и multiple-issue C6000) - он совсем уже не сырой а вполне

прожаренный...

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

[gladov 0]

..возникла проблема: 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 0]

Советую просто поставить последнюю версию 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 Создавался только один диапазон инициализации.