Патчи для решения проблеммы с размером 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, если нет то на ваш выбор.

Анатолий.

Сообщение отредактировал aesok - Feb 24 2007, 13:33

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

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

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



P.S:

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

Сообщение отредактировал gormih - Feb 26 2007, 22:59

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

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

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

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

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

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

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

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

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

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

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

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

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







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

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

Сообщение отредактировал gormih - Feb 27 2007, 16:51

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

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

есть маленнькая функция
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'ы.