Может ли меняться логика откомпилированной программы при использовании разных режимов оптимизации?

[Godzilla82]

Маразм, говорите? Представьте себе проблему перелопачивания кода при изменениях в схеме (каково будет менять код, при переносе функционала PB6 на PB3, например, если Вы вместо (1‹‹PB6) пишете 0x01000000).

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

Вы путаете volatile и static.

В Borland C++ для PC вообще нет таких директив.
И какая тут оптимизация что может поделать, если переменная глобальная и будет сохранять своё значение всегда и при вызове из любой функции/прерывания.

Медленнее, чем что?

Чем

ldi r16, 0x00
ldi r17, 0xFF
out PORTB, r17
out PORTB, r16

Это уже другое дело; это вопрос алгоритма, а не железа. И потом, это же не частота опроса клавиатуры, а скорость однократного опроса (если мы говорим о фунции GetKeyPress).

Это как раз вопрос железа. В алгоритме-то как раз всё вроде правильно. Выдаём одиночный импульс. И считываем клавишу. А на практике при высокой частоте этот одиночный импульс может потеряться (то есть считаться 0 вместо 1 за счёт инерционности монтажа).

[testerplus]

В том виде, в котором она сейчас, перелопачивать придётся всё равно много.

Вопрос не столько в объеме, cколько в гарантии того, что изменение введено везде, где надо, и не введено там, где не надо.

Сообщение от testerplus

Вы путаете volatile и static.

В Borland C++ для PC вообще нет таких директив.

Наверное, вы просто забыли. BC++ для PC обрабатывает квалификаторы (это не директивы) valotile и static по всем правилам. В аттаче скриншоты хелпа к BC++.

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

Просто Вы не сталкивались с volatile скорее всего потому, что для того, чтобы под BC++ понадобился volatile, нужно иметь дело с многопоточным приложением, в котором есть доступ к одним и тем же глобальным переменным. (Обработчики прерываний вообще не пишутся в прикладных приложениях на BC++). Если же Вы писали многопоточные приложения, не пользуясь volatile, то, скорее всего, Вы просто не подозреваете о слабых местах Ваших приложений.


А насчет static: я полагаю, Вы просто всегда, сталкиваясь с необходимостью сохранять переменную до следующего входа в функцию, переводили переменную в статус глобальных. В этом есть два недостатка:
1. Теряется наглядность. Когда переменная описана как локальная, нет сомнений, что она используется только в функции.
2. Если в нескольких функций нужны сохраняемые переменные со схожим функционалом (например счетчик, который интуитивно обзывается Counter), будет проблема с именованием глобальных переменных (понадобятся Counter1, Counter2 и т.д.).

Кстати, переменная может быть объявлена с обоими квалификаторами:

static volatile int Counter;

Справедливо и для BC++

А на практике при высокой частоте этот одиночный импульс может потеряться (то есть считаться 0 вместо 1 за счёт инерционности монтажа).

Да, это так. Но в большинстве случаев 2х nop'ов достаточно.

[SasaVitebsk]

2 testerplus. +1000

Даже несмотря на то, что константы я перестал применять ещё при программировании на ASM, при переходе на Си, отметил для себя что писанины стало больше. При чём чем дольше я пишу на Си, тем больше уходит на описание "глупостей". Результат - универсальность текстов, независимость проектов, очень быстрые корректировки проектов и перенос проектов. Есть проекты для разных камней с общими исходниками.

Зачем? Так это ведь главное преимущество работы на языках высокого уровня.

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

[Godzilla82]

Вопрос не столько в объеме, cколько в гарантии того, что изменение введено везде, где надо, и не введено там, где не надо.

Такую гарантию может дать только внимательность и ответственность программиста.

Наверное, вы просто забыли. BC++ для PC обрабатывает квалификаторы (это не директивы) valotile и static по всем правилам. В аттаче скриншоты хелпа к BC++.

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

В этом есть два недостатка:

1. Я бы сказал - наоборот. Повышается наглядность. Есть переменная. Глобальная. Она доступна везде. И вот она - объявлена заранее. И она, естесственно, будет сохранять своё значение от вызова к вызову и от функции к функции (например её можно изменить в двух обработчиках двух разных прерываний).

2. Ещё более улучшается наглядность, так как каждый счётчик получает осмысленные имена, например: time_count, mm_count и т.д.

Да, это так. Но в большинстве случаев 2х nop'ов достаточно.

Особенно если идёт обмен данными с какой-нить железякой

P.S. Что-то давно топикстартера не видать...

[st_1]

При чём чем дольше я пишу на Си, тем больше уходит на описание "глупостей".

А чтобы небыло "глупостей" полезно будет вам почитать K&R и вот это
http://www.pic24.ru/doku.php/osa/art...without_errors

[testerplus]

Такую гарантию может дать только внимательность и ответственность программиста.

"Внимательность" и "ответственность" - характеристики непостоянные, даже применительно к одому человеку (настроение, временные рамки, суета вокруг и т.д.). Так что спасает не "внимательность", а "однозначность": т.е. не "способность исправить ошибку", а "создание условий, при которых ее труднее допустить". А "ответственность" - в "дальновидности": т.е. не в "усидчивости и методичности при внесении изменений в программу", а в "умении предусматривать возможные изменения и заранее обеспечивать их надежность". Только не спорьте, что 100 раз изменить константу 0x01000000 на 0x00100000, предварительно убедившись, что меняем в нужном месте, проще и надежнее, чем один раз заменить (1 ‹‹ PB6) на (1 ‹‹ PB5) в строчке с #define'ом.

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

Я бы не советовал так несерьезно относиться к volatile, этот квалификатор не зря предусмотрен в Си. Потратьте полчаса, прочтите это: http://wiki.pic24.ru/doku.php/osa/ar...e_for_chainiks. Там с примерами (из реальных программ) и дизассемблером.

1. Я бы сказал - наоборот. Повышается наглядность. Есть переменная. Глобальная. Она доступна везде. И вот она - объявлена заранее. И она, естесственно, будет сохранять своё значение от вызова к вызову и от функции к функции (например её можно изменить в двух обработчиках двух разных прерываний).

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

2. Ещё более улучшается наглядность, так как каждый счётчик получает осмысленные имена, например: time_count, mm_count и т.д.

Ну, не будем разводить религиозных войн о системе именования. Озвучу только свое мнение: "осмысленная" часть имени - это "count", а приставка "time" или "mm" (кстати, уже загадка: что такое mm?) - это уже не смысл, а уточнение.
А о наглядности: Вам приходилось когда-нибудь работать с чужими исходниками? Будете очень сильно плеваться, когда для того, чтобы подсмотреть тип переменной, придется все время бегать к началу файла, вместо того, чтобы поднять глаза к верху экрана (к началу фукции).

Особенно если идёт обмен данными с какой-нить железякой

Это уже из другой оперы.

[SasaVitebsk]

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

Глобализация переменной не решает всех проблем. Вы просто не понимаете что вы пишите.
Приведу простой пример.

uint8_t global;

#pragma vector=TIMER1_OVF_vect
__interrupt static void inter(void)
{
  global++;
}

void main(void)
{

 for(;;)
 {
   if(global›50) break;
 }
 PORTA = 0xf0;
 for(;;)
 {
 }
}

В данном случае при оптимизации main, компилятор сначала вынесет if за рамки цикла. Оно и понятно, так как с точки зрения компилятора переменная global, будь она хоть 10000 раз глобальной внутри цикла не меняется. Так зачем её проверять в цикле? volatile эту проблему решит.

PS: на стиль не смотрите, это пример для наглядности.

2 st_1. Я глупости взял в кавычки. K&R я читал, хотя, что очевидно, не претендую на дословное цитирование. Я описываю очень много, возможно с первого взгляда избыточно. Но всё это выстрадано. Я на 200% поддерживаю лозунг - "ни одной констаны в тексте проги". Для наглядности можно посмотреть тексты uCOS от микриума. Я немного не так компаную, но педантизм микриума у меня не вызывает отторжения. В целом я их поддерживаю.

[st_1]

Я глупости взял в кавычки. K&R я читал, хотя, что очевидно, не претендую на дословное цитирование.

Не принимайте близко к сердцу.

[Godzilla82]

так как с точки зрения компилятора переменная global, будь она хоть 10000 раз глобальной внутри цикла не меняется. Так зачем её проверять в цикле? volatile эту проблему решит.

Пользовался примерно такой же конструкцией. В прерывании устанавливался флаг. А в цикле проверялся. Примерно так:

interrupt [TIM0_COMP] void timer0_comp_isr(void)
{
pw=0;
}

void my_function(void)
{
while (pw);
...
}

И как ни странно, это всё работало при всех оптимизациях

[st_1]

И как ни странно, это всё работало при всех оптимизациях

А может это были не вы? А может это был не СИ? А может это был не МК?