アセンブリ言語

アセンブリ言語
アセンブラからの典型的な二次出力- Motorola MC6800の元のアセンブリ言語（右）とアセンブルされた形式を表示
パラダイム命令型、非構造化、多くの場合メタプログラミング（マクロ経由）、特定のアセンブラは構造化またはオブジェクト指向
初登場1947 （1947年）
タイピングの規律なし
ファイル名拡張子.asm、、、、、、およびアセンブラ.sに応じて他のいくつか.S.inc.wla.SRC

コンピューター科学において、アセンブリ言語（アセンブラ言語[ 1 ]またはシンボリックマシンコードとも呼ばれる）[ 2 ] [ 3 ] [ 4 ] は、単にアセンブリと呼ばれることが多く、一般的にはASMまたはasmと略されるが、言語の命令とアーキテクチャのマシンコード命令との間に非常に強い対応関係を持つ低レベルのプログラミング言語である。[ 5 ]アセンブリ言語は通常、マシンコード命令ごとに1つのステートメント（1:1）を持つが、定数、コメント、アセンブラディレクティブ、[ 6 ]メモリ位置、レジスタ、マクロなどのシンボリックラベル[ 7 ] [ 1 ]も一般的にサポートされている。

言語が機械語命令を表すのに使用された最初のアセンブリ コードは、キャスリーンとアンドリュー ドナルド ブースの 1947 年の著書Coding for ARCに見られます。[ 8 ]アセンブリ コードは、アセンブラと呼ばれるユーティリティ プログラムによって実行可能な機械語に変換されます。「アセンブラ」という用語は、一般的に、ウィルクス、ホイーラー、ギルが1951 年に著したThe Preparation of Programs for an Electronic Digital Computer に由来するとされていますが、[ 9 ]彼らはこの用語を「複数のセクションからなる別のプログラムを 1 つのプログラムにアセンブルするプログラム」の意味で使用しました。[ 10 ]変換プロセスは、ソース コードをアセンブルするように、アセンブリと呼ばれます。アセンブラがプログラムを処理しているときの計算ステップは、アセンブリ時間と呼ばれます。

アセンブリは機械語命令に依存するため、各アセンブリ言語[注1 ]はx86やARMなどの特定のコンピュータアーキテクチャに固有のものです。[ 11 ] [ 12 ] [ 13 ]

同じアーキテクチャに複数のアセンブラが存在する場合もあれば、オペレーティングシステムまたは特定のオペレーティングシステムに固有のアセンブラが存在する場合もあります。ほとんどのアセンブリ言語はオペレーティングシステムコール用の特定の構文を提供しておらず、ほとんどのアセンブリ言語はあらゆるオペレーティングシステムで普遍的に使用できます。[注2 ]これは、アセンブリ言語がプロセッサの実際の機能すべてにアクセスできるようにするためです。プロセッサの機能はすべて、最終的にその機能に基づいており、すべてのシステムコールメカニズムはそれに依存しています。アセンブリ言語とは対照的に、ほとんどの高水準プログラミング言語は一般に複数のアーキテクチャ間で移植可能ですが、アセンブルよりもはるかに複雑なタスクである解釈またはコンパイルが必要です。

コンピュータが登場した最初の数十年間は、システムプログラミングとアプリケーションプログラミングの両方が完全にアセンブリ言語で行われるのが一般的でした。一部の用途では依然として不可欠なものですが、現在ではプログラミングの大部分は高水準のインタープリタ型言語やコンパイル型言語で行われています。フレッド・ブルックスは著書『銀の弾丸はない』の中で、アセンブリ言語プログラミングからの移行の影響を次のように要約しています。「ソフトウェアの生産性、信頼性、そして簡潔性の向上に最も大きく貢献したのは、プログラミングにおける高水準言語の漸進的な利用です。多くの観察者は、この進歩によって生産性が少なくとも5倍向上し、同時に信頼性、簡潔性、そして理解しやすさも向上したと考えています。」[ 14 ]

今日では、高水準言語で実装された大規模システムにおいて、パフォーマンス上の理由や、高水準言語ではサポートされていない方法でハードウェアと直接やりとりするために、少量のアセンブリ言語コードを使用することが一般的です。例えば、Linuxカーネルバージョン4.9のソースコードのうち、アセンブリ言語で記述されているのはわずか2%弱で、97%以上はC言語で記述されています。[ 15 ]

アセンブリ言語の構文

アセンブリ言語は、ニーモニックを使用して、たとえば、各低レベルのマシン命令またはオペコード、各ディレクティブ、通常は各アーキテクチャレジスタ、フラグなどを表します。ニーモニックには、組み込みのものもあれば、ユーザ定義のものもあります。多くの操作では、完全な命令を形成するために1 つ以上のオペランドが必要です。ほとんどのアセンブラは、プログラムおよびメモリの場所の名前付き定数、レジスタ、およびラベルを許可しており、オペランドの式を計算できます。したがって、プログラマは退屈な繰り返し計算から解放され、アセンブラプログラムはマシンコードよりもはるかに読みやすくなります。アーキテクチャによっては、これらの要素を組み合わせて、オフセットやその他のデータ、および固定アドレスを使用して特定の命令またはアドレッシングモードにすることもできます。多くのアセンブラは、プログラム開発を容易にし、アセンブリプロセスを制御して、デバッグを支援するための追加のメカニズムを提供しています。

列指向のアセンブラもあり、特定のフィールドを特定の列に配置する。これは1950年代から1960年代初頭にかけて、パンチカードを使用するマシンでは非常に一般的だった。一部のアセンブラは自由形式の構文を採用しており、フィールドは句読点や空白などの区切り文字で区切られる。また、ラベルなどのフィールドを特定の列に配置し、他のフィールドを区切り文字で区切るハイブリッド型のアセンブラもあり、1960年代には列指向構文よりもこちらの方が一般的になった。

用語

  • マクロアセンブラは、マクロ命令機能を備えたアセンブラであり、これにより (パラメータ化された) アセンブリ言語テキストを名前で表すことができ、その名前を使用して拡張テキストを他のコードに挿入することができます。
    • オープン コードとは、マクロ定義の外側にあるアセンブラ入力を指します。
  • クロスアセンブラ（クロスコンパイラも参照）は、生成されるコードが実行されるシステム（ターゲットシステム）とは異なる種類のコンピュータまたはオペレーティングシステム（ホストシステム）上で実行されるアセンブラです。クロスアセンブルにより、組み込みシステムやマイクロコントローラなど、ソフトウェア開発をサポートするためのリソースがないシステム用のプログラム開発が容易になります。このような場合、生成されるオブジェクトコードは、読み取り専用メモリ（ROM、EPROMなど）、プログラマ（マイクロコントローラのように読み取り専用メモリがデバイスに統合されている場合）、またはオブジェクトコードの正確なビットごとのコピーまたはそのコードのテキストベース表現（Intel 16進数やMotorola Sレコードなど）を使用したデータリンクを介して、ターゲットシステムに転送する必要があります。
  • 高水準アセンブラは、高度な制御構造 ( IF/THEN/ELSE、DO CASE など) や、構造体/レコード、共用体、クラス、セットなどの高水準抽象データ型など、高水準言語によく関連付けられる言語抽象化を提供するプログラムです。
  • マイクロアセンブラは、コンピューターの低レベルの操作を制御するマイクロプログラムの作成を支援するプログラムです。
  • メタアセンブラとは、「アセンブリ言語の構文的および意味的記述を受け取り、その言語用のアセンブラを生成するプログラム」[ 16 ]、またはそのような記述とともにアセンブラソースファイルを受け取り、その記述に従ってソースファイルをアセンブルするプログラムである。SDS 9シリーズおよびSDS Sigmaシリーズのコンピュータ用の「メタシンボル」アセンブラはメタアセンブラである。[ 17 ] Sperry UnivacもUNIVAC 1100/2200シリーズ用のメタアセンブラを提供した。[ 18 ]
  • インラインアセンブラ（または組み込みアセンブラ）は、高級言語プログラム内に含まれるアセンブラコードです。 [ 19 ]これは、ハードウェアに直接アクセスする必要があるシステムプログラムで最もよく使用されます。

重要な概念

アセンブラ

アセンブラプログラムは、演算やアドレッシングモードを表すニーモニックと構文の組み合わせを、それらの数値表現に変換することでオブジェクトコードを作成します。この表現には通常、演算コード（「オペコード」）やその他の制御ビットやデータが含まれます。また、アセンブラは定数式を計算し、メモリ位置やその他のエンティティのシンボル名を解決します。[ 20 ]シンボル参照の使用はアセンブラの重要な機能であり、面倒な計算やプログラム変更後の手動アドレス更新を省きます。ほとんどのアセンブラには、テキスト置換を実行するためのマクロ機能も含まれています。例えば、共通の短い命令列をサブルーチンではなくインラインで生成するなどです。

一部のアセンブラは、命令セット固有の単純な最適化を実行できる場合もあります。具体的な例としては、様々なベンダーから提供されているx86アセンブラが挙げられます。ジャンプサイジングと呼ばれる処理は、ほとんどのアセンブラで実行でき、要求に応じて任意の数のパスでジャンプ命令の置き換え（ロングジャンプをショートジャンプまたは相対ジャンプに置き換える）が可能です。また、RISCアーキテクチャ用アセンブラのように、命令の単純な並べ替えや挿入を行うものもあります。RISCアーキテクチャ用アセンブラは、CPUパイプラインを可能な限り効率的に活用するための合理的な命令スケジューリングの最適化に役立ちます。 [ 21 ]

アセンブラは1950年代から、機械語の上位段階として、そしてFortran、Algol、COBOL、Lispといった高水準プログラミング言語が登場する以前から存在していました。また、アセンブリ言語と高水準言語の両方に類似した特性を持つトランスレータや半自動コードジェネレータもいくつか存在しており、中でもSpeedcodeはおそらく最もよく知られている例の一つでしょう。

特定のCPUまたは命令セットアーキテクチャに対して、異なる構文を持つ複数のアセンブラが存在する場合があります。たとえば、x86ファミリプロセッサのレジスタにメモリデータを追加する命令は、オリジナルのIntel 構文では となりますが、これはGNU アセンブラで使用されるAT&T 構文で記述されます。見た目は異なりますが、異なる構文形式は通常、同じ数値マシンコードを生成します。単一のアセンブラが、構文形式のバリエーションとその正確な意味解釈をサポートするために、異なるモードを持つこともあります ( x86 アセンブリプログラミングの特殊なケースでは、FASM構文、TASM構文、理想モードなど)。 add eax,[ebx]addl (%ebx),%eax

パス数

オブジェクト ファイルを生成するためにソースを何回パスする必要があるか (アセンブラがソースを何回読み取るか) に基づいて、2 種類のアセンブラが存在します。

  • ワンパスアセンブラはソースコードを一度処理します。定義される前に使用されたシンボルについては、アセンブラは最終的な定義後に「エラッタ」を出力し、リンカーまたはローダーに、まだ定義されていないシンボルが使用されていた箇所にパッチを適用するよう指示します。
  • マルチパス アセンブラは、最初のパスですべてのシンボルとその値を含むテーブルを作成し、その後のパスでそのテーブルを使用してコードを生成します。

どちらの場合も、アセンブラは後続のシンボルのアドレスを計算するために、最初のパスで各命令のサイズを決定できなければなりません。つまり、後で定義されるオペランドを参照する演算のサイズがオペランドの型または距離に依存する場合、アセンブラは最初にその演算に遭遇したときに悲観的な見積もりを行い、必要に応じて、後のパスまたはエラッタで1つ以上の「ノーオペレーション」命令でそのサイズを埋め込みます。ピープホール最適化機能を備えたアセンブラでは、パス間でアドレスが再計算され、悲観的なコードをターゲットからの正確な距離に合わせて調整されたコードに置き換えることができます。

ワンパスアセンブラが最初に使われた理由は、メモリサイズとアセンブリ速度であった。2回目のパスでは、シンボルテーブルをメモリに格納する（前方参照を処理するため）、テープ上のプログラムソースを巻き戻して再読み込みする、カードやパンチ穴の開いた紙テープを再読み込みするといった作業が必要になることが多かった。その後のコンピュータでは、メモリ容量が大幅に増加し（特にディスクストレージ）、再読み込みをすることなく必要な処理をすべて実行できるようになった。マルチパスアセンブラの利点は、エラッタがないためリンク処理（アセンブラが直接実行コードを生成する場合はプログラムの読み込み）が高速化されることである。[ 22 ]

例：次のコードスニペットでは、1パスアセンブラは文S2をアセンブルする際に後方参照BKWDのアドレスを特定できますが、分岐文S1をアセンブルする際に前方参照FWDのアドレスを特定できません。実際、FWD は未定義である可能性があります。2パスアセンブラはパス1で両方のアドレスを特定するため、パス2でコードを生成する際にそれらのアドレスが分かります。 

S1 B 前進 ... 前輪 駆動 * ... BKWD EQU * ... S2 B BKWD

高水準アセンブラ

より洗練された高レベルアセンブラは、次のような言語抽象化を提供します。

詳細については、以下の 言語設計を参照してください。

アセンブリ言語

アセンブリ言語で書かれたプログラムは、一連のニーモニックプロセッサ命令とメタステートメント（宣言的演算、ディレクティブ、疑似命令、疑似オペレーション、疑似OPなどとも呼ばれる）、コメント、そしてデータから構成される。アセンブリ言語の命令は通常、オペコードニーモニックとそれに続くオペランド（データ、引数、またはパラメータのリスト）から構成される。 [ 24 ] 一部の命令は「暗黙的」である可能性があり、これは命令が操作するデータが命令自体によって暗黙的に定義されていることを意味する。つまり、そのような命令はオペランドを必要としない。結果として得られるステートメントは、アセンブラによってメモリにロードされて実行可能な機械語命令に変換される。

例えば、以下の命令はx86 / IA-32プロセッサに8ビットの即値をレジスタに転送するよう指示します。この命令のバイナリコードは10110で、その後に3ビットの識別子が続き、使用するレジスタを示します。ALレジスタの識別子は000なので、以下のマシンコードはALレジスタにデータ01100001をロードします。 [ 24 ]

10110000 01100001

このバイナリ コンピュータ コードは、次のように16 進数で表現すると、人間にとってより読みやすくなります。 

B0 61

ここで、B0は「次の値のコピーをALに移動する」という意味で、6116進数で 01100001 という値（10進数では 97 ）を表します。8086ファミリのアセンブリ言語では、このような命令にMOVというニーモニック（ moveの略語）が用意されているため、上記のマシンコードはアセンブリ言語で次のように記述できます。必要に応じて、セミコロンの後に説明コメントを記述します。これにより、読みやすく、記憶しやすくなります。 

MOV AL , 61h ; ALに10進数97（16進数61）をロードする

一部のアセンブリ言語（この言語を含む）では、MOVなどの同じニーモニックが、データのロード、コピー、移動を行う一連の関連命令群に使用されることがあります。対象となるデータは、即値、レジスタ内の値、レジスタ内の値または即値（直接）アドレスで指定されたメモリ位置などです。他のアセンブラでは、L（「メモリからレジスタへ移動」）、ST（「レジスタからメモリへ移動」）、LR（「レジスタからレジスタへ移動」）、MVI（「即値オペランドからメモリへ移動」）など、異なるオペコードニーモニックが使用される場合があります。

同じニーモニックが異なる命令に使用されている場合、そのニーモニックは、データ（61hこの例では ）を除く複数の異なるバイナリ命令コードに対応し、そのニーモニックに続くオペランドによって決まります。例えば、x86/IA-32 CPUの場合、Intelアセンブリ言語構文は、レジスタAHの内容をレジスタALMOV AL, AHに移動する命令を表します。この命令の16進数表記は [ nb 3 ]です。

88 E0

最初のバイト 88h は、バイトサイズのレジスタと別のレジスタまたはメモリ間の移動を識別し、2 番目のバイト E0h は、両方のオペランドがレジスタであり、ソースがAHであり、宛先がALであることを指定するようにエンコードされます (3 つのビット フィールドを使用) 。

このように、同じニーモニックが複数のバイナリ命令を表すことができる場合、アセンブラはオペランドを調べてどの命令を生成するかを決定します。最初の例では、オペランドは61h有効な16進数値定数ですが、有効なレジスタ名ではないため、B0命令のみが適用可能です。2番目の例では、オペランドはAH有効なレジスタ名ですが、有効な数値定数（16進、10進、8進、または2進）ではないため、88命令のみが適用可能です。

アセンブリ言語は、このような曖昧さのなさが構文によって普遍的に保証されるように設計されています。例えば、Intel x86アセンブリ言語では、16進定数は数字で始まる必要があります。そのため、16進数「A」（10進数の10に相当）は、レジスタAHの名前と間違えられないように、または0Ahと記述する必要があります。（同じ規則は、レジスタBH、CH、DHの名前、および「BEACH」のように、文字Hで終わり、それ以外は16進数字のみを含むユーザー定義シンボルの名前についても、曖昧さを防止します。） 0AHAH

元の例に戻ると、x86オペコード10110000( B0)は8ビットの値をALレジスタにコピーしますが、10110001( B1)はそれをCLに、10110010( )はそれをDLB2に移動します。これらをアセンブリ言語で記述した例を以下に示します。[ 24 ]

MOV AL , 1h ; ALに即値1をロードします。MOV CL , 2h ; CLに即値2をロードします。MOV DL , 3h ; DLに即値3をロードします。

MOVの構文は次の例に示すようにさらに複雑になることもあります。[ 25 ]

MOV EAX , [ EBX ] ; EBXに含まれるアドレスのメモリの4バイトをEAXに移動します。MOV [ ESI + EAX ], CL ; CLの内容をアドレスESI+EAXのバイトに移動します。MOV DS , DX ; DXの内容をセグメントレジスタDSに移動します。

いずれの場合も、MOVニーモニックはアセンブラによってオペコード88-8C、8E、A0-A3、B0-BF、C6、またはC7のいずれかに直接変換され、プログラマは通常、どれがオペコードであるかを知ったり覚えたりする必要はない。[ 24 ]

アセンブリ言語を機械語に変換するのはアセンブラの役割であり、その逆変換は少なくとも部分的には逆アセンブラによって実現できます。高級言語とは異なり、多くの単純なアセンブリ文と機械語命令の間には1対1の対応関係があります。しかし、場合によっては、アセンブラは複数の機械語命令に展開される疑似命令（基本的にはマクロ）を提供することで、一般的に必要な機能を提供することがあります。例えば、「より大きいか等しい場合に分岐」命令を持たないマシンの場合、アセンブラは「より小さい場合に設定」や「0の場合（設定命令の結果に基づいて）」に展開される疑似命令を提供することがあります。ほとんどのフル機能アセンブラは、ベンダーやプログラマがより複雑なコードやデータシーケンスを生成するために使用する、豊富なマクロ言語（後述）も提供しています。アセンブラ環境で定義された擬似命令やマクロに関する情報はオブジェクトプログラムには存在しないため、逆アセンブラはマクロや擬似命令の呼び出しを再構築することはできず、アセンブラがそれらの抽象アセンブリ言語エンティティから生成した実際の機械語命令のみを逆アセンブルすることができます。同様に、アセンブリ言語ソースファイル内のコメントはアセンブラによって無視され、生成されるオブジェクトコードには影響を与えないため、逆アセンブラはソースコメントを完全に復元することはできません。

それぞれのコンピュータアーキテクチャには独自の機械語があります。コンピュータは、サポートする演算の数と種類、レジスタのサイズと数、そしてストレージにおけるデータの表現方法がそれぞれ異なります。ほとんどの汎用コンピュータは基本的に同じ機能を実行できますが、その方法はそれぞれ異なります。対応するアセンブリ言語は、これらの違いを反映しています。

単一の命令セットに対して、複数のニーモニックセットまたはアセンブリ言語構文が存在する場合があり、通常は異なるアセンブラプログラムでインスタンス化されます。このような場合、最も一般的なニーモニックセットは通常、CPUメーカーが提供し、そのドキュメントで使用されているものです。

異なるニーモニック セットを持つ CPU の例として、Intel 8080 ファミリと Intel 8086/8088 が挙げられます。Intel はアセンブリ言語のニーモニック (少なくとも 1970 年代と 1980 年代初頭に公開されたドキュメントの各ページ) の著作権を主張していたため、Intel の命令セットと互換性のある CPU を独自に製造していた企業の中には、独自のニーモニックを発明したところもありました。Zilog Z80 CPU はIntel 8080Aの拡張版で、8080A のすべての命令に加え、さらに多くの命令をサポートしています。Zilog は、新しい命令だけでなく、8080A のすべての命令に対応するまったく新しいアセンブリ言語を発明しました。たとえば、Intel がさまざまなデータ転送命令にMOV、MVI、LDA、STA、LXI、LDAX、STAX、LHLD、およびSHLDというニーモニックを使用しているのに対し、Z80 アセンブリ言語では、それらすべてにLDというニーモニックを使用しています。同様のケースとして、 NEC V20およびV30 CPU があります。これらは、それぞれ Intel 8086 と 8088 の強化コピーです。Zilog の Z80 と同様に、NEC は Intel の著作権侵害の訴えを避けるために、8086 および 8088 のすべての命令に対して新しいニーモニックを発明しました。(このような著作権が有効であるかどうかは疑問であり、AMD [注 4 ]やCyrixなどの後の CPU 企業は、許可も法的罰則も受けずに Intel の x86/IA-32 命令ニーモニックをそのまま再公開しました。) 実際には V20 および V30 をプログラムした人の多くが、Intel ではなく NEC のアセンブリ言語で記述したかどうかは疑わしいです。同じ命令セット アーキテクチャの 2 つのアセンブリ言語は同型であるため (英語とPig Latinのように)、製造元が独自に公開したアセンブリ言語をその製造元の製品に使用する必要はありません。

x86 Linux 上の「Hello, world!」

x86プロセッサ上の Linux の 32 ビット アセンブリ言語では、「Hello, world!」を次のように印刷できます。 

section .text ; コード セグメントの開始global _start ; 生成されたオブジェクト ファイル_startで表示されるように _start を宣言します: mov edx , len ; 文字列の長さ、write() の 3 番目の引数mov ecx , msg ; 文字列のアドレス、write() の 2 番目の引数mov ebx , 1 ; ファイル記述子 (標準出力)、write() の最初の引数mov eax , 4 ; write() のシステム コール番号int 0x80 ; システム コール トラップmov ebx , 0 ; 終了コード、exit() の最初の引数mov eax , 1 ; exit() のシステム コール番号int 0x80 ; システム コール トラップsection .data ; データセグメントの開始msg db 'Hello, world!' , 0xa ; 印刷される文字列len equ $ - msg ; アセンブリ時に計算される定数としてのその文字列の長さ

言語設計

基本要素

アセンブラの作者が文を分類する方法や使用する命名法には、大きな多様性があります。特に、マシンニーモニックや拡張ニーモニック以外のものを擬似命令（pseudo-op）と呼ぶ人もいます。典型的なアセンブリ言語は、プログラム操作を定義するために使用される3種類の命令文で構成されています。

オペコードニーモニックと拡張ニーモニック

アセンブリ言語の命令（文）は、高級言語の命令とは異なり、一般的に非常に単純です。一般的に、ニーモニックとは、単一の実行可能な機械語命令（オペコード）のシンボル名であり、各機械語命令には少なくとも1つのオペコードニーモニックが定義されています。各命令は通常、演算またはオペコードと、0個以上のオペランドで構成されます。ほとんどの命令は、単一の値または値のペアを参照します。オペランドは、即値（命令自体にコード化された値）、命令で指定または暗黙的に指定されたレジスタ、またはストレージ内の他の場所にあるデータのアドレスのいずれかです。これは、基盤となるプロセッサアーキテクチャによって決定されます。アセンブラは、このアーキテクチャの動作を反映するだけです。拡張ニーモニックは、オペコードと特定のオペランドの組み合わせを指定するためによく使用されます。例えば、System/360アセンブラは、マスク15の を 、マスク0のを （「NO OPeration」（1ステップ何もしない）） をB拡張ニーモニックとして使用します。 BCNOPBC

拡張ニーモニックは、命令の特殊な用途をサポートするためによく使用され、その用途は命令名からは明らかでないことが多い。例えば、多くのCPUには明示的なNOP命令はないが、その用途に使用できる命令はある。8086 CPUでは、命令は に使用され、 は命令 をエンコードするための疑似オペコードである。一部の逆アセンブラはこれを認識し、命令 を としてデコードする。同様に、 System/360およびSystem/370用のIBMアセンブラは、ゼロマスクでおよび に拡張ニーモニックおよび を使用する。SPARCアーキテクチャでは、これらは合成命令として知られている。[ 26 ]xchgax,axnopnopxchgax,axxchgax,axnopNOPNOPRBCBCR

一部のアセンブラは、2つ以上の機械語命令を生成する単純な組み込みマクロ命令もサポートしています。例えば、一部のZ80アセンブラでは、命令はld hl,bcを生成するものと認識され、ld l,cその後に が続きますld h,b。[ 27 ]これらは擬似オペコードと呼ばれることもあります。

ニーモニックは任意のシンボルです。1985年にIEEEはすべてのアセンブラで使用される統一されたニーモニックセットとして標準694を発行しました。[ 28 ]この標準はその後撤回されました。

データ指令

データや変数を保持するデータ要素を定義するために使用される命令があります。これらの命令は、データの型、長さ、およびアライメントを定義します。また、これらの命令は、データが外部プログラム（別途アセンブルされたプログラム）で使用可能か、それともデータセクションが定義されているプログラム内でのみ使用可能かを定義することもできます。一部のアセンブラでは、これらを疑似命令（pseudo-ops）として分類します。

アセンブリ指令

アセンブリディレクティブは、擬似オペコード、擬似オペレーション、または擬似OPとも呼ばれ、アセンブラに「命令のアセンブル以外の操作を実行するよう指示する」コマンドです。[ 20 ]ディレクティブはアセンブラの動作に影響を与え、「オブジェクトコード、シンボルテーブル、リストファイル、および内部アセンブラパラメータの値に影響を与える可能性があります」。擬似オペコードという用語は、データを生成するディレクティブなど、オブジェクトコードを生成するディレクティブを指す場合もあります。[ 29 ]

擬似命令の名前は、機械語命令と区別するためにドットで始まることがよくあります。擬似命令を使用すると、プログラムのアセンブルをプログラマーが入力したパラメータに依存させることができます。これにより、1つのプログラムを、例えば異なるアプリケーション向けに、異なる方法でアセンブルすることができます。また、擬似命令を使用してプログラムの表現を操作し、読みやすく保守しやすいようにすることもできます。擬似命令のもう1つの一般的な用途は、実行時データ用の記憶領域を予約し、必要に応じてその内容を既知の値に初期化することです。

シンボリックアセンブラを使用すると、プログラマは任意の名前（ラベルまたはシンボル）をメモリ位置や様々な定数に関連付けることができます。通常、すべての定数と変数には名前が付けられ、命令は名前でそれらの位置を参照できるため、自己文書化コードが促進されます。実行可能コードでは、各サブルーチンの名前はそのエントリポイントに関連付けられているため、サブルーチンへの呼び出しはすべてその名前を使用できます。サブルーチン内では、GOTO の宛先にラベルが付けられます。一部のアセンブラは、通常のシンボルとは語彙的に区別されることが多いローカルシンボルをサポートしています（例：GOTO の宛先として「10$」を使用するなど）。

NASMなどの一部のアセンブラは、柔軟なシンボル管理機能を備えており、プログラマーは異なる名前空間を管理したり、データ構造内のオフセットを自動計算したり、リテラル値やアセンブラによって実行された単純な計算結果を参照するラベルを割り当てたりすることができます。ラベルは、定数や変数を再配置可能なアドレスで初期化するためにも使用できます。

アセンブリ言語は、他のほとんどのコンピュータ言語と同様に、プログラムのソースコードにコメントを追加できますが、アセンブリ時には無視されます。バイナリマシン命令のシーケンスの意味と目的を判断するのは困難な場合があるため、アセンブリ言語プログラムでは適切なコメントの挿入が不可欠です。コンパイラや逆アセンブラによって生成された「生の」（コメントのない）アセンブリ言語は、変更が必要な場合に非常に読みにくくなります。

マクロ

多くのアセンブラは定義済みマクロをサポートしており、その他のアセンブラは、変数や定数が埋め込まれたテキスト行のシーケンスを含むプログラマ定義（繰り返し再定義可能）のマクロをサポートしています。マクロ定義は、最も一般的には[注 5 ]アセンブラステートメント（ディレクティブ、シンボリックマシン命令、アセンブラステートメントのテンプレートなど）の組み合わせです。このテキスト行のシーケンスには、オペコードまたはディレクティブを含めることができます。マクロが定義されると、その名前をニーモニックの代わりに使用できます。アセンブラがこのようなステートメントを処理する場合、ステートメントをそのマクロに関連付けられたテキスト行に置き換え、ソースコードファイル内に存在するかのように処理します（一部のアセンブラでは、置換テキスト内に存在するマクロの展開も含まれます）。この意味でのマクロは、1950年代のIBMオートコーダにまで遡ります。 [ 30 ]

マクロアセンブラには通常、マクロの定義、変数の定義、算術式、論理式、文字列式の結果への変数の設定、反復処理、条件付きコード生成などのディレクティブがあります。これらのディレクティブの中には、マクロ定義内での使用に制限されているもの（HLASMのMEXITなど）もあれば、オープンコード内（マクロ定義外）での使用が許可されているものもあります（ HLASMのAIFやCOPYなど）。

アセンブリ言語における「マクロ」という用語は、C言語のプリプロセッサなど、他の文脈におけるよりも包括的な概念を表します。C言語のプリプロセッサでは、#defineディレクティブは通常、短い1行のマクロを作成するために使用されます。アセンブラのマクロ命令は、PL/Iや他の言語のマクロと同様に、それ自体が長い「プログラム」になる可能性があり、アセンブリ中にアセンブラによって解釈されて実行されます。

マクロは「短い」名前を持ちながら、コード行を複数行、あるいは実際には多数の行に展開できるため、アセンブリ言語のプログラムをより短く見せるために使用できます。これにより、高水準言語と同様に、ソースコードの行数が少なくて済みます。また、アセンブリプログラムに高水準の構造を追加したり、パラメータやその他の類似機能を介して埋め込みデバッグコードを導入したりすることもできます。

マクロアセンブラでは、マクロがパラメータを取ることがしばしば可能です。一部のアセンブラには非常に高度なマクロ言語が組み込まれており、オプションパラメータ、シンボリック変数、条件文、文字列操作、算術演算といった高水準言語要素が組み込まれています。これらはすべてマクロ実行中に使用可能であり、マクロはコンテキストを保存したり情報を交換したりすることができます。したがって、マクロはマクロ引数に基づいて、多数のアセンブリ言語命令やデータ定義を生成する可能性があります。これは、例えばレコード形式のデータ構造や「アンロール」ループを生成したり、複雑なパラメータに基づいてアルゴリズム全体を生成したりするために使用できます。例えば、「ソート」マクロは、複雑なソートキーの指定を受け取り、その特定のキーに合わせて作成されたコードを生成することができます。このため、仕様を解釈する一般的な手順に必要な実行時テストは必要ありません。このようなマクロスイートを使用して大幅に拡張されたアセンブリ言語を使用する組織は、高水準言語で作業していると考えることができます。なぜなら、そのようなプログラマはコンピュータの最低レベルの概念要素を扱っていないからです。この点を強調するものとして、 SNOBOL4 （1967年）の初期の仮想マシンの実装にはマクロが用いられていた。SNOBOL4は仮想マシン用のアセンブリ言語であるSNOBOL実装言語（SIL）で記述されていた。ターゲットマシンはマクロアセンブラを用いてこれをネイティブコードに変換した。[ 31 ]これにより、当時としては高い移植性が実現された。

メインフレーム時代、マクロは特定の顧客向けに大規模なソフトウェアシステムをカスタマイズするために用いられたほか、顧客の担当者がメーカーのオペレーティングシステムの特定バージョンを作成することで、雇用主のニーズを満たすためにも用いられました。例えば、IBMの会話型監視システム/仮想マシン（VM/CMS）やIBMの「リアルタイムトランザクション処理」アドオンである顧客情報管理システム（CICS ） 、そして1970年代に始まり、現在でも多くの大規模コンピュータ予約システム（CRS）やクレジットカードシステムを稼働させている航空会社/金融システムであるACP / TPFなどを扱うシステムプログラマーによって、マクロは活用されていました。

アセンブラのマクロ処理機能のみを使用して、全く異なる言語で記述されたコードを生成することも可能です。例えば、アセンブラに任意のコードを生成するよう指示するアセンブリ時演算子内にCOBOLコード行を含む純粋なマクロアセンブラプログラムを使用して、COBOLで記述されたプログラムのバージョンを生成することができます。IBM OS/360は、マクロを使用してシステム生成を実行します。ユーザーは、一連のアセンブラマクロをコーディングすることでオプションを指定します。これらのマクロをアセンブルすることで、ジョブ制御言語やユーティリティ制御ステートメントを含む、システムを構築するためのジョブストリームが生成されます。

これは、1960年代に認識されたように、「マクロ処理」の概念は「アセンブリ」の概念とは独立しているためです。前者は、現代の言葉で言えば、オブジェクトコードの生成というよりも、ワードプロセッサやテキスト処理に近いものです。マクロ処理の概念は、変数の設定やその値の条件付きテストを行う「プリプロセッサ命令」をサポートするC言語で登場し、現在も存在しています。アセンブラ内部の以前のマクロプロセッサとは異なり、Cプリプロセッサはループ機能も「go to」機能も備えていないため、チューリング完全ではありません。後者はプログラムのループを可能にします。

マクロ処理の強力さにもかかわらず、マクロは多くの高級言語 (主な例外はC、C++、 PL/I) では使用されなくなりましたが、アセンブラでは依然として使われ続けています。

マクロのパラメータ置換は厳密に名前によって行われます。マクロ処理時に、パラメータの値がテキスト形式でその名前に置換されます。結果として最もよく知られているバグは、マクロ作成者が名前を想定しているにもかかわらず、パラメータ自体が単純な名前ではなく式である場合です。マクロでは、 

foo: マクロ a ロードa*b

呼び出し側が変数名を指定し、「グローバル」変数または定数bが「a」の乗算に使用されるという意図がありました。fooがパラメータ と共に呼び出されるとa-c、 のマクロ展開がload a-c*b行われます。曖昧さを回避するために、マクロプロセッサのユーザーはマクロ定義内で仮パラメータを括弧で囲むことができ、呼び出し側は入力パラメータを括弧で囲むことができます。[ 32 ]

構造化プログラミングのサポート

マクロのパッケージは、実行フローをエンコードするための構造化プログラミング要素を提供するように書かれています。このアプローチの最も古い例は、 Concept-14 マクロ セット[ 33 ]で、元々はHarlan Mills (1970 年 3 月) によって提案され、IBM の Federal Systems Division の Marvin Kessler によって実装されました。これは、OS/360 アセンブラ プログラムに IF/ELSE/ENDIF などの制御フロー ブロックを提供しました。これは、アセンブリ言語でスパゲッティ コードを引き起こす主な要因の 1 つである、アセンブリ コードでのGOTO操作の使用を減らす、またはなくす方法でした。このアプローチは、1980 年代初頭 (大規模なアセンブリ言語の使用の末期) に広く受け入れられました。IBM の High Level Assembler Toolkit [ 34 ]には、このようなマクロ パッケージが含まれています。

もう一つの設計はA-Naturalである[ 35 ]、Whitesmiths社（Unix系Idrisオペレーティングシステムの開発者であり、最初の商用Cコンパイラと報告されている）の8080/ Z80プロセッサ用の「ストリーム指向」アセンブラである。この言語は、オペコード、レジスタ、メモリ参照などの生の機械要素を扱うためアセンブラに分類されたが、実行順序を示す式構文を組み込んでいた。括弧やその他の特殊記号、ブロック指向の構造化プログラミング構造により、生成された命令の順序が制御された。A-naturalは、手作業によるコーディング用ではなく、Cコンパイラのオブジェクト言語として構築されたが、その論理構文は一部のファンを獲得した。

大規模なアセンブリ言語開発が衰退して以来、より洗練されたアセンブラに対する需要はほとんど見られなくなった。[ 36 ]それにもかかわらず、リソースの制約や対象システムのアーキテクチャの特殊性により高水準言語を効果的に使用できない場合には、アセンブラは今でも開発され、適用されている。[ 37 ]

強力なマクロ エンジンを備えたアセンブラでは、Masm32 パッケージで提供されるスイッチ マクロなどのマクロを介した構造化プログラミングが可能です (このコードは完全なプログラムです)。 

include \ masm32 \ include \ masm32rt.inc ; Masm32ライブラリを使用する.code demomain: REPEAT 20 switch rv ( nrandom , 9 ) ; 0 から 8 までの数字を生成します。mov ecx , 7 case 0 print "case 0" case ecx ; 他のほとんどのプログラミング言語とは異なり、print "case 7" ; Masm32 スイッチは「変数ケース」を許可します。case 1 .. 3 .if eax == 1 print "case 1" .elseif eax == 2 print "case 2" .else print "cases 1 to 3: other" .endif case 4 , 6 , 8 print "cases 4、6、または 8" default mov ebx , 19 ; print 20 stars .Repeat print "*" dec ebx .Until Sign? ;符号フラグが設定されるまでループする。endsw print chr$ ( 13 , 10 ) ENDM exit end demomain

アセンブリ言語の使用

プログラム内蔵型コンピュータが導入された当時、プログラムは機械語で記述され、パンチ穴付き紙テープからコンピュータにロードされるか、コンソールスイッチから直接メモリにトグルで入力されていました。キャスリーン・ブースは「アセンブリ言語を発明した」とされています[ 38 ] [ 39 ]。これは、1947年にロンドン大学バークベック校でARC2の開発に携わっていた彼女が、アンドリュー・ブース（後に夫となる）がロンドン高等研究所の数学者ジョン・フォン・ノイマンと物理学者ハーマン・ゴールドスタインに相談したことを受けて始めた理論研究に基づいています[ 39 ] [ 40 ]。

1948年後半、電子遅延記憶自動計算機（EDSAC）のブートストラッププログラムにアセンブラ（「イニシャル・オーダー」と呼ばれる）が統合されました。これは、IEEEコンピュータ協会によって最初の「アセンブラ」の考案者として認められているデイビッド・ウィーラーによって開発された1文字ニーモニックを使用していました。 [ 20 ] [ 41 ] [ 42 ] EDSACに関する報告書では、フィールドを命令語に結合するプロセスを表す「アセンブリ」という用語が導入されました。[ 43 ] SOAP（シンボリック最適アセンブリプログラム）は、1955年にスタン・ポーリーによって書かれたIBM 650コンピュータ用のアセンブリ言語でした。[ 44 ]

アセンブリ言語は、初期のコンピュータで必要とされた、エラーが発生しやすく、面倒で時間のかかる第一世代のプログラミングの多くを排除し、プログラマを数値コードの記憶やアドレスの計算といった面倒な作業から解放しました。アセンブリ言語はかつてあらゆる種類のプログラミングに広く使用されていました。1950年代後半までには、プログラミングの生産性向上を求めて、アセンブリ言語の使用は主に高級言語に取って代わられました。[ 45 ]今日でも、アセンブリ言語はハードウェアの直接操作、特殊なプロセッサ命令へのアクセス、または重大なパフォーマンス問題の解決に使用されています。[ 46 ]典型的な用途は、デバイスドライバ、低レベルの組み込みシステム、リアルタイムシステムです（§ 現在の用途を参照）。

数多くのプログラムが完全にアセンブリ言語で書かれました。Burroughs MCP (1961) は、オペレーティングシステムが完全にアセンブリ言語で開発されていない最初のコンピュータでした。これは、Algol 方言であるExecutive Systems Problem Oriented Language (ESPOL) で書かれていました。多くの商用アプリケーションもアセンブリ言語で書かれており、その中には大企業が開発したIBM メインフレームソフトウェアの大部分も含まれています。COBOL、FORTRAN、そして一部の PL/I は最終的にアセンブリ言語に取って代わりましたが、多くの大規模組織は1990年代までアセンブリ言語によるアプリケーションインフラストラクチャを維持していました。

アセンブリ言語は、 Apple II、Atari 8ビットコンピュータ、ZX Spectrum、Commodore 64などの8ビット家庭用コンピュータの主要な開発言語でした。これらのシステムにおけるインタープリタ型BASICは、最高の実行速度と、利用可能なハードウェアを最大限に活用するための機能を十分に利用できませんでした。アセンブリ言語は、Atari 2600やNintendo Entertainment Systemなどの8ビットコンソールのプログラミングにおいて、デフォルトの選択肢でした。

IBM PC互換機の主要ソフトウェアであるMS-DOS、Turbo Pascal、Lotus 1-2-3スプレッドシートなどはアセンブリ言語で書かれていました。コンピュータの速度が飛躍的に向上するにつれ、アセンブリ言語は主要な開発言語というよりは、 Doomのレンダリングなど、プログラムの一部を高速化するためのツールとなりました。1990年代には、アセンブリ言語はセガサターンなどのシステムのパフォーマンスを最大化するために使用され、[ 47 ] 、またTMS34010統合CPU/GPUを搭載したモータルコンバットやNBA Jamなどのアーケードハードウェアの主要言語としても使用されました。

現在の使用状況

高級言語と比較したアセンブリ言語の有用性とパフォーマンスについては議論がある。[ 48 ]

アセンブリ言語は特定のニッチな用途で重要視されていますが（下記参照）、最適化のためのツールは他にもあります。[ 49 ]

2017 年 7 月現在、TIOBE によるプログラミング言語人気指数では、アセンブリ言語はVisual Basicなどを上回り 11 位にランクされています。[ 50 ]アセンブラは、速度の最適化またはサイズの最適化に使用できます。速度の最適化の場合、最新の最適化コンパイラは、いくつかの反例はあるものの、高級言語を手書きのアセンブリと同じくらい高速に実行できるコードに変換すると主張されています。[ 52 ] [ 53 ] [ 54 ]最新のプロセッサとメモリサブシステムの複雑さにより、コンパイラとアセンブリプログラマの両方にとって効果的な最適化がますます困難になっています。[ 55 ] [ 56 ]プロセッサのパフォーマンスの向上により、ほとんどの CPU がほとんどの時間アイドル状態になり、[ 57 ]キャッシュミス、 I/O操作、ページングなどの予測可能なボトルネックによって遅延が発生し、多くのプログラマにとって生のコード実行速度は問題になりません。

アセンブリ プログラミングの使用がより一般的である特定のコンピュータ プログラミング領域がまだあります。

アセンブリ言語は、今でもほとんどのコンピュータサイエンスや電子工学のプログラムで教えられています。今日ではアセンブリ言語をツールとして日常的に扱うプログラマーは少ないですが、その基礎となる概念は依然として重要です。2進演算、メモリ割り当て、スタック処理、文字セットのエンコード、割り込み処理、コンパイラ設計といった基本的なトピックは、コンピュータがハードウェアレベルでどのように動作するかを理解しなければ、詳細に学ぶことは困難です。コンピュータの動作は基本的に命令セットによって定義されるため、こうした概念を学ぶ論理的な方法は、アセンブリ言語を学ぶことです。現代のコンピュータのほとんどは同様の命令セットを持っています。したがって、1つのアセンブリ言語を学ぶだけで、基本概念を学び、アセンブリ言語の使用が適切な状況を認識し、高水準言語から効率的な実行コードを作成する方法を理解するのに十分です。[ 23 ]

代表的な用途

  • アセンブリ言語は通常、システムのブートコードで使用されます。ブート コードとは、オペレーティング システムを起動する前にシステム ハードウェアを初期化してテストする低レベルのコードで、多くの場合ROMに格納されます( IBM 互換 PCシステムおよびCP/MのBIOSがその一例です)。
  • アセンブリ言語は、既存のシステム コールの可用性に依存できず、システムが実行される特定のプロセッサ アーキテクチャ用にシステム コールを実装する必要があるオペレーティング システム カーネルなどの低レベル コードによく使用されます。
  • 一部のコンパイラは、完全にコンパイルする前にまず高水準言語をアセンブリに変換し、デバッグや最適化の目的でアセンブリ コードを表示できるようにします。
  • PascalやC言語といった比較的低水準言語向けのコンパイラの中には、ソースコードにアセンブリ言語を直接埋め込むこと（いわゆるインラインアセンブリ）を可能にするものがあります。こうした機能を利用するプログラムは、ハードウェアプラットフォームごとに異なるアセンブリ言語を用いて抽象化を構築できます。システムの移植可能なコードは、これらのプロセッサ固有のコンポーネントを統一されたインターフェースを介して利用できるようになります。
  • アセンブリ言語はリバースエンジニアリングに役立ちます。多くのプログラムは機械語形式でのみ配布されており、逆アセンブラでアセンブリ言語に変換するのは簡単ですが、逆コンパイラで高水準言語に変換するのは困難です。インタラクティブ・ディスアセンブラなどのツールは、このような目的で逆アセンブルを多用しています。この手法は、ハッカーが商用ソフトウェアをクラッキングするために、また競合他社が競合他社のソフトウェアを同様の結果で作成するために使用されています。
  • アセンブリ言語は、特に処理能力と RAM が限られている初期のパーソナル コンピュータで実行速度を向上させるために使用されます。
  • アセンブラは、高水準言語のオーバーヘッドなしに、フォーマットされコメントが付けられたソースコードから他のコードで使用されるデータブロックを生成するために使用できます。[ 65 ] [ 66 ]

参照

注記

  1. ^メタアセンブラ以外
  2. ^ただし、これらの言語を実装するアセンブラ プログラムが汎用的であることを意味するものではありません。
  3. ^これは、この命令の2つの冗長形式のうちの1つであり、動作は同一です。1970年代後半から1980年代初頭にかけての8086やその他のいくつかのCPUは、命令セットに冗長性を備えています。これは、エンジニアにとって、冗長コードを削除するよりも、限られたサイズのシリコンチップに収まるようにCPUを設計する方が簡単だったためです（ドントケア用語を参照）。各アセンブラは通常、2つ以上の冗長命令エンコーディングのうち1つだけを生成しますが、逆アセンブラは通常、それらのどれでも認識します。
  4. ^ AMD は、Intel からのライセンスに基づいて、セカンドソースの Intel 8086、8088、80286 CPU、およびおそらく 8080A と 8085A CPU を製造していましたが、80386 以降、Intel は x86 CPU 設計を誰とも共有することを拒否しました (AMD はこれについて契約違反で訴えられました)。また、AMD は Intel の支援や承認なしに、32 ビットおよび 64 ビットの x86 ファミリ CPU を設計、製造、販売しました。
  5. ^ 7070 Autocoder では、マクロ定義はアセンブラが呼び出す 7070 マクロ ジェネレータ プログラムです。Autocoder は、マクロ ジェネレータが使用する特別なマクロを提供します。

参考文献

  1. ^ a b「アセンブラー言語」。z /OS & z / VM & z/VSE用高水準アセンブラー言語リファレンス バージョン1リリース6。IBM。2014 [ 1990]。SC26-4940-06。
  2. ^ 「アセンブリ：レビュー」（PDF） . コンピュータサイエンスとエンジニアリング.オハイオ州立大学工学部 . 2016年. 2020年3月24日時点のオリジナルよりアーカイブ（PDF） . 2020年3月24日閲覧。
  3. ^ Archer, Benjamin (2016年11月). 『Assembly Language For Students』. ノースチャールストン、サウスカロライナ州、米国: CreateSpace Independent Publishing . ISBN 978-1-5403-7071-6アセンブリ言語はシンボリック マシン コードとも呼ばれます。
  4. ^ Streib, James T. (2020). 「アセンブリ言語ガイド」.学部生向けコンピュータサイエンストピックス. 出版社: Springer International Publishing. doi : 10.1007/978-3-030-35639-2 . ISBN 978-3-030-35638-5. ISSN  1863-7310 . S2CID  195930813 .アセンブリ言語でのプログラミングは、機械語でのプログラミングと同じ利点がありますが、より簡単です。
  5. ^ Saxon, James A.; Plette, William S. (1962). 『IBM 1401のプログラミング：自己学習型プログラムマニュアル』 エングルウッド・クリフス、ニュージャージー州、米国: Prentice-Hall . LCCN 62-20615 . (注:アセンブリ プログラムという用語の使用)
  6. ^ Kornelis, AF (2010) [2003]. 「高水準アセンブラ – オペコードの概要、アセンブラディレクティブ」 . 2020年3月24日時点のオリジナルよりアーカイブ。 2020年3月24日閲覧。
  7. ^ 「マクロ命令」 . z/OS & z/VM & z/VSE用高水準アセンブラー言語リファレンス バージョン1リリース6. IBM . 2014 [1990]. SC26-4940-06.
  8. ^ Booth, Andrew D; Britten, Kathleen HV (1947). Coding for ARC (PDF) . Institute for Advanced Study, Princeton . 2022年11月4日閲覧。
  9. ^ウィルクス、モーリス・ヴィンセント、ホイーラー、デイビッド・ジョン、ギル、スタンレー・J. (1951). 『電子デジタル計算機用プログラムの作成』（1982年再版）. Tomash Publishers . ISBN 978-0-93822803-5. OCLC  313593586 .{{cite book}}:ISBN / 日付の非互換性（ヘルプ）
  10. ^ Fairhead, Harry (2017年11月16日). 「コンピュータ言語の歴史 - 1950年代の古典的10年間」 . I Programmer . 2020年1月2日時点のオリジナルよりアーカイブ。2020年3月6日閲覧。
  11. ^ 「アセンブリ言語はオペレーティングシステムにどのように依存するのか？」 Stack Exchange . Stack Exchange Inc. 2011年7月28日。2020年3月24日時点のオリジナルよりアーカイブ。 2020年3月24日閲覧。(注意: システム コールは、MVS、VSE、VM/CMS などによって異なる場合が多く、オペレーティング システムによってバイナリ/実行可能形式も異なる場合があります。)
  12. ^ Austerlitz, Howard (2003). 「コンピュータプログラミング言語」. PCを用いたデータ収集技術. Elsevier. pp.  326– 360. doi : 10.1016/b978-012068377-2/50013-9 . ISBN 9780120683772アセンブリ言語（またはアセンブラ）は、コンパイルされた低水準のコンピュータ言語です。基本的にアセンブラのニーモニックを特定のCPUが理解できるコマンドに1対1で直接変換するため、プロセッサに依存します。これらのアセンブラのニーモニックは、そのプロセッサの命令セットです。
  13. ^ Carnes, Beau (2022-04-27). 「ARMでアセンブリ言語プログラミングを学ぶ」 . freeCodeCamp.org . 2022-06-21閲覧.アセンブリ言語は特定のコンピューターアーキテクチャに特化していることが多いため、複数の種類があります。ARMはますます人気が高まっているアセンブリ言語です。
  14. ^ Brooks, Frederick P. (1986). 「銀の弾丸はない ― ソフトウェア工学における本質と偶然」IFIP第10回世界コンピューティング会議議事録. pp.  1069– 1076.
  15. ^ Anguiano, Ricardo. 「Linuxカーネルメインライン4.9 sloccount.txt」 . Gist . 2022年5月4日閲覧。
  16. ^ Daintith, John編 (2019). 「メタアセンブラ」 . 『コンピューティング辞典』 . 2020年3月24日時点のオリジナルよりアーカイブ。 2020年3月24日閲覧。
  17. ^ Xerox Data Systems (1975年10月). Xerox Meta-Symbol Sigma 5-9 Computers Language and Operations Reference Manual (PDF) . p. vi. 2022年10月9日時点のオリジナルよりアーカイブ(PDF)されています。 2020年6月7日閲覧。メタアセンブラとして使用することで、ユーザーは独自のプログラミング言語を設計し、最小限の労力でそのような言語用のプロセッサを生成することができます。
  18. ^ Sperry Univac Computer Systems (1977). Sperry Univac Computer Systems Meta-Assembler (MASM) Programmer Reference (PDF) . 2022年10月9日時点のオリジナルよりアーカイブ(PDF) 。 2020年6月7日閲覧。
  19. ^ 「Cコードでインラインアセンブリ言語を使用する方法」 gnu.org . 2020年11月5日閲覧。
  20. ^ a b c dサロモン、デイビッド（1993年2月）[1992]。カリフォルニア州立大学ノースリッジ校（米国カリフォルニア州）にて執筆。イアン・D・チヴァース編『アセンブラとローダー』（PDF）。エリス・ホーウッド著『コンピュータとその応用』（第1版）。英国ウェスト・サセックス州チスター：エリス・ホーウッド・リミテッド／サイモン＆シュスター・インターナショナル・グループ。7、237～238頁。ISBN 0-13-052564-2. 2020年3月23日時点のオリジナルよりアーカイブ（PDF） . 2008年10月1日閲覧。（14+294+4ページ）
  21. ^ Finlayson, Ian; Davis, Brandon; Gavin, Peter; Uh, Gang-Ryung; Whalley, David; Själander, Magnus; Tyson, Gary (2013). 「命令の静的パイプライン化によるプロセッサ効率の向上」 .組み込みシステム向け言語、コンパイラ、ツールに関する第14回ACM SIGPLAN/SIGBED会議論文集. pp.  33– 44. doi : 10.1145/2465554.2465559 . ISBN 9781450320856. S2CID  8015812 .
  22. ^ Beck, Leland L. (1996). 「2」. 『システムソフトウェア：システムプログラミング入門』 Addison Wesley .
  23. ^ a b Hyde, Randall (2003年9月) [1996年9月30日]. 「序文（「なぜこんなことを学ぶ必要があるのか​​？」）/ 第12章 クラスとオブジェクト」. The Art of Assembly Language (第2版). No Starch Press . ISBN 1-886411-97-2. 2010年5月6日時点のオリジナルよりアーカイブ。2020年6月22日閲覧。訂正: [1] (928ページ) [2] [3]
  24. ^ a b c d Intelアーキテクチャ・ソフトウェア開発者マニュアル、第2巻：命令セット・リファレンス（PDF）。第2巻。Intel Corporation。1999年。 2009年6月11日時点のオリジナル（PDF）からアーカイブ。 2010年11月18日閲覧。
  25. ^ Ferrari, Adam; Batson, Alan; Lack, Mike; Jones, Anita (2018-11-19) [2006年春]. Evans, David (編). 「x86アセンブリガイド」 . コンピュータサイエンス CS216: プログラムとデータ表現.バージニア大学. 2020年3月24日時点のオリジナルよりアーカイブ。 2010年11月18日閲覧。
  26. ^ 「SPARCアーキテクチャマニュアル バージョン8」(PDF) . SPARC International . 1992年. 2011年12月10日時点のオリジナル(PDF)からアーカイブ。 2011年12月10日閲覧。
  27. ^ Moxham, James (1996). 「ZINT Z80インタープリタ」 . ZINT用Z80オペコード. 2020年3月24日時点のオリジナルよりアーカイブ。 2013年7月21日閲覧。
  28. ^ IEEE Std 694-1985: マイクロプロセッサアセンブリ言語のIEEE標準。IEEEコンピュータ協会。1985年。ISBN 0-7381-2752-3. OCLC  1415906564 .
  29. ^ Hyde, Randall . 「第8章 MASM: ディレクティブと疑似オペコード」(PDF) . 『The Art of Computer Programming』 . 2020年3月24日時点のオリジナルよりアーカイブ(PDF) . 2011年3月19日閲覧。
  30. ^ 1401 オートコーダシステム、プログラム番号 1401-AU-037、バージョン 3、修正レベル 11 (PDF)。1965年12月7日。 2024年1月21日閲覧。マクロ命令のコーディング時に1401 オートコーダを使用する場合、以下の軽微な制限が適用されます。
  31. ^グリスウォルド、ラルフ・E. (1972). 「第1章SNOBOL4のマクロ実装」 サンフランシスコ、カリフォルニア州、米国: WHフリーマン・アンド・カンパニー. ISBN 0-7167-0447-1。
  32. ^ 「マクロ（C/C++）、Visual Studio 2008用MSDNライブラリ」。Microsoft Corp. 2012年11月16日。2020年3月24日時点のオリジナルよりアーカイブ。 2010年6月22日閲覧。
  33. ^ Kessler, Marvin M. (1970-12-18). 「*Concept* Report 14 - OS/360で構造化プログラミングを可能にするマクロの実装」 . MVSソフトウェア：Concept 14 Macros . 米国メリーランド州ゲイサーズバーグ：International Business Machines Corporation . 2020年3月24日時点のオリジナルよりアーカイブ。 2009年5月25日閲覧。
  34. ^ 「高水準アセンブラツールキットの機能によりプログラマの生産性が向上」 .アナウンスメントレター. IBM . 1995年12月12日. A95-1432. 2023年3月7日時点のオリジナルよりアーカイブ。
  35. ^ Whitesmiths Ltd (1980-07-15). A-自然言語リファレンスマニュアル.
  36. ^ 「アセンブリ言語：定義とAnswers.comからのその他の情報」answers.com。2009年6月8日時点のオリジナルよりアーカイブ。 2008年6月19日閲覧。
  37. ^ Provinciano, Brian (2005-04-17). 「NESHLA: Nintendo Entertainment System向け高レベル・オープンソース・6502アセンブラ」オリジナルより2020年3月24日アーカイブ。2020年3月24日閲覧。
  38. ^ Dufresne, Steven (2018年8月21日). 「キャスリーン・ブース：アセンブリを発明しながら初期のコンピューターを組み立てる」 . 2020年3月24日時点のオリジナルよりアーカイブ。2019年2月10日閲覧。
  39. ^ a b Booth, Andrew Donald ; Britten, Kathleen Hylda Valerie (1947年9月) [1947年8月].汎用電子デジタルコンピュータの設計における一般的な考慮事項(PDF) (第2版). The Institute for Advanced Study, Princeton, New Jersey, US: Birkbeck College, London . 2020年3月24日時点のオリジナルからのアーカイブ(PDF) . 2019年2月10日閲覧。以下のテキストに含まれる独創的ではないアイデアは、さまざまな情報源から得たものです。…しかしながら、多くの実りある議論をしてくださったJohn von Neumann教授とHerman Goldstein博士に感謝の意を表したいと思います。…
  40. ^ Campbell-Kelly, Martin (1982年4月). 「英国におけるコンピュータプログラミングの発展（1945年から1955年）」. IEEE Annals of the History of Computing . 4 (2): 121– 139. doi : 10.1109/MAHC.1982.10016 . S2CID 14861159 . 
  41. ^ Campbell-Kelly, Martin (1980). 「EDSACのプログラミング：ケンブリッジ大学における初期のプログラミング活動」. IEEE Annals of the History of Computing . 2 (1): 7– 36. doi : 10.1109/MAHC.1980.10009 .
  42. ^ 「1985年コンピュータパイオニア賞 アセンブリ言語プログラミングでデビッド・ウィーラーが受賞」 2018年3月27日。
  43. ^ウィルクス、モーリス・ヴィンセント(1949). 「EDSAC – 電子計算機」. Journal of Scientific Instruments . 26 (12): 385– 391. Bibcode : 1949JScI...26..385W . doi : 10.1088/0950-7671/26/12/301 .
  44. ^ da Cruz, Frank (2019年5月17日). 「IBM 650 磁気ドラム計算機」 . コンピューティングの歴史 - コンピューティングの年表.コロンビア大学. 2020年2月15日時点のオリジナルよりアーカイブ。 2012年1月17日閲覧。
  45. ^ Abell, John C. 「1956年10月15日：Fortranがコンピューティングの運命を永遠に変える」 Wired . ISSN 1059-1028 . 2024年3月2日閲覧。 
  46. ^ Collen, Morris F. (1994年3月～4月). 「インフォマティクスの起源」 .米国医療情報学会誌. 1 (2): 96– 97. doi : 10.1136/jamia.1994.95236152 . PMC 116189. PMID 7719803 .  
  47. ^ Pettus, Sam (2008年1月10日). 「SegaBase Volume 6 - Saturn」 . 2008年7月13日時点のオリジナルよりアーカイブ。 2008年7月25日閲覧。
  48. ^ Kauler, Barry (1997-01-09). Windows アセンブリ言語とシステムプログラミング: PC と Windows 向けの 16 ビットおよび 32 ビット低レベルプログラミング. CRC Press . ISBN 978-1-48227572-8. 2020年3月24日閲覧。現代のプログラミングの世界では、アセンブリ言語の適用可能性について常に議論が交わされています。
  49. ^ Hsieh, Paul (2020-03-24) [2016, 1996]. 「プログラミングの最適化」 . 2020-03-24にオリジナルからアーカイブ。2020-03-24に閲覧。 …設計変更はパフォーマンスに大きく影響する傾向がある…アセンブリ言語に直接進むべきではない…
  50. ^ "TIOBE Index" . TIOBE Software . 2020年3月24日時点のオリジナルよりアーカイブ。 2020年3月24日閲覧。
  51. ^ Rusling, David A. (1999) [1996]. 「第2章 ソフトウェアの基礎」 . Linuxカーネル. 2020年3月24日時点のオリジナルよりアーカイブ。2012年3月11日閲覧。
  52. ^ a b Markoff, John Gregory (2005年11月28日). 「楽しみのために、手で最速のコードを書く：人間のコンピューターがチップの速度を上げ続ける」 . The New York Times . シアトル, ワシントン州, 米国. 2020年3月23日時点のオリジナルよりアーカイブ。 2010年3月4日閲覧。
  53. ^ "Bit-field-badness" . hardwarebug.org . 2010年1月30日. 2010年2月5日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  54. ^ "GCC makes a mess" . hardwarebug.org . 2009年5月13日. 2010年3月16日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  55. ^ハイド、ランドール. 「大論争」 . 2008年6月16日時点のオリジナルよりアーカイブ。2008年7月3日閲覧。
  56. ^ 「Code Sourcery が再び失敗」 . hardwarebug.org . 2010年1月30日. 2010年4月2日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  57. ^ Click, Cliff; Goetz, Brian. 「A Crash Course in Modern Hardware」。2020年3月24日時点のオリジナルよりアーカイブ。 2014年5月1日閲覧。
  58. ^ 「Fargo IIでの68Kプログラミング」。2008年7月2日時点のオリジナルよりアーカイブ。2008年7月3日閲覧。
  59. ^ "BLAS Benchmark-August2008" . eigen.tuxfamily.org. 2008年8月1日. 2020年3月24日時点のオリジナルよりアーカイブ。 2010年3月4日閲覧。
  60. ^ "x264.git/common/x86/dct-32.asm" . git.videolan.org. 2010年9月29日. 2012年3月4日時点のオリジナルよりアーカイブ。 2010年9月29日閲覧。
  61. ^ “rav1e/README.md at v0.6.3” . GitHub .オリジナルから2023年2月22日アーカイブ。 2023年2月21日閲覧。
  62. ^ “README.md · 1.1.0 · VideoLAN / dav1d” . 2023年2月13日. 2023年2月22日時点のオリジナルよりアーカイブ。2023年2月21日閲覧。
  63. ^ Bosworth, Edward (2016). 「第1章 アセンブリ言語を学ぶ理由」 www.edwardbosworth.com . 2020年3月24日時点のオリジナルよりアーカイブ。 2016年6月1日閲覧。
  64. ^ 「z/OS バージョン 2 リリース 3 DFSMS データ・セット用マクロ命令」(PDF)。IBM。2019年2月15日。2021年6月25日時点のオリジナルからアーカイブ(PDF) 。 2021年9月14日閲覧。
  65. ^ Paul, Matthias R. (2001) [1996]、「NECPINWの仕様とリファレンスドキュメント」、 NECPINW.CPI - NEC Pinwriters用DOSコードページスイッチングドライバ（2.08版）、FILESPEC.TXT、NECPINW.ASM、EUROFONT.INC（NECPI208.ZIPより）、2017年9月10日時点のオリジナルからアーカイブ、 2013年4月22日取得
  66. ^ Paul, Matthias R. (2002-05-13). "[fd-dev] mkeyb" . freedos-dev . 2018年9月10日時点のオリジナルよりアーカイブ。 2018年9月10日閲覧。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Assembly_language&oldid=1330662967#Mnemonics」より取得