Вот пример генерации кода. опции -Os

---------------------------------------------------------

int g;

int func(void)
{
int res;
{
uint8_t _SReg;
asm volatile("in %0,__SREG__\n\tcli" : "=r" (_SReg));

res = g;

asm volatile( "out __SREG__,%0" :: "r" (_SReg));
}
return res;
}

--------------------------------------------------------
WinAVR 20060421 (правильно)

28 0000 2FB7 in r18,__SREG__
29 0002 F894 cli
32 0004 8091 0000 lds r24,g
33 0008 9091 0000 lds r25,(g)+1
36 000c 2FBF out __SREG__,r18
40 000e 0895 ret

---------------------------------------------------------
WinAVR 20070122 (неправильно)

32 0006 8FB7 in r24,__SREG__
33 0008 F894 cli
37 000a 8FBF out __SREG__,r24
40 000c 8091 0000 lds r24,g
41 0010 9091 0000 lds r25,(g)+1
46 0014 0895 ret

---------------------------------------------------------

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

К сожалению это не компилятор сырой, а ваш код. Правильно писать так:


Анатолий.

Заметил, что по сравнению с WinAVR 20060125 код стал занимать немного больше места.
Например, bootloader занимал 2034 байта, стал 2078 байт (написан на с + макросы из boot.h и pgmspace.h). В 2к boot sector уже не влазит.
В чем отличия, еще еще не разбирался, но, похоже, придется менять "трюки" для уменьшения размера кода.

Если у вас есть локальные переменные в 'main()', сделайте их временно глобальными. 40 байт не обещаю, но байт на 20 код должен уменьшиться.

Анатолий.

[/quote]
Если у вас есть локальные переменные в 'main()', сделайте их временно глобальными. 40 байт не обещаю, но байт на 20 код должен уменьшиться.
[/quote]
Нет в main() локальных переменных. Из нее в зависимости от джамперов вызываются две static функции (для обновления "себя" или "соседа"). В них несколько локальных переменных (счетчики и байт, принятый по UART), остальные и массивы static.
Я этот загрузчик долго сворачивал, так что думаю, дело в сохранении многобайтовых переменных, принимаемых по UART, идущих старшим байтом вперед. Если записать так:
static unsigned char buf[512];
unsigned int size;
*( (unsigned char *)&size + 1) = buf[0];
*( (unsigned char *)&size + 0) = buf[1];
то компиллятор расположит переменную в памяти, что для счетчика не хорошо. Если записать так:
size = (buf[0] <<8) | buf[1];
то будут лишняя операция ИЛИ 2х-байтных чисел.
Как это все-таки правильно реализовать на С? Или только через ассемблерные вставки?

P.S.: если собрать этот bootloader в IAR 4.12 со средней оптимизацией по размеру, то получится 1940 байт. Есть за чем гнаться

Провел эксперименты, вот что получил:

unsigned int size;

size = ((unsigned int)mess[1] << 8) | mess[2];
3cd0: 80 91 63 00 lds r24, 0x0063
3cd4: 99 27 eor r25, r25
3cd6: d8 2f mov r29, r24
3cd8: cc 27 eor r28, r28
3cda: 80 91 64 00 lds r24, 0x0064
3cde: 99 27 eor r25, r25
3ce0: c8 2b or r28, r24
3ce2: d9 2b or r29, r25

size = ((unsigned int)mess[1] << 8) + mess[2];
3cd0: 80 91 63 00 lds r24, 0x0063
3cd4: 99 27 eor r25, r25
3cd6: d8 2f mov r29, r24
3cd8: cc 27 eor r28, r28
3cda: 80 91 64 00 lds r24, 0x0064
3cde: c8 0f add r28, r24
3ce0: d1 1d adc r29, r1

typedef union {
unsigned int i;
unssigned char c[2];
} un_int;
un_int size;

size.c[1] = mess[1];
size.c[0] = mess[2];
3cd0: d0 91 63 00 lds r29, 0x0063
3cd4: c0 91 64 00 lds r28, 0x0064

Наилучший результат дают union'ы, но программа теряет в читаемости: if (size.i) {...}, do {...} while (--size.i) ...
Есть еще какие-нибудь способы на С, без ассеблерных вставок?

В настоящий момент самый эффективный способ в GCC записывать в многобайтовые переменные побайтно, это использовать union'ы.

Нашел отличие:
00003900 <main>:
3900: 2f 92 push r2
3902: 3f 92 push r3
...
3920: cf 93 push r28
3922: df 93 push r29
3924: 88 e0 ldi r24, 0x08 ; 8
3926: 88 bb out 0x18, r24 ; 24
Всего 18 push при входе в main и соотв 18 pop. WinAVR 20060125 такого не делал.
Как указать, что при входе/выходе из функции не надо сохранять/восстанивливать регистры?
(для main в частности)

Не проще просто WinAVR 20060125 использовать?
Вообще есть какой-то резон обновлять компилятор, если предыдущая версия нормально работает?

Никак, эта проблемма обсуждалась в 'avr-libc-dev' майллисте и возможно будет решена в следуещей версии WinAVR.

Анатолий.

WinAVR еще долго будет сырым по определению.

Все таки продукт не коммерческий...

Хотите получить оптимизаию - пользуйте IAR или на худой конец CodeVision

Уважаемый gormih, этот топик о проблеммах в WinAVR. Если Вы хотите пообсуждать какой компилятор лучше, пожалуйста начните новую тему.

Анатолий.

Уважаемый Анатолий!

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

Он же не пишет - "лучше-хуже" он именно сообщает свое мнение чего в WinAVR не хватает. Хотя я с этим мнением не согласен.

Патчи для решения проблеммы с размером main() уже подготовленны.

Анатолий.

Хотите поговорить про оптимизацию ...
Давайте поговорим...
Вот вам небольшой тестик: Нужно скопировать один массив на 255 байт в два других.
Вот код:


Предлагаю поступить так, Вы компилируете этот код под IAR а я под WinAVR-20060421
при любом уровне оптимизации
Ну и дальше каждый выкладывает сюда результат - количество тактов на
выполнение цикла.
Готовы ?

P.S. WinAVR-20070122 действительно очень сырой, я попробовал поставить его
в надежде что исчезнут некоторые глюки предыдущей версии, но оказалось
что при компиляции куска проги которая раньше занимала ~2200байт
в новой версии у меня получилось 2600+ байт.
Честно говоря я даже разбираться не стал в чем дело и просто его стер.

Когда эти патчи будут доступны? (и где?)
И, как вы считаете, все-таки какую версию WinAVR стоит сейчас использовать?
Спасибо за Ваши ответы!

В WinAVR-20070122 есть два существенных изменения:
1. Добавленна поддержка 256КВ-ных мег.
2. WinAVR-2006... + AVRStudio 4.12 позволяет коректно отлаживать не более 64КВ кода. В WinAVR-20070122 + AVRStudio 4.13 эта проблема решена.

Если вы используете 128-е или 256-е меги и ваш проект больше 64КВ то лучше WinAVR-20070122 + AVRStudio 4.13, если нет то на ваш выбор.

Анатолий.

Не собираюсь этого делать по двум причинам:

1) Не собираюсь пользовать WinAVR просто потому, что уже неоднократно сравнивал для своих задач уровни оптимальности кода в разных компиляторах. Пользуюсь исключительно codevision как самый простой в понимании, вмеру навороченный компилятор с оптимальным уровнем качества генерируемого кода. Ваша задача явно заточена под winavr, не спорю что именно она будет скомпилироваа в нем самым оптимальным способом.

2) Вообще редко пишу на си, а когда это делаю WinAVR напрягает сложностью вставки ассемблерных вставок. Ни для кого не секрет, что оптимальней связки си+асм нет. WinAVR упорно игнорирует данное обстоятельство, делать ассемблерные вставки по меньшей мере неудобно.



P.S:

Вашу задачу я бы вообще написал на асме :-) Си использую только при необходимости сложных вычислений.

ну я так понимаю что Вы все-таки попробовали скомпилировать мою задачку под
CV(IAR) и посмотрев на код отказались от попыток сравнивать ?

Кстати, задачка НЕ написана под конкретный компилятор!
Это просто вариант когда есть 3 источника/приемника длинных данных
Выдернуто из реальной программы (с большими упрощениями)
Да и написано на чистом C как в учебниках учат...

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

ну это дело привычки

попробуйте написать лучше чем сгенерит WinAVR...(в данной конкретной задаче)

Не надеюсь. Да и не собираюсь думать, чего он там сделает. Просто возьму и напишу на асме - благо, что для меня это не проблема. У всех компиляторов свои методы компиляции тех или иных выражений на си, и думать, выяснять как скомпилирует выражение си конкретный компилятор не всегда есть время, согласитесь. Проще взять компилятор, который в большинстве случаев не давит на мозг своими наворотами и оптимально компилирует, либо просто написать на асме. Писать на асме вообще полезно - становишся ближе к железке, код становится чище и светлее :-) Спорить можно бесконечно, таких тем на форуме и других форумах великое множество. Но, в коенчном счете спорить на эту тему бесполезно - для большинства приложений нет никакой разницы на чем написана программа, главное чтобы она работала и программист понимал, как она работает (что бывает далеко не всегда)

Это говорит об одном - предметом вы не владеете, да и углублятся не собираетесь. Зато апломба поучать других у вас выше крыши.

А Ваше высказывания кроме того, что Вы хам - уж точно ничего не говорит. Я программированием микропроцессоров занялся еще в 9 классе средней школы. Вам уж точно меня не учить.

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

Тонкости оптимизации я изучал на дургом уровне. Сейчас дам Вам кусок кода, в котором будет не 3 строчки, а 200... Перекомпилируем в разных компиляторе. Вот тогда посмотрим. А то, что приведенный пример заточен под конкретный компилятор - и без того ясно. Говорить об оптимизации, беря за основу 3 строки на си - по меньшей мере не адекватно. Да мне это и не особо интересно. Я всего лишь высказал свое СУБЪЕКТИВНОЕ мнение, подкрепленное некоторыми практическими знаниями, а Вы сразу обвинили меня в некомпетентности, уклонении от темы итд. GNU GPL проекты никогда не отличались качеством выше, чем у всех коммерческих проектов, утверждать обратное опрометчиво, и Вам это должно быть хорошо известно. Основная причина придумана не мной - серьезный зрелый профессионал всегда найдет, как использовать свой талант во благо своего материального благополучия. На GNU GPL же тренируются молодые перспективные программисты, которые в основной своей массе через несколько лет перестают трудится во благо всего мира, и переходят в серьезные коммерческие проекты. Так кто по Вашему лучше напишет код - молодой перспективный, или зрелый зубр? Ответ сам собой напрашивается.

Линус, Эрик Реймонд безусловно дети малые
Да и Йорг Вунш уже лысину нажил.

Впрочем не увидел обещанного кода. Или он специальный невидимый?
Только пожалуйста на чистом платформонезависимом С.

Читайте внимательнее. Никто не оспаривает уникальности личностей пары десятков зубров линуксостроения, однако эта пара десятков далеко не все те, кто является основным двигателем по развитию GNU GPL. Именно поэтому я написал ОСНОВНАЯ МАССА.







Под рукой не нашел примера, который можно было бы так легко выложить.
А по памяти - возьмите любой универсальный драйвер под индикатор на основе hd44780, и потренеруйтесь :-)

Например вот это:

на сколько понимаю на этом всё

Вот еще что обнаружил:

есть маленнькая функция
static void putc(unsigned char c)
{
while ( !(UCSRA & _BV(UDRE)) ) ;
UDR = c;
}
и вызывается из очень многих мест. Но компиллятор ее везде делает инлайном, что съедает довольно много кода:
3fba: 5d 9b sbis 0x0b, 5 ; 11
3fbc: fe cf rjmp .-4 ; 0x3fba <main+0x6cc>
3fbe: 9c b9 out 0x0c, r25 ; 12

PS: оптимизация -Os. Стоит в нее добавить хотя бы один NOP - реализуется как функция и call'ы.

Я просил платформеннонезависиый код. Представленный таковым не является. Видимо это понятие вам незнакомо.
Кроме того ожидается, что будет представлены сравнительные результаты, которые докажут ваши слова.
Тратить время на компиляцию библиотек нет ни времени, не желания.


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

Это нормальное поведение компилятора, попытаться оптимизировать маленькие функции. Если вы не хотите чтобы функция бала инлайновой, объявите ее с атрибутом "noinline":

static void putc(unsigned char c) __attribute__((noinline));

Анатолий.

Спасибо! Освободил 78 байт кода.
Дело в том, что WinAVR20060125 этого не делал. Там, мне показалось, было так: если тело функции и все N-call'ов занимают больше места, чем инлайн N-раз, то функция делалась инлайном?

Да если честно мне платформонезависимый си грубо говоря "по барабану". Есть конкретные задачи, решать которые без привязки к платформе по меньшей мере безграмотно. Код, который не привязан к конкретной платформе это как минимум математическая задача, которая после своего решения должна быть связана интерфейсной частью с основной прогррамой. С огромной долей сомнения выскажу предположение, что математические задачи WinAVR решает лучше, чем остальные компиляторы ( ) , просто потому, что таковых задач на AVR мне решать не приходилось, да как то и не приходило в голову пока что. А вот то, что касается внешних интерфейсов - то тут Вы меня точно не переубедите - проверено мной на практике - код, генерируемый WinAVR при компиляции драйверов внешних устройств (как пример LCD контроллер выше) неадекватен. Я просто даже разбираться не стал, почему это hex после winavr весит 2 кб, а в других компиляторах на порядок меньше. Мне это, как разработчику НЕ ИНТЕРЕСНО, мне важен хороший результат в кратчайшие сроки, который я с легкостью получил в другом компиляторе. Уж извините, что Вас не спросил... возможно, уважаемый beer_warrior Вы настолько круто знакомы с WinAVR, что у Вас будут другие результаты, чего Вам искренне желаю.







Вот с этого места поподробнее.

Поумерьте свой пыд, господа.
Тема уже давно себя исчерпала и нечего огонь раздувать.

gormin довыступался до предупреждения из-за грубости и провокации религиозного спора.