WinAVR 2006, Компилятор полностью игнорирует циклы Опции

[Freeze Anti]

Здравствуйте.

У меня появилась такая проблема... компилятор полностью пропускает циклы... то есть вот пример...

на Си я пишу

Код

SetLCDPosition(2, 0);
for(short i = 0; i == 23; i++)
    ucTemp += sCurrentTemp[i];
ucTemp /= 24;
sprintf(sBuffer, "%3d", ucTemp / 2);

а в ассемблере получается

Код

181:              SetLCDPosition(2, 0);
+000002B3:   2F61        MOV     R22,R17          Copy register
+000002B4:   E082        LDI     R24,0x02         Load immediate
+000002B5:   940E0113    CALL    0x00000113       Call subroutine

185:              sprintf(sBuffer, "%3d", ucTemp / 2);
+000002B7:   921F        PUSH    R1               Push register on stack
+000002B8:   921F        PUSH    R1               Push register on stack
+000002B9:   E682        LDI     R24,0x62         Load immediate
+000002BA:   E090        LDI     R25,0x00         Load immediate
+000002BB:   939F        PUSH    R25              Push register on stack
+000002BC:   938F        PUSH    R24              Push register on stack
+000002BD:   92FF        PUSH    R15              Push register on stack
+000002BE:   92EF        PUSH    R14              Push register on stack
+000002BF:   940E03CE    CALL    0x000003CE       Call subroutine

моего цикла for(...) {...} нет совсем... так в нескольких местах программы (везде, где встречаются циклы)

пробовал при уровнях компиляции 0, 1, 3, s. При нулевом уровне у меня программа не вылазиит из прерывания по АЦП. То есть сразу после окончания обработки прерывания сбрасывается на начало прерывания... А при остальных - проглатываются циклы... может, кто сталкивался с подобной проблемой... подскажите пожалуйста, что можно сделать... везде в программе писать такое количество операторов это уж слишком загромоздит код (циклов ожидается достаточно большое количество)...

[zltigo]

И еще "short i" - ни к селу ни к городу - для 8bit это работа с чрезмерно большим 16bit значением, а для
32 ARM - с исскуственно ограниченным.
Если пользоватся минимальным набором типов, то для 8bit "unsigned char" , а для 16/32 соответствено "int".
Поскольку на 8bit int обычно "традиционно" 16bit, на 16bit - уже обычно логичный соразмерный, ну и на 32bit-овиках вообще все правильно.

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

Если пользоватся минимальным набором типов, то для 8bit "unsigned char" , а для 16/32 соответствено "int".

или uint_least8_t, uint_fast8_t из stdint.h - оптимальное для архитектуры значение подставится "само".

[zltigo]

или uint_least8_t, uint_fast8_t из stdint.h - оптимальное для архитектуры значение подставится "само".

Я говорил о минимальном наборе типов. Я по простоте душевной тоже за такой подход агитировал достаточно долго, пока не наступил на непонятки в IAR ARMc int_least8_t - в сложных выражениях не int , int_fast8_t там ведет себя похожим на int. Ну, короче я свой ручкаи завел bint (base int) для такого.

[Непомнящий Евген...]

Я говорил о минимальном наборе типов. Я по простоте душевной тоже за такой подход агитировал достаточно долго, пока не наступил на непонятки в IAR ARMc int_least8_t - в сложных выражениях не int , int_fast8_t там ведет себя похожим на int. Ну, короче я свой ручкаи завел bint (base int) для такого.

А можно поподробней?
У меня везде юзаются типы вроде byte (как типичная замена int), uint. ulong. Сейчас возникла необходимость один и тотже код исполнять как на компе (VC++), так и на МК. Начал переползать на uint_X, uint_fast_X. Вроде все получается неплохо.
А что у вас с ними за проблемы?
И еще вопросик - для чего нужны типы uint_least_X, если есть uint_fast_X? (Т.е. uint_X - фиксированный размер, uint_fast_X - самый быстрый тип размера не менее чем, а uint_least_X - ?)

[zltigo]

А что у вас с ними за проблемы?

Иногда int_least8_t не получается эквивалентом int на 32bit платформе

И еще вопросик - для чего нужны типы uint_least_X, если есть uint_fast_X?

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

[Непомнящий Евген...]

Иногда int_least8_t не получается эквивалентом int на 32bit платформе

А ваше решение? Вы просто создали "свой" int_least8_t, назвав его bint?

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

Не совсем понял. Почему он будет тяготеть к размещению в регистрах? Это ж обычный typedef....
Т.е. вы имеете в виду, что в "стандартных" ситуация типа счетчика цикла и т.д. следует использовать uint_least_X, а в неких исключительных - uint_fast_X?