Есть плата на AT91RM9200, на ней поднят стек (uIP), операционной системы нет. Программа просто получает поток данных и кладет в SDRAM.

Скомпилировали программу под ИАРом и под gcc в Линухе. Скорость работы программы, скомпиленной под gcc в 3 (три!) раза выше, чем под ИАРом. Стабильность работы стека после gcc выше. В обоих проектах включены кэши.

Это нормально, когда так отличается скорость работы одной и той же проги, скомпиленной разными компилерами? Как "ускорить" код от ИАРа? Пробовал разные оптимизации - не помогает. Что может быть не настроено в ИАРе?...

Простите за любопытство, просто тоже сейчас борюсь с производлительностью AT91RM9200, но на компилятор грешить даже мысли не было (теперь есть). А Вы под отладчиком работаете или нет?

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

Абсурд.
Скорее всего GCC неправильно выполняет какие-то операции и вылетает из процедур не выполняя их до конца. Отсюда и гигантский прирост скорости.
Либо сам счетчик времени врет.
GCC однозначно хуже компилирует чем коммерческие компиляторы, а тем более IAR.
Но разрыв идет на проценты а не в разы.

Это беспредметный разговор - версии GCC и IAR какие? Опции компиляции какие? Режимы ARM/Thumb?
IAR 4.1x имеет довольно много ошибок - в свое время регулярно на них наталкивались. Версии 4.3x значительно лучше, но один раз компилятор тоже "был пойман" на генерации не совсем требуемого кода. Текущий 4.41 вроде пока ни в чем плохом не замечен.
По опыту использования GCC 2.95, 3.1, 3.2 разных сборок под сygwin - некоторые проблемы есть, но все преодолимо, встроенный ассемблер у GCC считаю лучшим.
Очерь понравился MS EVC, но там ассемблер полностью в стиле MASM и много танцев с бубном для получения бинарника (в-основном, EVC заточен для написания приложений под WinCE).
Компилировалось несколько функций объемом 10-100 строк указанными компиляторами в режиме ARM - IAR впереди по компактности и скорости, но общие отличия действительно на уровне процентов, отнюдь не в разы.

Могу дать уточнения по гэцэцэ, по версии IAR Gemm ответит.
GCC 4.2.0, arm-none-eabi, сборка от codesourcery. Оптимизация - O2.
единственное отличие в коде - используются "несколько иные" memcpy и memset - выдрал из ARM'овского порта mplayer'а (IAR не понимает код GAS'а, к сожалению). Правда копирования из памяти в память очень мало.

Измеряем "скорость" одним и тем же сниффером, так что точность есть

P.S. Надо бы еще 3.4.6 и 2.9.5 затестить

А с чего вы взяли, что она не стабильно работающая?


IAR 4.41A. Режим ARM. Оптимизация отключена.


Да нет, вроде ничего не вылетает - корректное TCP соединение, корректные пакеты (смотрим снифером). Пингуется без ошибок. Только ГЦЦшная 0.19мс, а ИАРовская 0.3мс.


Работаем в IAR, отлаживаемся в нем же через JLink. Может и не надо грешить на компиллеры - возможно ошибка в нашем коде.


Есть подозрение, что дата кэш не включился, тк прироста в скорости не обнаружил. Включаю так:
asm("MRC p15, 0, r0, c1, c0, 0");
asm("ORR r0, r0, #0x00000004");
asm("MCR p15, 0, r0, c1, c0, 0");

Еще используем разные memcpy. Та, которая в ИАРовской библиотеке довольно медленная. Переписал свою на асме, но там траблы с выравниванием... Может кто поможет со быстрой стабильной memcpy и memset?

Я для включения дата кэша использую библиотечные функции:
//*----------------------------------------------------------------------------
//* \fn AT91F_EnableDCache
//* \brief Enable D Cache
//*----------------------------------------------------------------------------
void AT91F_EnableDCache(void)
{
unsigned int ctl;

ctl = AT91F_ARM_ReadControl();
ctl |= (1 << 2);
AT91F_ARM_WriteControl(ctl);
}

//*----------------------------------------------------------------------------
//* \fn AT91F_ARM_ReadControl
//* \brief Read Control register
//*----------------------------------------------------------------------------
inline unsigned int AT91F_ARM_ReadControl()
{
register unsigned int ctl;
asm("MRC p15, 0, r0, c1, c0, 0");
return ctl;
}

//*----------------------------------------------------------------------------
//* \fn AT91F_ARM_WriteControl
//* \brief Write Control register
//*----------------------------------------------------------------------------
inline void AT91F_ARM_WriteControl(unsigned int ctl)
{
asm("MCR p15,0,r0,c1,c0,0");
}

Тады ничего сказать не могу - без оптимизации IAR пускать не пробовал.

Хм, а разве на девятых ARM-ах кеш данных без включенного MMU работает? Помнится, там еще прилично кода по инициализации MMU требуется.

Ну это не в три раза и даже не в два.
С отключенной оптимизацией в ИАРе код заметно медленне исполняется.

Пробовал с оптимизациями - то же самое. Это только в пингах такая разница. В нормальном TCP обмене именно в 3 раза. Если не правильно включили дата кэш, то это неправильное включение - под обоими компиллерами.

Вот это: http://research.microsoft.com/invisible/sr.../_memfunc.s.htm
я подрихтовал немного под IAR: Нажмите для просмотра прикрепленного файла

Да, однако, с Ваших-же слов:




Да уж - глянул исходники IAR ( правда IAR 4.20 ) не ожидал такого тупого побайтового копирования увидеть.
Однозначно надо пользовать разумный вариант с пословным копированием.

Хотя в узких местах я традиционно с АРМ работаю с буферами выровненными на слово и размерами пакетов кратными слову. Затраты памяти не слишком велики а с быстродействием полегче.

P.S.
В приложении альтернативный приличный сишный вариант memcpy()

zltigo, читайте это так: при компиляции gcc (как ARM, так и x86) программа работает стабильно. При компиляции IAR'ом - стабильно не работает.

Ну я так примерно и прочитал. И посоветовал сначала добиться работоспособности.

Хорошо, как добиться работоспособности программы при компиляции IAR'ом, если компиляция с помощью gcc для двух платформ (ARM920t, x86) стабильно работает?

Я не умею давать ответов на абстрактные вопросы .

>Я не умею давать ответов на абстрактные вопросы
Зато диагноз "нестабильная программа", сделаный по фотографии сестры жены друга пациента поставлен "верно". Мои поздравления, доктор=)

парни, хватит бычится.
я щас досебу gcc4.3.0-20070622 еще раз попробуем
теперь gcc должен уметь cortex'ы жарить
немного перепилен оптимизатор по сравнению с 4.2
больше в с++ заметно наверно будет.

А фортран вам не нада?

ПРОЧИТАЙТЕ ПЕРВЫЙ ПОСТ СВОЕГО КОЛЛЕГИ я не знаю какого он это написал, но писал это

он а не я. С диагнозами разбирайтесь с ним. Что вы там в четыре руки слепили из того, что было мне не ведомо.
Я написал, то, что написал:

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

>Слушайте, любезный - ПРОЧИТАЙТЕ ПЕРВЫЙ ПОСТ СВОЕГО КОЛЛЕГИ я не знаю какого он это написал, но писал это
Простите за резкость, но я уже написал, что это было неточное выказывание. Не будем ссориться
И спасибо за помощь (с memcpy).

Да дело то не в этом . В коде явно присутствует какая-то небрежность и двусмысленность а уж поведение компилятора дело второе. Кроме того темнить начали. Cначала явно было сказано о нестабильности стека, потом сказано, что нестабильность следует читать, как неработоспособность откомпилированного IAR кода, хотя какая неработоспособность, если опять в заголовке говорилось о меньшей производительности.




И в мыслях не было. Закончили.

Пожалуйса.