この短い記事は、Samsungが「何が必要かをよく知っている」という考えに我慢したくないSamsung Badaモバイルプラットフォームのアプリケーションの開発者、およびGNU Compiler Collectionを使用してARMのコードを構築する関係者を対象としています。
Target-ReleaseまたはTarget-Debugでプロジェクトをビルドすると、ログが次のように書き込まれることに多くの人が気づいたと思います
arm-samsung-nucleuseabi-g++ -DSHP -I"D:/Work/Bada/1.2.1/include" -I"???/inc" -Os -Wall -E -fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork -o"???/Target-Release/dirent.i" "../src/bada/dirent.cpp"
'Finished building: ../src/bada/dirent.cpp'
アセンブリフラグ、つまり の一部
-Os -Wall -E -fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork
プロジェクトのプロパティに独自のフラグを追加できますが、これは悪いことです。これらはすべて左側に帰属し、
-fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork
通常は静的で、常に右側に追加されます。IDEでは、それについての言葉はありません。 さらに、「-Os」オプションはプロジェクトプロパティで不変です（「灰色」）。 何が起こっているのか説明します。
- -Os-オブジェクトのサイズを増加させない最適化のみが適用されます
- -fpic-位置独立コード再配置モデルによるアセンブリ。 Bada Toolchainのアセンブリのすべての結果（いわゆるアーティファクト）は動的ライブラリ（共有ライブラリ）であることを思い出してください。 このニュースは誰向けですか-典型的なコード<ProjectName> Entry.cppもご覧ください。
_EXPORT_ int OspMain （ int argc、 char * pArgv [ ] ）
_EXPORT_の定義にスキップすると、（FBaseConfig.h）が表示されます。
#if defined（_WIN32）// MSコンパイラとMinGW GCC <br/>
＃_EXPORT_ __declspec（dllexport）の定義 <br/>
#elif defined（__ GNUG__）// GCC <br/>
＃define _EXPORT_ __attribute __（（visibility（ "default"））） <br/>
#elif defined（__ ARMCC_VERSION）// ARMコンパイラ（RVCT 3.1） <br/>
＃_EXPORT_ <br/>を定義
#else <br/>
＃_EXPORT_ <br/>を定義
#endif
私の目的はこれだけですか？ したがって、PICは信頼性がありますが、若干遅いモデルです。 さらに、Badaではすべてのアプリケーションがサンドボックス内にあり、共通のダイナミックライブラリを共有できないため、PICを使用する意味はありません。 残念ながら、このフラグがなければ、プロジェクトアセンブリはダイナミックライブラリをリンクする段階で落ちる可能性があります（そして、私はチェックしました）。 ld （arm-samsung-nucleusabi-ldが実行）はリンクできない場合があるため、サムスンの韓国人はこのフラグを内側に縫い付けました。 GCC 4.xの欠陥のため、コンパイラはbinutilsが好まないR_ARM_MOVW_ABS_NCを再ロックします。 さて、アセンブリがLLVMを使用していた場合...私は何かに関与しました。 一般的に、この状況では、-fPICは不可欠です。 - -mfpu = vfpv3-浮動小数点モデルのバージョン
- -mfloat-abi = hard-浮動小数点アイロン操作のみを使用します。 一般的に、コードにARM FPUにない浮動小数点関数の呼び出しが含まれている場合、コンパイルは失敗しますが、これはほとんどありません。
- -mlittle-endian-理由は明らかではありません。 Cortex-A8についてです。したがって、彼はリトルエンディアンであることが知られています。
- -mthumb-interwork- ARMコードとThumbコードの両方を1つの実行可能ファイルに安全に結合する機能。 ご存知のように、ARMアーキテクチャには16ビットThumb命令のセットが含まれているため、とりわけ優れています。 ポイントは、1つのARM命令が32ビットを使用し、Thumb命令が半分のビットを使用することです。 合計で、結果のコードのサイズを半分（理論的に）削減しました。 実際には-ほぼ2回（追加の操作やその他の形式のオーバーヘッドがあります）。 デフォルトでは、アセンブリはARMコードで行われ、Thumbコードでは、プログラムはまったくコンパイルされない可能性があります（たとえば、「最適化された」アセンブラの挿入が好きですか？コンパイラはわいせつでカバーします）、Samsung WaveファームウェアにはThumbコードがあり、韓国人は安全です。 マイナスとして、追加のペアリング指示により、オブジェクト所有者のサイズがわずかに増加しています。
そのため、次の不正が見られます。
- 実行可能ファイルのサイズの最適化は常に望ましいとは限りません（特にシステム、アルゴリズムの場合）！
- もちろん、mfpu = vfpv3は良好ですが、皮質にはNEONがあります
- プロジェクトは、「ダム」Thumbの代わりにARM命令のセットにコンパイルされます
サムスンの位置は理解できます：遊び心のある手、言及された旗を変えることは、プロジェクトのアセンブリを簡単に台無しにします、そして、彼らは本当に韓国のサポートチームに彼らが本当であると証明できます。 しかし、私たちは何をしているかを知っています。 状況を修正できますか？ はい！
ファイル<Bada SDKのルート> /IDE/buildoptions.xmlに注目しましょう。 IDEを介して通常の人間の方法で変更できないフラグのセットが含まれているだけです。 このファイルを編集したら、必ずEclipseを再起動してください。 完全に引き離します：
<comp>-fpic -mthumb -fshort-wchar -O2 -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard</comp>
-mthumbは Thumbコードをコンパイルすることを強制し、 -O2は通常プログラムを最適化し、今では意味のない-mthumb-interworkが削除されます。 多くのプログラムでこのようなフラグを使用して動作を確認しましたが、すべて正常に機能しています。 次の2つのことに注意してください。
- -mfpu = neonを実行すると、デバイスで起動したときにアプリケーションがクラッシュします。 なぜ-はっきりしない、私はこの瞬間を探っている。 テストボードの仕事で、私は何度もやりました。
- -mthumb-interworkは、いくつかの特別な場合に必要になる場合があります。 私はテストを実行しました-それなしですべてがうまく動作します。
Bada 1.1デバイス（52xのような予算の波のライン）のアセンブリフラグには何が表示されますか？
<comp>-fpic -fshort-wchar -mcpu=arm9 -mfloat-abi=soft -mlittle-endian -mthumb-interwork</comp>
まず、Samsungの公式Webサイトの仕様にまったく記述されていない貧弱なプロセッサと-mfloat-abi = softがあります 。これは、FPUがまったく使用されていないためです。 arm.comのARM9仕様では、FPUは実際にオプションであると記載されています。 私はこれらのデバイスを持っていません。このフラグを-mfloat-abi = softfpまたは-mfloat-abi = hardに変更することをお勧めするかどうかはわかりません 。 しかし、再び-mthumbを追加することをお勧めします 。
多くの浮動小数点計算を行う人にアドバイスをします： -funsafe-math-optimizations -ffast-mathフラグを（通常の方法で）プロジェクトフラグに追加します。 後悔することはありません。
最後に、 ARM固有のすべてのGCCフラグへのリンク 。
開発に成功していただきありがとうございます！