Подскажите софт, Софт для ARM (LPC2478) Опции

[Rom20]

Доброго времени суток, решил зающать ARM7 (контроллер Philips LPC2478) с ним идет сопроводительная документация, в ней рекомендую для отладки программ использовать uVision (скачал uVision3) ну видимо обрезанная версия ни чего нет подскажите какой нибудь хороший отладочный софт на подобе AVR Studio что бы можно было так же отлаживать тыкать на регистры и всякое такое.

[etoja]

Rowley Crosstudio: www.rowley.co.uk/arm/

Это GNU компилятор + графическая оболочка.
Есть в местных закромах.

[SPACUM]

Rowley Crosstudio: www.rowley.co.uk/arm/

Это GNU компилятор + графическая оболочка.
Есть в местных закромах.

Подтверждаю, пользуюсь, и обязательно приобретите JTAG типа Wiggler или J-link, через них программируется в 10 раз быстрее,
чем через Flash Magic.
Не бойтесь загубить процессор, он много перезаписей выдерживает.
Не верьте рекламе Кейла, что короткий код и быстрее работает, если есть, то почти незаметно.
Если захотите Кейловскими примерами воспользоваться, то надо переписать названия ячеек
и применить макросы входа-выхода из прерываний(Кейл их вставляет по умолчанию).

[AlexandrY]

Не верьте рекламе Кейла, что короткий код и быстрее работает, если есть, то почти незаметно.

Вам что ли верить Попытайтесь доказать.

Или хотя бы опровергнуть вот эти результаты:
http://www.alylab.eu/Subjects/Tests/LPC/LPC.htm

GCC и все что на нем компилирует значительно хуже и очень заметно.

[winner]

GCC и все что на нем компилирует значительно хуже и очень заметно.

GCC всех уделывает, что неудивительно - над ним работают не только представители ARM а огромное сообщество, хотя скорей всего другие таскают оттуда код поэтому немного подтянулись на сегодняшний день и скорей всего сегодня особой разницы нет какой компилятор использовать, разве что LLVM может ощутимо выбиться в лидеры в обозримом будущем.
http://www.mcu-raisonance.com/tzr/scripts/...C-Benchmark.pdf

[zltigo]

Ох уж эти обзоры . Никому верить нельзя, только себе. Одно можно сказать, что "The ARM Company" давно уже не является безусловным лидером в компиляторописании. Говорить разве только можно о тройке лидеров.

[sonycman]

GCC всех уделывает, что неудивительно - над ним работают не только представители ARM а огромное сообщество

Очень древний тест, да и вообще смахивает на липу.

А есть что нибудь свежее, для кортексов, к примеру?
Было бы интересно посмотреть.

Хотя от знакомства с GCC у меня остались смешанные впечатления - где то хорош, а где то так себе.

[AlexandrY]

GCC всех уделывает, что неудивительно

Где-то когда-то у кого-то уделывал может быть, проверить невозможно.

Вот здесь данные посвежее: http://www.soel.ru/cms/f/?/374464.pdf

Как видно неотесанный GCC продувает в разы. Если его дооснастить либами как в CrossWorks то кое-как еще терпеть можно.
Но все равно продувает более чем в два раза.

[KRS]

Или хотя бы опровергнуть вот эти результаты:
http://www.alylab.eu/Subjects/Tests/LPC/LPC.htm

У вас по тестам получается IAR в 3 раза медленнее мертвого CARM.
Хотя, с помощью настроек можно добиться любого расположения компиляторов в таблице.
Но интересны варианты когда настроено на максимальную оптимизацию по скорости или по размеру.
Посмотрел там IAR проект - оптимизация вырублена.

Я тоже проводил сравнения, например -
http://electronix.ru/forum/index.php?showtopic=68880

Сейчас IAR и RVCT компилят примерно одинаково, у каждого есть свои + и -.
GCC чуть хуже.

А вот отладчик у IAR лично мне больше нравится.

[sonycman]

А вот отладчик у IAR лично мне больше нравится.

Чем же он хорош?
В ИАРе вообще нельзя при отладке смотреть состояние модулей периферии (как в кейле, например), или мне это просто показалось в первый раз?

[AlexandrY]

У вас по тестам получается IAR в 3 раза медленнее мертвого CARM.

Там и была хитрость, что CARM тогда очень ловко с float единичной точности обходился.
RealView и сейчас с упрощенной либой для float быстрее всех будет.
Отладчик в Keil-е да, уже не так интересен с тех пор как они практически перестали поддерживать периферию крупных чипов.

[SPACUM]

Вам что ли верить Попытайтесь доказать.

Я проверял на моей программе. Все вычисления в 32бит фиксированной точкой. Тригонометрию сам написал.
Размер программы был не интересен. Скорость хотелось бы увеличить. Для такого типа программы Кейл имел преимущество около 2%.
Может рекламный выигрыш связан с float и double?

[KRS]

В ИАРе вообще нельзя при отладке смотреть состояние модулей периферии (как в кейле, например), или мне это просто показалось в первый раз?

Можно, все регистры видны.
В IAR удобные макросы. (по событиям, загрузка, прошивка, рестарт и ...)
Log Breakpoint - точка останова по которой печатается в лог сообщение (можно переменные распечатать...)
Доступ к файлам на компе через fopen....
Т.е. в нем больше "консольных" возможностей, а не свистелок перделок

[zltigo]

Сейчас IAR и RVCT компилят примерно одинаково, у каждого есть свои + и -.
GCC чуть хуже.

Полностью аналогичная личная оценка.

[etoja]

GCC может скомпилировать ядро линукса, а остальные - нет.

[Сергей Борщ]

GCC может скомпилировать ядро линукса, а остальные - нет.

Все претензии к ядру. Можно написать программу из 5 строк, которую будет компилировать любой из перечисленных компиляторов, а остальные - нет. И при чем здесь компилятор?

[winner]

GCC может скомпилировать ядро линукса, а остальные - нет.

Пользователи Linux всегда в выигрышном положении - можно не беспокоиться, GCC достаточно хорош и нет ни одной причины по которой нужно рыскать по файлопомойкам в поисках пиратского компилятора или выкладывать деньги. Оптимальными должны быть в первую очередь алгоритмы - с этим в Linux все в порядке. Ни один тест не отражает реальное положение дел, можно посмотреть архивы keil - там gcc в разы проигрывает по всем тестам, что просто смешно - достаточно посмотреть адекватные тесты которые я приводил.

[zltigo]

адекватные тесты которые я приводил.

"Никому верить нельзя - мне можно"©

[winner]

"Никому верить нельзя - мне можно"©

Я же не призываю кинуть все и переходить на GCC - если вас устраивает ваш компилятор, нет причин переходить - "лучшее - враг хорошего" ;-)

[zltigo]

Я же не призываю кинуть все и переходить на GCC

Можно и кинуть и отпортироваться, буде на то будут веские причины. Проблем-то, если не идти на поводу у компиляторостроителей добавляющих непереносимые вещи для подсаживания пользователей, в переносе минимум. Многие гнутые инструменты безусловно стандарт де-факто, тот-же ARM IAR практически упал на binutils. Только вот компилятор GCC штука слишком для меня размытая . "Кто шил костюм"? временами имеет решающее значение - всякие сборки типа от Klen - я тут напылесосил их интернету всяких патчей и собрал - пробуйте, меня точно не устраивают. Сам я тоже этим заниматься не буду - мне работать надо. Всевозможные "фирменные" сборки GCC в конце концов закостеневают, ибо им надо и деньги "на бесплатном" стричь, а не GCC толкать вперед. Нужно будет - портану, ибо для некотрых платформ, в число которых входит и ARM, GCC крепкий член лидирующей группы.

[AlexandrY]

GCC может скомпилировать ядро линукса, а остальные - нет.

Но GCC не может скомпилировать ядро Windows CE и даже либу к ентому Windows.

А вот ARM RealView может и для тех и других либы делать.
Так что с практической точки зрения имеет смысл все писать под RealView. (Он же Keil)

Тем более что линуксы под встраиваемые платформы терпят полный провал.
А Window CE бъет рекорды популярности. И надо держаться поближе к лидерам.

[winner]

Тем более что линуксы под встраиваемые платформы терпят полный провал.
А Window CE бъет рекорды популярности. И надо держаться поближе к лидерам.

Вам нужно обязательно попробовать себя на сцене в передаче "Аншлаг". windows ce настолько выбился в лидеры что его разработчики пишут в своих блогах http://blogs.msdn.com/b/obloch/archive/201...s-not-dead.aspx

I am just back from the Embedded Systems Conference in San Jose, CA and I (again) had to answer these same questions again and again: “So is CE really dead?”

Этот "лидер" на сегодня поддерживает только 1 процессор и может работать с RAM не превышающую 512МB.

[SimpleSoft]

Этот "лидер" на сегодня поддерживает только 1 процессор

ARM/MIPS/SHx/x86

и может работать с RAM не превышающую 512МB.

Надо больше? Ставьте Windows Embedded Standart.

Споры бессмысленны. Для каждой задачи конкретная ОС.
Пример: работаю с OMAP3530 под Linux, WinCE 6.0 R3 и попробовал Windows Embedded Compact 7.
В Linux оптимизированный стек TCP/IP - скорость передачи по сети сильно (10,3 МБ/сек в Linux против 4,5МБ/сек) отличается от скорости под WinCE 6.0 R3 (правда не успел протестировать под Windows Embedded Compact 7).
По работе с графикой - удобно с WinCE. Хотя наличие OpenGLES уравнивает возможности.
Отладка приложений и ядра под WinCE на раз-два, в Linux на раз-два-три (Platform Builder против DDD, GDB, KGDB).
Открытый код Linux против платного полуоткрытого WinCE.
И к слову, собранная Windows Embedded Compact 7 компилятором с поддержкой ARMv7 (Cortex-A8) работает значительно быстрее чем WinCE 6.0 R3 (c Linux пока не сравнивал).

Сообщение отредактировал SimpleSoft - Aug 27 2010, 14:49

[winner]

ARM/MIPS/SHx/x86

Имеется ввиду что wince не поддерживает многопроцессорные системы - SMP.

[SimpleSoft]

Имеется ввиду что wince не поддерживает многопроцессорные системы - SMP.

Win CE 6 да, но Windows Embedded Compact 7 поддерживает SMP (ARMv7).

Сообщение отредактировал SimpleSoft - Aug 27 2010, 19:10

[SPACUM]

Цитата(zltigo @ Aug 27 2010, 12:27) *
"Никому верить нельзя - мне можно"©

Выскажу свое мнение, может неправильное, но есть.
1. Процессор LPC2478 слишком слаб, чтобы кроме основной задачи еще тянуть Linux или Windows.
С сетями и с многозадачностью не работаю, всё остальное из них вполне можно написать или взять готовым.
2. Человек не может выдавать новые гениальные идеи по расписанию, интеллектуальную собственность надо защищать.
Я не сторонник полностью открытых программ.
3. Не считаю нужным снабжать заказчика ломаным кейлом или требовать его покупки.

Поступаю следующим образом. Для конкретного типа процессора пишу библиотеку сильно оптимизированных
примитивов. (около 120 строк в ассемблере). При этом 90% времени процессор выполняет именно эти функции.
Оптимизация остальных 10% и выбор оптимального компилятора уже не интересны.
(размером программы не интересуюсь - без Линукса на все хватит, а флешку мне не заполнить)
Для LPC2478 Я выбрал Rowley CrossWorks, просто друг показал и мне понравилось. А у других и шрифт раздражает и
цвет не нравится. А сотни часов смотреть на это надо.
Заказчику передаю в виде небольшой программы для GCC и почти оптимальной библиотеки нужных ему функций.
А перейти на другой процессор запросто - переписать эти 120 строк и разобраться с периферией.

Сообщение отредактировал SPACUM - Aug 28 2010, 12:29

[SimpleSoft]

ещё 5 копеек в пользу Rowley CrossWorks - это поддержка FTDI FT2232. Под рукой была плата с FT2232, вытянув JTAG линии и настроив TRST, nRST на нужные GPIO, получил почти даром, отладчик и программатор.

[VslavX]

Для LPC2478 Я выбрал Rowley CrossWorks, просто друг показал и мне понравилось. А у других и шрифт раздражает и
цвет не нравится. А сотни часов смотреть на это надо.

ИМХО, не следует мешать в одну кучу свойства собственно компилятора и среды разработки - "мухи отдельно, котлеты отдельно". Выбираете текстовый редактор (если интересно - на форуме есть соответствующие темы - в чем народ только не работает) или среду себе "по вкусу" - и без напряга смотрите на нее "сотни часов". А компилятор, программатор, отладчик (я, правда, жесткий сторонник консольной отладки) уже цепляете как внешние инструменты - через командную строку. И переход на новую архитектуру приводит только к переписыванию make-файла, без нарушения душевного комфорта и насилия над собственной личностью в новой среде.

[demiurg_spb]

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

Золотые слова! Но не всегда это возможно к сожалению...
Например разработка java приложений и сборка их через make не очень кошерно. Всё таки есть устоявшиеся средства и способы...

[zltigo]

Например разработка java приложений...

Ну Вы бы еще Flash приложения помянули . Но к счастью в том, что называлось и все еще называется программированием инструментарий строится модульно и совсем не обязательно пользоваться набором "101 в одном", а можно собрать все самое приемлимое и подогнуть, дописать под себя.

[winner]

2. Человек не может выдавать новые гениальные идеи по расписанию,

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

интеллектуальную собственность надо защищать.

Следуя этому правилу придем к первобытному строю, когда знания были доступны избранным - колдунам, жрецам, шаманам.

Для конкретного типа процессора пишу библиотеку сильно оптимизированных
примитивов. (около 120 строк в ассемблере). При этом 90% времени процессор выполняет именно эти функции.
Оптимизация остальных 10% и выбор оптимального компилятора уже не интересны. А перейти на другой процессор запросто - переписать эти 120 строк и разобраться с периферией.

На форте не пробовали писать ? чем изобретать лисапеды.

[SPACUM]

<<Поэтому открытые проекты всегда будут развиваться быстрее и качественней - над ними работают тысячи людей по всему миру.>>
Начнем с Microsoft - надо повысить качество. Вы их попросите пусть откроют. Да здравствует Linux самый быстрый и качественный!

<<Следуя этому правилу придем к первобытному строю, когда знания были доступны избранным - колдунам, жрецам, шаманам.>>
Я не жадный, так сидел бы на видном месте и идеи бы раздавал, только подаяния просить не умею. Мои заказчики хотят готовый
продукт подешевле, и получше, чем у других, а за публикацию идей для всех платить не хотят. Вот и надо иметь что-то за пазухой.

<<На форте не пробовали писать ? чем изобретать лисапеды.>>
Ну я не знал, что все так делают, думал некоторые еще идеальные компиляторы ищут.

PS. Давайте без комментариев. Это личное мнение и по-другому мне не выжить. А что касается шаманских тайн, то они все спокойно
вскрываются, правда быстрее все самому разработать.

[winner]

Мои заказчики хотят готовый продукт подешевле, и получше, чем у других

Вы себе льстите, хотя как в поговорке "сам себя не похвалишь - никто не похвалит"..

думал некоторые еще идеальные компиляторы ищут.

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

[demiurg_spb]

Ну Вы бы еще Flash приложения помянули .

И "1с" и AIR.
Пути программирования неисповедимы:-)
И чем больше технологий хороших и разных тем быстрее движется прогресс.
И тем больше потребностей покрывается. ИМХО.
Но никто не отменял присказки "При всём богатстве выбора..."
Главное всё же, во всём этом, что есть возможность выбора.
Хочу халву ем, хочу - пряники

[SPACUM]

Вы себе льстите, хотя как в поговорке "сам себя не похвалишь - никто не похвалит"..



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

Это Вы обижаете автора ветки. Выбор компилятора это как-раз тема ветки. Я выбрал совсем не идеальный и объяснил почему.
Если Rom20 согласится с моим выбором - могу помочь в освоении.

Сообщение отредактировал SPACUM - Aug 29 2010, 11:16

[haker_fox]

Следуя этому правилу придем к первобытному строю, когда знания были доступны избранным - колдунам, жрецам, шаманам.

Знания и сейчас достпуны только избранным - тем кто добывает их. Открытие интеллектуальной собственности ни как не прибавит число знающих, зато лишит зарплаты тех, кто днями и ночами трудился над своим проектом. Посмотрите, сколько знаний вокруг, благодаря интернету, черпай и пользуйся. Однако рядовой студент не может решить рядовую задача по физике или математике.

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

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

[AlexandrY]

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

Вы спорите с изначально абсурдным утверждением. Тысячи разрабатывать один софтовый пакет не могут и никто так на самом деле не делает.
Это просто плод воспаленного воображения падких на дешевый пиар разработчиков.
Т.е такого подхода нет и быть не может.

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

С GCC для ARM как раз все ясно, там 50% участия самой фирмы ARM по заявлению самой ARM и никаких там особых альтернативных разработчиков нет.
И этот компилер всегда будет уступать RealView по производительности в каждый отдельно взятый момент времени.

[winner]

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

Ерунду Вы гворите. Яркий пример - самый главный опенсорсный продук ядро Linux. Там над каждой подсистемой есть координаторы, Торвальдс вообще только указания дает а разработки ведут очень большое количество людей по всему миру. Большой вклад делают корпорации, вообще где-то была процентная статистика участия отдельных компаний и всего остального сообщества.

С GCC для ARM как раз все ясно, там 50% участия самой фирмы ARM по заявлению самой ARM и никаких там особых альтернативных разработчиков нет.

Это как понимать, 50% кода принадлежит arm - а остальные 50% типа не в счет ? А как же code sourcery? RH ? а остальные компании участвующие как минимумум в оптимизации - nokia например ? В общем Вы не в теме.

[zltigo]

Ерунду Вы гворите. Яркий пример - самый главный опенсорсный продук ядро Linux.

Да яркий - как "сто тысяч Леммингов" чего-то с упоением "причастных" выдают на гора мутного латанного кода, но зато много. Есть ведь и друге опенсорсные ядра. Например, FreeBSD. И делаются они достаточно небольшим коллективом без шума и пыли, имеют вменяемые исходники, которые действительно можно с удовольствием читать и портировать.

[AlexandrY]

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

А сами разрабатывать не пытались это ядро? Идите попытайтесь там че нить разработать. Вас пошлют подальше в легком случае.
Не повторяйте мифы вообщем. Самый консервативный проект придумать сложно. Win CE развивается гораздо быстрее.

Это как понимать, 50% кода принадлежит arm - а остальные 50% типа не в счет ? А как же code sourcery? RH ? а остальные компании участвующие как минимумум в оптимизации - nokia например ? В общем Вы не в теме.

Здесь таже логика что и с ядром. Они эти нокии может бирюльки навешивают там где-то возле компилятора. А так они даже симбиан свой открыть не могут до конца.

[winner]

Да яркий - как "сто тысяч Леммингов" чего-то с упоением "причастных" выдают на гора мутного латанного кода, но зато много. Есть ведь и друге опенсорсные ядра. Например, FreeBSD.

Это вменяемое ядро еще вчера висло напрочь если достать неотмонтированную usb-флешку, над бздунами до сих весь мир потешается этим фактом.

Идите попытайтесь там че нить разработать. Вас пошлют подальше в легком случае.

Хе-хе - вот это очень правильный ответ на "выдают на гора мутного латанного кода" - никто там не примет в основную ветку говнокод.

[zltigo]

никто там не примет в основную ветку говнокод.

При том количестве говнокода в котором плавает даже якобы тщательно охраняемое "ядро" Линукса изобразить "а я на арене весь в белом" уже давно не удается.

[winner]

При том количестве говнокода в котором плавает даже якобы тщательно охраняемое "ядро" Линукса изобразить "а я на арене весь в белом" уже давно не удается.

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

[IgorKossak]

Тема с банальной просьбой плавно перерастает в религиозную войну.
Может закрыть?

[zltigo]

Может закрыть?

Не надо. Думаю, что все уже закончилось. Осталась пища для размышлений.

[VslavX]

Посмеяться хотите?
Потратил пару часов - скачал расхваливаемый в данной ветке Keil 4.12, и провел сравнение с IAR 5.41 и гонимым GCC 4.4.3, компилируя Dhrystone 2.1 для платы на LPC1768 (Cortex-M3).
Результаты такие:

Максимальная оптимизация по размеру:
Keil: -O3 -Ospace, 1816 байт, 95066 dps
IAR: -Ohz, 1886 байт, 95434 dps
GCC: -Os, 1966 байт, 108931 dps

В прошивку входит много чего HAL, операционка, и прочее, это все я компилировал IAR, менял только один объектник собственно с dhrystone, размер приведен именно для тестовой функции+ее константные данные. Итого: разницы в размере и скорости почти нет - в пределах зависимости от выравнивания кода во флеш.

Максимальная оптимизация по скорости:
Keil: -O3 -Otime, 2132 байт, 122243 dps
IAR: -Ohs, 1974 байт, 123734 dps
GCC: -O3, 2506 байт, 128803 dps
Итого: тожe практически паритет

А вот с GCC все было весело - для Кортекса я им не пользуюсь - последний у меня 4.1.1 для ARM. Cначала скачал готовую сборку от Macraigor 4.4.3 - я всегда оттуда беру. Установил - компилятор молча не работает. После получаса разборок выяснилось что ему не хватает некоторых библиотек - Цигвин у меня староват оказался для него, скачал, поковырялся, нашел нехватающее (почти гиг скачать пришлось), поставил, заработало, с матюками. И общий итог печальный - файл хоть компилируется и линкуется, но работать на плате оно не хочет - выходит с произвольным результатом. По итогам разбирательств - похоже проблема в сборке, она не поддерживает генерацию нового EABI от ARM-а, во всяком случае ключик -meabi=4 не жрется, а при компиляции без него IAR-овский линкер выдает варнинг - после потерянных двух часов мне уже дальше разбираться, искать другие сборки (не факт что совместимые) итд итп, стало лень. Для сравнения - на Кейл никогда не виданный в глаза было потрачено 15 минут. На GCC которым я пользуюсь лет 8 - более 2 часов и результата все еще нет, зато фана - полные штаны.

Утренний upd: частично разобрался с проблемой - почему-то линкер считал что последняя глобальная переменная объявленная в объектнике GCC свободна и лепил туда первую подходящую из IAR-овских объектников. Крупно не повезло что это была переменная обновляемая раз в 128 мс в прерывании значением прошедших тиков (профайлер) - быстро такое не обнаружить . Кто там виноват в совмещении переменных уже на разбирался - добавил еще одну липовую переменную в файле теста и все заработало. А вот результаты уже интересные - GCC проигрывает по размеру кода и немного выигрывает по скорости. Так что - не так уж оно мрачно все, после некоторых усилий GCC вполне юзабелен.

[zltigo]

Посмеяться хотите?

Да все совершенно ожидаемы. Когда-то (последний раз вскоре по появлению IAR V5) гонял эту-же троицу для ARM7 (и на Whetstone тоже). Результаты сходны. Собирал под заказчика и реальный проект под GCC после IAR V4. По размеру (компилировалось под производительность) отличия минимальны, производительность, правда, не оценивал - там было по любому с большим запасом.

[yes]

например, IAR - который супер пупер и за деньги очень хреново работает с FPU в ARM9 - то есть у него поддержка (либы эксепшены кривая) и с кодогенератором надо как-то хитрить, то есть программисты обплевались
с GCC, когда раньше брал в руки шашки самостоятельно, никаких проблем с поддержкой плавучки не испытывал

также вопрос к пользователям кортексов - а NEON хоть как-то поддерживается в коммерческих компилерах? прежде всего IAR, ну и RVDS интересны???

ну то есть я знаю, что GCC и RVDS поддерживают, но вопрос как? вроде как GCC сам умеет "векторизовать"
ну а IAR и Keil вроде как и не собираются поддерживать

btw: сейчас прет arm-gcc-llvm (вроде им Джобс пользуется) кто-нибудь пробовал???

[igorsk]

А вот с GCC все было весело - для Кортекса я им не пользуюсь - последний у меня 4.1.1 для ARM. Cначала скачал готовую сборку от Macraigor 4.4.3 - я всегда оттуда беру.

Готовый GCC лучше брать от CodeSourcery - там люди над ним за деньги работают, и поддержка новых фич появляется раньше майнлайна. Кстати я слыхал IAR вроде тоже на GCC перешёл.

также вопрос к пользователям кортексов - а NEON хоть как-то поддерживается в коммерческих компилерах? прежде всего IAR, ну и RVDS интересны???
ну то есть я знаю, что GCC и RVDS поддерживают, но вопрос как? вроде как GCC сам умеет "векторизовать"
ну а IAR и Keil вроде как и не собираются поддерживать

Keil сейчас юзает фирменный армовский компилятор, но т.к. сама среда заточена под младшие модели, поддержки Cortex-A и соответственно неона нету.
RVCT неон поддерживает давно, и авто-векторизацию тоже умеет.

Сообщение отредактировал igorsk - Aug 31 2010, 21:46

[VslavX]

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

Да, спасибо, глянул - мне понравилось, вроде даже Cygwin не нужен (у меня вечно с ним всякие траблы), скачаю - попробую. А в Lite-версии у них компилятор никак не урезанный? Командной строки мне полностью достаточно.

Кстати я слыхал IAR вроде тоже на GCC перешёл.

По меньшей мере заюзали binutils-ы. Но как-то криво - я линкер-ом 5.x до сих на грабли наступаю при пересборке старых проектов. Причем я четко понимал преимущества и особенности IAR-овского UBROF и старался ими не злоупотреблять - именно для лучшей переносимости.

[IgorKossak]

А в Lite-версии у них компилятор никак не урезанный?

Слегка урезанный. Поддерживается только Little-Endian и Soft-Float в отличие от платных.

[zltigo]

Но как-то криво - я линкер-ом 5.x до сих на грабли наступаю при пересборке старых проектов.

У них в не pro версии специально внесена несовместимость в объектники. С pro версией проблем не замечал (но много не пользовал) - хоть с GCC хоть с их интерпретацией инструментария.

[VslavX]

У них в не pro версии специально внесена несовместимость в объектники. С pro версией проблем не замечал (но много не пользовал) - хоть с GCC хоть с их интерпретацией инструментария.

Что понимается под "Pro" - это Full который?
У меня грабли были с некоторыми relocations (есть часть кода который написан на асме и должен быть позиционно-независимым, там это и вылезло), то есть в формате ELF-ARM они четко документированы и должны быть поддержаны, но линкер их "в упор" не понимал.

[zltigo]

Что понимается под "Pro" - это Full который?

Да.

но линкер их "в упор" не понимал.

Какой из двух (GCC/IAR) возможных?

[VslavX]

Какой из двух (GCC/IAR) возможных?

IAR-овский (для GCC лень было скрипт переписывать - выкрутился коррекцией кода), еще была пара случаев когда он просто падал с internal error. Сам IAR C-компилятор при разрешенной максимальной оптимизации тоже иногда глючит - и падает (internal error) и лажу выдает. Я сейчас вообще особого смысла держаться за IAR для ARM-ов не вижу, на AVR-ках - да, там ИАР по компактности вне конкуренции, а для ARM - выбор широкий. Попробую сборку GCC от CodeSourcery - вроде на первый взгляд ничего так и рискну прикладникам предложить (моя часть изначально многопортовая - GCC/IAR/MSVC, мне почти все равно).

[sonycman]

IAR-овский (для GCC лень было скрипт переписывать - выкрутился коррекцией кода), еще была пара случаев когда он просто падал с internal error. Сам IAR C-компилятор при разрешенной максимальной оптимизации тоже иногда глючит - и падает (internal error) и лажу выдает.

С кейлом у меня никогда не было проблем по части глюков, а ИАР - да, ассемблер при компиляции стартапа для кортекса запарил своими внутренними ошибками.
Поставишь лишний комментарий\впишешь строчку кода - и падает.
И это 5.50.5 версия!

Слава богу, си компилер пока не глючил

[zltigo]

ИАР - да, ассемблер при компиляции стартапа для кортекса запарил своими внутренними ошибками.

Для Cortex? Для Cortex, зараза, даже startup на 'C' пишется совершенно естественно. Дожили . Падений компилятора давно уже не встечал, на каком-то из первых - было. Документировали и пофиксили.

[VslavX]

Падений компилятора давно уже не встечал, на каком-то из первых - было. Документировали и пофиксили.

Держите, свеженькое - две недели назад наступил, версия 5.41, ключики такие:

Код

CFLAGS        = --cpu=Cortex-M3 -e --silent --endian little -Ohz    
          --no_path_in_file_macros
          --no_mem_idioms
          --no_unaligned_access

При -Ohz - падает, при -Oh работает, так и живем

Сам код:

CODE

typedef unsigned long DWORD, *PDWORD;

#pragma swi_number=0x00
__swi DWORD hal_swi_call1(
DWORD agr0);

#pragma swi_number=0x00
__swi DWORD hal_swi_call2(
DWORD arg0,
DWORD arg1);

#define hal_lock_interrupt() hal_swi_call1(0)
#define hal_unlock_interrupt(sr) hal_swi_call2(1, sr)

DWORD
hal_interlocked_inc(
PDWORD var)
{
DWORD lock, ret;
lock = hal_lock_interrupt();
ret = *var + 1;
*var = ret;
hal_unlock_interrupt(lock);
return ret;
}

DWORD
hal_interlocked_dec(
PDWORD var)
{
DWORD lock, ret;
lock = hal_lock_interrupt();
ret = *var - 1;
*var = ret;
hal_unlock_interrupt(lock);
return ret;
}

DWORD
hal_interlocked_set(
PDWORD var,
DWORD mask)
{
DWORD lock, ret;
lock = hal_lock_interrupt();
ret = *var;
ret |= mask;
*var = ret;
hal_unlock_interrupt(lock);
return ret;
}

DWORD
hal_interlocked_clr(
PDWORD var,
DWORD mask)
{
DWORD lock, ret;
lock = hal_lock_interrupt();
ret = *var;
ret &= ~mask;
*var = ret;
hal_unlock_interrupt(lock);
return ret;
}

DWORD
hal_interlocked_xchg(
PDWORD var,
DWORD value)
{
DWORD lock, ret;
lock = hal_lock_interrupt();
ret = *var;
*var = value;
hal_unlock_interrupt(lock);
return ret;
}

Про глюки библиотек при --no_unaligned_access вообще молчу

[sasamy]

Слегка урезанный. Поддерживается только Little-Endian и Soft-Float в отличие от платных.

А разве платная версия у них не отличается от бесплатной только тем что платна IDE ?

[IgorKossak]

А разве платная версия у них не отличается от бесплатной только тем что платна IDE ?

1. И IDE тоже, но вопросе речь была о командной строке.
2. Об остальных отличиях можно узнать пройдясь по приведённым мною ссылкам.

[sasamy]

1. И IDE тоже, но вопросе речь была о командной строке.
2. Об остальных отличиях можно узнать пройдясь по приведённым мною ссылкам.

Я не пользуюсь ихним тулчейном, предпочитаю свои сборки, но код для vfp и neon генерирует и lite версия.
http://processors.wiki.ti.com/index.php/Co...iler_Comparison

К тому же весьма интересно следующее заявление

These toolchains should not be used to build Linux kernels or applications.

Насчет приложеий согласен, а вот ядру нужен только голый компилятор, у него своя библиотека klibc

Сообщение отредактировал sasamy - Sep 2 2010, 10:01

[zuy]

Для Cortex? Для Cortex, зараза, даже startup на 'C' пишется совершенно естественно.

А не подскажете, какая именно фича в архитектуре кортекса сделала это возможным в отличии от 23хх серии?
Вчера только перечитывал migration from 23xx to 17xx, и не могу понять, почему в 23хх нельзя было так же без длинного стартапа на асме сделать.

[zltigo]

А не подскажете, какая именно фича в архитектуре кортекса сделала это возможным в отличии от 23хх серии?

Например, установка указателя стека "автоматом" по значению находящемуся по нулевому адресу. Например, наличие таблицы векторов вместо точек входа в обработчики exception.

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

Ну так покажите, например, как на 'С' установить стеки для всех режимов работы и написать программу ( ldr pc,[pc,#-0xFF0] ) из одного слова находящуюся по фиксированному адресу.

[zuy]

Например, установка указателя стека "автоматом" по значению находящемуся по нулевому адресу. Например, наличие таблицы векторов вместо точек входа в обработчики exception.

Ну так покажите, например, как на 'С' установить стеки для всех режимов работы и написать программу ( ldr pc,[pc,#-0xFF0] ) из одного слова находящуюся по фиксированному адресу.

Все, глаза раскрылись
Спасибо, стало полностью понятно.

[klen]

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

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

давайте кусок кода, будем смотреть. я на своей сборке сделаю, Вы на своей системе компиляции - там и сравним. Мне сейчас нравится коимпилять для Соrtех-M3
без библиотек и всякого го**а которое может замутить чистоту эксперимента.


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

[AlexandrY]

давайте кусок кода, будем смотреть. я на своей сборке сделаю, Вы на своей системе компиляции - там и сравним. Мне сейчас нравится коимпилять для Соrtех-M3
без библиотек и всякого го**а которое может замутить чистоту эксперимента.

Может CoreMark для начала?
http://www.coremark.org/home.php

[klen]

Может CoreMark для начала?
http://www.coremark.org/home.php

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

[sonycman]

Может CoreMark для начала?

Эх нифига себе: STM32 90nm 120 MHz
Даже LPC1768 позади остался! Это за счёт чего такая скорость получилась, у STM теперь флеш быстрее, чем у NXP?

[klen]

Эх нифига себе: STM32 90nm 120 MHz
Даже LPC1768 позади остался! Это за счёт чего такая скорость получилась, у STM теперь флеш быстрее, чем у NXP?

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

[igorsk]

Надо сравнивать с 1769, он тоже 120MHz.

[klen]

Надо сравнивать с 1769, он тоже 120MHz.

а там приведенное значение - посмотрите внимательнее, результат деленный на частоту.

по поводу сравнения компиллеров, скомпилил core_matrix.c. ниже выходной асм объектника, можно ужо и предметно бочки накатывать при странении и смотреть где кривости кодогенератора:

CODE

1 .syntax unified
2 .cpu cortex-m3
3 .fpu softvfp
4 .eabi_attribute 20, 1
5 .eabi_attribute 21, 1
6 .eabi_attribute 23, 3
7 .eabi_attribute 24, 1
8 .eabi_attribute 25, 1
9 .eabi_attribute 26, 1
10 .eabi_attribute 30, 4
11 .eabi_attribute 18, 4
12 .thumb
13 .file "core_matrix.c"
14 .section .text.core_init_matrix,"ax",%progbits
15 .align 1
16 .global core_init_matrix
17 .thumb
18 .thumb_func
20 core_init_matrix:
21 @ args = 0, pretend = 0, frame = 24
22 @ frame_needed = 0, uses_anonymous_args = 0
23 0000 2DE9F04F push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
24 0004 0025 movs r5, #0
25 0006 87B0 sub sp, sp, #28
26 0008 002A cmp r2, #0
27 000a 08BF it eq
28 000c 0122 moveq r2, #1
29 000e 2C46 mov r4, r5
30 0010 03E0 b .L3
31 .L4:
32 0012 0134 adds r4, r4, #1
33 0014 04FB04F5 mul r5, r4, r4
34 0018 ED00 lsls r5, r5, #3
35 .L3:
36 001a 8542 cmp r5, r0
37 001c F9D3 bcc .L4
38 001e 601E subs r0, r4, #1
39 0020 00FB00F7 mul r7, r0, r0
40 0024 0139 subs r1, r1, #1
41 0026 21F00301 bic r1, r1, #3
42 002a 7E00 lsls r6, r7, #1
43 002c 0C1D adds r4, r1, #4
44 002e 0296 str r6, [sp, #8]
45 0030 4500 lsls r5, r0, #1
46 0032 A619 adds r6, r4, r6
47 0034 0194 str r4, [sp, #4]
48 0036 0395 str r5, [sp, #12]
49 0038 B046 mov r8, r6
50 003a 4FF0000C mov ip, #0
51 003e 0127 movs r7, #1
52 0040 0590 str r0, [sp, #20]
53 0042 2BE0 b .L5
54 .L9:
55 0044 0024 movs r4, #0
56 0046 3D46 mov r5, r7
57 0048 A146 mov r9, r4
58 004a 0093 str r3, [sp, #0]
59 .L7:
60 004c 6A43 muls r2, r5, r2
61 004e 22F0FE42 bic r2, r2, #2130706432
62 0052 32F47F02 bics r2, r2, #16711680
63 0056 05D5 bpl .L6
64 0058 013A subs r2, r2, #1
65 005a 6FEA024A mvn sl, r2, lsl #16
66 005e 6FEA1A43 mvn r3, sl, lsr #16
67 0062 5A1C adds r2, r3, #1
68 .L6:
69 0064 1FFA85FB uxth fp, r5
70 0068 0BEB0203 add r3, fp, r2
71 006c 1FFA83FA uxth sl, r3
72 0070 28F804A0 strh sl, [r8, r4] @ movhi
73 0074 09F10109 add r9, r9, #1
74 0078 DA44 add sl, sl, fp
75 007a 6318 adds r3, r4, r1
76 007c 5FFA8AFA uxtb sl, sl
77 0080 0135 adds r5, r5, #1
78 0082 0234 adds r4, r4, #2
79 0084 8145 cmp r9, r0
80 0086 A3F804A0 strh sl, [r3, #4] @ movhi
81 008a DFD3 bcc .L7
82 008c 059D ldr r5, [sp, #20]
83 008e 009B ldr r3, [sp, #0]
84 0090 7F19 adds r7, r7, r5
85 0092 039D ldr r5, [sp, #12]
86 0094 0CF1010C add ip, ip, #1
87 0098 A844 add r8, r8, r5
88 009a 4919 adds r1, r1, r5
89 .L5:
90 009c 8445 cmp ip, r0
91 009e D1D3 bcc .L9
92 00a0 019C ldr r4, [sp, #4]
93 00a2 9E60 str r6, [r3, #8]
94 00a4 5C60 str r4, [r3, #4]
95 00a6 029C ldr r4, [sp, #8]
96 00a8 1860 str r0, [r3, #0]
97 00aa 3219 adds r2, r6, r4
98 00ac 511E subs r1, r2, #1
99 00ae 21F00306 bic r6, r1, #3
100 00b2 0436 adds r6, r6, #4
101 00b4 DE60 str r6, [r3, #12]
102 00b6 07B0 add sp, sp, #28
103 00b8 BDE8F08F pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
105 .section .text.matrix_sum,"ax",%progbits
106 .align 1
107 .global matrix_sum
108 .thumb
109 .thumb_func
111 matrix_sum:
112 @ args = 0, pretend = 0, frame = 0
113 @ frame_needed = 0, uses_anonymous_args = 0
114 0000 0023 movs r3, #0
115 0002 2DE9F041 push {r4, r5, r6, r7, r8, lr}
116 0006 9C46 mov ip, r3
117 0008 4FEA8008 lsl r8, r0, #2
118 000c 1C46 mov r4, r3
119 000e 1D46 mov r5, r3
120 0010 12E0 b .L12
121 .L15:
122 0012 51F82670 ldr r7, [r1, r6, lsl #2]
123 0016 ED19 adds r5, r5, r7
124 0018 9542 cmp r5, r2
125 001a 03DD ble .L13
126 001c 0A34 adds r4, r4, #10
127 001e A4B2 uxth r4, r4
128 0020 0025 movs r5, #0
129 0022 03E0 b .L14
130 .L13:
131 0024 6745 cmp r7, ip
132 0026 C8BF it gt
133 0028 0134 addgt r4, r4, #1
134 002a A4B2 uxth r4, r4
135 .L14:
136 002c 0136 adds r6, r6, #1
137 002e BC46 mov ip, r7
138 .L17:
139 0030 8642 cmp r6, r0
140 0032 EED1 bne .L15
141 0034 0133 adds r3, r3, #1
142 0036 4144 add r1, r1, r8
143 .L12:
144 0038 8342 cmp r3, r0
145 003a 01D0 beq .L16
146 003c 0026 movs r6, #0
147 003e F7E7 b .L17
148 .L16:
149 0040 20B2 sxth r0, r4
150 0042 BDE8F081 pop {r4, r5, r6, r7, r8, pc}
152 .section .text.matrix_mul_const,"ax",%progbits
153 .align 1
154 .global matrix_mul_const
155 .thumb
156 .thumb_func
158 matrix_mul_const:
159 @ args = 0, pretend = 0, frame = 0
160 @ frame_needed = 0, uses_anonymous_args = 0
161 0000 F0B5 push {r4, r5, r6, r7, lr}
162 0002 4700 lsls r7, r0, #1
163 0004 8600 lsls r6, r0, #2
164 0006 0025 movs r5, #0
165 0008 0DE0 b .L19
166 .L20:
167 000a 32F914C0 ldrsh ip, [r2, r4, lsl #1]
168 000e 03FB0CFC mul ip, r3, ip
169 0012 41F824C0 str ip, [r1, r4, lsl #2]
170 0016 0134 adds r4, r4, #1
171 0018 00E0 b .L21
172 .L22:
173 001a 0024 movs r4, #0
174 .L21:
175 001c 8442 cmp r4, r0
176 001e F4D1 bne .L20
177 0020 0135 adds r5, r5, #1
178 0022 D219 adds r2, r2, r7
179 0024 8919 adds r1, r1, r6
180 .L19:
181 0026 8542 cmp r5, r0
182 0028 F7D1 bne .L22
183 002a F0BD pop {r4, r5, r6, r7, pc}
185 .section .text.matrix_add_const,"ax",%progbits
186 .align 1
187 .global matrix_add_const
188 .thumb
189 .thumb_func
191 matrix_add_const:
192 @ args = 0, pretend = 0, frame = 0
193 @ frame_needed = 0, uses_anonymous_args = 0
194 0000 F0B5 push {r4, r5, r6, r7, lr}
195 0002 4600 lsls r6, r0, #1
196 0004 0024 movs r4, #0
197 0006 0BE0 b .L24
198 .L25:
199 0008 CF5A ldrh r7, [r1, r3]
200 000a 0135 adds r5, r5, #1
201 000c BF18 adds r7, r7, r2
202 000e CF52 strh r7, [r1, r3] @ movhi
203 0010 0233 adds r3, r3, #2
204 0012 01E0 b .L26
205 .L27:
206 0014 0023 movs r3, #0
207 0016 1D46 mov r5, r3
208 .L26:
209 0018 8542 cmp r5, r0
210 001a F5D1 bne .L25
211 001c 0134 adds r4, r4, #1
212 001e 8919 adds r1, r1, r6
213 .L24:
214 0020 8442 cmp r4, r0
215 0022 F7D1 bne .L27
216 0024 F0BD pop {r4, r5, r6, r7, pc}
218 .section .text.matrix_mul_vect,"ax",%progbits
219 .align 1
220 .global matrix_mul_vect
221 .thumb
222 .thumb_func
224 matrix_mul_vect:
225 @ args = 0, pretend = 0, frame = 0
226 @ frame_needed = 0, uses_anonymous_args = 0
227 0000 2DE9F047 push {r4, r5, r6, r7, r8, r9, sl, lr}
228 0004 0024 movs r4, #0
229 0006 4FEA400C lsl ip, r0, #1
230 000a 2646 mov r6, r4
231 000c 14E0 b .L29
232 .L32:
233 000e 41F8046B str r6, [r1], #4
234 0012 3546 mov r5, r6
235 0014 3746 mov r7, r6
236 0016 0BE0 b .L30
237 .L31:
238 0018 32F90580 ldrsh r8, [r2, r5]
239 001c 33F905A0 ldrsh sl, [r3, r5]
240 0020 51F8049C ldr r9, [r1, #-4]
241 0024 0137 adds r7, r7, #1
242 0026 0AFB0898 mla r8, sl, r8, r9
243 002a 0235 adds r5, r5, #2
244 002c 41F8048C str r8, [r1, #-4]
245 .L30:
246 0030 8742 cmp r7, r0
247 0032 F1D1 bne .L31
248 0034 0134 adds r4, r4, #1
249 0036 6244 add r2, r2, ip
250 .L29:
251 0038 8442 cmp r4, r0
252 003a E8D1 bne .L32
253 003c BDE8F087 pop {r4, r5, r6, r7, r8, r9, sl, pc}
255 .section .text.matrix_mul_matrix,"ax",%progbits
256 .align 1
257 .global matrix_mul_matrix
258 .thumb
259 .thumb_func
261 matrix_mul_matrix:
262 @ args = 0, pretend = 0, frame = 16
263 @ frame_needed = 0, uses_anonymous_args = 0
264 0000 2DE9F04F push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
265 0004 85B0 sub sp, sp, #20
266 0006 0293 str r3, [sp, #8]
267 0008 8300 lsls r3, r0, #2
268 000a 0193 str r3, [sp, #4]
269 000c 0023 movs r3, #0
270 000e 4FEA400B lsl fp, r0, #1
271 0012 1F46 mov r7, r3
272 0014 28E0 b .L34
273 .L37:
274 0016 DDF80880 ldr r8, [sp, #8]
275 001a C0EB040C rsb ip, r0, r4
276 001e 08EB4C0C add ip, r8, ip, lsl #1
277 0022 45F8047B str r7, [r5], #4
278 0026 3E46 mov r6, r7
279 0028 3B46 mov r3, r7
280 002a CDF80CC0 str ip, [sp, #12]
281 002e 0CE0 b .L35
282 .L36:
283 0030 DDF80C90 ldr r9, [sp, #12]
284 0034 32F91380 ldrsh r8, [r2, r3, lsl #1]
285 0038 39F90690 ldrsh r9, [r9, r6]
286 003c 55F804CC ldr ip, [r5, #-4]
287 0040 0133 adds r3, r3, #1
288 0042 09FB08CC mla ip, r9, r8, ip
289 0046 45F804CC str ip, [r5, #-4]
290 .L35:
291 004a 8342 cmp r3, r0
292 004c 5E44 add r6, r6, fp
293 004e EFD1 bne .L36
294 0050 0134 adds r4, r4, #1
295 0052 02E0 b .L38
296 .L39:
297 0054 0D46 mov r5, r1
298 0056 0024 movs r4, #0
299 0058 9A46 mov sl, r3
300 .L38:
301 005a 8442 cmp r4, r0
302 005c DBD1 bne .L37
303 005e 5446 mov r4, sl
304 0060 631C adds r3, r4, #1
305 0062 019C ldr r4, [sp, #4]
306 0064 5A44 add r2, r2, fp
307 0066 0919 adds r1, r1, r4
308 .L34:
309 0068 8342 cmp r3, r0
310 006a F3D1 bne .L39
311 006c 05B0 add sp, sp, #20
312 006e BDE8F08F pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
314 .section .text.matrix_mul_matrix_bitextract,"ax",%progbits
315 .align 1
316 .global matrix_mul_matrix_bitextract
317 .thumb
318 .thumb_func
320 matrix_mul_matrix_bitextract:
321 @ args = 0, pretend = 0, frame = 16
322 @ frame_needed = 0, uses_anonymous_args = 0
323 0000 2DE9F04F push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
324 0004 9B46 mov fp, r3
325 0006 85B0 sub sp, sp, #20
326 0008 8300 lsls r3, r0, #2
327 000a 0193 str r3, [sp, #4]
328 000c 0023 movs r3, #0
329 000e 4FEA4008 lsl r8, r0, #1
330 0012 1F46 mov r7, r3
331 0014 2CE0 b .L41
332 .L44:
333 0016 C0EB040C rsb ip, r0, r4
334 001a 0BEB4C0C add ip, fp, ip, lsl #1
335 001e 45F8047B str r7, [r5], #4
336 0022 3E46 mov r6, r7
337 0024 3B46 mov r3, r7
338 0026 CDF80CC0 str ip, [sp, #12]
339 002a 0091 str r1, [sp, #0]
340 002c 10E0 b .L42
341 .L43:
342 002e 0399 ldr r1, [sp, #12]
343 0030 32F913C0 ldrsh ip, [r2, r3, lsl #1]
344 0034 895F ldrsh r1, [r1, r6]
345 0036 0133 adds r3, r3, #1
346 0038 01FB0CF9 mul r9, r1, ip
347 003c 55F804CC ldr ip, [r5, #-4]
348 0040 C9F34611 ubfx r1, r9, #5, #7
349 0044 C9F38309 ubfx r9, r9, #2, #4
350 0048 09FB01CC mla ip, r9, r1, ip
351 004c 45F804CC str ip, [r5, #-4]
352 .L42:
353 0050 8342 cmp r3, r0
354 0052 4644 add r6, r6, r8
355 0054 EBD1 bne .L43
356 0056 0099 ldr r1, [sp, #0]
357 0058 0134 adds r4, r4, #1
358 005a 02E0 b .L45
359 .L46:
360 005c 0D46 mov r5, r1
361 005e 0024 movs r4, #0
362 0060 9A46 mov sl, r3
363 .L45:
364 0062 8442 cmp r4, r0
365 0064 D7D1 bne .L44
366 0066 5446 mov r4, sl
367 0068 631C adds r3, r4, #1
368 006a 019C ldr r4, [sp, #4]
369 006c 4244 add r2, r2, r8
370 006e 0919 adds r1, r1, r4
371 .L41:
372 0070 8342 cmp r3, r0
373 0072 F3D1 bne .L46
374 0074 05B0 add sp, sp, #20
375 0076 BDE8F08F pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
377 .section .text.matrix_test,"ax",%progbits
378 .align 1
379 .global matrix_test
380 .thumb
381 .thumb_func
383 matrix_test:
384 @ args = 4, pretend = 0, frame = 0
385 @ frame_needed = 0, uses_anonymous_args = 0
386 0000 2DE9F047 push {r4, r5, r6, r7, r8, r9, sl, lr}
387 0004 BDF92080 ldrsh r8, [sp, #32]
388 0008 0D46 mov r5, r1
389 000a 6FEA0851 mvn r1, r8, lsl #20
390 000e 0446 mov r4, r0
391 0010 6FEA1150 mvn r0, r1, lsr #20
392 0014 1646 mov r6, r2
393 0016 1146 mov r1, r2
394 0018 87B2 uxth r7, r0
395 001a 4246 mov r2, r8
396 001c 2046 mov r0, r4
397 001e 9946 mov r9, r3
398 0020 3FB2 sxth r7, r7
399 0022 FFF7FEFF bl matrix_add_const
400 0026 4346 mov r3, r8
401 0028 2046 mov r0, r4
402 002a 2946 mov r1, r5
403 002c 3246 mov r2, r6
404 002e FFF7FEFF bl matrix_mul_const
405 0032 3A46 mov r2, r7
406 0034 2946 mov r1, r5
407 0036 2046 mov r0, r4
408 0038 FFF7FEFF bl matrix_sum
409 003c 0021 movs r1, #0
410 003e FFF7FEFF bl crc16
411 0042 4B46 mov r3, r9
412 0044 8246 mov sl, r0
413 0046 2946 mov r1, r5
414 0048 2046 mov r0, r4
415 004a 3246 mov r2, r6
416 004c FFF7FEFF bl matrix_mul_vect
417 0050 3A46 mov r2, r7
418 0052 2946 mov r1, r5
419 0054 2046 mov r0, r4
420 0056 FFF7FEFF bl matrix_sum
421 005a 5146 mov r1, sl
422 005c FFF7FEFF bl crc16
423 0060 4B46 mov r3, r9
424 0062 8246 mov sl, r0
425 0064 2946 mov r1, r5
426 0066 2046 mov r0, r4
427 0068 3246 mov r2, r6
428 006a FFF7FEFF bl matrix_mul_matrix
429 006e 3A46 mov r2, r7
430 0070 2946 mov r1, r5
431 0072 2046 mov r0, r4
432 0074 FFF7FEFF bl matrix_sum
433 0078 5146 mov r1, sl
434 007a FFF7FEFF bl crc16
435 007e 4B46 mov r3, r9
436 0080 8246 mov sl, r0
437 0082 2946 mov r1, r5
438 0084 2046 mov r0, r4
439 0086 3246 mov r2, r6
440 0088 FFF7FEFF bl matrix_mul_matrix_bitextract
441 008c 3A46 mov r2, r7
442 008e 2946 mov r1, r5
443 0090 2046 mov r0, r4
444 0092 FFF7FEFF bl matrix_sum
445 0096 5146 mov r1, sl
446 0098 FFF7FEFF bl crc16
447 009c C8F10008 rsb r8, r8, #0
448 00a0 0546 mov r5, r0
449 00a2 0FFA88F2 sxth r2, r8
450 00a6 2046 mov r0, r4
451 00a8 3146 mov r1, r6
452 00aa FFF7FEFF bl matrix_add_const
453 00ae 28B2 sxth r0, r5
454 00b0 BDE8F087 pop {r4, r5, r6, r7, r8, r9, sl, pc}
456 .section .text.core_bench_matrix,"ax",%progbits
457 .align 1
458 .global core_bench_matrix
459 .thumb
460 .thumb_func
462 core_bench_matrix:
463 @ args = 0, pretend = 0, frame = 0
464 @ frame_needed = 0, uses_anonymous_args = 0
465 0000 13B5 push {r0, r1, r4, lr}
466 0002 0346 mov r3, r0
467 0004 0091 str r1, [sp, #0]
468 0006 1446 mov r4, r2
469 0008 D968 ldr r1, [r3, #12]
470 000a 5A68 ldr r2, [r3, #4]
471 000c 0068 ldr r0, [r0, #0]
472 000e 9B68 ldr r3, [r3, #8]
473 0010 FFF7FEFF bl matrix_test
474 0014 2146 mov r1, r4
475 0016 02B0 add sp, sp, #8
476 0018 BDE81040 pop {r4, lr}
477 001c FFF7FEBF b crc16
479 .ident "GCC: (Klen's GCC package (KGP) for ARM/elf platform) 4.6.0 20100903 (experimental)"
DEFINED SYMBOLS
*ABS*:0000000000000000 core_matrix.c
/tmp/ccnBPggq.s:15 .text.core_init_matrix:0000000000000000 $t
/tmp/ccnBPggq.s:20 .text.core_init_matrix:0000000000000000 core_init_matrix
/tmp/ccnBPggq.s:106 .text.matrix_sum:0000000000000000 $t
/tmp/ccnBPggq.s:111 .text.matrix_sum:0000000000000000 matrix_sum
/tmp/ccnBPggq.s:153 .text.matrix_mul_const:0000000000000000 $t
/tmp/ccnBPggq.s:158 .text.matrix_mul_const:0000000000000000 matrix_mul_const
/tmp/ccnBPggq.s:186 .text.matrix_add_const:0000000000000000 $t
/tmp/ccnBPggq.s:191 .text.matrix_add_const:0000000000000000 matrix_add_const
/tmp/ccnBPggq.s:219 .text.matrix_mul_vect:0000000000000000 $t
/tmp/ccnBPggq.s:224 .text.matrix_mul_vect:0000000000000000 matrix_mul_vect
/tmp/ccnBPggq.s:256 .text.matrix_mul_matrix:0000000000000000 $t
/tmp/ccnBPggq.s:261 .text.matrix_mul_matrix:0000000000000000 matrix_mul_matrix
/tmp/ccnBPggq.s:315 .text.matrix_mul_matrix_bitextract:0000000000000000 $t
/tmp/ccnBPggq.s:320 .text.matrix_mul_matrix_bitextract:0000000000000000 matrix_mul_matrix_bitextract
/tmp/ccnBPggq.s:378 .text.matrix_test:0000000000000000 $t
/tmp/ccnBPggq.s:383 .text.matrix_test:0000000000000000 matrix_test
/tmp/ccnBPggq.s:457 .text.core_bench_matrix:0000000000000000 $t
/tmp/ccnBPggq.s:462 .text.core_bench_matrix:0000000000000000 core_bench_matrix

UNDEFINED SYMBOLS
crc16

Сообщение отредактировал aaarrr - Sep 3 2010, 23:47

Причина редактирования: Оформление цитаты исходника

[sonycman]

флеш по идее у всех примерно одинаковая должна быть

Зато ускорители у всех разные - на 72 МГц LPC будет побыстрее, чем STM32 - индекс 1.75 против 1.5.
Вот и удивил индекс у нового STM - аж 1.9:

Вы бы код в codebox спрятали, а то "портянка" большущая получилась

[klen]

aaa.. я про тег codebox ничего не знал - кнопочками его не ввести. теперь буду знать. спасибо aaarrr