[zltigo 2]

В последних версиях IAR не выдает ни warning, ни remark ни на while(1), ни на for(;1;) .

Последние это какие? Ремарки включите.

    573          
    574              for(; 1; )
                            ^
Remark[Pe236]: controlling expression is constant
    575              {
    576                  led_process( led_cnt++ );

По-вашему фирма IAR "прогнулась" под привычки программистов? Как-то не соотносится это (желание "прогнуться") с введением той же MISRA C в их компиляторы, не находите?

Не нахожу. MISRA присутствует с незапамятных времен и с "успехом" ругается практически на все :), что написано. И соответственно доводит до полного абсурда систему варнингов.

[rezident 0]

Последние это какие? Ремарки включите

Ремарки включены. Проверил выражения while(1) и for (;1;) на 4-х версиях IAR: EW430 3.30A, EW430 4.10A, EW430 4.11B, EW430 4.20.1. Выдается такая же ремарка, как у вас в примере, но только на версии 3.30A 2005-го года выпуска. На остальных проглатывает без "всхлипов".

[zltigo 2]

Проверил...

Значит потеряли в 430 ветке. В ARM есть. Причем дело не в "проблеме" банального while( 1 ) а во всех выражениях, где по уже по ошибке получается вечное условие, которе молча тупо и молча :( :( :(выполняется. Это безусловно не подарок :( И паронаидальная MISRA такого не поймает.

[rezident 0]

Значит потеряли в 430 ветке. В ARM есть.

Возникло сомнение. Может я что-то не так делаю? :cranky: Специально скачал IAR EWARM 5.20.2. Создал новый проект. Включил ремарки везде, где только их встретил в опциях проекта. Но в результате ни на while(1), ни на for (;1;) осуждающих сообщений от компилятора я не получаю. :laughing: Что я не так делаю?

[dch 0]

ни на while(1), ни на for (;1;) осуждающих сообщений от компилятора я не получаю.

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

[sergeeff 1]

Да надо плюнуть на все эти глупости, написать:

 

label1:
...
...
goto label1;

 

и будет вам счастье! Никаких warning'ов, корректно и, скорее всего, максимально быстрый цикл. Правда, не структурненько, но и хрен бы с ними, этими условностями.

 

После можно расслабиться и спокойно готовиться к празднованию Нового года. Чего всем и желаю.

[zltigo 2]

Специально скачал IAR EWARM 5.20.2.

На V5 не проверял под рукой был последний из V4. Если планомерно убирают, то тем хуже :(. Причины, по которым считаю отсутствие предупреждений неправильным, изложил ранее. Косвенной причиной промолчать может служить и реальная необходимость в такой конструкции do{...}while(FALSE) Хотя и в этом случае лично я предпочел-бы "официальный трюк" для такого действа вместо молчаливой оптмизации. Если говорить о дурных программиских привычках, то часто встречаются комментирование куска исходника ввиде if(0){.....}

[_Pasha 0]

Думаю, что пишу в тему. История такая (WinAVR):

Все знают, что манипуляции с main() - дело неприличное. В общем, заметил я глупости, которые делает последний WinAVR - лишние сохранения/восстановления регистров, после чего стал везде писать

int main (void) __attribute__((naked));
int main(void)
{
//итд итп
}

Худеет где-то на 24 и более байта.

Т.е. компилер не понимат, что с main() не надо так обращаться, как со всеми прочими функциями...:(

[AHTOXA 18]

Если планомерно убирают, то тем хуже :(. Причины, по которым считаю отсутствие предупреждений неправильным, изложил ранее. Косвенной причиной промолчать может служить и реальная необходимость в такой конструкции do{...}while(FALSE) Хотя и в этом случае лично я предпочел-бы "официальный трюк" для такого действа вместо молчаливой оптмизации.

 

Возможно, это и есть "официальный трюк"? В смысле, может быть, ремарки не выдаются только на несколько фиксированных конструкций?

Rezident, не могли бы Вы проверить что-нибудь позаковыристей?

Типа

unsigned a;
while (a >= 0){
   ...
}

, или что-то наподобие?

[zltigo 2]

Т.е. компилер не понимат, что с main() не надо так обращаться, как со всеми прочими функциями...:(

Ничего не мешает, если сие необходимо сделать из main() return и вернувшись в startup заняться другими делами, например, выполнением supermain().... Посему в качестве "навязчивого сервиса" делать main() особой совершенно не верно. Ручками - ручками пожалуйста.

[Сергей Борщ 136]

после чего стал везде писать

int main (void) __attribute__((naked));

А это не вам aesok тут на форуме объяснял, что naked, кроме сохранения ненужных регистров, еще и выделение стека под локальные переменные отбрасывает? Т.е. делать так нельзя, для main() и подобных функций есть атрибут OS_task.

[NullPointer 0]

Если main() вызывается единожды и до разрешения прерываний, то логичнее использовать атрибут OS_main (насколько я запомнил, отличается от OS_task тем что не сохраняет I).

[_Pasha 0]

А это не вам aesok тут на форуме объяснял

Каюсь. :)

Однако, не имею привычки использовать локальные переменные, описанные непосредственно main() {здесь}. Я имею ввиду для AVR - праздная трата памяти.

[DenisIV 0]

Подскажите ещё плиз: У меня на асме для оптимизации была такая конструкция подпрограммы с несколькими точками входа. Например: здоровенная подпрограмма, которой передаётся байт для обработки (~100 вызовов) и вызов этой же подпрограммы с вполне конкретным значением (3-4 варианта по ~40 вызовов) Как можно это применить в С? Как программист C я понимаю, что вызов функции, которая будет содержать константу для этой функции подойдёт, но для PIC (8 уровней стека :( ) не прокатит... Есть какая-нибудь альтернатива? Дополнительный параметр в функции передавать не хочу- в экономии смысла не будет, скорее наоборот. Глобальная переменная-как вариант, но не выход...

Есть возможность вызвать функцию с какой-либо метки внутри, или это совсем глупо? Или есть варианты?

Или это должен делать и считать оптимизатор?

Изменено 30 декабря, 2008 пользователем DenisIV

[DenisIV 0]

Народ, это действительно засада или лыжи не едут... ?