アセンブリ言語（アセンブリげんご、assembly language）とは、コンピュータ、マイクロコントローラ、その他のプログラム可能な機器を動作させるための機械語を人間にわかりやすい形で記述する、代表的な低水準言語である。プロセッサが直接実行できる言語は、機械語である。しかし、機械語は、バイナリ（数値）の羅列なので人間には理解しにくい。そこで、機械語を直接記述するのではなく、ニーモニックと呼ぶ命令語でプログラムを記述することで、人間により分かりやすくしたものがアセンブリ言語である。ただし、アセンブリ言語の意味は、個々のプロセッサに依存する。したがって、高水準言語と比べると移植性は低い。アセンブリ言語で書いたプログラムを機械語プログラムに変換することをアセンブル (assemble) すると言う。また、それを行うプログラムのことをアセンブラ (assembler) と言う。なお、アセンブリ言語の意味で、「アセンブラ」または「アセンブラ言語」(Assembler Language)と呼ぶ場合がある。また、初期のコンピュータでは、「アセンブラ」を「アセンブリプログラム」と呼ぶ例もあった。アセンブリ言語の命令には、機械語に対応したものと、アセンブラに対する命令（疑似命令）やマクロがある。これらが機械語と1対1で対応するため、プログラマがCPUの動作を把握しながらプログラムを記述することができる。アセンブリ言語では、機械語に相当する低水準な操作またはオペコードをニーモニックで表す。オペコードによっては、機械語命令の一部として1つまたは複数のオペランドが必要である。また、多くのアセンブリ言語は、オペランドとしてラベルやシンボルを使ってアドレスや定数を表すことができ、それらの値をプログラム内にそのまま書く（ハードコーディング）のを防ぐことができる。マクロアセンブラはマクロ命令機能を備えており、アセンブリ言語のテキストに名前を事前に割り当て、その名前を使うことで他のコードにそのテキストを挿入できる。多くのアセンブラは、プログラム開発を支援したり、アセンブリ過程を制御したり、デバッグを支援したりといった付加機構を備えている。機械語は、実行したい計算の内容をCPUの内部構造に依存した非常に単純な操作に分割・変換したものであるため、人間には理解しづらい。したがって、機械語を並べながらプログラミングするのは、人間のプログラマにとっては負担が大きかった。そこで、機械語そのものを書く代わりに、機械語の「意味」に相当する短い記号や単語を対応させ、それを記述してプログラミングをすることが考えられた。世界で最初に実用的に稼働したノイマン型電子計算機とされるEDSACのローダ（外部記憶装置からプログラムやデータを読み出して主記憶装置に書き込むプログラム）でも、原始的なアセンブラの機能がすでに実装されている。EDSACは、ワード指向アーキテクチャで命令長が1ワードの固定長命令のマシンであり、入力装置は紙テープでありキャラクタ指向である。紙テープ上の A 1 0 0 F という文字列から十進法を数値に変換するなどの処理をおこない、「100番地の値をアキュムレータに加算する」という1ワードの命令を生成するといった機能が、EDSACのローダには実装されていた。機械語への変換は、人間が手で行うこともある。これをハンド・アセンブルと呼ぶ。単に定められた規則に従って記号や単語から機械語を生成するだけなので、自動的に機械語を出力するプログラムが作られるようになった。このプログラムをアセンブラという。コンピュータの歴史の初期には、このような、プログラムによって機械語プログラムを生成することを自動プログラミングと呼んだ。ドナルド・ギリースは、まだ発明されていなかったアセンブラを開発中に、フォン・ノイマンから開発を即座に止めるように言われた、という1950年代初期ならではの逸話がある。当時は、人間が手作業でもできるような瑣末な仕事をコンピュータにさせるような時代が来るとは考えられておらず、単に時間の無駄だとノイマンは考えたのである。アセンブラは、アセンブリ命令ニーモニックをオペコードに変換し、シンボル名をメモリ位置や他の実体に変換することでオブジェクトコードを生成する。シンボル名による参照の利用はアセンブラの重要な機能であり、面倒な計算やプログラム修正に伴うアドレスの更新の手間を省くことができる。多くのアセンブラはマクロ機能を備えており、よく使用する命令列をサブルーチン呼び出しではなくインライン展開することができる。実行ファイルを生成するのにソースファイルを何回パス（走査）するかでアセンブラを分類できる。どちらの場合も、アセンブラは最初のパスで各命令のサイズを確定させる必要があり、それによって後に出現するシンボルのアドレスを計算する。命令のサイズは後から定義されるオペランドの型や距離に依存することがあるため、アセンブラは最初のパスでは悲観的な見積もりをし、必要に応じてその後のパスまたは errata にて1つ以上のNOP命令（何もしない命令）を挿入してすき間を埋める必要がある。最適化を行うアセンブラでは、最初の悲観的コードをその後のパスで稠密なコードに書き換えてアドレスの再計算を行うことがある。もともとワンパスアセンブラは高速であるためよく使われていた。マルチパス動作をするには、磁気テープを巻き戻したりパンチカードのデッキをセットし直して読み込む必要があったためである。現代のコンピュータではマルチパスであってもそのような遅延は生じない。マルチパスアセンブラは errata がないため、リンク処理（アセンブラが直接実行コードを生成する場合はローダの処理）が高速化される。より洗練されたは言語として次のような抽象化を提供する。クロスアセンブラはクロスコンパイラと似ており、あるプラットフォームで動作するが、そのプラットフォームではなく別のプラットフォーム向けのオブジェクトコードを生成するアセンブラを指す。小型の組み込みシステムなど、対象システムでアセンブラを動作させられない場合に使用することが多い。その場合、生成した機械語コードを対象システムに転送する何らかの手段が必要である。単に機械語コードをバイト単位に転送することもできるが、ASCII表現の転送用フォーマットがメーカーから提供されている（モトローラの、インテルのなど）。メタアセンブラは、アセンブリ言語の文法や意味論を記述したものを入力とし、その言語のためのアセンブラを出力するプログラムである。アセンブリ言語で書かれたプログラムは、プロセッサの命令に対応したニーモニックの列、ディレクティブや擬似命令と呼ばれるメタな文、コメント、データで構成されている。ニーモニックとは、機械語の命令がプロセッサでおこなう動作を表現する英単語ないしその省略（LoadをLDなど）で表現したものである。通常の文はオペコードのニーモニックで始まり、パラメータ（データ、引数）のリストがそれに続く。それらをアセンブラが機械語命令に翻訳し、メモリにロードして実行できる形式にする。なかには、パイプライン処理などを最適化するために命令順序を入れ替えたり、ラベルの位置関係によってアドレッシングモードを最適化するアセンブラもあり、必ずしもソーステキストの記述とアセンブルの結果が直接対応するとは限らない。オペランドにはソースとデスティネーションの二種類があり、データとして読み取られるのがソースで、オペコードで示された命令の実行結果が格納されるのがデスティネーションである。ソースには定数・レジスタ・メモリのいずれか、デスティネーションにはレジスタ・メモリのいずれかを指定する。なお、オペランドの記述順序は、上の例では「デスティネーション, ソース」だが、「ソース, デスティネーション」の順に書くアセンブリ言語もある。また、オペランドの個数は命令によって異なり、典型的なオペランドは0以上のソースと1つのデスティネーションからなるが、プロセッサにより、暗黙のソースやデスティネーションを持つためにそれらを記述しない命令や、オペランドを持たない命令を持つ場合もある。例えば、次の命令はx86/IA-32プロセッサのもので、8ビット即値をレジスタに入れる命令である。この命令のバイナリコードは 10110 で、その後に3ビットのレジスタを指定する識別子が続く。"AL" レジスタの識別子は 000 なので、次に示す機械語は "AL" レジスタに 01100001 というデータをロードする。このバイナリコードを人間が読みやすいように十六進法で表現すると次のようになる。ここで、codice_1 は「"AL"に後続の値をコピーする」ことを意味し、codice_2 は 01100001 を十六進法で表したもの（十進法では 97）である。インテルのアセンブリ言語では、この種の命令に MOV というニーモニックを割り当てており、セミコロン以下に説明的コメントを添えたアセンブリ言語での表現は次のようになる。この場合、定数61Hがソース、レジスタALがデスティネーションに該当し、命令が実行されると、定数61Hが、レジスタALに単純に格納される。これが人間にとってはさらに読みやすく覚えやすい。アセンブリ言語によっては、MOV のようなニーモニックはロードやデータのコピー/移動を行う命令群を表すのに使われ、オペランドの種類によって実際のオペコードが異なっていてもニーモニックとしては同じものを使う。また、データのコピー/移動の方向などによって別々のニーモニックを使うアセンブリ言語もある（「メモリからレジスタへの移動」を L、「レジスタからメモリへの移動」を ST、「レジスタからレジスタへの移動」を LR、「即値をメモリへ移動」を MVI など）。インテルのオペコード 10110000 (codice_1) は8ビットの値を "AL" レジスタにコピーするが、10110001 (codice_4) は "CL" レジスタにコピーし、10110010 (codice_5) は "DL" レジスタにコピーする。これらをアセンブリ言語で表現すると次のようになる。MOVの構文には次の例のようにさらに複雑なものもある。MOV というニーモニックを使った文は、その内容によってアセンブラが 88-8E、A0-A3、B0-B8、C6、C7 のいずれかのオペコードに変換するので、プログラマはオペコードを知る必要がないし、オペコードを覚える必要もない。アセンブリ言語から機械語への変換はアセンブラが行うが、逆方向の変換の一部は逆アセンブラが行う。高水準言語とは異なり、単純なアセンブリ構文と機械語命令には1対1の関係がある。しかしアセンブラは擬似命令（マクロの一種）を提供していることがあり、1つの擬似命令をよく使われる機械語命令列に展開する。例えば、大小比較による条件分岐命令を持たないマシンの場合、アセンブラで大小比較命令とゼロなら分岐する条件分岐命令（比較命令の結果を使用）に展開される擬似命令を用意したりする。多くの高機能アセンブラは豊富なマクロ言語機能を備えており、複雑なコード列やデータシーケンスを生成できる。コンピュータ・アーキテクチャはそれぞれ独自の機械語を持つ。アーキテクチャが異なれば、サポートする命令の数や種類が異なり、レジスタの大きさや個数が異なり、データの格納形式が異なる。汎用コンピュータの多くは機能的にほぼ同等だが、実装は異なるので、アセンブリ言語にはその差異が反映されている。機械語の命令セットは、プロセッサによって異なる。命令セットが同じでも様々なニーモニックやアセンブリ言語の文法が存在しうる。一般にプロセッサの設計者あるいは製造者によって定義されたニーモニックが標準とされるが、アセンブラによってはこれと異なるニーモニックを用いる場合もある（GNUアセンブラのgasのインテルプロセッサ用など）。アセンブラの開発者によって用語の使い方に大きな差異があり、文の分類などが異なる。例えば、マシンのニーモニックや拡張ニーモニック以外は全て擬似命令と呼ぶ場合もある。典型的なアセンブリ言語は、プログラムの操作の定義に使われる命令文を以下の3種類に分類する。アセンブリ言語の命令文は一般に非常に単純で、高水準言語のそれとは異なる。一般にニーモニックは1つの機械語命令（オペコード）のシンボル名であり、個々の機械語命令には少なくとも1つのオペコード・ニーモニックが対応している。命令は一般に「オペコード」と0以上の「オペランド」で構成される。多くの命令は1つまたは2つの値を参照する。オペランドには即値（命令内に置かれる値）、レジスタ（暗黙のうちに使用される場合もある）、記憶装置内のデータの位置を示すアドレスなどがある。「拡張ニーモニック」はオペコードと特定オペランドの組合せを表すのに使われることが多い。例えば、System/360では、BC 命令にマスク15を組み合わせたものが B、BC 命令にマスク0を組み合わせたものが NOP という拡張ニーモニックで表される。「拡張ニーモニック」は命令の特殊な用途をサポートするのに使われることが多く、本来の命令の名称からはその用途が連想できないときに使うことが多い。例えば、多くのCPUは明示的にNOP命令を用意していないが、その用途に使える命令は存在する。8086では "xchg ax,ax" という命令が "nop" として使えるので、アセンブリ言語で "nop" を記述すると "xchg ax,ax" という命令に変換される。逆アセンブラにもこのあたりを認識し、"xchg ax,ax" を "nop" に変換するものがある。同様にIBMのSystem/360とSystem/370のアセンブラでは、拡張ニーモニック "NOP" と "NOPR" を使用し、それぞれ "BC" と "BCR" のマスク0の命令に変換する。SPARCアーキテクチャでは、拡張ニーモニックを "synthetic instructions" と呼んでいる。アセンブラによっては単純な組み込みマクロ命令を備えており、数個の機械語命令に展開される。例えば、一部のZ80用アセンブラでは、"ld hl,bc" というマクロ命令を "ld l,c" と "ld h,b" という2命令に展開する。データと変数を保持するデータ要素を定義するのに使われる命令文がある。データの型、長さ、境界（アライメント）を定義する。また、そのデータがプログラム外部（別ファイルでアセンブルされたプログラム）からも利用可能なのか、それともデータセクションを定義したプログラム内でのみ使用可能なのかも定義できる。一部のアセンブラはこれを擬似命令に分類している。アセンブリディレクティブは、擬似命令とも呼ばれ、アセンブラがアセンブリ実施中に実行すべき命令となっている。プログラマが入力するパラメータによって、異なった形でアセンブルが行われるよう指示することができる。また、プログラムの見た目を操作して、可読性と保守性を向上させるのにも使われる。例えば、記憶装置の領域を予約し、その初期内容を指定するディレクティブなどがある。ディレクティブの名称はドットで始まることが多く、それによって通常のニーモニックと区別している。擬似オペコード (pseudo-opcode) と言った場合、オブジェクトコードを実際に生成するディレクティブのみを指すこともある。シンボリックアセンブラでは、任意の名前（ラベルまたはシンボル）とメモリ位置を対応付けることができる。通常、定数や変数に名前をつけることができ、命令文ではそれらの位置を名前で参照できる。実行コードではサブルーチンのエントリポイントと名前を関連付け、サブルーチンを名前で呼び出すことができる。サブルーチン内では、分岐命令の分岐先をラベルで示すことができる。一部のアセンブラは「ローカルシンボル」をサポートしており、通常のシンボルとは語彙的に区別する（例えば、"10$" を分岐先に使用するなど）。一部のアセンブラは柔軟なシンボル管理を提供しており、複数の名前空間を管理したり、データ構造内のオフセットを自動的に計算したり、リテラル値やアセンブラが実施した単純な計算結果を参照するラベルを割り当てたりすることができる。ラベルは定数や変数をリロケータブルなアドレスで初期化するのにも使える。他の言語と同様アセンブリ言語でもソースコードにコメントを付与でき、アセンブラはそれらを無視できる。高水準言語に比べて可読性が低いため、コメントの重要性は高い。これらの機能を多用することで低水準のコードのコーディングや保守の問題を大幅に単純化することができる。コンパイラや逆アセンブラが生成するアセンブリソースはコメントがなく、自動生成されるシンボルが意味不明で、データ定義もないため、非常に可読性が低い。マクロの使用はアセンブリ言語に限らず（さらには、プログラミングに限らず）一般的な技法だが、アセンブリ言語でのプログラミングでは特に有用である。m4のような汎用のマクロプロセッサが使われることもあれば、アセンブラに組み込まれたマクロもある。以下ではアセンブラに組み込まれたマクロについて述べる。多くのアセンブラは事前定義されたマクロをサポートしており、中にはユーザーが定義可能なマクロをサポートしているものもある。マクロは命令列と変数や定数の定義を埋め込むことができ、その中にオペコードやディレクティブの列が含まれる。マクロが定義されると、その名前をニーモニックとして使用できる。アセンブラはソース内にマクロを発見すると、対応するコード列に置き換え、元からソースにそのコード列が存在したかのように処理をする（アセンブラによっては、マクロを展開した中にマクロがあれば、それも展開することができる）。マクロは短い名前だが、数行からかなり長い行数のコードに展開されるので、アセンブリ言語のプログラムの見た目を短くすることができる。また、マクロによってアセンブリ言語プログラムに高水準の構造を追加でき、パラメータ付きのデバッグ用コードを埋め込むなどの利用法がある。引数が使えるマクロを持つものもある。中には洗練されたマクロ言語を備えたアセンブラもあり、オプションパラメータ、記号変数、条件文、文字列操作、算術演算などの高水準言語要素を持ち、マクロ実行中にそれらを使用でき、またマクロがコンテキストをセーブしたり情報を交換したりすることも可能である。そういったアセンブラでは、マクロの引数に基づいて大量のアセンブリ言語命令またはデータ定義を生成できる。例えば、レコード風のデータ構造や展開されたループを生成するのに使え、複雑なパラメータに基づいてアルゴリズム全体を生成することもできる。そのようなマクロで大いに拡張されたアセンブリ言語を使用すると、あたかも一種の高水準言語であるかのようにプログラムを書くことができることもある。メインフレームの時代には、マクロは特定顧客の大規模ソフトウェアシステムのカスタマイズや、メーカーのオペレーティングシステムを顧客の要望に合わせた特注版にするのに使われていた。例えば、IBMの 、リアルタイムトランザクション処理用アドオン、CICS、/TPF（コンピュータ予約システム (CRS) やクレジットカード会社で使われているトランザクションOS）などで使われてきた。一方で、（やはりアセンブリ言語に限られないが）マクロには「落とし穴」も多い。最も単純なものとしては、式としての意味に従って変換されるのではなく、文字列から対応する文字列に変換されるためによるバグがある。例えば、次のようなマクロがあるとする。このマクロは foo という名前で仮引数 a をとる。呼出・展開時に a に渡された実引数と、（グローバル変数または定数である）b とを掛け、load する。しかし実引数が、a-c というような式であった場合、マクロとしては load a-c*b と展開され、（おそらく）意図されていない結果を招く。これを防ぐにはマクロ定義内で仮引数は常に括弧で囲むようにするか、呼び出し時に実引数が問題を起こしそうな式の場合は括弧で囲むようにする。このような問題は括弧で解決するが、マクロにおいて発生する問題として、一般に容易に解決できないことが知られている「名前の捕捉」という問題がある。たとえば直前の例のマクロの場合、実引数が b という名前であったとすると load b*b となって、実引数の自乗を計算する、という、（おそらく）前述の例よりももっと意図されていない結果を招く。このようなマクロの性質を一般にこの分野の専門用語で「不健全」と言う。詳細は「健全なマクロ」の記事を参照のこと。構造化プログラミングの要素を取り入れたアセンブラもある。最初期の例として "Concept-14 macro set" がある。Dr. H.D. Mills (March, 1970) が提案し、IBMの連邦政府システム部門の Marvin Kessler が実装したもので、System/360 のマクロアセンブラに IF/ELSE/ENDIF などの制御構造を導入した。これはRatforなどと同様の発想で、コードの表面上からGOTOを消し、制御構造風な読みやすいマクロでコードを書けるというものだった。1980年代にはこの手法が広まった。独特の設計として、（Unix系OS やCコンパイラで有名）が開発した8080/Z80プロセッサ用「ストリーム指向」アセンブラ A-natural がある。この言語はオペコードやレジスタ、メモリ参照といった要素をそのまま扱えるためアセンブラと呼ばれているが、実行順序を示す構文を取り入れていた。括弧やその他の記号でプログラムのブロック構造を指定したり、生成した命令列の実行順序を制御できる。A-natural は同社のCコンパイラが中間コードとしており、人間が直接使うものではなかったが、その構文にはファンも存在した。また構造化プログラミングとは若干異なるが、キャリーラボはBASIC風の文法のアセンブリ言語 BASE を開発した。Z80用の BASE-80 とMC6809用の BASE-09 がある。BASEの表記例は下記の通り（BASE-09）上記の記述は下記のアセンブラ表記に対応する。その後、アセンブリ言語で大規模システムを開発することが少なくなり、アセンブリ言語の高機能化の需要が減っていった。それでも、資源の制約が強い場合やターゲットシステムのアーキテクチャが高水準言語の効率的使用を妨げている場合、アセンブラは有用であり、高機能なアセンブラの開発も行われている。アセンブリ言語は、ごく単純なものまで含めれば、プログラム内蔵方式のコンピュータの最初期の1940年代から存在している。EDSAC (1949) の "initial orders"（現代の用語ではブートローダーに相当するもの）は、テープにパンチされた十進によるアドレスを、内部表現の二進に変換するなどの機能を持っていた（命令については、「1文字のニーモニック」に見えるかもしれないが、それは実際には同機の機械語そのものである）。ナサニエル・ロチェスターは1954年に IBM 701 用アセンブラを書いている。1955年、Stan Poley が IBM 650 用言語アセンブリSOAP (Symbolic Optimal Assembly Program) を開発した。アセンブリ言語は、初期のコンピュータでのプログラミングでの入力ミス削減や時間短縮に貢献し、機械語コード参照やアドレス計算といった退屈な作業からプログラマを解放した。その後高水準言語へと移行していったが、ハードウェアの直接操作、特殊命令の使用、性能向上といった目的で今もアセンブリ言語が使われている。特にデバイスドライバ、組み込みシステム、リアルタイムシステムでよく使われている。歴史的には多数のプログラムがアセンブリ言語だけで書かれてきた。ALGOLの方言であるで書かれた (1961) が登場するまで、オペレーティングシステムはアセンブリ言語で書くのが普通だった。商用アプリケーションもアセンブリ言語で書かれている。例えば、IBMのメインフレーム用ソフトウェアの多くはアセンブリ言語で書かれていた。COBOL、FORTRAN、PL/I などが取って代わっていったが、1990年代になってもアセンブリ言語のコードベースを保守し続けていた大企業も少なくない。初期のマイクロコンピュータでは、アセンブリ言語がよく使われており、OSやアプリケーションもアセンブリ言語で書かれた。これは、リソースの制約が厳しく、メモリやディスプレイのアーキテクチャが特殊だったからである。また、マイクロコンピュータ向けの高水準言語のコンパイラがなかったという面も重要である。また、初期のマイクロコンピュータのユーザはホビーストが主であり、何でも自前で作るという精神もそれに影響していたと見られる。1980年代から1990年代にかけて、ホームコンピュータ（ZX Spectrum、コモドール64、Amiga、Atari ST など）でもアセンブリ言語がよく使われていた。というのもそれらのBASICは性能が低く、ハードウェアの全機能を利用できないことが多かったためである。例えば、Amigaにはフリーウェアのアセンブリ言語統合開発環境 ASM-One assembler があり、Microsoft Visual Studio に匹敵する機能を備えていた。Don French が開発した VIC-20 用アセンブラは 1,639 バイトという小ささで、世界一小さいアセンブラと言われている。アドレスをシンボルで表現でき、各種アドレス計算（四則演算、AND、OR、冪乗など）が可能だった。商用製品でアセンブリ言語を使う最大の理由は、使用メモリ量を最小にし、オーバーヘッドを最小にし、性能と信頼性を向上させるためである。1980年代のビジネスソフトでは、例えば表計算ソフト Lotus 1-2-3 などはアセンブリ言語で書かれていた。日本では松が有名である。1990年代に入っても、コンシューマーゲームの多くはアセンブリ言語で書かれていた。ある業界関係者は、セガサターンの最高性能を引き出してプレイステーションに対抗するには、アセンブリ言語を使うしかなかったとしている（プレイステーションにはソニーが提供するCライブラリが存在した）。また、アーケードゲームのNBAジャム (1993) もアセンブリ言語で開発されている。ただし一方で、ファミコン時代すでにメタルスレイダーグローリーやスーパーファミコンのMOTHER 2・シムシティ、プレステのクラッシュ・バンディクーで、開発の一部にLISPが使われていたという話もあり、アセンブリ言語が全てという世界だった、と認識するのは誤りである。アセンブリ言語と高水準言語を比較した有用性と性能についての議論は、これまでよく行われてきた。アセンブリ言語は、後述するように特定の用途で重要な役割を演じている。しかし、一般的には、最適化コンパイラは人手で書かれたアセンブリ言語のコードと同等の性能を発揮すると言われている（例外もある）。最近のプロセッサやメモリサブシステムは複雑化してきたため、コンパイラでもアセンブリ言語でも効果的な最適化がますます困難になってきている。さらに言えば、プロセッサが高性能化するにしたがって入出力やページングによる遅延が無視できないレベルとなったため、コーディングによる性能追求は多くのプログラマにとって大きな問題ではなくなってきている。開発者がアセンブリ言語を選択する状況として、次のようなものがある。コンピュータ科学のカリキュラムでは、アセンブリ言語（ないし機械語）の基礎は必修である。なぜなら、コンピュータ科学ではコンピュータのハードウェア、具体的にはプロセッサやアーキテクチャについて学ぶが、（普通の）プロセッサが直接実行するのは高水準言語ではなく機械語だからであり、アーキテクチャは機械語の命令セットとして定義されるものだからである（Instruction Set Architecture、ISA）。またシステムソフトウェア、具体的にはコンパイラやオペレーティングシステムの「最も下側」の部分の理解のためにも必須である。なお一方で、最近のコンピュータの命令セットはその多くはどれも似ている。したがって、どれか1つのアセンブリ言語を学ぶだけで、基本概念、どんなときにアセンブリ言語を使用するのが適しているか、高水準言語から効率的な実行コードを生成する方法をある程度は学習できる。より実践的には、コンパイラが生成したコードを確認したい場合といったようなものがある。普段は意識しないような場所であっても、何か理由があっていざという時には腑分けできるということは重要である。これは、子どもが算数（筆算など）を学ぶ必要があるが、日常の計算には電卓を使っているのに似ている。また、「最適化の最後の手段」でもある。Unix系システムでは、アセンブラを as と呼ぶのが一般的だが、実体はそれぞれのOSで異なる。GNUアセンブラを使っているものが多い。同じ系統のプロセッサであっても、複数のアセンブリ言語の方言が存在する。アセンブラによっては他の方言のアセンブリ言語も使用可能な場合がある。例えば、TASMはMASM用コードを入力として受け付け可能だが、逆は不可能である。とNASMは文法がほぼ同じだが、サポートしているマクロが異なるため、相互の翻訳は困難である。いずれも基本機能は同じだが、追加機能に差異がある。

出典:wikipedia