[LeoLabs 0]

Вопрос - оптимальная степень оптимизации. Заметил косячок на максимальной оптимизации. Какую лучше ставить, чтобы не проверять каждый раз правильно ли откомпилированно?

[nameless 0]

Есть такая традиция - отключать оптимизацию при отладке [DEBUG mode]: багов по определению нет т.к. идет тупая сборка (компиляция) из готовых и неоптимизированных кусков.

После того, как разработчик отработал алгоритм в функционально законченном виде - приступаем к оптимизации [RELISE mode]. Мой практикум в программировании под ИАРом показывает, что косяки выявляются в таких кусках кода, которые не красиво написаны в сЁвом синтаксисе. Например, в какой-то ранней версии (не помню) функция не возвращала сложную составную переменную, получаемую в строке с return-ом, в более поздней - работает !!!

Пусть специалисты меня поправят...

[dxp 56]

Вопрос - оптимальная степень оптимизации. Заметил косячок на максимальной оптимизации. Какую лучше ставить, чтобы не проверять каждый раз правильно ли откомпилированно?

<{POST_SNAPBACK}>

Максимальная. По скорости или по размеру - зависит от проекта.

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

[SL@V@ 0]

Всегда использую только максимальную оптимизацию (в том числе и в дебаге - на последних стадиях отладки). Единственный "глюк" возникал только с участками кода где в условии цикла используется значение переменной не изменяемой в пределах текущего цикла (но её значение может меняться в прерывании). Просто забывал добавить в определении переменной модификатор volatile.

[nml 0]

Вот какая штука замечена в 3.20С:

Объявляю в регистре кучу флагов, например:

volatile __regvar __no_init struct 
               {
 unsigned char gluk1:1;    // не исп из-за глюка компилера
 unsigned char sending:1;  // 
 unsigned char priem:1;    //
 unsigned char setpnt:1;   //
 unsigned char sohran:1;   //
 unsigned char newotscet:1;    //
 unsigned char smena_rezima:1; //
 unsigned char flagt0:1;       //
     } @ 15;

так вот при оптимизации выше средней запись 1 в мл бит - нормально, а очистка мл бита - генерится CLR R15. Все остальные биты - нормально...

[KRS 1]

Вот какая штука замечена в 3.20С:

Объявляю в регистре кучу флагов, например:

volatile __regvar __no_init struct 
               {
 unsigned char gluk1:1;    // не исп из-за глюка компилера
 unsigned char sending:1;  // 
 unsigned char priem:1;    //
 unsigned char setpnt:1;   //
 unsigned char sohran:1;   //
 unsigned char newotscet:1;    //
 unsigned char smena_rezima:1; //
 unsigned char flagt0:1;       //
     } @ 15;

так вот при оптимизации выше средней запись 1 в мл бит - нормально, а очистка мл бита - генерится CLR R15. Все остальные биты - нормально...

<{POST_SNAPBACK}>

В 3.20D этот глюк исправили

[nml 0]

В 3.20D этот глюк исправили

<{POST_SNAPBACK}>

 

Да, слышал, но качать 50 мег, кряк искать... Влом... Когда глюк известен - он не страшен :-)

К тому же есть хороший принцип - работает - не трогай!