вопрос по 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.