Убил несколько часов на выключение WDT в Mega88 в программе на Си.
Вот такой код
__watchdog_reset();
MCUSR &= ~(1 << WDRF);
WDTCSR |= (1 << WDCE) | (1 << WDE);
WDTCSR = 0x00;
IAR при оптимизации умудрился разбить на процедуры (cross call), в результате чего между последовательными записями в WDTCSR проходило более 4 тактов, и выключенный изначально WDT включался, не давая нормально загрузиться системе.
Побороть смог только вынеся данный код в процедуру с выключением оптимизации для нее (#pragme optimize=none).
Возник вопрос - ни какими ключевыми словами нельзя изменить уровень оптимизации для фрагмента кода С ВОЗВРАТОМ к текущему уровню оптимизации (через #pragma optimize можно только установить требуемый уровень оптимизации, но не вернуться к установленному в свойствах проекта, по крайней мере я не нашел другого)?

Мне кажется, тут двух мнений быть не может: если нужно гарантировать не более 4-х тактов между инструкциями, то нужно писать на ассемблере. Иначе при каждом апгрейде версии компилятора и смене его настроек придётся проверять, как изменился этот кусок кода.

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

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


Не стОит быть столь категоричным.
Если программа написана грамотно, то апдейт версии компилятора (по крайней мере в данном случае) к ухудшению ситуации не приведёт.

Это я знаю, поэтому так и сделал (вынес в функцию, и предварил данной прагмой). Вопрос в другом - не хотелось 3 строчки выносить в функцию. Поэтому хотелось бы написать прагму перед этими строчками, и прагму, возвращающую "взад" уровень оптимизации после этих строк (по-моему, но точно не помню, в Кейле, или в BCPP так можно было сделать).
Ну что-ж: нет так нет.

И еще просто удивила замена ОДНОЙ команды вызовом процедуры с этой-же командой! "Перебдел" компилятор при оптимизации.

Вопрос знатокам: в указаном примере функция foo будет встраиваться? Мне inlining удается только когда поставлена опция оптимизации - high, а иначе RCALL foo. Не помогает даже #pragma inline=forced. (IARAVR 5.11B)

Самая вероятная ситуация: будет в релизе со включенной оптимизацией (а может и нет), в дебажной - будет отдельной процедурой.

В умных книгах написано, что компилятор не обязан встраивать inline функции, если с его точки зрения это хуже, чем вызвать обычную функцию.
См. Герб Саттер. Новые сложные задачи на С++.

А что, у компилятора или линкера есть какая то магическая опция "релизная версия"?

Есть переключение target-а на release/debug
Это опция не компилятора/линкера, а такой жёлтенькой оболочки IAR EWB
Причём и в том, и в другом можно задать любой уровень оптимизации, но по умолчанию в дебаге включен по-моему, "Best debug support", который отключает оптимизацию вообще

Поскольку может быть встроена функция только в том же файле, где определена, встает вопрос вообще о правильности пути для более-менее серьезного проекта.
Может быть, макрос? Оптимизатор не увидит смысла экономить на эпилогах - их просто не будет.

В том то и дело. Это название совокупности галочек в настройках, расставленных оболочкой по умолчанию. Т.е. нельзя говорить о том, что поведение будет зависеть от выбора в оболочке target release или target debug. Поведение будет полностью определяться положением галочек, расставленных в оболочке, но никак не названием этого target.


Путь однозначно правильный. Если нужно, функции с квалификатором inline, также как и static, могут быть вынесены в заголовочный файл. Объявление в виде функции (в отличие от макроса) возлагает на компилятор заботу о контроле правильности типов, а также о создании временных переменных для хранения параметров. Просто надо разобраться, почему не работает #pragma inline=forced. Возможно, они перешли на _Pragma("inline = forced"). И зачем вообще компилировать с оптимизацией, отличной от high - тоже совсем другой разговор.

В общем случае все это так, но если глянуть, с чего все начиналось у топикстартера, и какие же там переменные используются, то лично у меня вопрос остается.
Это просто разный инструмент, как вилка и ложка. Ложкой безопаснее, но вилкой в умелых то руках можно за два удара восемь дырок....

При записи вида:

Компилятор действительно генерит код не укладывающийся в 4 такта...
Я решал проблему, описываемую автором темы, записью нужного числа непосредственно в регистр, типа того:

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

Сообщение отредактировал tourist - Apr 24 2009, 12:13