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

Глобальная, но без volatile, т.е просто int a



А что мешает считать ее в регистр из памяти один раз, обработать и записать обратно? Отсутствие оптимизации? Заняты все регистры? С volatile было бы понятно: "мол, не ты один имеешь доступ к переменной, так что изменяй ее там, где она есть"

Можно, конечно, поугадывать ход мыслей компиляторописателей, но зачем? Жизнь слишком коротка. Ориентированность на результат - вот залог успеха. А ковыряние в дизассемблере, как правило, - это время, слитое в унитаз.

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

Спасибо, постараюсь руководствоваться Вашей рекомендацией.



Компилятор в Keil 4. Но дело, по-видимому, в отсутствии оптимизации. Включил оптимизацию 3-го уровня и жизнь наладилась)


Это да, я в тестовом примере не озаботился оптимальностью.

Если честно, не ожидал такой реакции :-) Чтобы совсем "добить", немного на тему преждевременной оптимизаци.
Признаюсь честно, сам грешил преждевременной оптимизацией поначалу. Заглядывал в дизассемблер, пытался понять, какой исходный код лучше подсунуть компилятору, чтобы на выходе получилось эффективнее. Это занятие сродни разгадыванию кроссвордов: пользы для дела никакой, оправдано только как досуг. А вред очевиден: потерянное время, засранные исходники.

Да я нормально отреагировал) Спасибо за ссылку, познавательно. Читал рекомендации, что оптимизировать надо там, где не пролезает по каким-то критериям. Вот тут и не пролезало: это ж надо в 2 раза меняется частота моргания, начал смотреть в дизассемблер.

Тогда предлагаю такой вариант:

За счёт большого числа нопов зависимость времени выполнения функции от уровня оптимизации кода становится маленькой. Не очень красиво, но проще, чем с таймером.

Возьму на заметку,спасибо, но я с таймером разобрался. Сейчас в прерываниях UARTa ковыряюсь.

Сообщение отредактировал IgorKossak - Jul 20 2011, 10:30

Это, возможно, и не нужно, хотя и не вредно совсем. А вот изучить документацию на используемый компилятор, и задать нужный уровень оптимизации нужно сразу. Оптимизация собственно кода (преждевременная, запоздалая или какая другая) в данном случае помянута ни к селу ни к городу.