3

Codesourcery の gnu ツール チェーンを使用して以前にビルドされた C プロジェクトがあります。最近、Realview の armcc コンパイラを使用するように変換されましたが、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 -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 で正常に動作するようになりました。しかし、パフォーマンスの問題はそのままです。

4

5 に答える 5

4

最適化がオンになっており、一部の環境ではクラッシュするため、コードが未定義の動作またはその他の潜在的なエラーを使用している可能性があります。このような動作は、最適化によって変更されるか、完全に壊れることさえあります。

最適化せずに両方のツール チェーンを試し、警告レベルが高く設定されていることを確認し、それらをすべて修正することをお勧めします。GCC は、エラー チェックにおいて armcc よりもはるかに優れているため、妥当な静的解析チェックです。コードがクリーンにビルドされていれば、動作する可能性が高くなり、オプティマイザが処理しやすくなる可能性があります。

于 2011-04-22T17:10:02.763 に答える
3

'--no_unaligned_access'を削除してみましたか？ARM11は通常、アラインされていないアクセスを実行でき（スタートアップコードで有効になっている場合）、コンパイラ/ライブラリにアクセスを強制しないと、コードの速度が低下する可能性があります。

于 2012-10-30T13:37:29.810 に答える
2

RVCTの現在のバージョンでは、「--fpu=SoftVFP」が次のように指定されています。

RVCT の以前のリリースでは、 --fpu=softvfp と暗黙的な VFP ハードウェアを備えた CPU を指定した場合、リンカは VFP 命令を使用してソフトウェア浮動小数点呼び出しを実装するライブラリを選択しました。これはもはや当てはまりません。この従来の動作が必要な場合は、--fpu=softvfp+vfp を使用してください。

これは、古いバージョンの RVCT を使用している場合、ハードウェア浮動小数点の有無に関係なく、ソフトウェア浮動小数点を使用する動作になることを示唆しています。GNU バージョンでは -msoft-float は、FPU が利用可能な場合にハードウェア浮動小数点命令を使用します。

どのバージョンの RVCT を使用していますか?

--fpuいずれにせよ、コンパイラは選択されたオプションに基づいて暗黙的に適切な選択を行うため、オプションを削除することをお勧めします--cpu。CPUの選択も修正する必要があります.RVCTオプションは、--cpu=ARM1136J-SGCCに言ったようにARM1136FJ-Sではないと言っています。これにより、VFP がないことをコンパイラに伝えたので、コンパイラが VFP 命令を生成できなくなることは間違いありません。

于 2011-04-25T17:46:39.033 に答える
1

などの要因により、同じソース コードでも劇的に異なるバイナリが生成される可能性があります。異なるコンパイラ (llvm と gcc、gcc 4 と gcc3 など)。同じコンパイラの異なるバージョン。同じコンパイラの場合、異なるコンパイラ オプション。最適化 (どちらのコンパイラでも)。リリースまたはデバッグ用にコンパイルされています (または使用したい用語が何であれ、バイナリはまったく異なります)。組み込みになると、複雑なブートローダーや ROM モニター (デバッガー) などを追加します。次に、ROM モニターと通信するか、デバッガーでコンパイルするホスト側ツールを追加します。gcc よりもはるかに優れたコンパイラであるにもかかわらず、ARM コンパイラは、バイナリが常に ROM モニタ上で実行されるという前提に感染していました。覚えておきたいのは、rvct が彼らの主要なコンパイラーになるまでに、その仮定は消えつつありました。

肝心なのは、バイナリ間の違いに影響を与える可能性のあるいくつかの主要な要因があり、異なるエクスペリエンスにつながる可能性があるということです。同じパフォーマンスまたは結果が得られると仮定することは悪い仮定であり、結果が異なることが予想されます。同様に、同じ環境内で、劇的に異なるパフォーマンス結果をもたらすバイナリを作成できるはずです。すべて同じソースコードから。

于 2011-04-24T21:27:34.770 に答える
0

CodeSourcery ビルドではコンパイラの最適化をオンにしていますが、Realview ビルドではオンにしていませんか?

于 2011-04-22T13:37:33.317 に答える