вот сборка для мипса под масдай

http://klen.org/Files/DevTools/kgp_mips_elf_20100419.7z
размер файла - 15 мб
я ее не тестил, неначем. нада всетаки взять ченить на pic32 соорудить

Поздравляю, вот результаты для популярного теста Coremark для PIC32

MPLAB C32 v1.10b (GCC3.4.4) - 166.31 Coremark, размер кода теста - 30652
Sourcery G++ Lite 4.4-147 (GCC4.4.1) - 184.72 Coremark, размер кода теста - 23772
KGP 20100418 (GCC4.6.0) - 200.60 Coremark, размер кода теста - 23120

Все компилировалось с оптимизацией: -O3 -funroll-loops. Последние Sourcery имеют еще graphite loop оптимизацию (-floop-interchange), которая чуть улучшает результат. У вас она не поддерживается.

Еще у меня линкер ругнулся на незнакомый таргет elf32-tradlittlemips, который задан в микрочиповском скрипте (я использовал его для линкера). Замена на elf32-littlemips помогла.

Полученный ELF файл теста Coremark не захотел импортироваться в MPLAB, хотя файлы тестов попроще проходили. Но такое раньше было и с Sourcery в ранних версиях MPLAB, возможно дело в нем.

моя сборка graphite подерживает, даже более - поддерживается lto оптимизация - только я не тестил. все библиотеки собраны с -g0 -Os -fomit-frame-pointer -funroll-loops -ffunction-sections -fgraphite. насчет -floop-interchange я погляжу отдельно - ее могли в оптимизаторе для 4.6.x переименовать/отменить/итд. А вообще еще нада проверить как графит работает - опции глотает а результат то я и не смотрел, нада проверить.

я правильно понял что мы локально всех порвали... или наооборот?

Опция -floop-interchange выполняет лишь одну из возможных трансформаций кода, когда компилятор использует Graphite
оптимизатор. Вот, что сообщает ваш компилятор, когда я задаю эту опцию: "sorry, unimplemented: Graphite loop
optimizations cannot be used". А вот указание для использования этой опции: "To use this code transformation,
GCC has to be configured with '--with-ppl' and '--with-cloog' to enable the Graphite loop transformation infrastructure".
Может все-таки графит прикручен не полностью? Хотя и без этой опции результат отменный, а эффект от нее на моих тестах
менее 1%.

Итак, ваш компилятор дает самый быстрый (чем больше марков, тем лучше) и компактный код для PIC32. Это, кстати,
опровергает утверждение разработчиков MPLAB C32 о том, что переход с GCC3.x.x на GCC4.x.x не оправдан из-за сильного
увеличения кода при компиляции "на скорость".

Спасибо, будем опробывать.

вот это и не понятно - у меня то все работает! ядро компиллера собрано с либами оптимизатора циклов ppl-cloog. косяг какойто блин. шайтан...емаЁ .

нашел косяг - неработает толлко в сборке по вынь, под линухом все работает. я забыл пересобрать libppl libcloog для i686-pc-mingw32, собралось без них и соответсветственно без графита.
в ледущей сборке все будет окей.
спасибо - значит и крайняя сборка для армов тоже с такойже проблемкой.

ну вот! опять нада все преесобрать для винды винда невезучая система.. все кривое, даже ровное искривляетсо

http://klen.org/Files/DevTools/kgp_mips_elf_20100421.7z


вроде бы готово, графит должен работать.

ошибки: сначала cc1.exe потребовал для работы libstdc++-6.dll, затем libgcc_s_sjlj-1.dll, закончилось все сообщением "The procedure entry point __qxx_personality_v0 could not be located in the dinamic link library libstdc++-6.dll."

Также имеются ошибка: сс1.exe требует libiconv-2.dll, при этом она находится в папке bin. Прошу помощи

действительно архив был кривой
сейчас "опять должн работать", архив и ссылка таже, 16мб, я еще подумал чето на 2 мега меньше чем должно быть...забил, издержки отладки сборочных скриптов - отладить на локальной машине нельзя - на ней всегда есть все библиотеки и их можно забыть положить в архив, а на удаленном хосте это вылазит. но ниче - пару итераций и все будет стабильн0. сделал усилие над релегиозными предубеждениями - перегрузился под масдай и потестил - компилит и бинарь генерит с пустым майном

извиняюсь если кто на медленном канале потратил время и нервы... сорри. но качнуть придется заново.


2_Konkere у Вас косяг непонятной природы, мож libiconv попортилась, 20100419 сборка вродебы у некоторых без проблем - даже тест собрали и прогнали. попробуйте крайнюю 20100421, будут проблемы пишите, разберемся.

Сейчас все заработало и графит тоже, правда эффект от него ничтожный - надо тестировать больше. И в некоторых случаях, старый MPLAB C32 дает все-таки лучший код (меньше и быстрее). А с PIC32 ситуация усложняется наличием кэша, когда для ускорения циклы развернули (-funroll_loops), но получили промахи в кэше и в итоге скорость упала. Хотя все это мелочи по сравнению с настройкой компилятора на использование родных и микрочиповских библиотек. Нормально это пока сделать не удается.

ето то еще почему?

Извините за занудство, но нельзя ли узнать, когда ждать эту следующую сборку?

давот переписал код систмы сборки, решил косяг с libgcc - сижу, смотрю в консоль - тестю ее, собирается свежак. если соберется то выложу. а под что нада то? предлагаеццо arm avr mips mingw32 mingw64 x86_64-linux

Под армы, вестимо

свежак:

для mingw32
http://klen.org/Files/DevTools/kgp_mingw32_20100510.7z

для ARM
http://klen.org/Files/DevTools/kgp_arm_eabi_20100509.7z
наконецто решена проблема с увеличением кода при использовании операции деления для типа uint64_t (в код прилазила обработка исключений, разматывание стека даже)

для MISP
http://klen.org/Files/DevTools/kgp_mips_elf_20100510.7z

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

ну т всех с прошедшим празником.

С ходу пока так: не хватает файлов make.exe и msys-1.0.dll
При добавлении из предыдущей сборки, make вываливается с кодом возврата 1.
Хотелось бы помимо mingw32 и arm, ещё avr видеть. Ибо активно пользуюсь.
Спасибо за работу.
Имеет смысл пробовать накатить поверх прошлой сборки?
--
Попробовал поверх старой - работает.

make.exe msys-1.0.dll к компиллеру не относится, поэтому я их удаляю из пакета, иногда забываю.
если накатите сверху все должно работать - просто файлы перезапишутся

один make неработает, нада в корне еще папку etc сделать иначе падает. так в мингв маке собран ...

sh.exe ещё не хватает

Да, действительно, etc в корень, make.exe msys-1.0.dll и sh.exe добавил, теперь работает.
Единственное, что меня смущало: установка на чистый комп не давала работоспособный компилятор. Ранние сборки (все не проверял, обновляю эпизодически) сразу давали правильный результат.

Ещё раз спасибо!

чистый - это без операционки?
я думаю это частные глюки. не компилятора. но все может быть. А че компиллер говорил?
должно работать так
1) распаковал, положил куда хочется
2) добавил путь в bin
фсе. должно работать.

"Чистый" - это без компилятора как такового, без make, только winXPproSP3
1. распаковал
2. положил
3. прописал путь
4. не работает. нет выше указанных файлов.
5. добавил их и пустую /etc - заработало.
без подсказки про /etc так и не сдвинулось бы, make падал с кодом 1.
компилятор без make не пробовал. скорее всего, работал бы.

make и sh - это не компилятор. Правильно, что их нет в сборке. Потому что обычно они уже имеются, причём правильной, выстраданной версии и сборки. Я бы, например, очень не хотел, чтобы вместе с компилятором у меня каждый раз обновлялись эти файлы.

я вижу ситуацию равнобедренно. нефиг тому что не относится к компиллеру там делать.
но с другой стороны - вместе с этим наборчиком получается минимальный полный набор джентельмена.
поэтому я думаю что make,rm, sh будут в отдельном архивчике с постоянным URL и будет все задокументировано в readme к KGP.

Извините за нескромный вопрос, а где можно взять патчи для сборки AVR binutil, gcc
Пытаюсь собрать новые для AVR под linux

смотря какие патчи и для чего. чтото есть на сайте avr-libc чтото в инете россыпью. я их не ищу ине использую. использую свежие исходники из cvs и svn репозирориев дописываю руками поверх свои правки.

Скажите пожалуйста, есть какое-нибудь лекарство от exception handling при выполнении 64-битной арифметики (например, деления)?
Для сведения, yagarto стал теперь arm-none-eabi и заболел тем же самым...
Линковать stubs для getpid и isatty не предлагайте.

я это пофиксил в крайней сборке. проверяйте.

А cortex-m0 поддерживается?

теоретически ды:

Known ARM CPUs (for use with the -mcpu= and -mtune= options):
cortex-m0, cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9,
cortex-a8, cortex-a5, arm1156t2f-s, arm1156t2-s, mpcore, mpcorenovfp,
arm1176jzf-s, arm1176jz-s, arm1136jf-s, arm1136j-s, arm1026ej-s, arm926ej-s,
iwmmxt2, iwmmxt, xscale, arm1022e, arm1020e, arm10e, arm968e-s, arm966e-s,
arm946e-s, arm9e, arm1020t, arm10tdmi, ep9312, arm940t, arm922t, arm920t,
arm920, arm9tdmi, arm9, arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi,
strongarm1110, strongarm1100, strongarm110, strongarm, arm810, arm8,
arm7dmi, arm7dm, arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720,
arm710, arm700i, arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600,
arm60, arm6, arm3, arm250, arm2

Known ARM architectures (for use with the -march= option):
iwmmxt2, iwmmxt, ep9312, armv7e-m, armv7-m, armv7-r, armv7-a, armv7,
armv6-m, armv6t2, armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e,
armv5t, armv5, armv4t, armv4, armv3m, armv3, armv2a, armv2

но я не проверял, проверите отпишитесь о результатах.

Спасибо! Это радует. Пробовать буду не ранее чем через месяц...

Наконец-то в одном месте собрались Jtag-программатор, я и отлажтиваемое устройство...

Получаю от линкера

- в коде в указанном месте сдвиг 64-х битной переменной влево.

Закоментировал.

Часть кода заработала. В целом проект не заработал (прпрывания не запустились, что-ли?).

че за процессор?
кусок кода который глюк производит с неразрешенной ссыдлкой. посмотрю. я на делениях только проверял.

AT91SAM7S64, ARM mode, проект (tc1*.zip) я выкладывал.
Объём (от yagarto) стал меньше процента на 3-4.

Код вот:



А что насчёт прерываний скажете? Похоже на то, что не возвращается или не входит в прерывание. Можете сказать, какие регистры надо сохранять? (у меня ассемблерный кусок обработчика такой):

2 klen а GCC для STM8 планов нет?

2_Genadi Zawidowski



я проверил сдвиг на lpc2103 - сдвиг работает, и __aeabi_llsl не использует, покажите ключи компиллера котрыми исходник компиляте
c прерываниями разбирайтесь сами - компиллер тут не причем.
смотрим в вашу функцию
value = & val;
вы присваиваете константному указателю адресс локальной переменной размещенной на стеке, котрая скорее всего херится при выходе из функции.
по моему разумению это сразу две ошибки в одной строчеке

2_oll
да пока такая перспектива не просматриватся. а нада оно вообще? нужен ли вообще stm8?

да пока такая перспектива не просматриватся. а нада оно вообще? нужен ли вообще stm8?
Извиняюсь что не в тему - поясню.
У нас тут такая бодяга с AVR - цены, например mega48 возросли в 3 раза ~2.75$. Ищу альтернативу. Мое мнение - STM8 подходящая замена AVRам (для 5-ти вольтовых устройств).

klen, я привёл кусок функции. Естественно, никаких возвратов указателей из функции не происходит.
Ключи компилятора в том проекте, что Вы уже один раз исследовали.

На всякий случай выделяю минимальный код:




Ключевм моментом являетмся неконстантный счётчик сдвигов.




Вобще-то указатель не константный, а указатель на константу...

Разница вот:

const char * cp;
и
char * const pc;

2_Genadi Zawidowski
я посмотрю в чем дело.

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

klen, спасибо Вам за сборку для arm.
А не имеется ли оной для Ubuntu?

имеется

Буду благодарен за ссылку на архив.
Спасибо.

свежак для arm, я полагаю окончательно решен вопрос с ликвидацие unwind кода при делении uint64_t, и вообще с uint64_t, все должно быть хорошо.
http://klen.org/Files/DevTools/kgp_arm_eabi_20100525.7z

свежак для мипсов
http://klen.org/Files/DevTools/kgp_mips_elf_20100525.7z

свежак для авыэров
http://klen.org/Files/DevTools/kgp_avr_20100525.7z

свежак для mingw32
http://klen.org/Files/DevTools/kgp_mingw32_20100525.7z
суда помимо самого компиллера, runtime lib и win32 api lib я собрал и положил:
libglew32 - пригодится для программирования трехмерной графики на OpenGL
libelf - работа с ELF бинарниками
libpthreads - POSIX потоки лоя масдая
libftd2xx - работа с USB-моcтами FT2232/FT485/....
libexpat - работа с XML
libiconv,libcharset - i18
QT-4.7 не положил - зело жирная, не влезет

2_Genadi Zawidowski
косяки которые Вы обраружили повидимуму ликвидировал, Ваш примерчик собирается, я его для опыта немного модифицировал - добавил деление
запускал на lpc2103 и stm32f103rbt6 - вычисления без ошибок

вот выход:

а в чем прикол засовывания стеков в bss?


2_Vasen
сборка arm на x86_64-linux-gnu
компиллер http://klen.org/Files/DevTools/ubuntu64/kg...m_eabi.tar.lzma
архив с библами котрые потребуются компиллеру http://klen.org/Files/DevTools/ubuntu64/lib.tar.lzma
это както криво - пока я пакеты делать не собираюсь

я дико извиняюсь, уважаемый klen, но ваша сборка для AVR чем отличается от WinAVR-20100110 ? просто я никогда не следил за развитием версий и т.п., но раз все хвалят ваши сборки - хочется и мне попробовать

я дико извиняюсь, уважаемый ARV, но просто я никогда не следил за развитием WinAVR и т.п.
если бе3 шуток то наверно не лучше и не хуже, а ИНАЯ.
1. всегда собирается из SVN транк-ветки. я называю свою сборку 'свежак' потому что свежее trunk нет ничего по определению ( в эту свежесть входять естественно и самые свежие косяки )
2. собираю со всеми доступными фичами короые получается собрать и запустить( также если получается в проблемных случаях найти ошибки поравить/доделать). Ну например имеет ли winAVR поддержку оптимизаторов Graphite и LTO? в моих сброках они работают (ответ на вопрос о их полезности и умении ими воспользоватся для AVR неочевиден - нада пробывать, для армов видно покрайней мере что код изменяется при их применении )
3, avr-libc тоже самая свежая + мои собственные правки, обычно добавки новых устройств. Правильнее былобы напрямую добавлять свое творчество в репозиторий avr-libc.... но все как всегда откладывается на завтра...
4, при сборке я эксперементирую с ключами компиляции libgcc libc и тд в попытке выжать максимум из текущей реализации компиллера
5. может и хвалят мои сборки для армов, но про avr это Вам представляется подтвердить.

и так, я лично охарактирезовал это все так; WinAVR прочие - более стабильные, моя более интересная. Если вы дружите с асмом, хотите повыжимать из компиллера байты и проценты скорости, интересуетесь не только результатом но и процессом - моя сборка для ВАС, если вам нужен скомпилированный результат то наверно надо проверить какой подойдет. Лично мои проекты ессесено собраны моими сборками - работют в железе и не жужжат, оди такой вотовот пдымется в воздух на аппарате тежелее воздуха железяка будет стоять в критическом месте, так что я как сапер в этом случае .

ну и последнее - найдете косяг в кодогенерации и кому взывать о помощи? будите в багзилу писать.... или Эрику, через полгода может вселенная услышит. а в нашем ыварианте будем разбиратся - на форуме людей много умных, Толик Соколов aka aesok опятже в наших рядах(правда этот паразит кудато пропал и шифруетсо мож женился? )

ну вот примерно как то татк

WinAVR-20100110 - gcc 4.3.3
Klen - gcc 4.6.0 (gcc 4.4.0 для Klen-20090323, 4.5.0 для Klen-20091202)

Некоторые баги (тяжело сказать - gcc как целого или порта AVR или эффект интерференции между ними) появились где-то на уровне gcc-4.2.x, сохранились в 4.3.х, пропали в 4.4.0

О'да!!!!!!!!!! переход от тройки к четверке был болезненный и четверка по началу была хуже тройки, но закладывались новые концепции.

пример из жизни, Миг-23МЛД в ближнем маневренном бою!!! рвал Миг-29 первых серий как Тузик грелку, причем драмматически. Со временем САУ на Миг29 поднастроили, напильньником приложтлись и ... вуаля! сверхмоневренный пипелац.

2_Genadi Zawidowski
Вы кажется какойто приемник творите или чтото в этом роде если не ошибаюсь.
новой сборкой должно собратся. хочу вашего подтверждения что кокос растет и крокодил ловится.
или пять не ловится?

спасибо, klen, за ответ, да видно не в коня корм... сложно мне понять ваши слова, т.к. до сего момента не сталкивался с багами avr-gcc... разве что вот один, который меня подкосил: с целью оптимизации по размеру объявил ряд переменных регистровыми, и напоролся на то, что компилятор ни слова не говоря собирает код, в котором происходит использование регистров из моих регистровых переменных в функциях разных модулей, в итоге, естественно, каша и бардак

было бы интересно узнать, ваша сборка как с регистровыми переменными (глобальными, естественно) себя ведет? и еще, упомянутые вами оптимизаторы - есть что-то на более-менее понятном языке об их возможностях? какие параметры управляют ими и т.п.?

klen, большое Спасибо!

2_ARV

c регистровыми переменными все очень просто.

0. правильно проектируем приложение

1. если линкуете без внешних либ которые знать не знают о ваших регистровых переменных будь то libgcc libc libm (хотя это мало реально)
нада для всех исходников при компиляции скормить компиллеру ключи .... где X,Y,... номера регистров. тогда никто эти регисрты трогать не будет и они спокойно будут использоватся переменными обявленными в С коде

2. в более реальном случае с использования ничего не знающих о вашей какойто там регистровой переменной библиотеках я делаю так - собираю все без регистровых переменных - нахожу в результирущем асм - листинге дыры в использовании регистров (в моем крайнем проекте это оказались r9 r12 r16 ) и делаю пункт 1. Это нада чтоб неналететь на затирание регистровых переменных библиотечными вызовами.

3, если в пункте 2 'дыр нет", берем перекомпилируем библиотеки а правильнее начинаем с пункта номаер ноль!!!! - делаем чтоб регистровых переменных ненужно было. хотя клиника случается и без них не обойтись, сам пользуюсь но не злоупотребляю.

Я думаю кнонить ченить должен добавит по этой теме.

2_Vasen
неужели без толкача завелась сразу? неверю. про ldconfig не стал писать хотя очем это я - линуксойды народ которуму разжовыать не нада