А что же им еще продвигать для своих 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

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

ИМХО
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 Создавался только один диапазон инициализации.