Столкнулся со следующей проблемой. Компилятор IAR 4.42. Проект превысил 60 кил, и ни каких особых багов я не замечал. Компилил с опцией NONE(BestDebugSupport). Решил откомпилить с опцией Medium и наткнулся на непонятный баг. Из StartUp код прыгает в main там следующий код:
Main()
{
Unsigned int x;
x=calculate_ram_crc();

//Сдесь x=1, как и должно быть

initialisation();
VICIntEnable |= (1<<5);

//Сдесь x=чему угодно???!!!

Кто нибудь сталкивался с таким багом?

А x используется дальше где-нибудь ?

Чёта я не понял? А куда мая предыдущая месага делась????
Х - так называемая расходная переменная, она дальше в main в сотни случаях пользуется.

Я бы спросил точнее: значение переменной x, полученное в результате вызова calculate_ram_crc(), где-нибудь используется? Если нет, то компилятор имеет полное право его выкинуть.

Может быть, там были матюки? Если так, то отмодерили.

Совет по стилю: вместо одной расходной переменной лучше применять разные, чтобы имя переменной в каждой отдельной ситуации поясняло, зачем она используется. Работа компилятора - сделать код не хуже, чем при использовании одной переменной. Ему это вполне по силам.

Ещё один совет по стилю: если функция раздулась до сотни строк, значит её надо разбивать на подфункции.

Если программа выглядит примерно так:

то в точке 1 x может быть каким угодно.

Разумеется. Функция calculate_ram_crc проверяет RAM и возвращает succes или false и соответственно далее в зависимости от результата, идёт разветвление программы, конкретно в моём примере следующим образом:
while(x)
{
...
}

Да нет???? Мне кто-то ответил, что сталкивался с таким, я спросил в чём грабдли были. После обеда, пришёл и в придкушении ответа зашёл на форум, а тут не моего ни его ответов нет!

Смысловые переменные конечно имеют уникальные названия, но согласитесь есть очень много мест где переменная требуется максимум на пару строк, тот же самый пресловутый:

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

Это я образно выразился. Если кусок кода начинает приобретать лёгкие черты инкапсуляции то он сразу превращается в функцию
Ну а теперь вернусь к своим "баранам". Переменную анализирую выводом в терминал. Без оптимизации всё работает отлично. С аптимизацией нет. Пока не копаюсь в дезасемблировании поскольку, даже если найду ущербный код, то это не поможет от него избавится.

Днем было какое-то странное поведение, возможно форум падал и восстановился с предыдущего бекапа.Тут четко видно, что х - временная переменная и дальше не используется. Или использовать плюсы и тогда for(uint_fast8_t x = 0; x < 8; x++) {}Связь между регистрами и переменными - забота компилятора. И скорее всего связи такой нет. Переменная может "путешествовать" по регистрам по мере необходимости. Повторное использование переменной скорее мешает компилятору, чем помогает.

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

Скрыта вместе с предыдущим бессодержательным ответом.
Сообщения, как и названия тем, должны быть хоть как-то наполнены смыслом.

Ну если переменная локальная, то имхо, переадресация её из одного регистра в другой является более "стрессовой" ситуацией для компилятора.

Ну здесь Вы лукавите (имхо). Связь между ЛОКАЛЬНЫМИ переменными и регистрами непосредственная. И если помогать в этом компилятору, то и код будет "лучше".

Сообщение отредактировал Beginning - Nov 23 2007, 14:13

С чего бы "стрессовой", если он сам ее и перекладывает? На высоких уровнях оптимизации такое встечается.Какая может быть связь, если переменная может быть в регистре, а если вдруг этот регистр понадобился - переменная перекочует на стек? Вы "поможете" компилятору, потом добавите еще одну локальную переменную с бОльшим временем жизни и вся ваша "помощь" пойдет коту под хвост, ибо переменные распределятся по регистрам и стеку иначе. Я предпочитаю не мешать компилятору делать его работу. Помогаю, заводя локальные блоки как показывал выше. И ему проще, и мне понятнее.

Cупер компилятор выдал следующий перл. При максимальной компиляции генерит код который сразу вываливается в UNDEF Есть один момент, который необходимо знать. При поиске IAR4.42 не нашёл полную установочную версию, зато нашёл самораспаковывающуюся. 10 метров заархивированных 7z разорхивировалися в 160 метров!!! Проверял – вроде всё на месте, кроме helpov. Кто ни будь сталкивался с такими чудесами?

Извините, я в глубоко сомневаюсь. Тут какая-то лажа.

Это как-же нужно было "искать" что-бы на родном сайте IAR просто не взять .

Moderator:
Придерживайтесь заявленной темы.

Мне надо было с ключиком. Проект кже давно за 30 кил разрешённых в триальной версии.

А вы попробуйте сжать свой установленный IAR хотябы RAR, и с удивлением обнаружите что он сжался раз в 5! Не 10 метров конечно но ~24 у меня сжался.