なぜプログラムはアセンブリでより頻繁に記述されないのですか？[閉まっている]

アセンブリプログラミングはCなどの高レベルの言語よりも時間がかかり、プログラミングが難しいというのが主流の意見のようです。したがって、これらの理由により、高レベルの言語で記述する方が推奨または想定されます。移植性が向上するという理由から。

最近、私はx86アセンブリで作成しており、おそらく移植性を除いて、これらの理由はおそらく本当ではないことに気づきました。おそらく、それは親しみやすさと、アセンブリを適切に作成する方法を知っていることの問題です。また、アセンブリでのプログラミングは、HLLでのプログラミングとはかなり異なることに気づきました。おそらく、優れた経験豊富なアセンブリプログラマは、経験豊富なCプログラマがCで書くのと同じくらい簡単かつ迅速にプログラムを書くことができます。

おそらくそれは、アセンブリプログラミングがHLLとはかなり異なり、異なる考え方、方法、方法を必要とするためです。

移植性が問題でない場合、実際には、CはNASMなどの優れたアセンブラに対して何を持っているでしょうか。

編集： 指摘しておきます。アセンブリで記述する場合は、命令コードだけで記述する必要はありません。マクロとプロシージャ、および独自の規則を使用して、さまざまな抽象化を行い、プログラムをよりモジュール化し、保守しやすく、読みやすくすることができます。ここから、優れたアセンブリの作成方法に慣れることができます。

ASMは、持っている貧しい読みやすさをして本当に保守性ではない、より高いレベルの言語に比べて。

また、Cなどの他のより人気のある言語よりもASM開発者がはるかに少ない。

さらに、高級言語を使用して新しいASM命令（SSEなど）が利用可能になった場合は、コンパイラを更新するだけで、古いコードで新しい命令を簡単に利用できます。

次のCPUに2倍のレジスタがある場合はどうなりますか？

この質問の逆は、コンパイラにはどのような機能があるのでしょうか。

ASMをできる限り上手に最適化できる/したい/すべきではないでしょうかgcc -O3。

地獄®、私はコンパイラです。

この文章を読んでいる間、私は数千行のコードをスキャンしました。私は、何年にもわたって費やす膨大な量の学術研究に基づいて、何百もの異なる最適化手法を使用して、あなたの単一の行を最適化する数百万の可能性を閲覧しました。3行のループを数千の命令に変換して高速化するだけで、少し気になることもありません。最適化の長い期間に行くことや、最も汚いトリックをすることに恥はありません。そして、もしあなたが私に望まないなら、たぶん1日か2日、私はあなたの好きなように振る舞います。コードの1行も変更することなく、いつでも使用しているメソッドを変換できます。あなたのコードがアセンブリでどのように見えるかを示すことさえできます、必要に応じて、さまざまなプロセッサアーキテクチャ、さまざまなオペレーティングシステム、およびさまざまなアセンブリ規約で使用します。はい、すべて数秒で。なぜなら、私はできるからです。そして、あなたは知っています、あなたはできません。

PSああ、ところで、あなたが書いたコードの半分を使用していませんでした。私はあなたに好意をしてそれを捨てました。

6502、Z80、6809、8086チップ用のアセンブラのシェッドロードを作成しました。私が取り組んでいるプラットフォームでCコンパイラが利用可能になるとすぐにそうするのをやめ、すぐに少なくとも10倍以上の生産性が向上しました。ほとんどの優れたプログラマは、合理的な理由で使用するツールを使用しています。

アセンブリ言語でのプログラミングは大好きですが、高級言語と同じことを行うにはより多くのコードが必要であり、コード行とバグの間には直接的な相関関係があります。（これは数十年前のThe Mythical Man-Monthで説明されていました。）

Cを「ハイレベルアセンブリ」と考えることは可能ですが、その上にいくつかの手順を実行すると、別の世界にいることになります。C＃では、これを書くことについて二度と考えません：

foreach (string s in listOfStrings) { /* do stuff */ }

これは、数十、おそらく数百行のアセンブリコードであり、それを実装する各プログラマは異なるアプローチをとり、次に来る人はそれを理解する必要があります。したがって、多くの人がそうであるように、プログラムが主に他の人が読むために書かれていると信じる場合、アセンブリは一般的なHLLよりも読みにくくなります。

編集：一般的なタスクに使用されるコードの個人用ライブラリと、Cのような制御構造を実装するためのマクロを蓄積しました。しかし、GUIが標準になった90年代に壁にぶつかりました。日常的なものに費やされた時間が多すぎました。

ASMが不可欠であった最後のタスクは、数年前、マルウェアと戦うためのコードを作成することでした。ユーザーインターフェースがないので、膨らむことなくすべて楽しい部分でした。

他の人の読みやすさ、保守性、コードの短縮、したがってバグの減少、およびはるかに簡単であるという回答に加えて、さらに理由を追加します。

プログラム速度。

はい、アセンブリでは、コードを手動で調整して、最後のすべてのサイクルを利用し、物理的に可能な限り速くすることができます。しかし、誰が時間を持っていますか？完全に愚かではないCプログラムを作成する場合、コンパイラーは最適化の非常に優れた仕事をします。おそらく、手作業で行う最適化の少なくとも95％を行うことで、それを追跡することを心配する必要はありません。ここには間違いなく90/10種類のルールがあり、最後の5％の最適化は最終的に95％の時間を費やします。なぜわざわざ？

平均的なプロダクションプログラムで約10万行のコードがあり、各行が約8〜12個のアセンブラー命令である場合、100万のアセンブラー命令になります。

これをすべて手作業でまともな速度で書くことができたとしても（コードの8倍以上のコードを書く必要があることを思い出してください）、機能の一部を変更したい場合はどうなりますか？これらの100万の指示から数週間前に書いたものを理解することは悪夢です！モジュールも、クラスも、オブジェクト指向設計も、フレームワークも、何もありません。そして、最も単純なものでさえも作成しなければならない類似のコードの量は、せいぜい困難なものです。

また、高級言語と同じくらいコードを最適化することはできません。たとえば、コードだけでなく意図を記述するためにCが非常に多くの最適化を実行する場合、アセンブラーではコードを記述するだけで、アセンブラーは実際にはコードに注目に値する最適化を実行できません。あなたが書くものはあなたが得るものであり、私を信頼します、あなたがそれを書いているときにあなたがパッチしてパッチを当てる100万の命令を確実に最適化することはできません。

ええと、私は「昔は」多くのアセンブリを作成してきましたが、高級言語でプログラムを作成すると、生産性が大幅に向上することを保証できます。

アセンブラ能力の合理的なレベルでは、その多くのアセンブラを記述する必要はありませそんなにので、あなたは、システムレベルまたは組み込みプログラミングの任意の並べ替えで働く場合は特に、便利なスキルですが、時にはそれはボックスが何であるかを理解することが重要ですので、実際にやって。アセンブラの概念と問題についての低レベルの理解がない場合、これは非常に難しい場合があります。

ただし、実際にアセンブラーで多くのコードを書くことに関しては、それがあまり行われないいくつかの理由があります。

• （ほとんど）必要はありません。非常に初期のシステム初期化や、C関数またはマクロに隠されたいくつかのアセンブラーフラグメントなどを除いて、アセンブラーで一度記述された可能性のあるすべての非常に低レベルのコードは、問題なくCまたはC ++で記述できます。

• 高水準言語（CおよびC ++でさえ）のコードは、機能をはるかに少ない行に凝縮し、バグの数がソースコードの行数と相関することを示すかなりの研究があります。つまり、アセンブラとCで解決された同じ問題は、長いため、アセンブラでより多くのバグが発生します。同じ議論が、Perl、Pythonなどの高レベル言語への移行の動機となっています。

• アセンブラーで作成すると、詳細なメモリレイアウト、命令の選択、アルゴリズムの選択、スタック管理などから、問題のすべての側面に対処する必要があります。高レベルの言語では、これらすべてが取り除かれます。そのため、 LOCの条件。

基本的に、上記のすべては、Cまたは他の言語と比較して、アセンブラーで利用できる抽象化のレベルに関連しています。アセンブラは、独自の抽象化をすべて作成し、独自の自己規律を通じてそれらを維持することを強制します。Cのような中級言語、特により高水準の言語は、そのままで抽象化を提供します。新しいものを比較的簡単に作成する機能。

組み込みプログラミングの世界で彼の時間のほとんどを費やしている開発者として、私はアセンブリが死んだ/時代遅れの言語からはほど遠いと主張します。上位レベルの言語では正確または効率的に表現できない場合があるコーディング（たとえば、ドライバーなど）の金属に近いレベルがあります。ハードウェアインターフェイスルーチンのほぼすべてをアセンブラで記述します。

つまり、このアセンブリコードは、Cコードから呼び出せるようにラップされ、ライブラリのように扱われます。多くの理由により、プログラム全体をアセンブリで記述していません。まず第一に、移植性です。私たちのコードベースは、異なるアーキテクチャを使用するいくつかの製品で使用されており、それらの間で共有できるコードの量を最大化したいと考えています。2つ目は、開発者の親しみやすさです。簡単に言えば、学校は以前のようにアセンブリを教えていません。開発者はアセンブリよりもCの方がはるかに生産的です。また、アセンブリ言語コードでは利用できない、さまざまな「エクストラ」（ライブラリ、デバッガ、静的分析ツールなど）をCコードで利用できます。純粋なアセンブリプログラムを作成する場合でも、いくつかの重要なハードウェアライブラリはCライブラリとしてしか利用できないため、これはできません。ある意味で、それは鶏/卵の問題です。利用できるライブラリや開発/デバッグツールが少ないため、人々はアセンブリから遠ざかっていますが、ライブラリを作成する労力を保証するのに十分な人々がアセンブリを使用していないため、libs /ツールは存在しません。

結局のところ、ほとんどすべての言語に対応する時間と場所があります。人々は自分たちが最も慣れ親しんでいるものを使っています。おそらく、プログラマーのレパートリーにはアセンブリの場所が常に存在しますが、ほとんどのプログラマーは、はるかに少ない時間でほぼ同じくらい効率的な高水準言語でコードを記述できることに気付くでしょう。

アセンブリで記述する場合は、命令コードだけで記述する必要はありません。マクロとプロシージャ、および独自の規則を使用して、さまざまな抽象化を行い、プログラムをよりモジュール化し、保守しやすく、読みやすくすることができます。

つまり、基本的に言っているのは、高度なアセンブラを上手に使用すると、ASMコードをC（またはとにかく独自の発明の別の低レベルの言語）にますます近づけることができるということです。 Cプログラマーと同じくらい生産的です。

それはあなたの質問に答えますか？;-)

私はこれをぼんやりとは言いません。私はまさにそのようなアセンブラーとシステムを使ってプログラムしました。さらに良いことに、アセンブラは仮想プロセッサをターゲットにすることができ、別のトランスレータがターゲットプラットフォーム用にアセンブラの出力をコンパイルしました。LLVMのIFで発生するのとほぼ同じですが、初期の形式では、約10年前の日付です。したがって、移植性に加えて、効率のために必要な特定のターゲットアセンブラーのルーチンを作成する機能がありました。

そのアセンブラーを使用して書くことはCとほぼ同じくらい生産的であり、GCC-3（これは私が関わっていた頃でした）と比較すると、アセンブラー/トランスレーターはほぼ同じくらい高速で通常は小さいコードを生成しました。サイズは本当に重要であり、会社にはプログラマーがほとんどいなかったため、有用なことをする前に、新入社員に新しい言語を教える用意がありました。また、アセンブラーを知らない人（顧客など）がCを記述し、同じ呼び出し規約を使用して同じ仮想プロセッサ用にコンパイルできるなどのバックアップがありました。したがって、それは限界的な勝利のように感じました。

それは、アセンブラー技術、ライブラリーなどを開発するために、何年にもわたる作業でした。確かに、その多くが移植性のあるものになりました。もしそれが1つのアーキテクチャしか対象としていなかった場合は、すべてを歌ってすべてを踊るアセンブラの方がはるかに簡単だったでしょう。

要約すると、あなたはCが好きではないかもしれませんが、Cを使用する努力がより良いものを思いつく努力よりも大きいということではありません。

アセンブリは、異なるマイクロプロセッサ間では移植できません。

私たちがトイレの外に出ないのと同じ理由、またはラテン語やアラム語を話さないのはなぜですか。

テクノロジーが登場し、物事をより簡単に、よりアクセスしやすくします。

編集-人を不快にするのをやめるために、私は特定の言葉を削除しました。

どうして？シンプル。

これを比較：

        for (var i = 1; i <= 100; i++)
        {
            if (i % 3 == 0)
                Console.Write("Fizz");
            if (i % 5 == 0)
                Console.Write("Buzz");
            if (i % 3 != 0 && i % 5 != 0)
                Console.Write(i);
            Console.WriteLine();
        }

と

.locals init (
    [0] int32 i)
L_0000: ldc.i4.1 
L_0001: stloc.0 
L_0002: br.s L_003b
L_0004: ldloc.0 
L_0005: ldc.i4.3 
L_0006: rem 
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0 
L_0014: ldc.i4.5 
L_0015: rem 
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0 
L_0023: ldc.i4.3 
L_0024: rem 
L_0025: brfalse.s L_0032
L_0027: ldloc.0 
L_0028: ldc.i4.5 
L_0029: rem 
L_002a: brfalse.s L_0032
L_002c: ldloc.0 
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0 
L_0038: ldc.i4.1 
L_0039: add 
L_003a: stloc.0 
L_003b: ldloc.0 
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret 

それらは機能的には同じです。2つ目はアセンブラーでもありませんが、.NET IL（Javaのバイトコードに類似した中間言語）です。2番目のコンパイルは、ILをネイティブコード（つまり、ほぼアセンブラー）に変換し、より不可解なものにします。

x86（_64）でもASMは、コンパイラーが最適化するのが難しい命令を利用して多くを得る場合には理にかなっていると思います。たとえば、x264はエンコードに多くのasmを使用しており、速度の向上は非常に大きなものです。

理由はたくさんあると思いますが、考えられる2つの簡単な理由は

1. アセンブリコードは間違いなく読むのが難しいです（私も書くのに時間がかかることを確信しています）
2. 製品に取り組む開発者の巨大なチームがある場合、コードを論理ブロックに分割し、インターフェースで保護すると役立ちます。

初期の発見の1つ（1960年代の経験から得られたBrooksのMythical Man-Monthにあります）は、1日あたりのデバッグされたコード行において、人々は1つの言語で他の言語とほぼ同じくらい生産性が高いということでした。これは明らかに普遍的には真実ではなく、あまりにも遠くに押すと壊れる可能性がありますが、ブルックスの時代の高級言語については一般的に真実でした。

したがって、生産性を上げる最も速い方法は、1行のコードでより多くのことを実行できる言語を使用することであり、実際には、少なくともFORTRANやCOBOLなどの複雑な言語では機能するか、より最新の例Cを使用することになります。

移植性は常に問題です-今ではないとしても、少なくとも最終的には。プログラミング業界は毎年何十億もかけて古いソフトウェアの移植に費やしており、それが書かれた当時、「明らかに」移植性の問題はまったくありませんでした。

アセンブリがあまり一般的でなくなったとき、悪循環がありました。高水準言語が成熟するにつれて、アセンブリ言語の命令セットは、プログラマーの便宜のために少なくなり、コンパイラーの便宜のために多く作られました。

そのため、現実的には、どのレジスタを使用するか、どの命令がわずかに効率的かなど、正しい判断を下すことが非常に難しい場合があります。コンパイラーは、ヒューリスティックを使用して、どのトレードオフが最高の見返りをもたらす可能性が高いかを判断できます。私たちはおそらく小さな問題を検討し、今ではかなり洗練されたコンパイラに勝る可能性のあるローカル最適化を見つけることができますが、平均的なケースでは、優れたコンパイラはおそらく優れたプログラマよりも最初の試行でより良い仕事をするでしょう。最終的には、ジョンヘンリーのように、マシンを打ち負かすかもしれませんが、そこにたどり着くまでに真剣に火傷するかもしれません。

私たちの問題も今ではかなり異なります。1986年に、私は画面に数百ピクセルを配置することを含む小さなプログラムからもう少し速度を上げる方法を理解しようとしていました。アニメーションをぎくしゃくさせないようにしました。アセンブリ言語の公正なケース。今私は、住宅ローンの契約言語とサービサーポリシーに関する抽象化を表現する方法を理解しようとしています。ビジネススタッフが話す言語に近いものを読みたいと思います。LISPマクロとは異なり、アセンブリマクロは規則の点でそれほど強制されないため、優れたアセンブラでDSLにかなり近いものを取得できる場合でも、さまざまな種類の癖が発生しやすくなります。 Ruby、Boo、Lisp、C＃、さらにはF＃で同じコードを記述した場合、問題が発生します。

ただし、問題が効率的なアセンブリ言語で簡単に表現できる場合は、さらに強力になります。

他の人が言ったことのほとんどは同上。

Cが発明される前の古き良き時代、高級言語がCOBOLやFORTRANのようなものだけだったとき、アセンブラに頼らなければ実行できなかったことがたくさんありました。すべてのデバイスにアクセスできるなど、柔軟性を最大限に活用できる唯一の方法でした。しかし、Cが発明され、アセンブリで可能なほとんどすべてのことがCで可能になりました。その後。

そうは言っても、アセンブラーで書くことを学ぶことは、新しいプログラマーにとって非常に役立つ演習だと思います。彼らが実際にそれを多く使用するのではなく、コンピュータ内部で実際に何が起こっているのかを理解しているからです。私は、ビットとバイトとレジスターで実際に何が起こっているのかを明確に知らないプログラマーからのプログラミングエラーと非効率的なコードをたくさん見ました。

私は今から約1か月間、アセンブリでプログラミングを行っています。私はよくCでコードを書き、それをアセンブリーにコンパイルして私を支援します。おそらく、Cコンパイラの最適化能力を最大限に活用していませんが、私のC asmソースに不要な操作が含まれているようです。したがって、優れたCコンパイラが優れたアセンブリコーダーよりも優れているという話は、常に正しいとは限らないことに気づき始めています。

とにかく、私の組み立てプログラムはとても速いです。また、アセンブリを使用すればするほど、コードの記述にかかる時間が短縮されます。また、可読性が低いアセンブリについてのコメントは正しくありません。プログラムに正しくラベルを付け、追加の詳細が必要なときにコメントを付けると、準備は完了です。実際のところ、プログラマーはプロセッサーのレベルで何が起こっているのかを見ているため、アセンブリーはプログラマーにとってより明確です。他のプログラマについては知りませんが、私にとっては、ブラックボックスのようなものではなく、何が起こっているのかを知ることが好きです。

とはいえ、コンパイラーの本当の利点は、コンパイラーがパターンと関係を理解し​​、ソース内の適切な場所にそれらを自動的にコーディングできることです。よく使われる例の1つは、コンパイラーが関数ポインターを最適にマップする必要があるC ++の仮想関数です。ただし、コンパイラーは、コンパイラーのメーカーがコンパイラーにできることを実行することに限定されます。これにより、プログラマーはコードで奇妙なことをしなければならず、コーディング時間を追加しなければならない場合があります。

個人的には、市場は高級言語を強くサポートしていると思います。アセンブリ言語が今日存在する唯一の言語である場合、彼らはプログラミングを行う人が約70％少なくなり、おそらく90年代に私たちの世界がどこにあるかを知っています。高レベルの言語は、幅広い人々にアピールします。これにより、より多くのプログラマーが私たちの世界に必要なインフラストラクチャを構築できるようになります。中国やインドなどの発展途上国は、Javaなどの言語から大きな恩恵を受けています。これらの国々はITインフラストラクチャを迅速に開発し、人々はより相互につながります。つまり、高水準言語は、優れたコードを生成するためではなく、世界の市場での需要を満たすのに役立つために人気があるということです。

私は現在comp orgでアセンブリを学習しています。興味深いことですが、書くのも非常に非効率的です。物事を機能させるには、頭の中に多くの詳細を保持する必要があり、同じものを書くのも遅い。たとえば、C ++の単純な6行のforループは、18行以上のアセンブリに相当します。

個人的には、ハードウェアレベルで物事がどのように機能するかを学ぶことの多くの楽しみは、コンピューティングがどのように機能するかについてのより大きな感謝を私に与えます。

Cが優れたマクロアセンブラより優れているのは、C言語の型チェックです。ループ構造。自動スタック管理。（ほぼ）自動変数管理。アセンブラーの動的メモリー技術は、お尻の大きな痛みです。リンクされたリストを適切に行うことは、Cに比べて恐ろしく恐ろしく、それでもfoo.insert（）をリストすることができます。そしてデバッグ-まあ、何がデバッグしやすいのかについてのコンテストはありません。HLLはそこで勝利します。

アセンブラでのキャリアのほぼ半分をコード化したので、assmeblerで考えるのが非常に簡単になります。これは、Cコンパイラが何をしているかを確認するのに役立ちます。これは、Cコンパイラが効率的に処理できるコードを書くのにも役立ちます。Cで書かれたよく考えられたルーチンは、少しの作業でアセンブラーに必要なものを正確に出力するように書くことができます-そしてそれはポータブルです！クロスプラットフォームの理由から、私はすでにいくつかの古いasmルーチンをCに書き直す必要があり、面白くありません。

いいえ、私はCに固執し、HLLで得られる生産性の時間に対するパフォーマンスのわずかな低下に対処します。

私が個人的にアセンブリでプログラムを頻繁に記述しない理由だけに答えることができます。主な理由は、それを行うのがより面倒であることです。また、すぐに気づかずに微妙に誤解するほうが簡単だと思います。たとえば、1つのルーチンでレジスタの使用方法を変更しても、1つの場所でこれを変更するのを忘れる場合があります。それはうまく組み立てられ、ずっと後でないと気付かないかもしれません。

とは言っても、アセンブリにはまだ有効な用途があると思います。たとえば、SIMDを使用し、偏執的な「すべてのビットが神聖である」[引用V.Stob]アプローチに従って、大量のデータを処理するためのかなり最適化されたアセンブリルーチンがいくつかあります。（しかし、単純なアセンブリの実装は、コンパイラーが生成するものよりもずっと悪いことに注意してください。）

Cはマクロアセンブラです。そしてそれは最高のものです！

それはアセンブリができるほとんどすべてを行うことができます、それは移植可能であり、埋め込まれたアセンブリコードをまだ使用できる何かを行うことができないほとんどのまれなケースです。これにより、アセンブリで絶対に書く必要があるプログラムのごく一部だけが残り、アセンブリ以外は何も残りません。

また、より高いレベルの抽象化と移植性により、ほとんどの人がCでシステムソフトウェアを作成する価値が高まります。また、一部のプログラムを作成するために多くの時間とお金を費やす場合、移植性は必要ないかもしれませんが、自分を制限したくない場合があります。将来的にそれを使用できるようになるでしょう。

人々は他の方向もあることを忘れているようです。

そもそもなぜアセンブラで書くのですか？本当に低レベルの言語でプログラムを書いてみませんか？

の代わりに

mov eax, 0x123
add eax, 0x456
push eax
call printInt

あなたも書くことができます

B823010000
0556040000
50 
FF15.....

これには非常に多くの利点があり、プログラムの正確なサイズがわかり、命令の値を他の命令の入力として再利用でき、アセンブラーで記述する必要さえなく、任意のテキストエディターを使用できます...

そして、あなたがまだこれについてアセンブラを好む理由は、他の人々がCを好む理由です...

それは常にその方法だからです：時間の経過と良いものも過ぎ去ります:(

しかし、asmコードを書くときは、高レベルのlangをコーディングするときとはまったく違った感じになりますが、生産性ははるかに低くなります。まるで絵描きのようです。CPU機能だけで制限なしで、好きなように好きなものを自由に描くことができます...それが私が大好きな理由です。この言語がなくなるのは残念です。しかし、誰かがまだそれを覚えてコーディングしている間は、決して死ぬことはありません！

$$$

会社がコードを$$$に変えるのを助けるために開発者を雇います。有用なコードをより早く作成できれば、会社はそのコードをより速く$$$に変えることができます。

高レベルの言語は、一般に、大量の有用なコードを作成するのに適しています。これは、アセンブリがその場所を持たないと言っているのではありません。他に何もしない時と場所があるからです。

アセンブリをCよりも高いレベルの言語（Java、Python、Rubyなど）と比較すると、HLLの利点はさらに大きくなります。たとえば、これらの言語にはガベージコレクションがあります。メモリのチャンクを解放するタイミングを気にする必要はなく、解放が早すぎるためにメモリリークやバグが発生することもありません。

他の人が以前に述べたように、ツールが存在する理由は、それがどれだけ効率的に機能できるかです。HLLは同じ行をasmコードの多くの行と同じように実行できるので、アセンブリが他の言語に取って代わられるのは当然だと思います。そして、ハードウェアに近いいじくりのために-Cのインラインアセンブリと言語ごとのその他のバリアントがあります。ポールカーター博士がPCアセンブリ言語で言う

「... Pascalのようなプログラミング言語よりも、コンピューターが実際に低レベルでどのように機能するかをよりよく理解します。コンピューターがどのように機能するかをより深く理解することにより、Cなどの高レベル言語でソフトウェアをより生産的に開発できることがよくあります。 C ++。アセンブリ言語でプログラミングすることを学ぶことは、この目標を達成するための優れた方法です。」

私の大学のコースで集会の紹介があります。概念を明確にするのに役立ちます。しかし、アセンブリのコードの90％を書く人はいないと思います。今日のアセンブリに関する深い知識はどの程度重要ですか？

これらの回答をめくって、レスポンダーの9/10がアセンブリで作業したことがないと思います。

これは、古くからある質問であり、頻繁に出て来て、あなたは同じ、ほとんど誤解された答えを得ます。移植性がない場合でも、私は自分で組み立てのすべてを行います。それでも、私はアセンブリで行ったようにCでコーディングします。