Это intrinsic function, описанная в EWAVR_CompilerReference.pdf и обьявленная в intrinsics.h

Причем тут "тяжелое наследие"!? Это удобное расширение Си, реализованное в ИАРовских компиляторах в виде intrinsic function. Выше я уже приводил кусок хелпа, а Сергей Борщ кратко про нее рассказал.

Могу повториться: встретив эту функцию, компилятор заменяет её кодом минимальной длины (циклами), который выполняется заданное число тактов конкретного процессора. Большое преимущество этой фичи в том, что во-первых не нужно в ручную подбирать циклы, а во-вторых, этот кусок кода не трогает оптимизатор. Все свои программные задержки, где забываешь счетчик цикла объявить volatile, оптимизатор безжалостно выкидывает

Одно плохо: функция не стандартная.

Еще это является с некоторых пор и "тяжелым наследием 16-разрядной архитектуры" - в том же EW430, например, с некоторых пор тоже существует такой интринсик.

Вообще, имхо, к архитектуре это отношения не имеет, местами вполне полезная фишка.

Есть предложение считать правильной такую версию: эта функция реализована в компиляторах ИАРа для процессоров, у которых детерминировано время выполнения команд. Вот, например, у ARM7 время выполнения зависит от места исполнения (ОЗУ/флеш), от настроек ускорителя, у более старших (скорее всего) - от настроек кеша. Поэтому в EWARM такой функции нет.


Это у Николая стиль общения такой - "тяжелое наследие", "обломок совместимости". Не обращай внимания.

Понятно... А то я озадачился отсутствием этой функции в моих библиотеках... специально искал ее и не нашел...

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

Даже на 8051-м процессоре(поискал и нашел-таки в старых залежах) я постарался аналогичную функцию исключить из употребления и необходимые задержки предпочитал вставлять сам в виде 2-3 asm(" nop"); или соответствующих циклов.

Зачем? А вот как раз затем - что аналогичная функция в моем случае позволяла задать пераметром не только константное выражение. В результате - один из наших "сильно умных" практикантов написал кусок кода с операцией деления при рассчете этой задержки. Ну а деление в свою очередь - не имело аппаратной поддержки... Как результат - вот именно то о чем говорил zltigo - вместо задержки на фиксированное количество тактов - получалось черт знает что. Если точнее - функция-то задержку делала правильную, но ей предшествовало вычисление величины этой задержки, которое занимало в несколько раз большее время и это время сильно зависело от заданных значений.


Угу... А когда забудешь и влепишь выражение в параметр подобной функции - это лучше?
Я предпочитаю явное указание оптимизатору давать : "а не лезь сюда со своим интеллектом" - volatile это...
А насчет рассчитать величину задержки - а что тут такого суперсложного?

Насчет стандартности - такая функция(и другие ей подобные) стандартной быть не может и не должна. Ибо она платформенно-зависимая в очень большой степени.


А у меня не EWAVR_CompilerReference.pdf , у меня EWARM_CompilerReference.pdf

Сообщение отредактировал Николай Z - Jan 10 2008, 08:54

Да ничего, но ее надо рассчитать. Для чего надо знать про оптимизацию. Или вставлять код на асме. А __delay_cycles(X) делает это автоматом, наиболее корректно и затем при чтении кода не возникает вопросов о том, что это такое.
Так что в ситуациях, когда нужны небольшие задержки - по моему, самое оно.
Насчет переносимости - она обычно используется где-то глубоко внизу, а при переносе на другую платформу "низ" обычно приходится так или иначе переписывать...




В данном случае компилятор не позволит использовать неконстантное выражение.

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

Ну а было бы - допустим - прозрачным, самоочевидным и ясным определение это функции - то и не было бы тут этого обсуждения. Кстати...

Вот по такому определению функции мне совершенно неясно - что параметр должен быть константным выражением (eго Baser привел и видимо оно в *.h и забито):
...
Значит это ограничение забито где-то еще... Ну а часто ли мы по каждому поводу лазаем по мануалам?
Вот и делайте выводы.

Сообщение отредактировал Николай Z - Jan 10 2008, 09:56

Чесно говоря я не могу придумать более самоочевидного и ясного определения:
__delay_cycles(k); - подождать k циклов (вставить k виртуальных NOPов).
А если параметр будет некорректным - компилятор ругнется. ПосмОтрите в хелп (один раз) и далее будете применять правильно. А посколько функция нестандартная, скорее перед ее применением посмотрите в хелп (также один раз).

А приведенный вами пример с задержкой для 8051 только подтверждает мои слова, там у вас компилятор не ругался, а что получилось?
Вот и делайте выводы.

Да ради бога - нравится используйте...

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

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

Вот вам еще один довод против вашего метода:
Даже если ваша функция задержки обложена volatile, __root и т.д., в ней напрочь отключена оптимизация, то где гарантия, что новая версия компилятора не станет по другому генерить код и все задержки поплывут!?

Гарантия в НЕИСПОЛЬЗОВАНИИ софтовых задержек . Заодно не будет удивления от отсутствия у других компиляторов и компиляторов для других платформ не сколь полезных, сколь провоцирующих функций задержек.

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

А разве трудно сделать простейшую функцию опроса таймера? Кто сказал, что один таймер это мало?
Процесс простейший:
1) Узнать текущий отсчет таймера...
2) Посчитать требуемый...
3) Пока значение меньше требуемого - вертеть цикл с операций NOP...

Ну а если Вам нужна задержка на 1-2-3-5 тактов - обкладывайте это место volatil-ом сколько хотите и никакой оптимизатор туда не полезет... Особенно если там вставлен ассемблерный код прямо в C-шную функцию...

А для длинных задержек - не грех и семафоры устроить и ждать их(call-back или любой другой механизм)...

Ну а если Вы заглянете в коды FreeRTOS - для STR912 - то вообще обнаружите, что там весь тайминг построен вообще не на таймерах... А на сторожевом таймере - watchdog-е... Мне это было немного странно - при наличии целых 3-х таймеров и одном RTC, но вот так есть...

Сообщение отредактировал Николай Z - Jan 12 2008, 11:58

Согласен, можно и так

Дэк - классика это... К тому же - Вы сами сказали - для очень коротких - лучше на ASM написать функцию, которую никакой оптимизатор не тронет - C-шный... И сомнений не будет - относительно правильности-неправильности определения нестандартной функции... Индусы, которые их лепят - далеко не всегда думают о всех возможных последствиях опрел\деления функций подобных delay_cycle(n)...