0

これを参考にして：
CコードによるFLASH使用率の計算

実際の組み立て説明書の計算を確認することにしました。
そのため、私のスクリプトはアセンブリ命令をカウントし、機能有効化コードのアセンブリ リスト ファイルにあります。
例えば

if(TRUE == feature1_enable)
{
    // instruction counting starts here
    doSomething;
    .
    .
    .
    // instruction counting stops here
}

これにより、コードのサイズを把握できる数 x が得られます。

結果をクロスチェックするためにnm、機能コードのオブジェクトファイルに決めましたが、nm は個々のステートメントではなく関数全体のサイズを示します。
そのため、その機能のコード部分を別のファイルにコピーし、その機能を作成し、必要なヘッダーを含め、このファイルをコンパイルするために変数を宣言しました (ローカルはローカルのまま、グローバルはグローバルのままにすることに注意してください)。したがって、新しいファイルは次のようになります。 

#include "header1.h"
#include "header2.h"

global_variables;
void checkSize( void )
{
    local_variables;

    // feature1_enable code
    doSomething;
    .
    .
    .
 }

現在、関数checkSizeには機能有効化コードのみが含まれているため、コンパイル後にnmobj ファイルを使用すると、アセンブリ カウントとほぼ同じ結果が得られるはずです (関数のセットアップで使用される余分なサイズは別として)。しかし、そうではなく、私は大きな違いを受け取りました。(アセンブリ命令の場合は1335バイト、nmobjファイルの場合は1458バイト)。
さらに明確にするために、関数を使用してファイルのアセンブリを作成checkSizeし、元のアセンブリ ファイルと比較しました。関数の追加により余分なものがあることは理解していcheckSizeますが、機能の命令により、コードが同じになることが期待されます（同じコンパイラーの最適化と他のオプションを使用）。
しかし、それらは同じではありませんでした。

ここで問題となるのは、大きな関数内の機能コードのアセンブリ手順と、機能コードだけで他のファイルに移動するときに、なぜこのような違いがあるのか​​ということです。
どちらの場合も、余分なサイズを予測するものはありますか?

4

2 に答える 2

0

最適化はトリッキーです。大きな関数 (および大きなファイル) 内では、コンパイラはより広いコンテキストを持ち、より積極的に最適化する可能性があります。一般的な式を再利用したり、短い形式の分岐を選択したりします (ターゲット アーキテクチャを知らなければ正確に言うのは困難です)。

PS: アセンブリ カウントからバイト カウントにどのように移行するのかよくわかりません。

于 2014-04-17T23:42:29.477 に答える