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 получаем профанацию идеи.

[ReAl]

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

А он и не обязан. Гарантируется только то, что будет минимум 8 бит. "прошу минимум 8 бит, остальных требований не имею, на усмотрение компилятора". Сколько - как выйдет. На каком-нибудь сигнальнике без байтовой адресации будет 16 бит, на арме с вполне приличной работой с байтами - может быть и 8 и 32 - "на усмотрение".

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

IMHO, регистры тут ни при чем. "прошу минимум 8 бит, но при этом требование - максимальная скорость работы". И тут уже в процессоре с 32-битными регистрами и без команды загрузки байта с расширением знака для int_fast8_t наиболее вероятно будет использовано 32 бита, чтобы после загрузки байта не тратить время на команды, которыми расширится знак.

[zltigo]

На каком-нибудь сигнальнике без байтовой адресации будет 16 бит, на арме с вполне приличной работой с байтами - может быть и 8 и 32 - "на усмотрение".

Проблема не в усмотрении, а в том, что это "усмотрение" не всегда нравится - на том-же ARM нет "вполне приличной работы с байтами". Нет , посему когда вдруг он вдруг компилятор иногда начинает дополнительно извращаться с какой-нибудь 24bit маской мне это совершенно не нравится.

IMHO, регистры тут ни при чем.

Не могу утверждать что "ни при чем" - вполне логично предположить, что это вполне может служить и заменителем давно почти всеми похереного "register". Если вдруг есть какие-то дополнительные официальные (а не очевидные трактовки fast и least) рекомендации было-бы интересно посмотреть.

[ReAl]

Если вдруг есть какие-то дополнительные официальные (а не очевидные трактовки fast и least) рекомендации было-бы интересно посмотреть.

Ничего кроме пары абзацев в стандарте не видел. От них устойчивое впечатление как "оптимизация преимущественно на размер" и "оптимизация преимущественно на скорость" для платформ начиная от 8-битных и больше ничего.
Это типы, а register - это storage class - вещи ортогонгальные. Может быть register int_least8_t и может быть int_fast8_t без него.

Проблема не в усмотрении, а в том, что это "усмотрение" не всегда нравится - на том-же ARM нет "вполне приличной работы с байтами". Нет , посему когда вдруг он вдруг компилятор иногда начинает дополнительно извращаться с какой-нибудь 24bit маской мне это совершенно не нравится.

Ну так если интересовала по мере возможности скорость работы, а не по мере возможности компактность размещения в памяти - то почему был взят int_least8_t а не int_fast8_t ???
Я надеюсь, что fast8 таки на ARM будет 32 бита, ну а на AVR будет 8, так как их хватает.

7.18.1.2 Minimum-width integer types
1 The typedef name int_leastN_t designates a signed integer type with a width of at least N, such that no signed integer type with lesser size has at least the specified width. Thus, int_least32_t denotes a signed integer type with a width of at least 32 bits.
2 The typedef name uint_leastN_t designates an unsigned integer type with a width of at least N, such that no unsigned integer type with lesser size has at least the specified width. Thus, uint_least16_t denotes an unsigned integer type with a width of at least 16 bits.
3 The following types are required:
int_least8_t
int_least16_t
int_least32_t
int_least64_t
uint_least8_t
uint_least16_t
uint_least32_t
uint_least64_t
All other types of this form are optional.

7.18.1.3 Fastest minimum-width integer types
1 Each of the following types designates an integer type that is usually fastest216) to operate with among all integer types that have at least the specified width.
2 The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.
216) The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements.
3 The following types are required:
int_fast8_t
int_fast16_t
int_fast32_t
int_fast64_t
uint_fast8_t
uint_fast16_t
uint_fast32_t
uint_fast64_t
All other types of this form are optional