Компилю текст:
#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? или я что-то не так пишу или хваленый иар не спосбен на подвиги?
ЧТО Я НЕ ТАК ДЕЛАЮ?

Похоже, всё-таки не способен...

Вот как это скомпилировал CodeVision, для сравнения:

Код

26 char blink_timer;
;27
;28 // Timer 0 output compare A interrupt service routine
;29 interrupt [TIM0_COMPA] void timer0_compa_isr(void)
;30 {

       .CSEG
_timer0_compa_isr:
       ST   -Y,R30
       IN   R30,SREG
;31 blink_timer++;
       INC  R2
;32 }
       OUT  SREG,R30
       LD   R30,Y+
       RETI

вариант с переменной в памяти:

Код

;26 volatile char blink_timer;
_blink_timer:
       .BYTE 0x1
;27
;28 // Timer 0 output compare A interrupt service routine
;29 interrupt [TIM0_COMPA] void timer0_compa_isr(void)
;30 {

       .CSEG
_timer0_compa_isr:
       ST   -Y,R30
       IN   R30,SREG
       ST   -Y,R30
;31 blink_timer++;
       LDS  R30,_blink_timer
       SUBI R30,-LOW(1)
       STS  _blink_timer,R30
;32 }
       LD   R30,Y+
       OUT  SREG,R30
       LD   R30,Y+
       RETI

не верю! ну не может такого быть!

Ещё немного сравнительных результатов от ICC v6.30C и GCC 20040720 соответственно:

Нет слов.
Только маты.

Кстати,
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?

Да, практически так же:

Задал этот вопрос (почему через указатели а не через STS) разработчикам, жду ответа, но т.к. у меня нет лицензии ждать придется долго, если вообще дождусь.
Но что я накопал: в applications notes лежит pdfник "Efficient C Coding for AVR".
наткнулся я там на следующее:

When accessing the global variables as structures the compiler is using the Z-pointer and the LDD and STD (Load/store with displacement) instructions to access the data. When the global variables are accessed without structures the compiler use LDS and STS (Load/store direct to SRAM).

, что по-русски значит: если переменная объявлена как структура, то компилятор будет использовать указатели, если нет то через LDS и STS.

вот такие дела.

однако переменная у меня объявлена:
unsigned char blink_timer = 0;
где не вижу я структуры.

, еще не стоит я думаю горячиться по поводу прологов, эпилогов и т.п. Не редко проблемы с компилятором называются "сам дурак".

P.S. pdfник "Efficient C Coding for AVR" ориентирован на иаровский компилятор.

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


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

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

[/quote]

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


[/quote]

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

Ну и сколько это байт оверхеда на фоне всего проекта? Сравнивайте весь проект (или хотя бы более-менее значимую часть), скомпиленные одним компиятором и другим.

Переменным не обязательно быть подряд. Им достаточно быть в пределах досягаемости указателя - 64 байта. Для того, чтобы они были вместе, достаточно их объявить вместе и включить оптимизацию clustering variables, которая, afair, включена по умолчанию.

ну что ж: вот расстояние между байтами 19, а как обрабатывается - при полной оптимизации, включая Clustering of variables.

5 #pragma vector = TIMER2_OVF_vect

\ In segment CODE, align 2, keep-with-next
6 __interrupt void system_timer(void)
\ system_timer:
7 {
\ 00000000 93FA ST -Y, R31
\ 00000002 93EA ST -Y, R30
\ 00000004 931A ST -Y, R17
\ 00000006 930A ST -Y, R16
\ 00000008 B71F IN R17, 0x3F
8 blink_timer++;
\ 0000000A .... LDI R30, 0x66
\ 0000000C .... LDI R31, 0x01
\ 0000000E 8100 LD R16, Z
\ 00000010 9503 INC R16
\ 00000012 8300 ST Z, R16
9 mySREG++;
\ 00000014 .... LDI R30, 0x79
\ 00000016 .... LDI R31, 0x01
\ 00000018 8100 LD R16, Z
\ 0000001A 9503 INC R16
\ 0000001C 8300 ST Z, R16
10
}
\ 0000001E BF1F OUT 0x3F, R17
\ 00000020 9109 LD R16, Y+
\ 00000022 9119 LD R17, Y+
\ 00000024 91E9 LD R30, Y+
\ 00000026 91F9 LD R31, Y+
\ 00000028 9518 RETI


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

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

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

Непонятно, как Вы объявили переменные. Нужно, чтобы они были вместе объявлены, чтобы компилятор видел их одновременно. Если они в разных файлах объявлены, то, ессно, компилятор тут ничего поделать не сможет (даже если они реально попали в предел 64 байта один от другого), т.к. просто не знает, что они рядом и не может рулить их размещением. А вот как это получается:

Заметьте, что смещение при обращении ко второй переменной равно 1, несмотря на то, что при объявлении между ними массив в 200 байт. Т.е. компилятор эффективно расположил обе переменные последовательно - имеет право. Это и есть clustering variables. Т.е. достаточно, чтобы оба объявления были доступны компилятору в одной единице компиляции.



Если Вам мало быстродействия, при этом у Вас просто инкремент байта - напишите это на асме и не страдайте. Я не спорю с тем, что в данном конкретном случае IAR делает не лучшим образом - злоупотреляет переходами к косвенным обращениям, - но поверьте, в целом зачастую именно это дает ему значимое преимущество.

Об этом их backfire следует сообщить разработчикам, чтобы они в дальнейшем поработали над поведением компилятора в ISR. Хотя, думается, что если до сих пор не исправили, то это по той причине, что никого [из пользователей] этот факт особенно не волнует. Ведь и в самом деле, если работоспособность и устойчивость системы зависит от пары тактов, то тут явно что-то не то в дизайне. Всегда должен быть какой-то запас. На устойчивость. На развитие. В конечном итоге все упирается в "успевает - не успевает". Если один успевает на три такта быстрее, чем успевает другой, то конечный результат будет одним и тем же.

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

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

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


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

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


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

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