アセンブリ言語プログラミングに関する考え

何年もそれに入り込まずに何かをした後、私はルーツに戻ることにしました。 プログラミングへ。 繰り返しになりますが、この分野の「現代の成果」が多数あることを考えると、本当に不十分なもの、それを楽しく便利なものにするために何をすべきかを決定することは困難でした。 多くのことを少し試した後、彼はコンピューターを知った最初の日から（また、シンクレアirの創作のコピーと共に）アセンブリ言語プログラミングに引き込まれた場所に戻ることにしました。 実際、かつて私はアセンブラーを非常によく知っていました（この場合はx86について話している）が、ほぼ15年間は何も書きませんでした。 したがって、これは一種の「放dig息子」の帰還です。

しかし、ここで最初の失望が待っていました。 残念なことに、インターネットで見つかった書籍、マニュアル、およびその他のアセンブラーのリファレンスには、アセンブラーでのプログラミング方法、正確な理由、およびその内容に関する最小限の情報が含まれています。





しかし、通常の本は、おそらく「スラグ」の山の下にあるはずです、私は単にそれらを見つけませんでした。 したがって、知識をアーキテクチャ、ニーモニック、および「2本の指でイチジクを成形する方法」のすべての種類のグローバルな記述で埋める前に、「イデオロギー」の観点からアセンブリ言語プログラミングの問題にアプローチします。

牧歌？

テキストの後半で、現在広く普及している分類とは異なる分類を使用します。 しかし、これは「真実の色についての議論」の理由ではなく、プログラミングに関する著者の視点を説明する方が簡単なのはこの形式にあるだけです。



それで、今日、プログラマーにとって幸福の時代が来たように思えます。 すべての機会と願いのための資金の膨大な選択。 ここには、数百万の「フレームワーク」/「パターン」/「テンプレート」/「ライブラリ」と、プログラミング、「数百の言語と方言、数十の方法論とプログラミングへのさまざまなアプローチ」を「促進する」数千のツールがあります。 それを取る-私はしたくない。 しかし、「とられない」。 そして、それは宗教的な信念の問題ではありませんが、それはすべて味のないものを食べる試みのように見えます。 希望と熱意があれば、もちろんこれに適応できます。 しかし、プログラミングに戻ると、提案された技術的な美しさのほとんどでは見えません-多くの「クランチ」だけが見えます。 その結果、これらの「成果」を使用すると、幸運な場合、風景を魅了するのではなく、「アーティストのブラシ」から固体の「抽象化」またはルボキが出てきます。 ほとんどのプログラマーは本当にそのような平凡で無知であり、遺伝学のレベルで問題を抱えていますか？ いいえ、そうは思いません。 理由は何ですか？

今日、プログラミングには多くのアイデアと方法があります。 それらの中で最も「ファッショナブルな」ものを考えてください。

• 命令型プログラミング-このアプローチでは、プログラマーが問題の解決につながる一連のアクションを設定します。 これは、プログラムを論理的に独立した操作（モジュール、関数、手順）を実行する部分に分割することに基づいています。 しかし、型付きアプローチ（以下を参照）とは異なり、ここには重要な機能があります-変​​数の「型付け」の欠如。 つまり、「変数のタイプ」という概念はありませんが、同じ変数の値が異なるタイプを持つことができるという理解を使用しています。 このアプローチの印象的な代表は、ベーシック、REXX、ムンプスです。
• 型付きプログラミングは、プログラマーとシステムが変数の可能な値を制限する場合の命令型プログラミングの修正です。 最も有名な言語には、パスカル、C。
• 関数型プログラミングは、関数の階層を「構築」する（そして、それに応じて欠落している関数を作成する）ことで解決する場合、問題を解決するより数学的な方法であり、問​​題の解決につながります。 例：Lisp、Forth。
• 自動プログラミングとは、プログラマーが内部の「状態」を変更/保存し、外部とやり取りできるメッセージ/エグゼクティブ要素の交換で構成されるモデル/ネットワークを構築するアプローチです。 つまり、これは一般に「オブジェクトプログラミング」と呼ばれるものです（オブジェクト指向ではありません）。 このプログラミング方法は、Smalltalkで導入されています。

しかし、他の多くの言語はどうでしょうか？ 原則として、これらはすでに「突然変異体」です。 たとえば、型付きアプローチとオートマトンアプローチが混在すると、「オブジェクト指向プログラミング」が得られました。



ご覧のとおり、各アプローチは（特定の実装の制限を考慮しなくても）プログラミング手法自体に独自の制限を課しています。 しかし、そうすることはできません。 残念ながら、これらの制限は「クリーンなアイデアを維持する」ために人為的に作成されることがよくあります。 その結果、プログラマーは、最初に見つかったソリューションを、使用されている言語または使用されている「テンプレート」のイデオロギーに少なくとも何らかの形で一致する形に「歪める」必要があります。 これは、デザインや開発の新しい手法や手法を考慮に入れなくても可能です。



アセンブリ言語でプログラミングする場合、私たちは望むようにすべてを自由に行うことができ、ハードウェアを使用できるように思えます。 しかし、あらゆる種類の機器に「ユニバーサルドライバー」を使用したいとすぐに、「創造性」の自由を規定の（標準化された）アプローチとドライバーの使用方法に変更せざるを得ません。 他の同僚の成果を使用する機会、または私たちの労働の成果で同じことをする機会を与える機会が必要になったらすぐに、プログラムの部分間の相互作用の選択の自由をいくつかの交渉/標準化された方法に変更することを余儀なくされます。



したがって、多くの場合アセンブラーに引き裂かれる「自由」は、しばしば「神話」であることが判明します。 そして、私の意見では、これ（制限の理解、およびそれらの整理方法）にさらに注意を払う必要があります。 プログラマーは、導入された制限の理由と、アセンブラーを多くの高水準言語と区別するものを理解する必要があり、そのような必要が生じた場合にアセンブラーを変更できます。 しかし、今では、アセンブラープログラマーは、高レベル言語によって課せられた制限に耐えることを余儀なくされており、それらをプログラミングする人が利用できる「ジンジャーブレッド」はありません。 一方では、オペレーティングシステムは既に実装された多くの機能を提供し、既製のライブラリなどがあります。 しかし、その使用方法は、特に、アセンブラーで書かれたプログラムから考慮されることなく、または一般的にx86アーキテクチャのプログラミングロジックに反することなく実装されます。 その結果、現在、OSの機能または高レベル言語の外部ライブラリを呼び出すアセンブラーでのプログラミングは、「恐怖」と「恐怖」です。

森の中に行くほど、厚くなる

そのため、アセンブラは非常にシンプルですが、使用できる必要があることに気付きました。 そして主な一貫性は、プログラムを実行するランタイム環境と対話する必要があることです。 高レベル言語のプログラマーが既に必要なライブラリ、関数、サブプログラムにアクセスしていて、言語の考え方に沿った形で外の世界とやり取りできる場合、アセンブラープログラマーはあらゆる種類の障害物を乗り越えなければなりません空の場所。 コンパイル中に高水準言語が生成するものを見ると、コンパイラーを書いた人は、プロセッサーがx86アーキテクチャーでどのように動作するのかわからない、または「2つのうちの1つ」（c）のように感じます。



順番に取得しましょう。 プログラミングは主にエンジニアリングです。つまり、実際の問題を効果的に（信頼性、利用可能なリソースの使用、実装のタイミング、使いやすさの観点から）解決することを目的とした科学的創造性です。 そして、エンジニアリングの中心にあるのはシステムアプローチです。 つまり、ソリューションを、完全かつ完全な真空で機能する一種の「分離不可能な」ブラックボックスと見なすことは不可能です。





残念ながら、私たちは持っているものと一緒に暮らさなければなりませんが、これは将来避けるべきです。 そのため、実際にはプログラムは一連のモジュールであり（それらがどのように呼び出され、どのように「動作する」かは重要ではありません）、それらを構成することで問題の解決策を達成します。 効率のために、これらのモジュールを再利用できることが非常に望ましいです。 そして、それをただの費用で使用するだけでなく、便利な方法で使用します。 そして、ここで私たちは別の不快な「驚き」を待っています。 ほとんどの高級言語は、「関数」や「手順」などの構造単位で動作します。 そして、それらと対話する方法として、「パラメーターの受け渡し」が使用されます。 これは非常に論理的であり、ここでは疑問が生じません。 しかし、いつものように、「重要ではないことは重要です-どのように行われるか」（c）。 そして、ここから最も分かりにくいものが始まります。 現在、パラメーターの転送を編成する3つの方法が一般的です： cdecl 、 stdcall 、 fastcall 。 したがって、これらのメソッドはいずれもx86に「ネイティブ」ではありません。 さらに、呼び出されたルーチンの機能を拡張するという点で、すべてに欠陥があります。 つまり、送信されるパラメータの数を増やすことにより、この関数/サブプログラムのすべての呼び出しポイントを変更するか、同様の機能を備えた新しいサブプログラムを作成せざるを得ず、わずかに異なる方法で呼び出されます。



パラメータを渡すための上記の方法は、2つの個別のスタック（データスタックとアドレス/制御スタック）および開発されたスタック操作コマンド（少なくともスタック要素へのインデックスアクセス）を備えたプロセッサで比較的うまく機能します。 ただし、x86でプログラミングする場合は、最初にパラメーターの受け渡しを行うときに障害を起こさなければなりません。その後、スタックから「構造的に」パラメーターを削除することを忘れないでください。 途中で、スタックの最大深度を推測/計算しようとします。 x86（16/32ビットモード）は次のプロセッサであることに注意してください。

• 専用レジスタ（RON-汎用レジスタ-は存在しない：つまり、1つのコマンドを使用してGSレジスタの内容にEDIの値を乗算してEDX：ECXペアの結果を取得したり、EDIのペアから値をESIレジスタの内容に分割することはできませんEAXレジスタ）;
• レジスタはほとんどありません。
• 1つのスタック。
• メモリセルは、そこに格納されている値のタイプに関する情報を提供しません。

言い換えると、複数の独立したスタックなどをサポートする、大きなレジスタファイルを持つプロセッサに使用されるプログラミング方法です。 x86でプログラミングする場合、ほとんどの部分は適用されません。



「高級言語」で書かれた既製のモジュールとの相互作用の次の機能は、「変数のタイプ」との「闘争」です。 一方では、変数型の出現の理由は明らかです-プログラマーは、サブプログラム/モジュール内で使用される値を知っています。 これに基づいて、変数の値のタイプを設定することにより、言語トランスレーターに値のタイプ/制限の制御を割り当てることにより、プログラムの作成を「単純化」できることは非常に理にかなっています。 しかし、ここでは赤ちゃんに水がかけられました。 すべてのプログラムは、真空で球形の馬を生成するためではなく、ユーザーデータを使用した実用的な作業のために作成されているためです。 つまり、システムアプローチの明らかな違反です。高級言語の開発者が、外界との相互作用を考慮せずにシステムを調べているかのようです。 その結果、型付き言語でプログラミングする場合、開発者は「不正な」入力データのすべての可能なタイプを予測し、不確実性を回避する方法を探す必要があります。 そして、ここでは、正規表現をサポートし、例外的な状況を処理し、さまざまな種類の値のメソッド/プロシージャの署名やその他の松葉杖の他の世代のモンスターシステムが登場します。



前述のように、x86アーキテクチャの場合、メモリセルに格納される値自体には型がありません。 アセンブラープログラマーには特権があり、この値自体の処理方法を決定する責任があります。 そして、値のタイプを決定する方法とそれを処理する方法-から選択する多くのオプションがあります。 ただし、これらはすべて、ユーザーから受け取った値にのみ関係します。 型付き言語の開発者が正しく指摘したように、内部変数とサービス変数の値の型は、ほとんど常に事前に知られています。



この理由（高レベル言語で記述されたモジュールへのパラメーターの倒錯した送信、および同じモジュール内の送信されたパラメーターのタイプを厳密に監視する必要性）が主な理由のようです。 そして大多数は、苦しむよりも他の人によって既に解決されていることを利用するために「高レベル言語」のワイルドを理解することを好みます。 そして、まれなアセンブラー翻訳者は、少なくとも何らかの形でプログラマーをこのルーチンから「アンロード」します。

どうする

アセンブリ言語プログラミングの15年の中断を考慮した予備調査結果。

まず、プログラムのモジュールまたは部分について。 一般的な場合、アセンブリ言語でプログラムの2つのタイプの実行モジュール-「操作」と「サブプログラム」を強調する価値があります。

• 「操作」とは、「アトミック」アクションを実行し、その実行に多くのパラメーターを必要としないモジュールを意味します（たとえば、画面全体をクリアする操作、または一連の数値の中央値を計算する操作など）。
• 「サブプログラム」は機能モジュールと呼ばれるべきであり、適切に機能するには、多くの入力パラメーター（2x-3x以上）が必要です。

そして、ここでは、命令型および関数型言語の経験を評価する価値があります。 彼らは、使用すべき2つの貴重なツールを提供しました。「データ構造」（または、たとえば、REXX-複合変数/補足変数）と「非データ安定性」。



パラメータをサブプログラムに転送するには、「構造」、つまりメインプログラムと呼び出されたサブプログラムの両方にアクセス可能な特定のメモリ領域にあるパラメータの形成セットを使用すると便利です。 さらに、アプローチを標準化し、「0-howl」パラメーターを、構造の塗りつぶされた/重要なフィールドのビットマスクとして使用できます。 つまり、コールシグネチャの一種であり、実際に使用されるパラメータに応じて、サブルーチンがさらに分析し、作業のロジックを変更できます。 さらに、開発者は、古い呼び出しとの互換性を維持しながらルーチンの機能を拡張し、サポートされているAPIのフレームワーク内で同じ機能を持つ多くの同様のルーチンを作成することなく、使用するパラメーターの数を増やすことができます。 このアプローチの追加の利点は、スタックでの「寄生」作業の削減です。



また、非免疫のルール、つまり、送信されるパラメーターの不変性に従うことも役立ちます。 サブプログラムは、渡された構造体の値を変更することはできません（変更すべきではありません）。結果は、レジスター（2〜3個のパラメーター以下）または作成中の新しい構造体に返されます。 したがって、サブプログラムによるデータの「忘れられた」変更の場合、構造のコピーを作成する必要がなくなり、すでに作成された構造全体またはその主要部分を使用して、1つまたは同様のパラメーターセットで動作する複数のサブプログラムを呼び出すことができます。 さらに、ほぼ「自動的に」次の「機能的」ルール、つまりサブプログラムと操作の内部コンテキスト独立性に到達します。 言い換えると、状態/データをその処理のメソッド/サブルーチンから分離すること（オートマトンモデルとは対照的）。 並列プログラミングの場合、および1つのサブプログラムを共有する場合、多くの実行コンテキストを生成して「非交差」を監視する必要性と、複数の呼び出しの場合に異なる「状態」を持つ1つのサブプログラムの複数インスタンスの作成の両方を取り除きます。



データの「タイプ」については、「すべてをそのまま」残しておくか、ホイールを再発明して、命令型言語の翻訳者の開発者が長い間使用していたものを活用することはできません-「値タイプ識別子」。 つまり、外界からのすべてのデータが分析され、受信した各値には、処理中のタイプ（整数、浮動小数点、パックBCD、文字コードなど）およびフィールド/値のサイズの識別子が割り当てられます。 この情報があれば、プログラマーは、値を入力するための不必要に狭い「ルール」のフレームワークにユーザーを追い込むことはなく、一方で、プロセスでユーザーデータを処理する最も効率的な方法を選択することができます。 しかし、繰り返しますが、これはユーザーデータの操作にのみ適用されます。



これらは、設計、デバッグ、エラー処理の問題とは関係なく、アセンブラープログラミングの一般的な考慮事項でした。 0から（そして特にアセンブラで）それらを書くOS開発者が考えることを持ち、彼らがアセンブラのプログラミングをより体系的で便利で楽しいものにする方法を選択することを願っています彼らは他の人の、しばしば絶望的に「曲がった」オプションを盲目的にコピーしません。