Вчера еще лежал 20080402-rc1, сегодня уже 20080402.
из плюсов по сравнению с 20071221 - не выдает ошибочное предупреждение gcc версии 4.3.0. Выдает нелепые предупреждения-пожелания поставить скобки в выражениях типа X = Y << 2 + 5. просит отделить пробелом точку с запятой от пустого цикла:


из минусов - начали переделывать eeprom.h, изменили порядок параметров у eeprom_write_block(), теперь порядок соответствует memcpy, memmove и т.д. Могли бы и название другое дать - теперь при смене версии приходится переписывать исходник или добавлять функцию-обертку с условной компиляцией. В файле встречаются ссылки на функции __eerd_block() и __eewr_block(), которых линкер не нашел. Соответственно проект не собрался, качество кода сравнить не могу. Описание eeprom.h убрано из документации avr-libc.
Не нашел своих же ситемных заголовочных файлов - пришлось указать путь вручную через ключ -I (возможно криво встал - вечером проверю на домашнем компе). Вчера ставил дома rc2 - он заголовочники находил.

make, sh и прочие оставлись теми же, что и в предыдущих версиях. Проблема, описанная в соседней ветке осталась.

Убрали АДУ.

Пока это все, что заметил.

Хм. Оба спрятали, выложили 20080407.

Таки выдает. На переменные с атрибутом PROGMEM и на PSTR(). На переменные, объявленные с PROGMEM через typedef (например, через типы введенные в avr/pgmspace.h) - не выдает.
Вернули назад. Снова совместимо с предыдущими версиями.
Так и осталось.
Закомментировал обращение к eeprom. Не смотрел еще, что они там улучшили, но статистика по нескольким проектам такая:
Первый проект писался без напряжения, второй - "утаптывался" чтобы влезть в доступную память, третий - портирован с ИАРа, тоже "утоптан" но не очень сильно.
Осталось.

Пожалуйста протестируйте версию 20080407 с ключем "--param inline-call-cost=5"

Анатолий

Выходит, плюсов как таковых - нет вовсе? :-)

Пожалуйста. Результат меня заинтересовал, я проверил все три проекта с этим параметром от 0 до 10:20071221 на этот параметр не реагировал. Ключик возьму на заметку. А отрицательным его нельзя сделать?

И что делать с eeprom?

P.S. странно - на домашнем компе системные заголовочные файлы компилятор нашел.

Сергей Борщ а не осталось ли у Вас до кучи 20060421 ?
можете на нем попробовать ?
Думаю переползать на чего-нить посвежее, но пока не определился на какую версию,
был неудачный опыт попыток переползания на 200701xx, ну и я отложил это дело,
но когда-то ведь придется...

Странно у меня минимум был при значениях 4..6, при больших и меньших размер кода увеличивался.



Не слежу я за ним. Его уже второй раз полностью переписывают.

Анатолий.

Интересно, а чтение/сравнение перед записью когда-нить есть шансы увидеть в
библиотеке ?
Все таки запись ради записи, ИМХО, выглядит ущербно, учитывая то что на реализацию этого
нужны доли % производительности...

Не было, поставил.
первый проект после подтачивания скрипта линкера дал 3901
второй не скомпилился: error: cannot bind packed field `Msg_DriverID.msg_driver_id_t::Time' to `systime_t&'
третий заоптимизировал в ноль - включена --gc-sections, а его скрипты линкера с этой опцией несовместимы. К счастью, в этом проекте у меня --gc-sections ничего не выкидывает, без --gc-sections получилось 2462.



А вы при компиляции задаете -Winline? Для меня было большим сюрпризом, что несмотря на inline и на определение функций-членов в объявлении классов gcc часто решает не встраивать некоторые функции. Спасает только __attribute__((always_inline)). В процессе "утаптывания" этих исходников все функции, вызываемые только в одном месте были объявлены с __attribute__((always_inline)), т.е. код сделан максимально линейным. Возможно с этим связана такая разница в результатах.

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

Я тоже протестировал 20080407 на себе.
При оптимизации о2 размер всех моих проектов слегка увеличился.
Игры с "--param inline-call-cost" впечатляют...

Есть проблемы с заголовочным файлом "math.h"
пришлось убрать из него определение функций:

А то на них были маты...
Кстати, та же фигня была и в сборке от Клёна...
В остальном всё ГУД!

Помоему с официального сайта эту версию уже убрали..

На официальном сайте сейчас другая версия:
WinAVR-20080411 от 2008-04-12 12:24
Похоже надо подождать действительно релиза, что-то подобное было и с предыдущей версией.
Название темы пора менять или новую открывать

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

В 20080411 поправили eeprom. То есть все компилится, в железе не пробовал.

А я как пионер, обновлялся... Думал, а вдруг какую ошибку неприятную исправили? И каждый раз всё хужее и хужее :-) В прошлый переход пара проектов перестала помещаться в кристалл... Хорошо хоть вовремя наткнулся на сообщение Сергея Борща про -ffunction-sections -fdata-sections, с их помощью - впихнул:-)
Короче, я пока тоже пас:-)

А здесь сообщения тоже противоречивые, хотя есть и положительные. Наверно стоит подождать. Либо пробывать самому.

Проекты компилируются без ошибок, но часть из них не работает в железе. Есть серьёзная бага с не сохранением R16 (почитайте баглист на http://sourceforge.net/tracker/?atid=52007...mp;func=browse)

Размер кода только увеличился в сравнении с WinAVR 20070525.

И ещё, я нашёл пару приколов в стабилной версии WinAVR 20070525, которую использую постоянно:
1)
При компиляции с -oS код получается больше (212 байт), чем с -o2 (210 байт).
Пример во вложенном файле.
Там процедура mcu_init присутствует дважды один раз она встраивается компилятором как inline,
но при этом она же остаётся в asm листинге и как обычная процедура с заканчивающаяся ret.
2)
В прерываниях сохраняется в стэке, а потом очищается регистр __zero_reg__ (r1), после чего востанавливается перед reti.
Хотя он вовсе не используется процедурой.
3)
Код при оптимизации -o2 получается просто смешным:
проверка условия происходит дважды!!!

if (time_is_up)
loop:
lds r24, 0x0061 // первый раз
and r24, r24
breq loop

// тело условия

lds r24, 0x0061 // второй раз вместо rjmp loop !!!
and r24, r24
breq loop

Я в шоке! (всё это можно увидеть скомпилировав вложенный файл)Нажмите для просмотра прикрепленного файла

к сожалению по моим пробам после 20060421 код очень часто увеличивается,
правда сО всякими спецключами я не пробовал, но и код который пробовал не требует этих ключей.
нуу... 2 байта это совсем не показатель, всегда можно написать так что при оптимизации
по скорости код будет более медленным чем при оптимизации по размеру, ну и конечно наоборот..
Ну это не баг а уже довольно давно фича AVR Gcc, если это фсе мне начинает сильно
мешать то объявляю прерывание как:
void TIMER2_COMP_vect(void) __attribute__((signal)) __attribute__((naked));
ну и уже все сохранение/востановление пишу сам.

Специально я ничего не делал.
На мой взгляд это действительно бага, т.к. сгенерированный компилятором код одной функции присутствует _дважды_ в одой единице трансляции. И именно по этой причине размер программы увеличивается...

Всё делать руками... А для чего тогда вообще на С писать?

Я не говорю что все делать руками,
только в тех случаях когда нужно сделать очень короткое быстрое прерывание с минимумом
накладных расходов. При этом вся остальная прога может быть на С.

Это я чисто риторически спрашивал....

Проверил на 20080411:
1)
Проблема с дублированием кода процедуры осталось.
2)
Размер кода при оптимизации o2 и oS одинаков 214 байт.
Ушла проблема с двойной проверкой условий, что не может не радовать!
3)
Ненужное сохранение в стэке __zero_reg__ (r1) осталось.

Может кто-нибудь зарегистрирует ошибки 1 и 3 на:
http://sourceforge.net/tracker/?atid=52007...mp;func=browse)
А то у меня с письменным английским не так хорошо, как могло бы быть...

Использование данной версии 20080411 невозможно из-за баги с R16.
Часть программ не работает в железе по этой причине.

Не надо свое незнание языка С выдавать за баг компилятора уже третий пост подрят.

В дали компилятору команду оптимизировать код? Он вставил инлай версию функции 'mcu_init' в 'main', при этом ускорив код на команды вызова/возврата?

Вы обьявили функцию 'mcu_init' как глобальную, компилятор должен обрабатывть ситуацию что эта функция может быть вызвана из другого модуля? И для этого случая оставить код полной версии 'mcu_init'?

Где ошибся компилятор?

Объявите 'mcu_init' как static.

Анатолий.

К слову, могли бы и не ждать три поста подряд а поправить ранее



Спасибо за поучение.
Static совершенно упустил из виду.
С кодом функции всё в порядке.
Вопрос был задан для того чтобы понять суть проблемы.
Одна проблема была в недопонимании и она решилась благодаря Вам.
Я думаю, что это было интересно не только мне...
Антон.

Веду проект на Си, все прерывания только на асме, в которых стараюсь SREG не портить. в этом сильно помогает условие равенства r1=0. d в какой-то момент прога начала глючить.
оказалось:
при операциях умножения результат в r1:r0. при этих операциях компилятор не обрамляет участок кода рапретом/разрешением прерываний.
поэтому __zero_reg__ не всегда равен 0. и поэтому при прерываниях гцц генерирует пуш/поп r0
/*******/
off
хотелось бы чтоб r0,r1 стали общими регистрами,а r2==0 и р3==1 ВСЕГДА

Кстати, да. Давно такое желание возникло - иметь фактически словный временный регистр __temp_hi__/__temp_lo__, возможно, c синонимом __temp_reg__ для младшего, а __zero_reg__ перекинуть на R2. Единичный регистр как-то вроде и не очень нужен.
Да, это исключает пару R3/R2 из возможных словных пар, но добавляет R1/R0.
На распределение регистров для передачи аргументов, сохраняемых вызываемым и вызывающим это вроде бы не влияет.

Понадобится перетряхивание ассемблерной части libc - почти уверен, что не везде хватит просто переименования __zero_reg__ да и исключить ненужные теперь его обнуления после использования R1 надо будет. Что-то ещё (те же подпрограммы блочной работы с eeprom) тоже могут упроститься.

Готов принять участие в этом куске работы (асм-часть libc, ассемберные вставки типа util/crc16.h, ...).
Что это потянет за собой в кодогенераторе - просто плохо себе представляю.

Во всём есть скрытый смысл!

Пять баллов!

Снова спрятали, теперь 20080430. Релноты старые. Ну и как теперь искать, что они изменили?

Ага, судя по Bug 1945375 поправили багу с сохранением R16. Выходит, можно переползать и менять топик на "уже вполне созрел"

Багу превнесённую исправили - это хорошо. А в чём преимущества новой версии?

Все сборки avr-gcc основанные на GCC 4.3 имеют еще один критический баг. Если из обработчика прерывания вызывается функция то может возникнуть ситуация когда будут сохранены не все регистры которые изменяются в обработчике. Должны сохраняться все call-used регистры, а сохраняются только те регистры которые используются а обработчике. Если вызываемая функция использует какие нибудь из call-used регистров которые не используются в вызвавшем ее обработчике прерывания, то они будет искажены.

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

Анатолий.

Уже другой:
WinAVR 20080512 May 12, 2008

В кратких релнотах они пишут, что исправили этот буг: Или это не оно?

Если кто-нибудь знает, что в нем изменили по сравнению с 20080430 - напишите, пожалуйста.

Да это он.



Так ведь написали, исправили только этот баг.

Точно. Я сначала решил, что это они в 20080430 его исправили. Значит, этой версией теперь можно пользоваться?

На данный момент критических багов не известно.

Анатолий.