いくつかのコメント:
1) 絶対にしない パフォーマンスまたは最適化の制約がそれを保証しない限り、アセンブリは行わないでください。次のメトリックは、アセンブリで屋根を通り抜けます:
- コーディングする時間
- デバッグの時間
- 試してみる時間
- それを文書化する時間
- それをコーディングしたときに何をしていたかを理解する時 (1 年後)
- 間違いの可能性
2) 名前空間のカプセル化と コンパイル時間 の容易さから、C よりも C++ が好みです。 オブジェクト指向の実践。 C では、グローバル変数と名前空間の競合が発生する機会が多すぎます。 (リアルタイム Java は素晴らしいですが、私が理解していることから、その要件は依然としてかなり高いものです)
というか、C++ のサブセット:例外、仮想関数、実行時の型識別、およびほとんどの場合の動的メモリ割り当てを除外します。基本的には、実行時に多くの余分なリソースが必要になるため、コンパイル時に指定されていないものはすべて除外します。それが C++ の「肥大化」です。
TMS320 および MSP430 マイクロコントローラー (それぞれ) には、TI と IAR の両方のコンパイラーを C++ 用に使用しましたが、適切な最適化設定により、C++ に期待されるオーバーヘッドを削減する素晴らしい仕事をします。 (特に、inline を賢明に使用して助けた場合) キーワード)
コードの再利用を促進するコンパイル時の利点のために、テンプレートを使用したこともあります。 8 ビット、16 ビット、および 32 ビットの CRC を処理する単一のソース コード ファイルを作成します。コンパイル時のポリモーフィズムにより、クラスの通常の動作を指定し、それを再利用できますが、その関数の一部をオーバーライドできます。ここでも、適切な最適化設定により、TI コンパイラのオーバーヘッドは非常に低くなりました。
Microchip PIC 用の C++ コンパイラを探していました。私が見つけた唯一の会社は IAR です。 ($$$ は障害でしたが、いつか購入したいと思っています) Microchip C18/C30 コンパイラはかなり優れていますが、C++ ではなく C です。
3) コンパイラの最適化に関する特定の警告:デバッグが非常に困難になる可能性があります。多くの場合、最適化された C/C++ コードをシングルステップで実行することは不可能であり、ウォッチ ウィンドウには、最適化されていないコードに含める必要があると思われるものとは相関関係のない変数が表示されることがあります。 (優れたデバッガーは、特定の変数が存在しないように最適化されているか、メモリ位置ではなくレジスターに最適化されていることを警告します。多くのデバッガーはそうしません。>:(
また、優れたコンパイラでは、#pragmas を使用して関数レベルで最適化を選択できます。私が使用したものでは、ファイル レベルでの最適化しか指定できませんでした。
4) C コードをアセンブリに接続する:通常、これは困難です。最も簡単な方法は、必要な署名を持つスタブ関数を作成することです。 uint16_t foo(uint16_t a, uint32_t b) {return 0; } 、ここで uint16_t =unsigned short、通常はビット数を明示します。次に、それをコンパイルし、それが生成するアセンブリを編集します (コードの開始/終了部分を残すようにしてください)。注意 完了後にレジスタを復元せずにレジスタを破壊しないようにしてください。
非常に何かをしている場合を除き、インライン アセンブリは通常、問題を引き起こす可能性があります。 割り込みの有効化/無効化のように簡単です。
私が最も気に入っているアプローチは、コンパイラの組み込み/「拡張 ASM」構文です。 MicrochipのCコンパイラはGNU Cコンパイラに基づいており、インラインアセンブリのビットをコーディングできる「拡張ASM」を備えていますが、参照しているレジスタ/変数を伝えるための多くのヒントを与えることができ、すべての保存を処理します/アセンブリ コードが C で「適切に動作する」ことを確認するためのレジスタの復元。TMS320 DSP 用の TI のコンパイラはこれらをサポートしていません。いくつかの用途がある組み込み関数の限定されたセットがあります。
アセンブリを使用して、頻繁に実行される制御ループ コードを最適化したり、sin()、cos()、および arctan() を計算したりしました。しかし、それ以外の場合は、アセンブリから離れて、高級言語に固執します.
ほとんどのマイクロコントローラー メーカーは、PC でコードをコンパイルしてマイクロコントローラーに転送できる、ある種のクロス コンパイラーを提供しています。
なぜ C?
C の利点は、将来、コードを他のマイクロコントローラーに簡単に移植できることです。コンピューティングの歴史は、通常、コードがハードウェアの実装よりも長持ちすることを示しています。
2 つ目の利点は、コードをより読みやすく保守しやすくする制御構造 (if、for、while) です。
なぜアセンブリ言語なのか?
手作業で最適化を行うことができます。
評決
この種の質問でよくあることですが、トレードオフは特定の用途に大きく依存します。
多くの場合、C コード内でアセンブリ呼び出しを行うことによって 2 つを混在させることができることに注意してください。そのため、プロジェクトに適したバランスを見つけることができます。
PIC ハードウェア固有
ほとんどの PIC ハードウェアでは GCC のオプションがないようです。一方、コメント投稿者が指摘したように、16 ビット PIC24 および dsPIC33 用の Microchip C30 コンパイラは gcc です。
PIC も SDCC ではまだサポートされていません。
新しい情報:コメントによると、SDCC は PIC を有効にサポートしています。
他にもオープンソースのオプションがいくつかありますが、私はそれらの経験がありません。
最適なオプションは、おそらく C でコーディングすることです。次に、手動で最適化する必要があり、コンパイラよりも優れた作業を行うことができる非常に少数のインスタンスについては、アセンブリを c ファイルにコーディングする必要があります。