関連：
マイクロコントローラー用のコードを書いている場合、アセンブリ言語、C言語、またはその他の高級言語で書いている場合、本当の違いはありますか？Cコードを書いた場合、どのようにコンパイルしますか？
ありがとう
brulak
質問する
29716 次
17 に答える
33
いくつかのコメント：
1）パフォーマンスまたは最適化の制約によって保証されない限り、絶対にアセンブリしないでください。次のメトリックは、アセンブリで屋根を通過します。
- それをコーディングする時間
- それをデバッグする時間
- それをテストする時間
- それを文書化する時間
- それをコーディングしたときに何をしていたかを理解する時間（1年後）
- 間違いを犯す可能性
2）私の好みは、名前空間のカプセル化とコンパイル時のオブジェクト指向プラクティスの促進のために、CではなくC++です。Cには、グローバル変数と名前空間の衝突の機会が多すぎます。（リアルタイムJavaは素晴らしいですが、私が理解していることから、その要件はまだかなり高いです）
むしろC++のサブセット：例外、仮想関数、実行時型の識別、ほとんどの場合動的メモリ割り当てを除外します。通常、実行時に多くの追加リソースが必要になるため、コンパイル時に指定されないままになっているものはすべて除外します。これがC++の「肥大化」です。
私はTIとIARの両方のコンパイラをC++、TMS320およびMSP430マイクロコントローラ（それぞれ）に使用し、適切な最適化設定を使用して、C++に期待されるオーバーヘッドを削減するという素晴らしい仕事をしています。inline（特に、キーワードを慎重に使用して支援する場合）
私は、コンパイル時の利点のいくつかにテンプレートを使用して、コードの再利用を促進しています。たとえば、8ビット、16ビット、および32ビットのCRCを処理する単一のソースコードファイルを作成します。コンパイル時のポリモーフィズムにより、クラスの通常の動作を指定し、それを再利用できますが、その関数の一部をオーバーライドできます。繰り返しになりますが、TIコンパイラは、適切な最適化設定により、オーバーヘッドが非常に低くなっています。
MicrochipPIC用の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コンパイラはGNUCコンパイラに基づいており、インラインアセンブリのビットをコーディングできる「拡張ASM」を備えていますが、参照しているレジスタ/変数を示すためのヒントをたくさん与えることができ、すべての保存を処理します。 /レジスタを復元して、アセンブリコードがCで「うまく機能する」ことを確認します。TMS320DSP用のTIのコンパイラはこれらをサポートしていません。いくつかの用途がある組み込み関数の限られたセットがあります。
アセンブリを使用して、頻繁に実行される制御ループコードを最適化したり、sin（）、cos（）、およびarctan（）を計算したりしました。しかし、そうでなければ、私はアセンブリから離れて、高級言語に固執するでしょう。
于 2009-01-16T23:25:42.520 に答える
21
ほとんどのマイクロコントローラーメーカーは、PCでコードをコンパイルし、それをマイクロコントローラーに転送できる、ある種のクロスコンパイラーを提供しています。
なぜC？
Cの利点は、将来、コードを他のマイクロコントローラーに簡単に移植できることです。コンピューティングの歴史は、コードが通常ハードウェア実装よりも長持ちすることを示しています。
2番目の利点は、コードをより読みやすく、保守しやすくする制御構造（if、for、while）です。
なぜアセンブリ言語なのか？
最適化を手作りすることができます。
評決
この種の質問ではよくあることですが、トレードオフは特定の用途に大きく依存します。
多くの場合、Cコード内でアセンブリ呼び出しを行うことで、この2つを混在させることができるため、プロジェクトに適したバランスを見つけることができます。
PICハードウェアに固有ほとんどのPICハードウェアにはGCCのオプションがないようです。一方、コメント提供者が指摘したように、16ビットPIC24およびdsPIC33用のMicrochipC30コンパイラはgccです。PICもSDCC
ではまだサポートされていません。新しい情報：コメントによると、SDCCはPICを実行可能にサポートしています。
他にもいくつかのオープンソースオプションがありますが、私はそれらの経験がありません。
于 2009-01-16T21:45:31.300 に答える
7
おそらく最良のオプションはCでコーディングすることです。次に、手動で最適化する必要があり、コンパイラよりも優れた仕事をすることができるごくわずかな場合は、アセンブリをcファイルにコーディングする必要があります。
于 2009-01-16T21:53:36.840 に答える
7
アセンブリ コーディングは、PC では過去のものですが、組み込みには非常に関連性があります。
組み込みでのアセンブリの記述は、PC でのアセンブリの記述とは異なります。PC コンパイラは、最適化された命令を生成する点で「人間よりも優れています」。組込みシステムは奇妙なアーキテクチャを持つことが多く、その最適化コンパイラは PC 最適化コンパイラほど成熟していません。
于 2009-02-13T21:06:16.523 に答える
5
マイクロコントローラのアセンブリを記述する際に遭遇した問題の 1 つは、コードのレイアウト方法に細心の注意を払う必要があることです。ジャンプ テーブルがメモリの境界を越えており、コードが非常に奇妙な場所にジャンプすることは、かなり厄介です。C でコーディングすると、コンパイラがそのベースをカバーします。
于 2009-01-16T21:55:30.830 に答える
5
私は間違いなく C を選びます。C の方が高速で、より信頼性の高いソフトウェアを作成できます。アセンブリは提供するものがほとんどなく、まれにしかありません。C では次のことに注意してください。
- PC からでも、既存のプラットフォームからコードを簡単に移植できます。
- 実行速度やコードサイズを犠牲にすることなく、高級言語で開発できます。高品質のコンパイラが利用可能であれば (PIC18 には多くの選択肢があります)、手作りのアセンブリよりも C の方が優れている可能性が高いでしょう。
- コードのデバッグ、テスト、保守がはるかに簡単になります。C はより信頼性の高いコードを生成します。
特にPIC18に関係するもう1つのこと。非直感的な PIC アーキテクチャやメモリ BANK などに対処する必要はありません。
于 2009-01-16T21:59:20.197 に答える
4
私は過去に 8051 用のIAR C コンパイラで良い経験をしました。
私の最近のアプローチは常にこれでした:-
優れた最適化コンパイラを使用して C で記述し、サイズまたは速度に問題がある場合にのみ、アセンブラーで特定の部分を書き直すことを検討してください。
ただし、このアプローチを採用して以来、アセンブラを1行も書く必要はありません...
于 2009-01-16T22:04:23.260 に答える
4
cに行く！
私は大手家電メーカーで働いていました。私がアセンブリを最後に見たのは、1996 年頃、RC5 および RC6 デコードおよび TV チューニング アルゴリズム用のいくつかの小さな割り込みサービス ルーチンでした。その後は常に c と C++ を使用しました (クラスのみを使用し、stl、例外、rtti は使用しませんでした)。私は 8051 用の古い KEIL コンパイラと、greenhills コンパイラ (MIPS) および VxWorks ツールセット (PowerPC ベース) で良い経験をしています。
Roddy が言うように、最初に C で記述し、後でアセンブリで最適化します (必要な場合)。
于 2009-01-21T15:48:16.630 に答える
3
多くの場合、組み立てはより速くなります。デスクトップを使用している場合、コンパイラーは、手作業によるアセンブリが必要になることはめったにないという点で最適化される傾向がありますが、uCの世界では、必要になることがよくあります。また、割り込み処理ルーチンなどを作成する必要がある場合、Cでは作成できないことがよくあります。
コンパイルに関しては、ターゲットのCコンパイラをグーグルで探しましょう。
于 2009-01-16T21:45:13.627 に答える
2
場合を除いて、間違いなく C
プログラムメモリは非常に限られています。アセンブラ コードを手作業で入念に最適化した後、この 1024 バイトのフラッシュにプログラムを収め、残り 0 バイトにしたとします。この場合、どの C コンパイラも役に立ちません。
絶対的なタイミング制御が必要です。割り込みレイテンシが長すぎる場合は、アセンブラに頼る必要があります。
于 2009-02-13T20:58:34.360 に答える
2
最近の問題は、組み込みが 6 ピンと数バイトの RAM を備えた ATTiny から、一部の人々のデスクトップ コンピューターを恥じさせる組み込み OS を実行するマルチコア SBC まで、何でもあり得ることです。
そのため、言語/開発環境の選択では、システムの複雑さと効率性を考慮する必要があります。
最初に - C はどこでも機能し、かなりうまくスケーリングします。上位に行くほど、複雑さを処理するために外部ライブラリなどを呼び出すことになります。
非常に小さなマイクロ (フラッシュ/RAM をバイト単位で測定) の場合は、ASM を使用するのが最適です。kb 範囲に達すると、すべてのバイトをカウントする必要がないため、C またはその他の従来の言語を使用できます。メガバイトを扱えるようになると、RTOS を使用してすべてを処理し、開発時間を短縮する能力と、ますます必要になる可能性の両方が得られます。本格的な OS を実行できるハードウェアを手に入れるまでには、おそらくハードウェアから自分自身を抽象化し、Java などのパッド付きセルにすべてを書き込むだけで、それがどれほど無駄であるか、どのように動作するかについてあまり心配する必要はありません。もう本当のプログラマーではありません... ;)
上記の例外は、ハードウェアから引き出すことができるすべてのパフォーマンスが必要な場合です。その時点で、効率を維持するためにレベルを 1 つまたは 2 つ下げる必要がある場合があります。
于 2012-06-22T18:12:35.090 に答える
1
デバイス固有のペリフェラルに大きく依存するコードを書いていて、使用しているツール チェーンがそれらを効率的に利用するために必要な組み込み関数を提供しない場合 (くだらない Freescale DSP563CC コンパイラなど)、アセンブリを使用します。
それに加えて、アセンブリと高水準言語の使用に関する暗黙のルールは、デスクトップ ソフトウェア開発のルールとほぼ同じだと思います。つまり、コードをクリーンに保ち、保守しやすくし、ホット コードを機械語で最適化します。
于 2009-02-07T04:57:49.100 に答える
1
That is the bottom line if you use C you can hand optimize later, I wouldnt use anything other than C or assembler (no C++, etc).
The key is the microcontroller instruction set if you are using a PIC or even an 8051 I would use assembler only. If it is a compiler friendly isa like arm or avr or msp430 then use C to save some typing but you will probably have some routines in assembler for various reasons. Likewise you probably want to avoid a C library, even newlib can be just too bulky, borrow code or ideas from them but dont just link one in. Oh, back to the question, look at what C compilers are available for the target, again arm and avr you wont have any problems. Likely msp is okay as well. Just because Keil or Iar will SELL you a compiler doesnt mean you should buy it or use it, the output of pay for as well as free compilers can be dreadful. You need to be well versed in the asm anyway and examine the output (you probably have to write a disassembler to do this).
Bottom line (another bottom line), there is no global answer (well avoid anyhthing higher than C is a global answer) it always depends on what the platform is what your resources are what your task is what the performance requirements are what the portability requirements are (if it is truly embedded on a microcontroller much of it is by definition not portable) what compilers, debuggers, jtag, etc are availble, even so far as what host operating system are you developing on can be a big factor.
于 2009-01-22T20:54:59.770 に答える
0
残念なことに、これまでに Forth や Scheme について誰も言及していません。どちらも小規模な環境に適しており、生産性を大幅に向上させることができます。
于 2009-02-09T21:58:07.160 に答える
0
プレーン C またはパスカル、Modula2。ただし、コンパイラが利用できるため、これは C を意味します。
動的な割り当てとプログラムのサイズは通常非常に限られているため、C++ などのエクストラはスタイルの根拠からのみ興味深いものです。
また、アプリがタイトになると、より複雑なランタイムが苦痛になる可能性があります。
アセンブラも有用ですが、それは本当に大量に販売し、ファームウェアが小さいほどチップが小さく安価になり (フラッシュが少なく)、プログラムのサイズが監視可能である場合に限られます (読んでください: そのうちにバグがなくなる可能性はいくらかあります)。 )
于 2009-05-01T21:43:52.193 に答える