アセンブリ言語

アセンブリ言語

アセンブラからの典型的な二次出力- Motorola MC6800の元のアセンブリ言語（右）とアセンブルされた形式を表示
パラダイム	命令型、非構造化、多くの場合メタプログラミング（マクロ経由）、特定のアセンブラは構造化またはオブジェクト指向である
初登場	1947年; 77年前 （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]}は特定のコンピュータアーキテクチャに固有のものである。^{[11] [12] [13]}

同じアーキテクチャに複数のアセンブラがある場合もあれば、1 つのアセンブラが 1 つのオペレーティング システムまたは特定のオペレーティング システム専用である場合もあります。ほとんどのアセンブリ言語は、オペレーティング システム コールに特定の構文を提供しておらず、ほとんどのアセンブリ言語はどのオペレーティング システムでも普遍的に使用できます。^{[注 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アセンブラが挙げられます。ジャンプサイジングと呼ばれる^[20]ほとんどのアセンブラは、要求に応じて、任意の数のパスでジャンプ命令の置き換え（長いジャンプを短いジャンプまたは相対ジャンプに置き換える）を実行できます。他のアセンブラは、命令の単純な並べ替えや挿入さえ行う場合があります。たとえば、RISCアーキテクチャ用の一部のアセンブラは、 CPUパイプラインを可能な限り効率的に活用するための合理的な命令スケジューリングを最適化できます。^[21]

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

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

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

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

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

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

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

S1    B    前進
  ...
前輪駆動   *
  ...
BKWD   EQU *
  ...
S2     B   バックWD

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

• 高レベルのプロシージャ/関数の宣言と呼び出し
• 高度な制御構造 (IF/THEN/ELSE、SWITCH)
• 構造体/レコード、共用体、クラス、セットなどの高レベルの抽象データ型
• 高度なマクロ処理（ IBM 700 シリーズやIBM 7000 シリーズなどでは 1950 年代後半から、IBM System/360 (S/360) などでは 1960 年代から一般的なアセンブラで利用可能）
• クラス、オブジェクト、抽象化、多態性、継承などのオブジェクト指向プログラミング機能^[23]

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

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

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

10110000 01100001

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

B0 61

ここで、B0は「次の値のコピーをALに移動する」という意味で、 は6101100001 という値の 16 進表現です。これは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に移動する命令を表します。この命令の ^{[nb 3] 16 進形式は次のとおりです。}

88 E0

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

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

アセンブリ言語は、常に、この種の曖昧さのなさが構文によって普遍的に強制されるように設計されています。たとえば、Intel x86 アセンブリ言語では、16 進定数は数字で始まる必要があります。そのため、16 進数 'A' (10 進数の 10 に相当) は、 ではなく0Ahまたはと記述され、具体的にはレジスタAHの名前として表示されないようにします。(同じルールにより、レジスタBH、CH、およびDHの名前、および文字Hで終わり、それ以外は 16 進数字の文字のみを含むユーザー定義シンボル (単語 "BEACH" など) の曖昧さも防止されます。) 0AHAH

元の例に戻ると、x86オペコード10110000（B0）は8ビットの値をALレジスタにコピーし、10110001（ ）はそれをCLB1に移動し、10110010（ ）はそれをDLに移動します。これらに対するアセンブリ言語の例を以下に示します。^[24]B2

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 の対応があります。ただし、場合によっては、アセンブラは、一般的に必要な機能を提供するために、いくつかのマシン言語命令に展開される疑似命令(基本的にはマクロ) を提供することがあります。たとえば、「より大きいか等しい場合に分岐」命令がないマシンの場合、アセンブラは、マシンの「より小さい場合に設定」および「ゼロの場合に分岐 (設定命令の結果による)」に展開される疑似命令を提供することがあります。ほとんどのフル機能のアセンブラは、ベンダーやプログラマーがより複雑なコードやデータ シーケンスを生成するために使用する、豊富なマクロ言語 (後述) も提供します。アセンブラ環境で定義された疑似命令とマクロに関する情報はオブジェクト プログラムには存在しないため、逆アセンブラはマクロと疑似命令の呼び出しを再構築できず、それらの抽象アセンブリ言語エンティティからアセンブラが生成した実際のマシン命令のみを逆アセンブルできます。同様に、アセンブリ言語ソース ファイル内のコメントはアセンブラによって無視され、アセンブラが生成するオブジェクト コードには影響しないため、逆アセンブラは常にソース コメントを完全に復元できません。

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

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

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

アセンブラの作成者がステートメントを分類する方法と、使用する命名法には、かなりの多様性があります。特に、マシン ニーモニックまたは拡張ニーモニック以外のものを疑似操作 (疑似操作) と表現する人もいます。一般的なアセンブリ言語は、プログラム操作を定義するために使用される 3 種類の命令ステートメントで構成されています。

• オペコードニーモニック
• データ定義
• アセンブリ指令

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

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

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

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

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

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

疑似命令の名前は、マシン命令と区別するためにドットで始まることがよくあります。疑似命令を使用すると、プログラムの組み立てをプログラマーが入力したパラメーターに依存させることができるため、1 つのプログラムをさまざまな方法で組み立てることができます (さまざまなアプリケーション用など)。または、疑似命令を使用して、プログラムのプレゼンテーションを操作し、読みやすく保守しやすくすることもできます。疑似命令のもう 1 つの一般的な用途は、実行時データ用のストレージ領域を予約し、必要に応じてその内容を既知の値に初期化することです。

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

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

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

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

マクロ アセンブラには通常、マクロの定義、変数の定義、算術式、論理式、または文字列式の結果への変数の設定、反復、条件付きコードの生成などのディレクティブがあります。これらのディレクティブの一部は、マクロ定義内での使用に制限される場合があります (例: HLASMのMEXIT )。一方、その他のディレクティブは、オープン コード内 (マクロ定義外) で許可される場合があります (例: HLASM の AIFおよびCOPY )。

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

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

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

マクロは、メインフレーム時代に特定の顧客向けに大規模なソフトウェア システムをカスタマイズするために使用されました。また、顧客の担当者がメーカーのオペレーティング システムの特定のバージョンを作成して雇用主のニーズを満たすためにも使用されました。これは、たとえば、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発生します。曖昧さを回避するために、マクロプロセッサのユーザーはマクロ定義内で仮パラメータを括弧で囲むか、呼び出し側が入力パラメータを括弧で囲むことができます。^[31]

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

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

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

強力なマクロ エンジンを備えたアセンブラーでは、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   
	  	
	  
	 
		 
	 				
		 		
	   
		 
			 
		 
			 
		
			 
		
	   
		 
	
		  		     
		
			 
			 
		 		 
	
	  
  
  
 

プログラム内蔵型コンピュータが導入されたとき、プログラムは機械語で書かれ、紙テープからコンピュータにロードされるか、コンソールスイッチから直接メモリに切り替えられた。^[要出典] キャスリーン・ブースは「アセンブリ言語を発明したとされている」^{[37] [38]。これは、}アンドリュー・ブース（後に夫となる）がロンドン大学バークベック校でARC2に取り組んでいた1947年に、ロンドン高等研究所の数学者ジョン・フォン・ノイマンと物理学者ハーマン・ゴールドスタインに相談したことを受けて始めた理論的研究に基づいている。^{[38] [39]}

1948年後半、電子遅延記憶自動計算機（EDSAC）のブートストラッププログラムにアセンブラ（「初期命令」という名前）が組み込まれました。これは、IEEEコンピュータ協会によって最初の「アセンブラ」の作成者として認められているデビッド・ウィーラーによって開発された1文字のニーモニックを使用していました。 ^{[20] [40] [41]} EDSACのレポートでは、フィールドを命令語に結合するプロセスに「アセンブリ」という用語が導入されました。^[42] SOAP（Symbolic Optimal Assembly Program ）は、1955年にスタン・ポーリーによって書かれたIBM 650コンピュータ用のアセンブリ言語でした。^[43]

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

多数のプログラムが完全にアセンブリ言語で書かれました。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 ビット コンソールのプログラミングのデフォルトの選択肢でした。

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

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

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

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

開発者がアセンブリ言語の使用を選択する状況がまだあります。

• Atari 2600、Commodore 64、グラフ電卓など、高水準言語の選択肢が限られている古いプロセッサ^{[説明が必要]}を搭載したシステム用のコードを記述する。^{[57] 1970年代と1980年代のこれらのコンピュータ用のプログラムは、}デモシーンやレトロゲームのサブカルチャーの文脈で記述されることが多い。
• デバイス ドライバーや割り込みハンドラーなど、ハードウェアと直接対話する必要があるコード。
• 組み込みプロセッサまたはDSPでは、1 秒間に 1000 回または 10000 回発生する割り込みなど、高繰り返し割り込みでは、割り込みごとに必要なサイクル数が最短になります。
• コンパイラに実装されていないプロセッサ固有の命令を使用する必要があるプログラム。一般的な例としては、多くの暗号化アルゴリズムの中核にあるビット単位の回転命令や、バイトのパリティや加算の 4 ビットのキャリーの照会などがあります。
• 電話、自動車の燃料および点火システム、空調制御システム、セキュリティ システムのファームウェアなど、高級言語に関連付けられたランタイムコンポーネントまたはライブラリに頼らずに実行する必要があるスタンドアロン実行可能ファイル。
• パフォーマンスに敏感な内部ループを持つプログラム。アセンブリ言語では、高級言語では実現が難しい最適化の機会が提供されます。たとえば、BLAS ^{[51] [58]}を使用した線形代数や離散コサイン変換（x264のSIMDアセンブリバージョンなど） ^[59]などです。
• C などの高級言語のプログラムのベクトル化された関数を作成するプログラム。高級言語では、SIMD ニーモニックに直接マップされるコンパイラの組み込み関数によってこれが支援されることもありますが、それでも特定のベクトル プロセッサに固有の 1 対 1 のアセンブリ変換が行われます。
• シミュレーション、航空ナビゲーション システム、医療機器などのリアルタイムプログラム。たとえば、フライバイワイヤシステムでは、テレメトリを解釈して、厳しい時間制約内で処理する必要があります。このようなシステムでは、インタープリタ言語、自動ガベージコレクション、ページング操作、またはプリエンプティブ マルチタスクによって発生する可能性のある予測不可能な遅延の原因を排除する必要があります。このようなシステムにアセンブリ言語または低レベル言語を選択すると、プログラマーは処理の詳細をより詳細に把握して制御できるようになります。
• タイミング攻撃を防ぐために、実行に常に厳密に同じ時間がかかる暗号化アルゴリズム。
• rav1e（ AV1用エンコーダ）^[60]やdav1d（AV1用リファレンスデコーダ）^{[61]などのビデオエンコーダとデコーダには、利用可能な場合に}AVX2とARM Neon命令を活用するためのアセンブリが含まれています。
• IBMメインフレームコンピュータ用に書かれたレガシーコードを修正および拡張します。^{[62] [63]}
• 環境を完全に制御する必要がある状況、何事も当然とみなすことのできない極めて高度なセキュリティが求められる状況。
• コンピュータウイルス、ブートローダー、特定のデバイスドライバー、またはハードウェアや低レベルのオペレーティング システムに非常に近いその他の項目。
• 追加のオーバーヘッドを最小限に抑えながら監視、トレース、デバッグを行うための命令セット シミュレーター。
• クロスコンパイラが利用できない新しいプロセッサまたは特殊なプロセッサ上に高級言語が存在しない状況。
• 次のようなプログラム ファイルの リバース エンジニアリングおよび変更:
  • 元々高級言語で記述されていたかどうかわからない既存のバイナリ。たとえば、ソース コードが入手できない、またはソース コードが失われたプログラムを再作成する場合や、プロプライエタリ ソフトウェアのコピー保護をクラックする場合などです。
  • ビデオゲーム（ROM ハッキングとも呼ばれます）は、いくつかの方法で可能です。最も広く使用されている方法は、アセンブリ言語レベルでプログラム コードを変更することです。

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

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

• コンパイラ
• アセンブラの比較
• 逆アセンブラ
• 16進数
• 命令セットアーキテクチャ
• リトルマンコンピュータ– 10 進アセンブリ言語を備えた教育用コンピュータモデル
• ニブル
• 型付きアセンブリ言語

• バートレット、ジョナサン (2004)。 『プログラミングの基礎 - Linux アセンブリ言語を使用したプログラミング入門』。Bartlett Publishing。ISBN 0-9752838-4-7. 2020年3月24日時点のオリジナルよりアーカイブ。2020年3月24日閲覧。[4]
• ブリトン、ロバート (2003)。MIPSアセンブリ言語プログラミング。プレンティス ホール。ISBN 0-13-142044-5。
• Calingaert, Peter (1979) [1978-11-05]。ノースカロライナ大学チャペルヒル校で執筆。Horowitz , Ellis (編)。アセンブラ、コンパイラ、プログラム翻訳。コンピュータソフトウェアエンジニアリングシリーズ (第 1 刷、第 1 版)。米国メリーランド州ポトマック: Computer Science Press, Inc. ISBN 0-914894-23-4. ISSN  0888-2088. LCCN  78-21905 . 2020年3月20日閲覧。（2+xiv+270+6ページ）
• Duntemann, Jeff (2000)。アセンブリ言語ステップバイステップ。Wiley。ISBN 0-471-37523-3。
• ハイド、ランドール (2010)。アセンブリ言語の芸術(第 2 版)。No Starch Press。ISBN 978-1593272074。
• Jorgensen 編「Ubuntu を使用した x86-64 アセンブリ言語プログラミング」(PDF)。
• Kann, Charles W. (2015). 「MIPSアセンブリ言語プログラミング入門」。2020年3月24日時点のオリジナルよりアーカイブ。2020年3月24日閲覧。
• Kann, Charles W. (2021)。「アセンブリ言語プログラミング入門：基礎から実践まで：ARM版」。オープン教育リソース。
• ノートン、ピーター、ソチャ、ジョン(1986)。ピーター ノートンの IBM PC 用アセンブリ言語ブック。ニューヨーク、米国: ブレイディ ブックス。
• シンガー、マイケル (1980)。PDP -11. アセンブラ言語プログラミングとマシン編成。ニューヨーク、米国: John Wiley & Sons。
• スウィートマン、ドミニク (1999)。MIPS Runを参照。Morgan Kaufmann Publishers。ISBN 1-55860-410-3。
• ウォルドロン、ジョン (1998)。RISCアセンブリ言語プログラミング入門。アディソンウェスリー。ISBN 0-201-39828-1。
• 「ASM コミュニティ ブック」。2009 年。2013 年 5 月 30 日時点のオリジナルよりアーカイブ。2013年 5 月 30 日閲覧。(ASM コミュニティによる「役立つ ASM 情報、チュートリアル、コード例が満載のオンライン ブック」は、インターネット アーカイブにアーカイブされています。)

• WikiWikiWebのアセンブリ言語とアセンブリ言語の学習ページ
• アセンブリ言語プログラミングの例