Снова не пойму как IAR работает с переменными...
Оптимизация вся выключена, дабы не влиять излишне.

Имеем такой вот код:



Почему компилятор, имея в регистре значение переменной, и следующую операцию с ней же, тем не менее сначала сохраняет ее, а потом загружает? Переменная не volatile.
Почему в первом и втором случае обращение к одной и той же переменной делается по разному??
Как избежать такого извращенного обращения к переменным?

Эквивалентный (нормальный) код:


Спасибо заранее!

ИМХО потому что запись

на самом деле краткая и обозначает

Аналогично

обозначает

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

А почему оно в одном случае загружает переменную из памяти при помощи LDS, а в другом через LDI?

И по обьёму кода и по скорости варианты lds/sts и ldi/ldi/ld/st эквивалентны.
Второй вариант начинает иметь преимущество если переменная длиннее одного байта или когда она участвует в цепочечных операциях.

Почти эквивалентны. Первый вариант все ж чуток быстрее, насколько помню. Но по объему если работа с объектом больше одного байта, второй начинает неслабо рулить.

На этот раз для меня не понятный момент. До этого - не встречался с такой ерундой.
Переменная объявлена так (начало файла)

int16_t static HeadInBuf=0, EndInBuf=0; // RS232. Указатели буфера. Указатель на голову и хвост достоверных данных

Внизу в колове имеется такой оператор.
...
while (HeadInBuf == EndInBuf)
AnswerGo(); // Ждать прихода символа с RS485
....

Сижу в отладчике - вижу, что переменные HeadInBuf и EndInBuf - разные (пришёл пакет данных), но условие не проверяется, непрерывно выполняется AnswerGo(). И из цикла не выходит.

Скорее всего надо чего-то указать компилятору при инициализации переменных. Вопрос - что?

Добавить volatile в объявлении переменных. Или даже заменить static на volatile, т.к. я не уверен, что компилятор съест их оба враз.

Cовершенно разные ни коим образом не противоречащие друг-другу вещи - не может не скушать.
Правда следует отметить, что static ни каким боком к проблеме не относится.

Информация к размышлению. Объявление не менял. Поменял конструкцию на вот такую.

do
AnswerGo();
while (HeadInBuf == EndInBuf); // Ждать прихода символа с RS485

И всё заработало.

В обоих случаях смотрел откомпилированный текст.

В первом случае было типа

rcall ...
brne ...
rcall ...
rjmp PC-1 ( должно было компильнутся в PC-3)

Во втором случае придраться не к чему. Надо сказать что эта конструкция в тексте встречается 3 раза, и возможно он пытался к общему знаменателю придти. ???

Опции по оптимизации выставлены такие.
speed high
все птички
3 прохода
птичка

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

Всем спасибо за ответы.
С точки зрения логики работы программы - оба варианта для меня равнозначны. Так как ответ выдаётся ч/з паузу после приёма предыдущего пакета, а выход из цикла - после получения нового. Сама конструкция несколько тяжеловесней, но не буду об этом.

Хочу спросить следующий вопрос. Таким образом после объявления переменной как volatile, код (в общем случае) должен быть эффективнее? Я это к тому, что наблюдаю как компилятор создаёт в ряде случаев локальные переменные и с ними работает, а не обращается напрямую. Вопрос не эффективности, а защиты данных.

Он не будет эффективнее, скорее даже наоборот. Но код будет коррекктным, поскольку volatile запрещает компилятору оптимизацию (с его точки зрения) кода при обращении к этим переменным. Типичный пример оптимизации - работа с копией переменной в регистре а не с самой переменной в памяти. Компилятор считает, что если переменная в цикле не изменяется, то повторное обращение к памяти излишне. Т.е. компилятор выносит за пределы цикла все действия инвариантные данному циклу. В данном случае это неверно, поскольку значение переменной меняется иным, неизвестным компилятору, образом (в прерываниях). В случае же обращений к переменным volatile компилятор будет знать об этом и будет в цикле обращаться всегда к самой переменной, а не к ее копии.

Сообщение отредактировал _Bill - Dec 8 2006, 17:33

Спасибо, разъяснили доступно. Извините за наглость, но чтобы окончательно закрыть данный вопрос, - а существуют ли директивы компилятора позволяющие включать/отключать оптимизацию выборочно по тексту? У меня, к примеру, это первый случай возникновения такой ситуации и не хочется глобально отключать оптимизацию переменной по той или иной причине.

Заранее спасибо за ответ.

Естественно.
#pragma optimize=
Подробности естественно в документации на компилятор.
Но в Вашем конкретном случае это просто использование volatile - можете считать, что это "отключение оптимизации" для конкретной переменной.

Интересно мыслите, однако! Как вам такой пример, я честно говоря до сих пор не понимаю отчего IAR 4.11a так себя ведет. Оптимизация включена на максимум, окромя "cross-call"

Все это компилится в ледующий код:

Сохраниение и восстановление стека я опустил.
Что мы видим? Грузим переменную, проверяем ее, если условие выполняется, опять ее же грузим (ЗАЧЕМ?), причем засоряя адресные регистры, модифицируем и сохраняем. В результате имеем 3 лишних комманды + 4 для сохраниения-восстановления адресных регистров. Более чем в 2 раза, однако! Никак оптимальным такой код не назовешь. Что скажете..?