私は、ARM\Freescale\PIC マイクロコントローラなど、さまざまなマイクロコントローラ プラットフォームに移植できるアプリケーションを開発するために、C プログラミング言語のプロジェクトに取り組んでいます。現在、このアプリケーションを Linux で開発していますが、上記のプラットフォームに移植する必要があります。
私が知りたいのは、新しいプラットフォームに移植する前に、「コード」とデータメモリのフットプリント\サイズを決定できるツール（オープンソースが望ましい）があるかどうかです。
「Google」で検索しましたが、これまでのところ何も見つかりませんでした。Linuxでも同様です。
あなたからのどんな助けも私を大いに助けます。
-ヴィカス
小さなプログラムの場合、サイズの大部分は、プログラムが依存するライブラリ/DLL によって決まります。ARM/Freescale/Pic を参照しているので、データ サイズが MB 単位ではなくバイト単位で測定されるコンパクトな組み込みアプリケーションを扱っていると思います。
独自のコードの場合、サイズの違いは次のように決定されます。
あなたの場合、PICが最も重要な部分であると予想しています（RAM / ROMの制約のため）。したがって、PC 開発中に PIC コンパイル サイズを適切に監視するだけで十分です。リンカ出力には、監視できる TEXT/DATA/BSS サイズに関する情報が含まれます。
私は一般的に組み込みシステムに取り組んでいます。私の仕事では、データ サイズの多くは設計時にわかっています (つまり、バッファ数 * バッファ サイズ)。コード サイズについては、設計時にサニティ チェックを行うのに役立つさまざまなアーキテクチャの経験則があります。たとえば、いくつかの既存のコード ライブラリのスイートを定義します。これらのライブラリについては、各アーキテクチャのパフォーマンスとサイズの数値がわかっています。このようにして、設計時に期待できる比率を知ることができます。PC プログラムに 1 MB のデータがある場合、8 ビット PIC には収まりません.....
テキスト/コード セグメントのサイズは、最適化レベルとバックエンドによって異なります。GCC は、その情報を生成するように構成できます。
ジェレミーが言ったように、ランタイムはもう少し難しいです。彼の提案に加えて、最も一般的な使用シナリオのコンテキストでプログラムを分析するために、 gcovや gprof を試してみることもできます。この種のインストルメンテーションは、サイズよりも複雑さに重点を置いていますが、少なくとも、どこにメモリ分析を集中すべきかをよりよく知ることができます。
アプリケーションがどれだけのメモリを必要とするかはわかりません。それがどのように使用されるかについていくつかの仮定を立て、さまざまなシナリオでアプリケーションを試す必要があります。
テスト中は、/proc ファイル システムのメモリ使用量統計を監視するか、ps コマンドを使用して同じことを行うことができます。
コンパイラはマップファイルを生成できます/生成します。一般的に言えば、マップ ファイルにはコードとデータ サイズ (または場所の範囲) があります。異なるターゲットの異なるコンパイラ間で違いがある場合があります。また、ここの他の投稿で指摘されているように、提供されたライブラリへの依存関係も全体的なメモリ使用量に影響します。