アセンブリ言語プロジェクトをどのように構成しますか？
だから、私は学校に戻ってからMIPSコースを受講しています。そして、最終プロジェクトに着手するところに近づいています。
私は常に、大規模でよく構造化されたプロジェクトの1つでした。多くのサポートツール、プロジェクト内の制御と懸念の十分に分離されたゾーン、広範なテストなどです。残念ながら、私はアセンブリ言語コード用のツールについてはあまり知りません。
地獄、最も基本的には、複数のファイルを作成する方法（またはそれを裏返すために、プロシージャのグループをファイルに分離し、それらの間で相互参照する方法）がわかりません。標準はありますか（ish ）これらのことのための練習？
他の情報がなければ、Cプリプロセッサ（またはm4）：Pを使用してコンポーネントを作成する必要があるのではないかと思います。それ以外に、私がより大きなプロジェクトを構築することをどのように提案しますか？
また、「8スペースのハードタブを使用する」以外の、比較的保守可能/共有可能でクリーンなアセンブリ言語のコードの記述に関するアドバイスも歓迎します。
このトピックについて本を書くことができます。きっと一部は。 。 。
各ツールチェーンには独自の長所、欠点、および癖があるため、答えるのは困難です。私は半ダースの異なる方法で異なるプロジェクトを構造化する必要がありましたが、私が最もよく使用した2つについて触れます。
ほとんどすべての手法で、コンポーネントを適切に分割する必要があります。目標は、各モジュールを1）コードに掘り下げることなく簡単に使用できる明確に定義され文書化されたブラックボックス、および2）後続のプロジェクトでそのまま再利用できるほど一般的なものにすることです。私のプロジェクトはすべて、「math」、「dispatcher」、「timer」モジュールを使用しています。次に、SPI、I2C、SCI、PWMなどのモジュールがある場合があります。ほとんどの場合、この機能の分離はかなり直感的です。
最初の手法は、各モジュールを個別にアセンブルし、それらをすべてオブジェクトライブラリに配置することです（オブジェクト指向プログラミングの「オブジェクト」ではなく、マシンコードの「オブジェクト」）。次に、メインプログラムを作成するとき、ライブラリルーチンを呼び出すだけで、リンカが必要なオブジェクトモジュールを実行可能ファイルに自動的に含めます。
しかし、一部のツールチェーンはオブジェクトライブラリを適切にサポートしないか、作成と維持が面倒です。そのような状況では、メインプログラムの最後に必要な各ソースモジュールを「インクルード」し、アセンブラーが1つのラージオブジェクトモジュールを作成します（これにより、リンカーが簡単になります）。
どちらの場合も、メインプログラムは、ハードウェア定義とマクロ定義の「インクルード」のリストから始まります（私は、可読性と移植性の両方のために、たくさんのマクロを使用しています）。次に、メインコードを追加します。オブジェクトライブラリを使用している場合は、それだけです。ソースライブラリを使用している場合は、必要なソースモジュールの「インクルード」のリストで終わります。
私は続けることができましたが、遅いです。 。 。