Вот, наткнулся на свои макросы...
Хм, запрета прерывания нет, но работает... Ах, да... Я же WDT никогда не отключаю.
Вот таким косвенным путем происходит обучение правильному использованию ресурсов контроллера

Вот именно, что все это очень странно. Насколько меня учили, порты в МК - это volatile-переменные, поэтому компилятор при оптимизации должен позаботиться о всех сторонних эффектах, если он претендует на совместимость со стандартом "С". Т.е. явное игнорирование разработчиками компилятора стандарта. Попросту говоря, баг. Или не так?

В чем тут игнорирование стандарта?

Я бы сформулировал по другому:
Имеет ли право Атмел приводить пример сишного текста программы работы с WDT, если конкретная реализация в машинных кодах зависит от компилятора.

Короче, так - если у автора текст не совпадает полностью с примером в даташит - не прав автор.
Если текст совпадает - не прав Атмел.

Есть там глава про сторонние эффекты и volatile-переменные. Нужно, конечно, рыться и внимательно читать, но, по памяти, стандарт прямо запрещает оптимизацию ДАЖЕ по времени, если в этом принимают участие volatile-переменные. А тут работу препроцессора взял на себя компилятор и оптимизировал как хотел... Компилятор НЕ ИМЕЛ ПРАВА на такие вольности.

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

Тогда вообще ничего не понятно.
Почему, как указывалось в http://electronix.ru/forum/index.php?showt...st&p=583723

"Код
WDTCSR |= (1 << WDCE) | (1 << WDE);
Компилятор действительно генерит код не укладывающийся в 4 такта...
Я решал проблему, описываемую автором темы, записью нужного числа непосредственно в регистр, типа того:
Код
WDTCSR |= 0x01;
При этом (как ни странно) код получается нормальный, даже с полной оптимизацией, и число попадает в регистр без лишних тедлодвижений..."

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

Нет, разный. В одном случае установлен 1 бит, и компилятор генерит инструкцию sbi, во втором случае 2 бита, и иначе как через in, or, out не получится. А еще проще не использовать в этой конструкции "или" вообще - сразу писать нужное число. Потому что состояние остальных битов, как правило, известно заранее:

Ну, я воспринял это просто как пример. Типа автору стало лень считать HEX-содержание своего кода.... и понесся обосновывать
А вот сейчас в спокойной обстановке дома решил исследовать что же на самом деле происходит и ... чешу затылок. Мне никак не удается при любых уровнях оптимизации и вообще без нее добиться того, чтобы компилятор по разному оттранслировал процедуру инициализации WDT.
Т.е. вот такой код независимо от того стоит перед ним #pragma optimize=none или нет, написаны команды инициализации в виде команд препроцессору или в виде чисел (закоментарено) все равно транслируются одинаково.


ассемблерный код

Наверное поэтому никогда раньше не задумывался над этим вопросом, хотя по привычке всегда использовал #pragma optimize=none
Может быть с оптимизацией таки можно заставить компилятор генерировать вызовы функций посредине двух WDTCSR = ..., но надо таки постараться не по детски
PS. Компилятор последний, 5.20, для примера взята mega48