アセンブリよりもCを使用する利点と欠点は何ですか？
私は現在、電気通信および電子工学の工学を勉強しており、マイクロプロセッサープログラミングでアセンブラーからCに移行しました。これは良い考えだと思います。アセンブリと比較して、Cの利点と欠点は何ですか？
私が見る長所/短所は次のとおりです。
利点：
- Cの構文は、アセンブラーの構文よりもはるかに学習しやすいと言えます。
- Cは、より複雑なプログラムを作成するために使用する方が簡単です。
- Cの学習は、アセンブラの学習よりも生産性がいくらか高いので、Cの周りにはアセンブラよりも開発が進んでいます。
欠点：
- アセンブラはCよりも低いレベルのプログラミング言語であるため、ハードウェアに直接プログラミングするのに適しています。
- メモリ、割り込み、マイクロレジスタなどで作業することを示唆するはるかに柔軟性があります。
以下は、あなたに役立つかもしれないいくつかのスタックオーバーフローの回答です（これらは、トップレスポンス、受け入れられた回答です）：
利点
https://stackoverflow.com/questions/143561/is-there-a-need-to-use-Assembly-these-days （10,000ユーザーのみ）、または アーカイブ
- アセンブリは、ブートローダーの初期段階で使用されます。スタックのCPUパワーが利用できず、Cコンパイラがスタックに物を保存しようとしないようにするのが難しい場合。それでも、初期化が完了すると、ブートローダーの大部分はCで記述されます。
- アセンブリは、ミューテックスロックプリミティブを記述するために使用されます。 Cコンパイラに必要な場所でメモリバリア命令を発行させることは基本的に不可能です。
- Memset（）やmemcpy（）などのルーチンは、多くの場合、アセンブリで実行されます。たとえば、大きなアンロールループを使用してmemset（）を記述しました。このループは、分岐アドレスを動的に計算して、ループの中央にジャンプして最後の1回の繰り返しを行います。 Cルーチンはより多くのコードを生成し、余分なI $ミスが発生します。同様に、CPU命令セットには、Cコンパイラーが使用しないキャッシュラインロードまたはmemcpy（）を劇的に高速化できるその他の命令が含まれていることがよくあります。
欠点
https://stackoverflow.com/questions/2684364/why-arent-programs-written-in-Assembly-more-often
- ASMは可読性が低く、高級言語と比較して実際に保守することができません。
- また、Cなどの他のより人気のある言語よりもASM開発者がはるかに少ない。
- さらに、高水準言語を使用して新しいASM命令（SSEなど）が利用可能になった場合は、コンパイラーを更新するだけで、古いコードで新しい命令を簡単に利用できます。
例
以下の最後の投稿は、Cよりも高速なアセンブリの例を示すシナリオを概説するスタックオーバーフローの投稿です（同じ機能を実行する場合）。
https://stackoverflow.com/questions/577554/when-is-assembler-faster-than-c
Cは、アセンブリに比べてプログラミングが簡単です。再ハッシュする価値がない明らかな理由があります。
Cは使いやすいため、プログラムをより速く作成できます。一般に、これらのプログラムはデバッグも保守も簡単です。さらに、Cで大規模で複雑なプログラムを管理する方が簡単です。
多くの場合、コンパイラーによって生成されたコードは、手書きのアセンブラーと同じくらい（速度と効率の点で）優れています。
Cはかなり低レベルで、非常に低くしたくはありません。抽象化の層を追加することは、めったに悪いことではありません。
下げる必要がある場合は、アセンブリを使用できます。それ以外の場合は、Cを使用できます。
アセンブリはCコードで記述できますが、Cはアセンブリコードで記述できません。
Cプログラムは、さまざまなマイクロプロセッサアーキテクチャにコンパイルできます。
マイクロプロセッサプログラミングでアセンブラからCに移行しました。これは良いアイデアだと思います
恐れる必要はありません。100％アセンブラで新しいプログラムを開発する人はいません。最近では、Cは最も小さくてくだらない8ビットアーキテクチャでも使用できます。 ただし、いくつかのアセンブラを知っていると、大幅に優れたCプログラマになります。また、アセンブラーで作成する必要があるプログラムには、常にいくつかの小さな詳細があります。
Cの構文は、アセンブラーの構文よりもはるかに学習しやすいと言えます。
はい、確かに構文は簡単です。ただし、C言語全体をすべての迷惑な詳細で学習することは、特定のアセンブラのすべての詳細を学習するよりもはるかに複雑です。 Cははるかに大きく、より広い言語です。しかし、繰り返しになりますが、すべての詳細を学ぶ必要はないかもしれません。
Cは、より複雑なプログラムを作成するために使用する方が簡単です。
実際、Cは、カプセル化やローカルスコープ/ローカル変数などのモジュール式プログラム設計のメカニズムを提供します。また、Cには標準ライブラリと、過去30年間に書かれた膨大なリソースがあります。そして最も重要なことに、Cは移植可能です。
Cの学習は、アセンブラの学習よりも生産性がいくらか高いので、Cの周りにはアセンブラよりも開発が進んでいます。
Cには、事前に作成された機能、ライブラリ、リソースが豊富に用意されているため、ホイールの再発明が少なくなります。しかし、それとは別に、あなたの発言は主観的なものです。それは個人的な好みの問題だと思います。
たとえば、私は経験豊富なCプログラマーで、たまにC++をプログラミングしています。 C言語を知っているだけでなく、その言語も知らないため、C++での生産性ははるかに低くなります。しかし、そう感じたからといって、必ずしもCでのプログラミングがC++でのプログラミングよりも生産的であるとは限りません。経験豊富なC++プログラマーは、確かに反対の意見を持っているでしょう。
「生産的」には多くの側面があります。非常に重要な側面は、メンテナンス時間、特にメンテナンスによって引き起こされるバグを修正するのにかかる時間です。 Cは、アセンブラよりも保守がはるかに簡単です。
アセンブラはCよりも低レベルのプログラミング言語であるため、ハードウェアに直接プログラミングするのに適しています。
ハードウェアプログラミングはどちらの言語でも直接行うことができます。 Cで実行できない唯一のことは、CPUコア自体のスタックポインターや条件レジスタなどにアクセスすることです。したがって、ハードウェアプログラミングによって独自のCPUと通信する場合、はい、アセンブラはCよりも少し多くのことを許可します。外部ハードウェアにアクセスすることを意味する場合、アセンブラはCよりも利点がありません。特定の外部デバイス用の汎用アセンブラコード（汎用Cコードよりも）。
メモリ、割り込み、マイクロレジスタなどで作業することを示唆するはるかに柔軟性があります。
これは正しくありません。 Cでは、interruptキーワードなどのコンパイラ固有のCコードに依存する必要があるかもしれませんが、これらすべてを行うこともできます。
最後に、Cに重点を置いて、MCUをプログラムするために両方の言語を知る必要があります。
埋め込む方法に応じて、Cは大きくて遅いプログラムを生成します。これにより、製品のその部分のコストが著しく増加します。それは、製品全体の海の低下かもしれませんし、製品を根本的に変えるかもしれません。はい、ソフトウェアの開発と保守の労力はより安価であると言う人もいるかもしれませんが、深く埋め込まれていて、低電力で小さくて安価な部品を目指しているのであれば、多くのコードについて話しているのではありません。そのコードは主にそのベンダーまたはその特定のチップに固有であるため、Cでの移植性の利点はゼロであり、とにかく各ターゲットを書き直す必要があります。 ARMからのcortex-mシリーズにより、Cがasmと競合できるようになりました。組み込み製品でCまたは他の高レベルの言語を使用していなかったわけではありませんが、彼らは費用をかけてそれをやった。
CとASMの議論は、専門的には常にCで記述し、正当化できる場所でASMを使用することで終わります。そして、あなたはそれを正当化することができます。組み込みの世界では、パフォーマンスとサイズがあります。
このディスカッションにはターゲットを含める必要があります。多くの人がCをMicrochipで使用しましたが（mipsであるpic32ではなく古いpics）、コンパイラーにとっては恐ろしい命令セットであり、非常に教育的で興味深い命令セットですが、コンパイラーは不親切です。 msp430、avr、arm、thumb、mipsなど、すべてコンパイラに適しています。 8051も悪い。
言語よりもツール。特に、コードの開発と管理について心配することが論拠であるような場合には、今日そして明日そこに存在するためのツールが必要です。 1つのグループによって管理される単一のgcc modを含めて、単一のソースツールを持つことは、ビジネスの観点からは危険です。複数のアセンブラを見つける可能性が高く、そのチームに所属するに値する人なら誰でも、週末にアセンブラを組み立てることができます（作成するアセンブリがghee whizディレクティブでなく、マクロが幸せでない限り）。 asmとCの両方で、10年前のLinuxディストリビューションを実行するために仮想マシンを使用することを意味する場合でも、オープンソースツール（または独自の社内ツール）を使用する必要があります。製品の寿命。
結論として、Cとasmの両方を使用/学習/教育し、Cから始めて、正当化できるasmを使用します。
アセンブリの場合、コードの保守性とパフォーマンスの間には避けられない妥協点があります。読みやすく保守しやすいアセンブリを記述したり、高度に最適化されたコードを記述したりできます。しかし、両方を行うことはできません。
Cの場合、妥協点は完全に消えるわけではありませんが、それほど目立たなくなります。適度に最適化された、読みやすく保守しやすいCを作成できます。
優れたアセンブリ言語プログラマは、ほとんどいつでもコンパイラを打ち負かすことができますが、ほとんどの場合、代わりに意図的に読みやすく保守しやすいコードを書くことを選択します。したがって、優れたアセンブリ言語プログラマは、ほとんどの場合コンパイラに打ち負かされます。
スマートな方法は、アセンブリとCの両方を使用することです（アセンブリのみまたはCのみの代わりに）。優れたアセンブリ言語プログラマが保守性のある/遅いコードを書くことを選択したであろうコードの部分にはCを使用し、残りの部分にはAssemblyを使用します（「高度に最適化され、保守が難しい」が実際に正当化される場合）。