Почему мой код работает плохо при построении с помощью инструментов Realview, но лучше с Codesourcery?
У меня есть проект C, который ранее создавался с помощью цепочки инструментов Codesourcery gnu. Недавно он был преобразован для использования компилятора armview Realview, но производительность, которую мы получаем с помощью инструментов Realview, очень низкая по сравнению с тем, когда он компилируется с помощью инструментов gnu. Разве это не должен быть противоположный случай, то есть он должен давать лучшую производительность при компиляции с инструментами 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 -Время
Командная строка GNU GCC:
arm-none-eabi-gcc -mcpu = arm1136jf-s -ml-endian -msoft-float -O3 -Wall
Я использую Realview Tools версии 4.1 и GCC версии 4.4.1
ОБНОВЛЕНИЕ 2
Проблема Лаутербаха была решена. Это было вызвано из-за Semihosting, так как SWI-полухостинг не обрабатывался в среде Lauterbach. Ретаргетинг библиотеки C, чтобы избежать Semihosting, сделал свое дело, и теперь моя программа успешно работает с Lauterbach и Realview ICE. Но проблема производительности в том, как она есть.
5 ответов
Поскольку у вас есть оптимизация, а в некоторых средах она дает сбой, возможно, ваш код использует неопределенное поведение или другую скрытую ошибку. Такое поведение может измениться с оптимизацией, или даже полностью сломаться.
Я предлагаю вам попробовать обе цепочки инструментов без оптимизации, и убедиться, что уровень предупреждения установлен на высоком уровне, и исправить их все. GCC намного лучше, чем armcc при проверке ошибок, поэтому это разумная проверка статического анализа. Если код строится чисто, он с большей вероятностью сработает, и оптимизатору будет легче его обрабатывать.
Вы пытались удалить '--no_unaligned_access'? ARM11, как правило, могут осуществлять доступ без выравнивания (если он включен в коде запуска), и принуждение компилятора / библиотеки не выполнять их может замедлять ваш код.
Текущая версия 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 монитора (отладчика) и тому подобное. Затем добавьте к этому инструменты на стороне хоста, которые общаются с монитором или компилируются в отладчике. Несмотря на то, что компиляторы arm были гораздо лучше, чем gcc, они были заражены предположением, что двоичные файлы всегда будут запускаться поверх их монитора. Я хочу помнить, что к тому времени, когда rvct стал их основным компилятором, это предположение было на исходе, но с тех пор я действительно не использовал их инструменты.
Суть в том, что есть несколько основных факторов, которые могут повлиять на различия между двоичными файлами, которые могут и будут приводить к другому опыту. Предполагая, что вы получите ту же производительность или результаты, это неверное предположение, ожидаемо, что результаты будут отличаться. Аналогично, в одной и той же среде вы должны иметь возможность создавать двоичные файлы, которые дают резко отличающиеся результаты производительности. Все из того же исходного кода.
У вас включены оптимизации компилятора в вашей сборке CodeSourcery, но не в сборке Realview?