Блог

У меня есть проект на C, который ранее создавался с помощью цепочки инструментов gnu Codesourcery. Недавно он был преобразован для использования компилятора armcc от Realview, но производительность, которую мы получаем с помощью Realview tools, очень низкая по сравнению с тем, когда он скомпилирован с помощью gnu tools. Не должно ли быть наоборот, т. Е. он должен обеспечивать лучшую производительность при компиляции с помощью инструментов Realview? Чего мне здесь не хватает. Как я могу улучшить производительность с помощью инструментов Realview?

Также я заметил, что если я запускаю двоичный файл, созданный Realview Tools с помощью Lauterbach, он выходит из строя, но если я запускаю его с помощью Realview ICE, он работает нормально.

ОБНОВЛЕНИЕ 1

Командная строка Realview:

armcc -c —diag_style=ide —depend_format=unix_escaped —no_depend_system_headers —no_unaligned_access —c99 —arm_only —debug —gnu —cpu= ARM1136J-S —fpu= SoftVFP —apcs =/nointerwork -O3 -Otime

Командная строка GNU GCC:

arm-none-eabi-gcc -mcpu=arm1136jf-s -mlittle-endian -msoft-float -O3 -Wall

Я использую Realview Tools версии 4.1 и GCC версии 4.4.1

ОБНОВЛЕНИЕ 2

Проблема Лаутербаха решена. Это было вызвано из-за полуохостинга, поскольку SWI с полуохостингом не обрабатывался в среде Lauterbach. Перенастройка библиотеки C, чтобы избежать полухостинга, сделала свое дело, и теперь моя программа успешно работает с Lauterbach, а также с Realview ICE. Но проблема с производительностью остается такой, какая она есть.

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

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

Вы пробовали удалить ‘—no_unaligned_access’? ARM11s обычно может выполнять нерегулируемый доступ (если включен в коде запуска), и принуждение компилятора / библиотеки не выполнять их может замедлять ваш код.

В текущей версии RVCT указано ‘—fpu =SoftVFP’:

В предыдущих выпусках RVCT, если вы указали —fpu =softvfp и процессор с неявным оборудованием VFP, компоновщик выбирал библиотеку, которая реализовывала программные вызовы с плавающей запятой с использованием инструкций VFP. Это больше не так. Если вам требуется это устаревшее поведение, используйте —fpu = softvfp vfp.

Это наводит меня на мысль, что если у вас, возможно, старая версия RVCT, поведение будет заключаться в использовании программной плавающей точки независимо от наличия аппаратной плавающей точки. Хотя в версии GNU msoft-float будет использовать аппаратные инструкции с плавающей запятой, когда доступен FPU.

Итак, какую версию RVCT вы используете?

В любом случае я предлагаю вам удалить --fpu опцию, поскольку компилятор сделает неявный соответствующий выбор на основе выбранной --cpu опции. Вам также необходимо исправить выбор процессора, в вашем параметре RVCT указано --cpu=ARM1136J-S , что это не ARM1136FJ-S, как вы сказали GCC. Это, несомненно, помешает компилятору генерировать инструкции VFP, поскольку вы сказали ему, что у него нет VFP.

Один и тот же исходный код может создавать совершенно разные двоичные файлы из-за таких факторов, как. Разные компиляторы (llvm против gcc, gcc 4 против gcc3 и т.д.). Разные версии одного и того же компилятора. Разные параметры компилятора, если используется один и тот же компилятор. Оптимизация (на любом компиляторе). Скомпилирован для выпуска или отладки (или любых других терминов, которые вы хотите использовать, двоичные файлы совершенно разные). При внедрении вы добавляете усложнение в виде загрузчика или монитора пзу (отладчика) и тому подобных вещей. Затем добавьте к этому инструменты на стороне хоста, которые взаимодействуют с монитором rom или компилируются в debugger. Несмотря на то, что компилятор arm намного лучше, чем gcc, компиляторы arm были заражены предположением, что двоичные файлы всегда будут выполняться поверх их монитора rom. Я хочу помнить, что к тому времени, когда rvct стал их основным компилятором, это предположение было на исходе, но с тех пор я действительно не использовал их инструменты.

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

Включена ли оптимизация компилятора в вашей сборке CodeSourcery, но не в сборке Realview?