Ed Nather によるこの素晴らしい説明によると、どうやら以前はそうだったようです。今日はどう？つまり、CPU / FPU / GPU /などの十分な知識があれば可能ですか。どのようなシナリオでも、主流のアセンブラー (nasm、GAS など) によって生成されるものよりも効率的なマシン コードを作成するには? GPU カーネルの場合はどうですか?
編集：「建設的ではない」？お願いします。この質問は@Pointyの回答を生み出しました。これは、アセンブラの仕組みに精通していない人にとっては非常に啓発的でした。誰かがお気に入りに追加しました。Pointy が愛情を込めて投票者の 1 人であるという事実はいい感じですが、それが最良の回答である場合、それは受け入れられます。
2つのこと：
「アセンブリ言語」と呼ばれるものはありません。アセンブラは、特定のアーキテクチャの命令のテキスト エンコーディングを実行に適した形式に変換するプログラムです。特定のアセンブラが公開する正確な機能は、その設計者次第です。多くの CPU アーキテクチャには、いくつかのアセンブラが用意されています。
アセンブラの仕事は、人がマシン命令の正確なシーケンス (および、初期化されたメモリ位置、ストレージの予約済みブロック、ランタイム エグゼクティブへのディレクティブなど、プログラムの他の側面) を要求するための「使いやすい」方法を提供することであるためです。 、特定のアセンブラでは生成できないプログラムを手動で生成できる場合、それは実際には不適切なアセンブラを持っていることを意味するだけです。Intel が iAPX 86 シリーズ用に開発したアセンブラ (Microsoft のmasmではなく、弱い模倣者でした) には、かなり典型的なマクロ機能があり、オペコード ニーモニック (もののようMOVにADD、、BNEなど）任意に延長する。このようなアセンブラを使用すると、任意のコードを作成することが明らかに可能になります。
プログラミングにおける実際の懸念事項は、コンピューターが非常に詳細に作業を完了するための戦略を選択する責任をプログラマーに負わせることが、パフォーマンスにとって価値があるかどうかです。もちろん、この質問には 1 つの答えはありません。考えられる状況は多数あり、さまざまなコンピューティング デバイスが存在し、主に物事は常に変化しているためです。たとえば、1959 年には、FORTRAN のような高水準言語をマシン コードに変換するコンピューティング タスク自体が、コンピューターにとって大きな作業負荷でした。プログラミング言語がどのように機能するかについての理解は、まだ始まったばかりでした。
今日、「機械語」を知る唯一の理由は (「言語」という言葉は実際には正確ではないことに注意してください)、利用可能な (または便利な) アセンブラーがないときに命令シーケンスを作成することです。これは、特定の命令シーケンスを明示的に作成する方が、何らかの理由で高級言語を使用するよりも優れていると想定しています。それでも、それを行っていた場合、選択した命令シーケンスを発行するために高級言語でソフトウェアを作成することになるのが一般的です。つまり、あるタスクのために「ドメイン固有のアセンブラー」を効果的に作成します。良い例は、Java や JavaScript VM のように、オンザフライで機械語ブロックを構築する仮想マシン インタープリターのようなもののコードです。
アセンブラは、アセンブリ言語を機械語に変換します。アセンブリ言語が機械語命令と 1 対 1 の関係を持っていることが理想的ですが、常にそうであるとは限りません。 ほとんどの場合、命令のアセンブリ言語構文からの変換と機械語コードは、アセンブラで行う場合でも手動で行う場合でも同じです。当然、時々ドントケアビットがいくつかあり、アセンブラーと人間は異なるドントケアビットを選択する可能性があるため、結果はビット一致のビットである必要はありませんが、縦方向と速度方向は同一であり、まったく違いはありません。
人間とアセンブラー ソフトウェアの違いは、もしあれば、アセンブリ言語がマシン コードと 1 対 1 の関係にないこと、および/またはさまざまな理由でプログラマーがアセンブラーに処理を任せたいことです。これは、疑似命令、マクロ、または外部で定義された変数に関係するものである可能性があります。
アセンブリ言語は、特定のアセンブラーによって定義されている用語です。同じプロセッサに対して、互換性のない多くの異なるアセンブリ言語を使用できます。また、言語が特定の命令を選択するために必要なすべての情報を完全に記述していないインスタンスがあるアセンブリ言語を使用することもできます。たとえば、一部のアセンブラを使用した一部の命令セットのニア ジャンプとファー ジャンプです。
したがって、リンゴとリンゴを比較したい場合、手で組み立てたコードとソフトウェアで組み立てたコードの間に違いはありません。つまり、問題のコードはあいまいにならないように適切に記述されているため、ソフトウェアと人間のアセンブラーはそれをアセンブルできます。dont care ビット以外の違いが見つかった場合は、最適化に関係している可能性があります。これは、人間のアセンブラーがコードを変更することに関係しており、一致するアセンブリ言語を変更できる/変更する必要があります。この違いは、人間とアセンブリ言語のアセンブラーには何の関係もありませんが、あるプログラマーは別のプログラマーと比較してプログラムします。基本的に、ソフトウェア アセンブラを使用してアセンブリ言語で同じ結果を得ることができます。
非常に特殊なランタイム環境をターゲットにしている熟練したアセンブリ言語プログラマーは、おそらくコンパイラーが生成するよりも優れた動作をするコードを生成できます。コードの性質に応じて、必要な作業量に比べてパフォーマンスが大幅に向上する場合とそうでない場合があります。
一方、Java や .NET などのフレームワークを使用すると、プログラマーはソフトウェアを「中間」形式にコンパイルできます。この形式は、必要に応じて、実際に実行される環境向けの特定の最適化を含むマシン コードに変換できます。「任意のプラットフォーム」で実行するようにコンパイルされたコードは、実行中のプラットフォーム用に手動で調整されたフレームワーク エンジンによって実行される場合、そのプラットフォーム用に手動で調整されたアセンブリ コードほどには実行されない可能性がありますが、コードよりは優れています。これは、他のプラットフォームでのパフォーマンスを最適化するために手動で調整されました。