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

Сергей, Вовсе даже нет! Просто этого оказалось достаточно. И спасибо было вполне отдушевное.

Неправильно поняли - я никого ловить не собирался. И противоречия в ответах я не наблюдаю.
Я только пытаюсь понять - а зачем это уточнение.
Я видите ли в том случае, если что-то не понял имею обыкновение переспросить.

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

Или задавать вопросы - это большой грех?

Сообщение отредактировал Николай Z - Jan 8 2008, 15:13

Нужно делать то, что нужно. А что нужно - либо точность, либо скорость - думайте. Еще придется думать о переполнении.

Макрос. Срабатывает при компиляции. На "большом" компутере. Переполнение... Нет, представляю, как оно может случиться, но по-моему, если не формировать секундные задержки наносекундным макросом то переполниться сложно

Про точность понима, а вот про скорость не понима... Что будет работать быстрее и почему?

У вас в макросах все константы - целые числа. Поэтому и все промежуточные результаты будут целыми. Все дробные части отбрасываются. Для точности нужно сначала УМНОЖИТЬ, а потом ПОДЕЛИТЬ.

А вот насчет переполнения сам не уверен: компилятор при константе UL будет считать в 32-разрядных целых или в 64-разрядных?
Если в 32-разрядных, то при больших частоте кварца и задержке будет и переполнение

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

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

UL - 32 разрядные. ULL - 64 разряда
Отнюдь. Если параметр x в точке использования макроса - константа, то IAR все выражение вычислит на этапе компиляции (а в приведенном в посте №1 коде там именно константа). Если переменная - то да, на этапе исполнения.

Спасибо! Самый понравившийся ответ
Видимо, именно потому, что не подумал о возможности подстановки вместо x "неконстанты" я и не мог понять, почему так. На всяческий случай подправил "универсально" в своих макросах - чтобы сначала выполнялось деление.

А вот действительно, наконец-то задумался и тоже не понял, что значит в данном примере СКОРОСТЬ.
Макрос то использует встроенную функцию ИАРа:

И если он будет генерить для одной и той-же или для близких по величине констант код, работающий сильно различное время, то это будет явный ляп ИАРа. А его не наблюдается
Так что может коллега zltigo имел в виду не скорость, а размер кода?

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




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

На этапе компиляции. Baser правильно заметил - аргументом __delay_cycles() может быть только константа, ибо компилятор для каждой конкретной задержки генерит подогнанный по тактам код. Для задержек в 2-4 такта вообще без цикла. Если использовать в качестве аргумента переменную - выдает ошибку на этапе компиляции. Исходя из этого можно посоветовать aspIDу поменять макросы назад - чтобы сначала выполнялось умножение и при прочих равных иметь бОльшую точность. А F_CPU объявить с индексом ULL - чтобы вычисления выполнялись в 64 битах и (при разумных задержках) не происходило переполнения.

Ну тогда в этом наиконкретнейшем случае наилучший вариант найден. Главное теперь известно, что возможны варианты

__delay_cycles() - это тяжелое наследие 8-ми разрядной архитектуры? Или что?

Я что-то перерыл все библиотеки в своем IAR-е 4.3 и вообще ее не обнаружил...

Что-то смутно помню подобное из архитектуры 8051... подобное... хотя всего год как бросил этот обломок совместимости...

Сообщение отредактировал Николай Z - Jan 9 2008, 20:44

Естественно