[klen 1]

to klen: А будет ли свежак для mips или уже не поддерживается данное направление?

 

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

 

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

размер файла - 15 мб

я ее не тестил, неначем. нада всетаки взять ченить на pic32 соорудить

[Mitsufan 0]

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

 

Поздравляю, вот результаты для популярного теста 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, возможно дело в нем.

Изменено 20 апреля, 2010 пользователем Mitsufan

[klen 1]

Поздравляю, вот результаты для популярного теста 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 переименовать/отменить/итд. А вообще еще нада проверить как графит работает - опции глотает а результат то я и не смотрел, нада проверить.

 

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

[Mitsufan 0]

моя сборка 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 не оправдан из-за сильного

увеличения кода при компиляции "на скорость".

[Konqere 0]

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

 

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

размер файла - 15 мб

я ее не тестил, неначем. нада всетаки взять ченить на pic32 соорудить

 

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

[klen 1]

Вот, что сообщает ваш компилятор, когда я задаю эту опцию: "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%.

 

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

 

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

в ледущей сборке все будет окей.

спасибо - значит и крайняя сборка для армов тоже с такойже проблемкой.

 

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

[klen 1]

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

 

 

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

[Mitsufan 0]

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."

[Konqere 0]

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

 

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

размер файла - 15 мб

я ее не тестил, неначем. нада всетаки взять ченить на pic32 соорудить

 

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

[klen 1]

действительно архив был кривой

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

 

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

 

 

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

[Mitsufan 0]

действительно архив был кривой

 

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

[klen 1]

Хотя все это мелочи по сравнению с настройкой компилятора на использование родных и микрочиповских библиотек. Нормально это пока сделать не удается.

 

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

[AHTOXA 14]

ФИСЕ. нашел где это пофиксить, но пока токо руками получаетсо собрать libgcc. В следующей сборке эта проблема будет решена

 

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

[klen 1]

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

 

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

[AHTOXA 14]

а под что нада то?

 

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