[NullPointer 0]

...найдите, откуда эти утилиты берутся на "больном" и уберите этот путь из path.

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

Файлы на больном и остальных компах идентичны.

--

 

Оно починилось. Но причину поломки так и не знаю :(

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

 

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

Даты доступа\создания\изменения файлов WinAVR не додумался проверить до удаления\установки :(

[halfdoom 0]

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

[_Pasha 0]

Попросил заказчик использовать gcc-4.5.1

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

Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.5.3/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=i686-linux-gnu --host=i686-linux-gnu --target=avr
Thread model: single
gcc version 4.5.3 (GCC)

и под масдаем - сабж

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

Изменено 9 августа, 2012 пользователем IgorKossak

[GenaSPB 11]

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

 

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

Причём, сабжёвый компилятор проигрывает сильно 1020-й и 710-й сборкам.

 

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

 

[halfdoom 0]

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

[_Pasha 0]

-mfaster-structs

With -mfaster-structs, the compiler assumes that structures should have 8 byte alignment. This enables the use of pairs of "ldd" and "std" instructions for copies in structure assignment, in place of twice as many "ld" and "st" pairs. However, the use of this changed alignment directly violates the SPARC ABI . Thus, it's intended only for use on targets where the developer acknowledges that their resulting code will not be directly in line with the rules of the ABI .

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

Изменено 5 августа, 2012 пользователем _Pasha

[halfdoom 0]

Спецом выдавливают, мсм

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

[_Pasha 0]

Собсна из 8-битов одни АВРки :)

SDCC чистой культурой ГЦЦ аж никак не назвать, но даже там, в далеких пампасах чуднОго вИденья компилятора,

умудряются, например, беречь как зеницу ока концепцию SW стэка для пиков.

В то время как оформление всех переменных как static - единственный ключ к сохранению производительности. Странно это всё...

Изменено 5 августа, 2012 пользователем _Pasha

[GenaSPB 11]

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

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

[demiurg_spb 0]

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

Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох: -3 Кб на проекте размером 70Кб, при переходе на него с последнего WinAvr (avr-gcc 4.3.3).

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

 

[ReAl 0]

Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох

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

А то мне как-то лень разбираться, а Keln тоже утратил интерес к AVR.

 

[demiurg_spb 0]

Ни чем не могу помочь... Разве только под win:

http://sourceforge.net/projects/mobileches...hots%20(Win32)/

[halfdoom 0]

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

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

 

Отнюдь, avr-gcc 4.7.1 весьма и весьма неплох

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

 

[demiurg_spb 0]

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

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

#define __PROG_TYPES_COMPAT__

Все эти PGMы уже больше не нужны ввиду наличия гораздо более удобного механизма с ключевым словом __flash.

Будут вопросы - спрашивайте, я самую малость причастен к avr-libc и в частности pgm_read_float в pgmspace.h накалякал:)

[ReAl 0]

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

 

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

Буду рад ошибиться.

 

Но typedef int16_t PROGMEM prog_int16_t по сути никогда и не работал. Т.е. тип при этом не создавался.

Я даже не говорю об обращении по адресу переменной типа prog_int16_t, но ведь даже контроля типов при передаче в функцию не было.

Так что такой typedef только сокращал писанину (её и #define-ом сократить можно), но ничем не отличался от

int16_t  ip PROGMEM;