Команда which %exename%.exe для всех *.exe из C:\WinAVR\utils\bin и C:\WinAVR\bin выдаёт эти же пути, т.е. ничего стороннего не запускается.
Файлы на больном и остальных компах идентичны.
--

Оно починилось. Но причину поломки так и не знаю
Переустановка поверх не излечивала, а вот удалить\поставить излечило.

Смена системной даты могла повлиять? Выставлял год как-то аж до 1991 (так надо было), и мог в это время WinAVR использовать.
Даты доступа\создания\изменения файлов WinAVR не додумался проверить до удаления\установки

Попросил заказчик использовать gcc-4.5.1 (тот, что из avr-toolchain-installer-3.3.1.1020-win32.win32.x86). На сабже размер кода для меги8 был 4338 байт, на новом 4872 байт. Спрашивается, откуда такая разница? Ответ - везде понемногу, причем раскладка по регистрам совершенно другая, поэтому точное сравнение невозможно. Для меги168 пока вообще не вмещается во флэш...

А у меня из-под убунты

и под масдаем - сабж
Отличий при сборках вообще нету. Наверное, это не нормально. Попробую пересобрать с десяток проектов и сравнить.

Сообщение отредактировал IgorKossak - Aug 9 2012, 09:19

У меня при компиляции avr-toolchain-installer-3.4.0.1146-win32.win32.x86.exe по сравнению с 1020 код подрос код заметно. В моём случае на 32 килобайтах около 300 байт.
Причём, сабжёвый компилятор проигрывает сильно 1020-й и 710-й сборкам.

Попробуйте выборочным запрещением инлайна функций поиграться, static у функций поставить где надо.

В общем, нашел основной источник роста: излишне "умный" компилятор позаменял везде, где смог дотянуться, обращения через указатели на lds/sts. На некоторых кусках, где используется конструкции вида p=pp;*p++=a; *p++=b; *p++=c;fn(p) получаем 3 sts'a и еще арифметику для pp+3. Переменных (в структурах) в этом проекте очень много, отсюда и заметный прирост в объеме.

ГЦЦ погряз в маразме, в нек-рых аспектах касательно 8 битников. Спецом выдавливают, мсм

Сообщение отредактировал _Pasha - Aug 5 2012, 15:48

Уже не помню кто, писал, что проблемы с 8-битниками у gcc принципиальные и радикальных улучшений не предвидится, т.к. основные разработчики ориентируются на 32/64-битные системы.

Собсна из 8-битов одни АВРки
SDCC чистой культурой ГЦЦ аж никак не назвать, но даже там, в далеких пампасах чуднОго вИденья компилятора,
умудряются, например, беречь как зеницу ока концепцию SW стэка для пиков.
В то время как оформление всех переменных как static - единственный ключ к сохранению производительности. Странно это всё...

Сообщение отредактировал _Pasha - Aug 5 2012, 16:56

Это ради скорости, вероятно? Если так - пусть живёт... Если нет - как отключить, не знаете?

Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох: -3 Кб на проекте размером 70Кб, при переходе на него с последнего WinAvr (avr-gcc 4.3.3).
И это ещё без LTO (косяки в avr-libc не позволяют его пока использовать), но ситуация уже очень скоро изменится к лучшему с выходом avr-libc-1.8.1.

Если бы ещё кто-то не поленился собирать-выкладывать свежие сборки под линукс...
А то мне как-то лень разбираться, а Keln тоже утратил интерес к AVR.

Ни чем не могу помочь... Разве только под win:
http://sourceforge.net/projects/mobileches...hots%20(Win32)/

Нет, скорости это не добавляет (указатель все равно подгружается позже), только бесполезно увеличивает размер кода.


Может быть, но вот изъятие поддержки типа "typedef int16_t PROGMEM prog_int16_t;" несколько расстраивает.

Напрасно расстраиваетесь, если нужна совместимость со старыми дедовскими методами нужно объявить глобально или до включения pgmspace.h

Все эти PGMы уже больше не нужны ввиду наличия гораздо более удобного механизма с ключевым словом __flash.
Будут вопросы - спрашивайте, я самую малость причастен к avr-libc и в частности pgm_read_float в pgmspace.h накалякал

(сверните кто-нибудь строку в 78 сообщении, а то она в монитор 1600 по горизонтали не лезет, надо на 1920 попробовать)

Ещё руки не дошли пробовать, но если я правильно понял обсуждения, то __flash сейчас только в С-шном форнт-энде, в С++-ном его нет (пространства памяти в С-шном стандарте появились, а не в С++-ном).
Буду рад ошибиться.

Но typedef int16_t PROGMEM prog_int16_t по сути никогда и не работал. Т.е. тип при этом не создавался.
Я даже не говорю об обращении по адресу переменной типа prog_int16_t, но ведь даже контроля типов при передаче в функцию не было.
Так что такой typedef только сокращал писанину (её и #define-ом сократить можно), но ничем не отличался от