вопрос по IARy, IAR спасовал? Опции

[LeoLabs]

Компилю текст:
#pragma vector = TIMER2_OVF_vect
__interrupt void system_timer()
{
blink_timer++;
}

и выдает:

#pragma vector = TIMER2_OVF_vect
__interrupt void system_timer()
ST -Y, R31
ST -Y, R30
ST -Y, R17
ST -Y, R16
IN R17, 0x3F
}
blink_timer++;
LDI R30, LOW(blink_timer)
LDI R31, (blink_timer) >> 8
LD R16, Z
INC R16
ST Z, R16
}
OUT 0x3F, R17
LD R16, Y+
LD R17, Y+
LD R30, Y+
LD R31, Y+
RETI

при максимальной оптимизации.
Не пойму почему бы ему не использовать STS? или я что-то не так пишу или хваленый иар не спосбен на подвиги?
ЧТО Я НЕ ТАК ДЕЛАЮ?

[AlexOr]

Кстати,
LDI R30, LOW(blink_timer)
LDI R31, (blink_timer) >> 8
LD R16, Z
INC R16
ST Z, R16

занимает столько же места как и

LDS R30,_blink_timer
SUBI R30,-LOW(1)
STS _blink_timer,R30

но последнее в прерывании намного выгоднее (быстрее и менее расходно по регистрам).
Черт меня дернул сделать проект на IAR.
Сейчас взглянул на прологи/эпилоги и Ужаснулся.

Вопрос вдогонку:
Этот замечательный CodeVision умеет также легко работать с EEPROM как IAR?

[dxp]

Кстати,
LDI R30, LOW(blink_timer)
LDI R31, (blink_timer) >> 8
LD R16, Z
INC R16
ST Z, R16

занимает столько же места как и

LDS  R30,_blink_timer
SUBI R30,-LOW(1)
STS  _blink_timer,R30

но последнее в прерывании намного выгоднее (быстрее и менее расходно по регистрам).

Это до тех пор, пока у Вас единственное обращение к однобайтовой переменной. Сделайте эту переменную интом, выигрыш не замедлит проявиться. Или, к примеру, если там не к одной переменной обращение, а к нескольким, лежащим в пределах досягаемости указателя (для этого их надо объявлять вместе). Или к структуре обращение. Словом, когда ситуация уходить от первого простейшего случая, результат меняется

Черт меня дернул сделать проект на IAR.
Сейчас взглянул на прологи/эпилоги и Ужаснулся.

Не стОит так переживать из-за этой мелочи. Она погоду не делает совершенно. Наоборот, способность IAR'а приводить обращения к косвенным дает очень приличный выигрыш на деле. AVR-GCC имеет весьма неплохой кодогенератор, но он проигрывает IAR'у именно на этом моменте - AVR-GCC злоупотребляет lds/sts, из-за чего размер кода там получается больше.

Не знаю, как сегодня обстоит дело, но некоторое время назад остальные компляторы - CodeVision, ImageCraft уступали по качеству кодогенерации обоим - и IAR'у, и AVR-GCC. Может сейчас что-то изменилось, но сомневаюсь. Сравнивать надо не на коде из трех строк, а на реальных проектах. Попробуйте, увидите, что IAR рулит.

[vet]

Это до тех пор, пока у Вас единственное обращение к однобайтовой переменной. Сделайте эту переменную интом, выигрыш не замедлит проявиться. Или, к примеру, если там не к одной переменной обращение, а к нескольким, лежащим в пределах досягаемости указателя (для этого их надо объявлять вместе). Или к структуре обращение. Словом, когда ситуация уходить от первого простейшего случая, результат меняется

Черт меня дернул сделать проект на IAR.
Сейчас взглянул на прологи/эпилоги и Ужаснулся.

Не стОит так переживать из-за этой мелочи. Она погоду не делает совершенно. Наоборот, способность IAR'а приводить обращения к косвенным дает очень приличный выигрыш на деле. AVR-GCC имеет весьма неплохой кодогенератор, но он проигрывает IAR'у именно на этом моменте - AVR-GCC злоупотребляет lds/sts, из-за чего размер кода там получается больше.

Не знаю, как сегодня обстоит дело, но некоторое время назад остальные компляторы - CodeVision, ImageCraft уступали по качеству кодогенерации обоим - и IAR'у, и AVR-GCC. Может сейчас что-то изменилось, но сомневаюсь. Сравнивать надо не на коде из трех строк, а на реальных проектах. Попробуйте, увидите, что IAR рулит.

Прямо сейчас скомпилировал реальный проект средних размеров на меге162.
Результаты:

Код

                    speed    size
CodeVision:        12956    12580
IAR:               12394    11182

Как видим, выигрыш не так уж велик.
Лично меня CodeVision привлекает тем, что генерирует предсказуемый код, отлично интегрируется с ассемблером, а также лучше IAR'а использует аппаратные ресурсы AVR.

[dxp]

Прямо сейчас скомпилировал реальный проект средних размеров на меге162.
Результаты:

Код

                    speed    size
CodeVision:        12956    12580
IAR:               12394    11182

Как видим, выигрыш не так уж велик.

Но он есть! И по скорости, и по размеру кода. Несмотря на несуразности в ISR. И не такой уж маленький. Почти 5% в первом случае и более 12 во втором. Представте, что проект занимает не 12 кил, а 15. Тут уже вопрос встает - "влезет/не влезет", а это серьезно.

Кстати, для МК этого калибра размер проекта не такой маленький. Неужели можно так просто взять реальный проект и пересобрать другим пакетом?! Там же куча тулзозависимых вещей типа директив компилятора, расширенных ключевых слов и прочего. Т.е. требуется основательная доработка напильником.

Лично меня CodeVision привлекает там, что генерирует предсказуемый код,

Что непредсказуемого в кодогенерации у IAR?

отлично интегрируется с ассемблером,

Не понял, что имеется в виду.

а также лучше IAR'а использует аппаратные ресурсы AVR.

Опять, простите, не понял. Какие ресурсы? В чем "лучшесть"?

Кстати, сравнивать эти два компилятора в некотором роде не совсем корректно - IAR несравненно богаче по возможностям - там есть ++. Это дорогого стОит. Предвижу возражение, что Вам это не надо. Не надо, так не надо. А мне надо. И весьма. Я не агитирую за IAR, не предлагаю бросить используемый инструмент и переходить на него. Смысл всего сказанного в том, что на сегодняшний день в целом IAR (при всех его недостатках) объективно является лучшим пакетом для AVR.

[vet]

Как видим, выигрыш не так уж велик.

Но он есть! И по скорости, и по размеру кода. Несмотря на несуразности в ISR. И не такой уж маленький. Почти 5% в первом случае и более 12 во втором. Представте, что проект занимает не 12 кил, а 15. Тут уже вопрос встает - "влезет/не влезет", а это серьезно.

Выигрыш по скорости - спорный вопрос. Что касается размера кода, процитирую:

Всегда должен быть какой-то запас. ... На развитие.

то есть - неправильно закладывать в проект кристалл, на котором программа едва уместится.

Кстати, для МК этого калибра размер проекта не такой маленький. Неужели можно так просто взять реальный проект и пересобрать другим пакетом?! Там же куча тулзозависимых вещей типа директив компилятора, расширенных ключевых слов и прочего. Т.е. требуется основательная доработка напильником.

Да не особенно, директивы заменяются аналогами вручную, ключевые слова правятся глобальной заменой, а С - он везде С.

Что непредсказуемого в кодогенерации у IAR?

В CodeVision имеем чёткие правила, как располагаются глобальные/локальные переменные, можно заранее сказать, какие регистры/флаги испортятся после тех или иных операций на С. В случае IAR этого уже нельзя с определённостью сказать на этапе написания программы, он распоряжается регистрами по своему усмотрению и в зависимости от опций проекта.

отлично интегрируется с ассемблером,

Не понял, что имеется в виду.

Просто примеры:

Код

BOOL TickerNotExpired() {
 #asm("movw r30,_dwCounter")
 #asm("or r30,r31")
}

...

byte KeyPressed() {
 #asm
   lds r30,_key
   clr r31
   sts _key,r31
 #endasm
}

...

 byte b/*r16*/, m/*r17*/, sz/*r18*/, i/*r19*/;

   i = curr_zero;
   b = RxRadioBuf.u[i];
   m = RxFEC[i];
   #asm("swap r17")
   #asm("rol r17")
   #asm("swap r17")
   #asm("rol r16")
   if (PIN_RX) m |= 1;
   m &= 0x0F;
   RxFEC[i] = m;
   RxRadioBuf.u[i] = b;

...

 //memmove(&conf_buf,&conf_buf+1,sizeof(conf_buf)-1);
 i=0;
 #asm
   LDI  R26,LOW(_conf_buf+1)
   LDI  R27,HIGH(_conf_buf+1)
   LDI  R30,LOW(_conf_buf)
   LDI  R31,HIGH(_conf_buf)
 #endasm
 do {
   #asm
     ld r0,x+
     st z+,r0
   #endasm
 } while (++i<sizeof(conf_buf)-1);

а также лучше IAR'а использует аппаратные ресурсы AVR.

Опять, простите, не понял. Какие ресурсы? В чем "лучшесть"?

Пример: карта размещения переменных типичного проекта. Обратите внимание на размещение битовых переменных.

Код

Variable                          Address   Size
f5ms                             GPIOR0.0    1/8
f1s                              GPIOR0.1    1/8
fNeedTransmit                    GPIOR0.2    1/8
thebit                           GPIOR0.3    1/8
failed                           GPIOR0.4    1/8
KeyCode                               90h      1
Digits                                91h      6
fNumberEntered                   GPIOR0.5    1/8
iTransmit                              R2      1
iTestKey                            R3,R4      2
bMatch                           GPIOR0.6    1/8
TestedKey_S7                           R5      1
i1s                                    R6      1
sreg_sv                                R7      1
r30_sv                                 R8      1
code                                  97h      8
last                                  9Fh      8

...

;16   thebit = FALSE; if (TCH_IN) thebit = TRUE;
    CBI  0x13,3
    SBIC 0x10,0
    SBI  0x13,3

Кстати, сравнивать эти два компилятора в некотором роде не совсем корректно - IAR несравненно богаче по возможностям - там есть ++. Это дорогого стОит. Предвижу возражение, что Вам это не надо. Не надо, так не надо. А мне надо. И весьма. Я не агитирую за IAR, не предлагаю бросить используемый инструмент и переходить на него. Смысл всего сказанного в том, что на сегодняшний день в целом IAR (при всех его недостатках) объективно является  лучшим пакетом для AVR.

Бесспорно, IAR - самый мощный компилятор для AVR, другое дело, что преимущества IAR'а проявляются на больших проектах, писать же код для какой-нибудь tiny2313, на мой взгляд, удобнее и выгоднее на CV.