Макросы в IAR EWAVR, v5.40.1 Опции

[ivainc1789]

В девайсах ATtiny иногда приходится сильно экономить память программ и использовать макросы. Поначалу все получалось и вдруг наступил затык. Три раза проект компилировался нормально, а с четвертого вдруг началась ругань на один из макросов. Причем его строки однотипны, а ругается только с четвертой. Подскажите в чем причина? Использую IAR EWAVR.

[ivainc1789]

Непонятно, как именно вообще макросы могут сэкономить память программ (или вообще какую-нибудь память). И как ваши конкретные макросы её экономят.

Очень просто. Можно написать макрос как подпрограмму. Например, подпрограмма выбора Vref в ADC на основе всех возможных сочетаний. Это займет значительный кусок кода. Но потом выяснится, что применяется данная программа только один раз для установки Vref = 1v1. Ясное дело, это неэффективно. Если такую задачу решать с помощью макроса, то экономия памяти налицо. Вот почему для многих установок ADC полезно все же писать макросы, но для установки мультиплексора, возможно, подпрограмму (это зависит уже от конкретики задачи)...

Дело в том,что независимо от аргумента ваша фича скомпилируется в кучу операторов.

С чего бы это? Какая куча? Скомпилируется только то, что соотв. условию по аргументу...
А посути-то есть что сказать? Если есть желание попробовать, прилагаю код...

Прикрепленные файлы

 macro.rar ( 417 байт ) Кол-во скачиваний: 33

 

[Dog Pawlowa]

А посути-то есть что сказать?

1) По сути... где фигурные скобки?!
2) Еще раз по сути ... ИАР имеет очень удобную фичу отладки макросов, которая заключается в выводе в файл текста после препроцессора.
3) И третий раз по сути ... Ваши общие рассуждения о расходе памяти программ в случае оформления фрагмента кода как подпрограммы без оговорок о оптимизации и "инлайнирование" неверны. Программист может (и, пожалуй, обязан) написать так, что в любом случае память программ будет расходоваться одинаково экономно.

[ivainc1789]

1) По сути... где фигурные скобки?!
2) Еще раз по сути ... ИАР имеет очень удобную фичу отладки макросов, которая заключается в выводе в файл текста после препроцессора.
3) И третий раз по сути ... Ваши общие рассуждения о расходе памяти программ в случае оформления фрагмента кода как подпрограммы без оговорок о оптимизации и "инлайнирование" неверны. Программист может (и, пожалуй, обязан) написать так, что в любом случае память программ будет расходоваться одинаково экономно.

По всем трем пунктам большое спасибо. Писал все это под утро, уж на автопилоте. Только это что-то мало помогло. Решил упростить все до безобразия и вот... Что же еще упускаю?


2) если вы про пояснения в листинге, то там то же, что и в окне Build

3) Программист может (и, пожалуй, обязан) написать так

То есть вы считаете, что программист заранее ОБЯЗАН знать, что лучше применить макросы или подпрограммы? По-моему, это не так тривиально и возможно только когда окончательно устаканится код... Лично меня как-то все время больше "тянет" на подпрограммы и уже позже, начинаю замечать, что вызовов не так много и возможно макросы отработают лучше...

[Dog Pawlowa]

То есть вы считаете, что программист заранее ОБЯЗАН знать, что лучше применить макросы или подпрограммы?

Ну нет же! Вы воюете с ветряными мельницами, выискивая несуществующую разницу.
Про pragma inline=forced Вы слышали? Она позволяет сделать так, что содержимое функции будет вставлено в текст программы. Потом, после оптимизации Вы получите код, идентичный написанному с использованием макросов.
Все одно, разница только в синтаксисе.
У Вас SETBIT() - это макрос, а у меня SetPin() - это функция, а компилируются они одинаково.