Снова не пойму как 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 компилятор будет знать об этом и будет в цикле обращаться всегда к самой переменной, а не к ее копии.

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

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

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

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

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

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

Или вот еще, тоже шедевр. Блин, чем больше в дизассемблере лажу - тем больше расстраиваюсь!

Простое копирование двух массивов. Ну почему не задействовать пару свободных регистров указателей, скажем Х и Z? Нет, мы будем каждый раз грузить новые значения указателей в ОДНУ регистровую пару, теряя по 2 машинных цикла на каждой итерции. Вроде ж начало получилось хорошее, а дальше... Не понимаю!

То же самое, реализованное в цикле. Еще хуже:

Лучший код генерит только ICC, но вот полчить его в работающем виде и без ограничений по времени/коду пока сложно...

Тем не менее местами просто сказка и песня! Нарадоваться не могу. А вариант, который Вы показываете более характерен для подпрограмм или прерываний. Ещё некоторые моменты меня беспокоят.
Например вход выход из прерывания при максимальной оптимизации по времени типа такого:

834 }
\ ??CrossCallReturnLabel_588:
\ 00000214 BE4F OUT 0x3F, R4
\ 00000216 .... RCALL ?Subroutine201
\ ??CrossCallReturnLabel_563:
\ 00000218 .... RCALL ?Subroutine206
\ ??CrossCallReturnLabel_579:
\ 0000021A .... RCALL ?Subroutine200
\ ??CrossCallReturnLabel_560:
\ 0000021C 9049 LD R4, Y+
\ 0000021E 9518 RETI

Где каждая п/п - восстановление группы регистров.

У меня в настоящий момент М2560. Занято от силы 30К! Зачем так делать??? На ASMе такое даже в страшном сне не приснилось бы.

Конечно не по Вашему вопросу, но конструкцию которую Вы приводите при большом размере пересылаемых данных лучше сделать так.

memcpy(AdrActiveKom[i],AdrActiveKom[i+1],x);

(В данном случае AdrActiveKom - это массив ссылок) Для данных например так:

memcpy(&Status.Day+AdrStatus,&SlaveBuf[1],5);

Я проверял. Получается значительно эффективнее по времени.

Попробовал ради интереса. Получил другие результаты. Код:




Результат:



Ага, но тут массивы объявлены в одном файле, компилятор их "кластеризовал" и обошелся эффективно одним указателем, благо размеры массивов это позволяют. Усложним компилятору задачу, объявив один из массивов внешним:



Результат:



Он не так печален, как вашем примере. Может все-таки с оптимизацией что-то не то?



Код:



Результат:


Что может быть короче?

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

Код, который вы показали, был характерен для IAR'овских компляторов версий 2.хх - они там упорно делали все подобные обращения в память через Z-pointer, что далеко не всегда хорошо, на что было указано и в версиях 3.хх уже ситуация изменилась к лучшему. Основная же причина сидит не в компиляторах, а в самом AVR, в котором мало (всего два) полноценных аппаратных регистра-указателя (Y и Z, X - неполноценный, у него отсутствует очень важный режим адресации со смещением). Т.е. один из указателей занят под указатель стека данных (еще один, мягко говоря, неудачный момент AVR - обо всех этих "фичах" AVR уже подробно говорилось, если интересно, поищите по форуму), остается один Z-pointer, который компилятор и пытается использовать. В данном случае удалось выйти с честью из положения, т.к. производится просто последовательное копирование. А вот если бы надо было выборочно извлекать байты из массивов, то тут X-pointer уже не порулил бы совсем и код был бы действительно печальным.

Совершенно верно, только приведенные здесь примеры относятся к компиллеру IAR 4.20a. Я сам удивляюсь, в программе много мест копирования массивов, и почти везде он все делает правильно. Копирование массивов с автоинкрементой регистров указателей. Особенно если большие массивы. Но бывают места, где оптимизатор "теряется" :-) Я ж не придумал это.
И еще напрягают попытки ИАРа по два раза считывать одну и ту же ячейку памяти при выполнении кода типа при отстутствующем спецификаторе volataile
А в общем, ИАР мне нравится. Но это ж не значит, что он не может быть лучше ;-)

Попробуйте так:

Попробовал. Никакой разницы. Да оно в общем-то и понятно. Было бы удивительно, ведь с точки зрения "С" а--; и а -= 1; абсолютно идентичны.

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

И вот на этой приятной ноте и хочется спросить, - а стоит ли применять такие методы?

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

Например высказывание одного человека в форуме (примерно так) "... я групирую и увязываю связанные данные в структуры и в п/п передаю указатель на структуру... ...С массивами вообще не работаю... .... получается очень эффективно...". Я совершенно согласен с автором. Ничего сложного в этом нет. Понятно что можно обратится к элементу байтового массива Arr[i] или *(Arr[0]+i), но где у этого край??? Можно и умножение сдвигами заменить и двинутся дальше.

По идее эффективность работы с массивами должна после трансляции быть такой же как и при работе с указателями. Но этого нет. При больших массивах выигрыш от встроенной функции копирования или очистки массивов (приведенных выше) в разы! Очень существено. Хотя тот же компилятор запросто мог бы применить аналогичный приём!


И ещё никто не ответил мне на следующий вопрос. Почему при совершенно свободной Flash памяти и установленном максимальном уровне оптимизации по скорости компилятор генерит такое значительное колличество вспомогательных подпрограмм? Что я делаю не так и как этого избежать. Я же на них inline поставить не могу. Где это задаётся?

Мой пост прошу не относить к критическим в адрес компилятора. Компилятор мне нравится и претензий у меня к нему, фактически нет. Просто хочу лучше узнать его. И проанализировать разные подходы людей к программированию. Особенно учитывая Ваш опыт.

С уважением.

Речь как я понял идет о перекрестных вызоывах. Полезная штука, кстати сказать, при незначительной потери в скорости, получается выигрыш от 10% и выше по объему кода. Одинаковые куски кода заменяются на подпрограммы. На этапе отладки я обычно отключаю. Ищите галочку "cross call" в закладке C++ -> Optimization.

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

более эффективно, чем

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

Я могу ошибаться, но речь идет о Function Inlining. Cross Call делает как раз "обратную" операцию - выносит из функций общие блоки в отдельные вызовы.

Вы действительно ошибаетесь.
Речь была о том, что cross call оптимизацию предлагается отключить, чтобы компилятор не создавал много вложенных функций. При максимальном уровне оптимизации эта опция включена по умолчанию.
Что касается Function Inlining, то это относится к пользовательским функциям. Если компилятор сочтёт их достаточно короткими, то он их инлайнит.

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


В результате имеем нормальный код:


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

Если уж подсказывать, то подсказывать по полной программе:

Согласен. Это уже полный портабл...

Хе-хе. И правда в таком случае IAR все делает грамотно. Вот только читабельность кода страдает. Наверно и вправду чем быстрее код - тем ближе к ассемблеру :-)

PS: всех с наступающим!

Вообще-то, IAR игнорирует ключевое слово register. Или нет?

Может игнорировать если нельзя обеспечить.

Причем игнорировать молча. Иными словами, если можно обеспечить, то и так задействует регистр, если нельзя, то не задействует, ничего не сообщая. Так сегодня поступает подавляющее большинство (если не все) компиляторов. От ключевого слова register ничего не зависит, оно является рудиментом и артефактом. Оставленным в языке для совместимости со старым кодом. Есть не просит, пусть будет.

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

Это не совсем так. Просто в IAR сделано именно так. Где размещать переменные решает только компилятор. В других средах (например, в Borland) имеется возможность выбора: не размещать переменные в регистрах, размещать автоматически или размещать по ключевому слову register. Сейчас, когда ресурсов в PC предостаточно, компиляторы стали достаточно "умными", то необходимость в использовании register как бы отпадает. Но в контроллерах с ограниченными ресурсами иногда желательно дать возможность решать вопрос о размещении переменных самому программисту.

И как, например, запретить размещать переменную в регистре? Какое ключевое слово для этого используется?


Борланд - это PC. Неужто в нем недостаток регистров? Ни разу не встречал в коде для Борланда (начиная с версий оного 4 и выше) подобных попыток оптимизаций.

Имхо, уже давным давно прошла необходимость рулить такими оптимизациями из С-кода. Компилятор с этим разберется лучше. Программисту надо состредоточиться на алгоритме, а уж как по регистрам совать - тут все карты на руках у компилятора. Если хочется адекватного результата ручному контролю, то это ассемблер (вызов функции или вставки).

Кроме IAR, еще несколько компиляторов не замечены во внимании к ключевому слову register: CCS/TMS320F28xx, VDSP++/Blackfin, avr-gcc (правда, с последним знакомство поверхностное).

P.S. Посмотрел в доку на Билдер:

-r-
Про Builder, правда ничего не скажу и отключением никогда не пользовался и пользоваться не буду .

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

В Borland C++ в проекте можно указания опции для использования регистровых переменных:
None, Automatic и Register keyword. Т.е. в первом случае компилятор не будет размещать переменные в регистрах, во втором случае он будет размещать переменные в регистрах автоматически как только он сочтет это нужным. В третьем случае в регистрах будут размещаться только те переменные, для которых указан класс памяти register.

Похоже Вы немного пошутили или не то имели ввиду. По сравнению с AVR в PC регистров почти нет.

А если учитывать, что часть из них связано с определёнными функциями (CX - регистр счётчик, BX,EX -базы, AX - аккумулятор). То такая оптимизация вообще не имеет смысла. Да и при таком построении процессора, вопрос такой экономии не ставится. Там оптимизация строится на базе совершенно других принципов. Длина цикла - размер кэша - объём данных по работе с памятью, "грамотное обращение" к переферии и т.д.

Не стоит забывать, что эти регистры 32-разрядные. И есть возможность использовать их и как 16-, и как 8-разрядные. К тому же, у AVR есть определенные проблемы с использованием младших 16 регистров. Так что реально используются только 16 старших регистров. А если требуются данные типа long или float, так их останется на все про все всего 4. И опять же, у PC инструкции позволяют оперировать с ячейками памяти как с регистрами (при увеличении длины инструкции и времени ее выполнения). Так что вопросы оптимизации программы за счет использования регистров остаются весьма актуальными.

Ну это скорее желаемое чем действительное. Регистры действительно 32-ух битные, но их нельзя использовать, например как 2 16-ти битных или 4 - восьми битных. Если говорить о "определённых проблемах по использованию отдельных регистров", то здесь INTEL явно лидирует. Например сложить B и С Вам не удастся. Если же Вы попытаетесь написать реальную прогу, даже на ассемблере, длиной хотябы листа два, используя расширенные команды, то Вам врятли удастся съэкономить даже один регистр. А компилятор даже не будет пытаться это делать.
Но это и не нужно. Вы совершенно правы, во второй части. INTEL имеет развитой механизм работы с памятью. Учитывая все мыслимые способы адресации. А сама архитектура (кэш буфер данных) позволяет к значительным массивам используемых данных обращаться, фактически как к регистрам. Кроме кэша данных есть кэш программы, что накладывает свои особенности. Ну и наконец, наличие нескольких ALU (в пнях уже по-моему 2-целочисленных и 1 с плавающей запятой) - тоже имеет значение. Поэтому оптимизация программ там имеет совершенно другие принципы и особенности. Согласно литературе это всё учитывается компиляторами. Я читал, что в Windows используются циклы определённой длины, а компилятор прогу делает так, что бы распаралеливание было максимальным.

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

Именно, что верно. А "НО" не верно. Зато верно поскипанное:
Читая документацию случайно наткнулся. EWAVR_Compiler reference-> Implementation-defined behavior-> REGISTERS:
То же самое и в доке на ARM.
P.S. Так что зря мы тут копья ломали, все ответы - они в доке, только нужно знать, где искать. А чтобы знать, нужно сначала ее прочитать. Только кто ж ее читает, от корки до корки ?

Ну положим совсем не зря:
-Ключевое слово существует.
-Некоторыми компиляторами игнорируется.
-Некоторыми - нет.
-Иcпользование как минимум не помешает.

Ну а документацию - документацию надо читать именно упорно от корки до корки. Я обычно перед сном раньше читал, последние годы как-то и на сон не хватает .