私は、新しい言語を学ぶことで得られる最も重要なことの 1 つは、新しい言語の使い方ではなく、そこから得られる概念の知識であるという考えを固く信じています。Assembly がどれほど重要で有用であるかを尋ねているわけではありません。また、実際のプロジェクトでそれを使用したことがなくてもかまいません。
私が知りたいのは、アセンブリのどの概念が一般的なプログラマーにとって最も重要だと思うかということです。アセンブリに直接関係している必要はありません。CPU キャッシュなど、高級言語ですべての時間を費やしている典型的なプログラマーが理解できない、または当然のことと考えているものでもあります。
アセンブリを使用すると、CPU が同時に処理できる変数 (マシン ワード サイズの整数) の数を把握できます。いくつかの一時変数のみを含むようにループを分割できれば、それらはすべてレジスターに収まります。そうでない場合、物事がメモリにスワップアウトされるため、ループの実行が遅くなります。
これは私の C コーディングに本当に役立ちました。スパゲッティをできるだけ少なくして、すべてのループをタイトでシンプルにするようにしています。
いくつかのアセンブリ言語を学ぶことで、x86 命令セットがいかに不十分であるかを実感しました。可変長命令？タイミングを予測するのは難しいですか？非直交アドレッシング モード？うーん。
私たち全員が MIPS を実行したり、ARM や PowerPC を実行したりすれば、世界はより良いものになるでしょう :-) むしろ、Intel/AMD が半導体の専門知識を利用して、マルチコア、超高速、超低価格の MIPS を作成した場合x86 プロセッサの代わりに、これらすべての償還品質を備えたプロセッサ。
アセンブリ言語は、いくつかの大きな概念だけでなく、多くの小さなことを教えてくれると思います。
ここで考えられることをいくつか挙げますが、x86 と RISC 命令セットの両方を使用して学習することに代わるものはありません。
おそらく、整数演算が最速だと思います。整数の整数平方根 (つまり、floor(sqrt(i))) を見つけたい場合は、整数のみの近似ルーチンを使用するのが最善ですよね?
いや。数学コプロセッサ (x86 上) にはfsqrt命令があります。float への変換、平方根の取得、および再び int への変換は、すべて整数のアルゴリズムよりも高速です。
次に、メモリへのアクセスなど、たどることはできますが、アセンブリを詳しく調べるまでは適切に評価できないことがあります。リンクされたリストがあり、リストの最初の要素に、頻繁にアクセスする必要がある変数が含まれているとします。リストはめったに並べ替えられません。その変数にアクセスする必要があるたびに、リストの最初の要素へのポインターをロードし、それを使用して変数をロードする必要があります (使用間で変数のアドレスをレジスターに保持できないと仮定します)。 . 変数をリストの外に格納した場合は、1 回の読み込み操作だけで済みます。
もちろん、いくつかのサイクルを節約することは、最近では通常重要ではありません。しかし、高速である必要があるコードを作成する予定がある場合、この種の知識は、インライン アセンブリと一般的に他の言語の両方に適用できます。
呼び出し規約はどうですか？(一部のアセンブラーはこれを処理します。本物のプログラマーはそれらを使用しません。) 呼び出し元または呼び出し先はスタックをクリーンアップしますか? スタックも使用しますか？レジスタで値を渡すこともできますが、x86 命令セットがおかしいため、特定のものを特定のレジスタで渡す方が適切です。そして、どのレジスタが保持されますか? C コンパイラがそれ自体で実際に最適化できないことの 1 つは、呼び出しです。
戻りアドレスを PUSH してから JMP してプロシージャーに入れるなど、ちょっとしたトリックがあります。プロシージャが戻ると、プッシュされたアドレスに移動します。関数呼び出しに関する通常の考え方からのこの逸脱は、それらの「悟りの状態」のもう 1 つです。革新的な機能を備えたプログラミング言語を設計する場合は、ハードウェアで可能な面白いことを知っておく必要があります。
アセンブリ言語の知識は、コンピューターのセキュリティに関するアーキテクチャ固有のことを教えてくれます。バッファ オーバーフローを悪用する方法、またはカーネル モードに侵入する方法、およびそのような攻撃を防ぐ方法。
次に、自己変更コードの超クールさ、および関連する問題として、再配置やコードへのパッチの適用などのメカニズムがあります (これには、マシン コードの調査も必要です)。
しかし、これらすべてには正しい精神が必要です。置けるような人なら
while(x--)
{
...
}
それが何をするかを学ぶと、それが何をするかを理解するのが難しいと思うなら、アセンブリ言語はおそらくあなたの時間の無駄です.
コンピューターが「フードの下」でどのように機能するかをよりよく理解するために、アセンブリ言語を知ることは良いことです。何かをデバッグしていて、デバッガーが提供できるのはアセンブリコードのリストだけである場合に役立ちます。問題が何であるかを理解するチャンスとの戦い。ただし、低レベルの知識を高レベルのプログラミング言語に適用しようとすること、たとえば、CPU が命令をキャッシュする方法を利用しようとしたり、奇妙な高レベル コードを記述してコンパイラに超効率的なマシン コードを生成させたりすることは、おそらくマイクロ最適化しようとしている兆候。ほとんどの場合、パフォーマンスの向上が必要でない限り、通常はコンパイラの裏をかこうとしない方がよいでしょう。パフォーマンスの向上が必要な場合は、アセンブリにこれらのビットを記述した方がよいでしょう。
したがって、物事がどのように機能するかをよりよく理解するためにアセンブリを知ることは良いことですが、得られた知識は必ずしも高水準言語でコードを記述する方法に直接適用できるとは限りません。ただし、その点については、関数呼び出しがアセンブリ コード レベルでどのように機能するかを学習すること (スタックと関連するレジスタについて学習すること、スタックでパラメーターがどのように渡されるかについて学習すること、自動ストレージがどのように機能するかを学習することなど) が成功したことを発見しました。 「スタック領域不足」エラーや「無効な呼び出し規約」エラーなど、上位レベルのコードで発生した問題をより理解しやすくなりました。
最も重要な概念はSIMDとそれの創造的な使用です。SIMDを適切に使用すると、文字列処理からビデオ操作、行列演算に至るまで、さまざまなアプリケーションでパフォーマンスが大幅に向上します。これは、純粋なCコードの10倍以上のパフォーマンス向上を実現できる場所です。これが、単なるデバッグを超えてアセンブリが依然として役立つ理由です。
私が取り組んでいるプロジェクトのいくつかの例（すべての数値はCore 2のクロックサイクルカウントです）：
逆8x8H.264DCT（周波数変換）：
c: 1332
mmx: 187
sse2: 127
8x8クロマ動き補償（双一次内挿フィルター）：
c: 639
mmx: 144
sse2: 110
ssse3: 79
4 16x16絶対差演算の合計（モーション検索）：
c: 3948
mmx: 278
sse2: 231
ssse3: 215
（はい、そうです-Cより18倍以上速いです！）
16x16ブロックの平均二乗誤差：
c: 1013
mmx: 193
sse2: 131
16x16ブロックの分散：
c: 783
mmx: 171
sse2: 106
メモリ、レジスタ、ジャンプ、ループ、シフト、およびアセンブラーで実行できるさまざまな操作。アセンブリ言語クラスのプログラムをデバッグする日々は欠かせません - 苦痛でした! -しかし、それは確かに私に良い基礎を与えてくれました.
私たちが今日使用している（そして私が大好きな）ファンシーパンツのすべてが、最終的にこれらすべてのものに要約されることを忘れています（または、おそらく知らなかったかもしれません）。
今では、アセンブラーを知らなくても生産的で有利なキャリアを築くことができますが、これらの概念は知っておくとよいと思います。
アセンブリで再帰とループを学ぶことは、私に多くのことを教えてくれました。私が使用している言語のコンパイラ/インタープリタがどのようにスタックにプッシュし、必要に応じてポップするかという基本的な概念を理解することができました。また、悪名高いスタック オーバーフローを悪用する方法も学びました。(これは、いくつかの get コマンドと put コマンドを使用して、C で驚くほど簡単です)。
日常の状況で asm を使用する以外に、アセンブリが教えてくれた概念を使用することはないと思います。
アドレッシングモードは非常に重要だと思います。
私の母校はそれを極端に扱いました、そしてx86がそれらを十分に持っていなかったので、私は私が覚えているそれらのうちの少なくとも7つを持っていたに違いないPDP11のシミュレーターですべてを研究しました。振り返ってみると、それは良い選択でした。
現在、x86 asm は CPU の根幹への直接的な接続ではなく、API のようなものです。あなたが書いたアセンブラオペコードは、それ自体がまったく異なる命令セットにコンパイルされ、再配置され、書き直され、修正され、一般的に認識できないほど壊れています。
したがって、アセンブラを学習しても、CPU の内部で何が起こっているかについての基本的な洞察が得られるわけではありません。私見ですが、アセンブラを学習するよりも重要なのは、ターゲット CPU とメモリ階層がどのように機能するかをよく理解することです。
この一連の記事では、後者のトピックをかなり徹底的にカバーしています。
高速実行:
ストレージへの高速アクセスから低速アクセス: