アセンブリ言語

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
モトローラ MC6800 のアセンブリ言語のソースコード

アセンブリ言語(アセンブリげんご、assembly language)とは、コンピュータマイクロコントローラ、その他のプログラム可能な機器を動作させるための機械語を人間にわかりやすい形で記述する、代表的な低水準言語である。なお、Assemblyとは組立を意味し日本語の意味では組立言語となる。

概要[編集]

プロセッサが直接実行できる言語は機械語のみであるが、機械語はバイナリ(数値)の羅列なので人間には理解しにくい。そこで、機械語を直接記述するのではなく、ニーモニックと呼ばれる命令語でプログラムを記述することで、人間により分かりやすくしたものがアセンブリ言語である。アセンブリ言語の意味は個々のプロセッサに依存するため、高水準言語のような移植性はない。

アセンブリ言語で書かれたプログラムを機械語プログラムに変換する事をアセンブル (assemble) すると言い、それを行うプログラムの事をアセンブラ (assembler) と言う。なお、アセンブリ言語の意味で「アセンブラ」または「アセンブラ言語」(Assembler Language)と呼ぶ場合も多い[注 1][1]

初期のコンピュータでは「アセンブラ」を「アセンブリプログラム」と呼ぶ例もあった[2]

アセンブリ言語の命令は、アセンブラに対する命令(疑似命令)やマクロ命令を除き、基本的には[注 2]機械語と1対1で対応し、プログラマがCPUの動作を把握しながらプログラムを記述する事ができる。

アセンブリ言語ではマシンの低水準な操作またはオペコードニーモニックで表す。オペコードによっては、機械語命令の一部として1つまたは複数のオペランドが必要である。また、多くのアセンブリ言語はオペランドとしてラベルやシンボルを使ってアドレスや定数を表すことができ、それらの値をプログラム内にそのまま書く(ハードコーディング)のを防ぐことができる。マクロアセンブラマクロ命令機能を備えており、アセンブリ言語のテキストに名前を事前に割り当て、その名前を使うことで他のコードにそのテキストを挿入できる。多くのアセンブラは、プログラム開発を支援したり、アセンブリ過程を制御したり、デバッグを支援したりといった付加機構を備えている。

歴史[編集]

機械語は、実行したい計算の内容をCPUの内部構造に依存した非常に単純な操作に分割・変換したものであるため、人間には理解しづらい。機械語を並べながらプログラミングするのは、人間のプログラマにとっては負担が大きかった。

そこで、機械語そのものを書く代わりに機械語の「意味」に相当する短い記号や単語を対応させ、それを記述してプログラミングをすることが考えられた。

世界で最初に実用的に稼働したノイマン型電子計算機とされるEDSACのローダ(外部記憶装置からプログラムやデータを読み出して主記憶装置に書き込むプログラム)において、既に原始的なアセンブラの機能が実装されている。EDSACはワード指向アーキテクチャで命令長が1ワードの固定長命令のマシンであり、入力装置は紙テープでありキャラクタ指向である。紙テープ上の A 1 0 0 F という文字列から十進法を数値に変換するなどの処理をおこない、「100番地の値をアキュムレータに加算する」という1ワードの命令を生成する、といった機能が、EDSACのローダには実装されていた。

機械語への変換は人間が手で行うこともあり、ハンド・アセンブルと呼ぶ。単に定められた規則に従って記号や単語から機械語を生成するだけなので、自動的に機械語を出力するプログラムが作られるようになった。このプログラムをアセンブラという。

コンピュータの歴史の初期には、このような、プログラムによって機械語プログラムを生成することを自動プログラミングと呼んだ。

ドナルド・ギリースには、まだ発明されていなかったアセンブラを開発中に、フォン・ノイマンに開発を即座に止めるように言われたという、1950年代初期ならではの逸話がある。当時は人間が手作業でもできるような瑣末な仕事をコンピュータにさせるような時代が来るとは考えられておらず、単に時間の無駄だとノイマンは考えたのである。

主要概念[編集]

アセンブラ[編集]

アセンブラは、アセンブリ命令ニーモニックをオペコードに変換し、シンボル名をメモリ位置や他の実体に変換することでオブジェクトコードを生成する[3]。シンボル名による参照の利用はアセンブラの重要な機能であり、面倒な計算やプログラム修正に伴うアドレスの更新の手間を省くことができる。多くのアセンブラはマクロ機能を備えており、よく使用する命令列をサブルーチン呼び出しではなくインライン展開することができる。

パス回数[編集]

実行ファイルを生成するのにソースファイルを何回パス(走査)するかでアセンブラを分類できる。

ワンパスアセンブラ
ソースコードを1回だけパスするアセンブラ。定義される前にシンボルが使われているとオブジェクトコードの最後に "errata" を置く必要があり、リンカまたはローダが未定義シンボルが使われていた位置にあるプレースホルダーを書き換える。あるいは、未定義なシンボルを使用するとエラーになる。
マルチパスアセンブラ
最初のパスで全シンボルとその値の表を作成し、その表を使ってその後のパスでコードを生成する。

どちらの場合も、アセンブラは最初のパスで各命令のサイズを確定させる必要があり、それによって後に出現するシンボルのアドレスを計算する。命令のサイズは後から定義されるオペランドの型や距離に依存することがあるため、アセンブラは最初のパスでは悲観的な見積もりをし、必要に応じてその後のパスまたは errata にて1つ以上のNOP命令(何もしない命令)を挿入してすき間を埋める必要がある。最適化を行うアセンブラでは、最初の悲観的コードをその後のパスで稠密なコードに書き換えてアドレスの再計算を行うことがある。

もともとワンパスアセンブラは高速であるためよく使われていた。マルチパス動作をするには、磁気テープを巻き戻したりパンチカードのデッキをセットし直して読み込む必要があったためである。現代のコンピュータではマルチパスであってもそのような遅延は生じない。マルチパスアセンブラは errata がないため、リンク処理(アセンブラが直接実行コードを生成する場合はローダの処理)が高速化される[4]

高水準アセンブラ[編集]

より洗練された高水準アセンブラ英語版は言語として次のような抽象化を提供する。

クロスアセンブラとメタアセンブラ[編集]

クロスアセンブラクロスコンパイラと似ており、あるプラットフォームで動作するが、そのプラットフォームではなく別のプラットフォーム向けのオブジェクトコードを生成するアセンブラを指す。小型の組み込みシステムなど、対象システムでアセンブラを動作させられない場合に使用することが多い。その場合、生成した機械語コードを対象システムに転送する何らかの手段が必要である。単に機械語コードをバイト単位に転送することもできるが、ASCII表現の転送用フォーマットがメーカーから提供されている(モトローラのSREC、インテルのHEXなど)。

メタアセンブラは、アセンブリ言語の文法や意味論を記述したものを入力とし、その言語のためのアセンブラを出力するプログラムである[6]

アセンブリ言語[編集]

アセンブリ言語で書かれたプログラムは、プロセッサの命令に対応したニーモニックの列、ディレクティブや擬似命令と呼ばれるメタな文、コメント、データで構成されている。ニーモニックとは、機械語の命令がプロセッサでおこなう動作を表現する英単語ないしその省略(LoadをLDなど)で表現したものである。通常の文はオペコードのニーモニックで始まり、パラメータ(データ、引数)のリストがそれに続く[7]。それらをアセンブラが機械語命令に翻訳し、メモリにロードして実行できる形式にする。

なかには、パイプライン処理などを最適化するために命令順序を入れ替えたり、ラベルの位置関係によってアドレッシングモードを最適化するアセンブラもあり、必ずしもソーステキストの記述とアセンブルの結果が直接対応するとは限らない。

オペランドにはソースとデスティネーションの二種類があり、データとして読み取られるのがソースで、オペコードで示された命令の実行結果が格納されるのがデスティネーションである。ソースには定数・レジスタ・メモリのいずれか、デスティネーションにはレジスタ・メモリのいずれかを指定する。

なお、オペランドの記述順序は、上の例では「デスティネーション, ソース」だが、「ソース, デスティネーション」の順に書くアセンブリ言語もある。また、オペランドの個数は命令によって異なり、典型的なオペランドは0以上のソースと1つのデスティネーションからなるが、プロセッサにより、暗黙のソースやデスティネーションを持つためにそれらを記述しない命令や、オペランドを持たない命令を持つ場合もある。

例えば、次の命令はx86/IA-32プロセッサのもので、8ビット即値レジスタに入れる命令である。この命令のバイナリコードは 10110 で、その後に3ビットのレジスタを指定する識別子が続く。AL レジスタの識別子は 000 なので、次に示す機械語AL レジスタに 01100001 というデータをロードする[8]

10110000 01100001

このバイナリコードを人間が読みやすいように十六進法で表現すると次のようになる。

B0 61

ここで、B0 は「ALに後続の値をコピーする」ことを意味し、61 は 01100001 を十六進法で表したもの(十進法では 97)である。インテルのアセンブリ言語では、この種の命令に MOV というニーモニックを割り当てており、セミコロン以下に説明的コメントを添えたアセンブリ言語での表現は次のようになる。

MOV AL, 61h       ; Load AL with 97 decimal (61 hex)

この場合、定数61Hがソース、レジスタALがデスティネーションに該当し、命令が実行されると、定数61Hが、レジスタALに単純に格納される。これが人間にとってはさらに読みやすく覚えやすい。

アセンブリ言語によっては、MOV のようなニーモニックはロードやデータのコピー/移動を行う命令群を表すのに使われ、オペランドの種類によって実際のオペコードが異なっていてもニーモニックとしては同じものを使う。また、データのコピー/移動の方向などによって別々のニーモニックを使うアセンブリ言語もある(「メモリからレジスタへの移動」を L、「レジスタからメモリへの移動」を ST、「レジスタからレジスタへの移動」を LR、「即値をメモリへ移動」を MVI など)。

インテルのオペコード 10110000 (B0) は8ビットの値を AL レジスタにコピーするが、10110001 (B1) は CL レジスタにコピーし、10110010 (B2) は DL レジスタにコピーする。これらをアセンブリ言語で表現すると次のようになる[8]

MOV AL, 1h        ; Load AL with immediate value 1
MOV CL, 2h        ; Load CL with immediate value 2
MOV DL, 3h        ; Load DL with immediate value 3

MOVの構文には次の例のようにさらに複雑なものもある[9]

MOV EAX, [EBX]	  ; Move the 4 bytes in memory at the address contained in EBX into EAX
MOV [ESI+EAX], CL ; Move the contents of CL into the byte at address ESI+EAX

MOV というニーモニックを使った文は、その内容によってアセンブラが 88-8E、A0-A3、B0-B8、C6、C7 のいずれかのオペコードに変換するので、プログラマはオペコードを知る必要がないし、オペコードを覚える必要もない[8]

アセンブリ言語から機械語への変換はアセンブラが行うが、逆方向の変換の一部は逆アセンブラが行う。高水準言語とは異なり、単純なアセンブリ構文と機械語命令には1対1の関係がある。しかしアセンブラは擬似命令(マクロの一種)を提供していることがあり、1つの擬似命令をよく使われる機械語命令列に展開する。例えば、大小比較による条件分岐命令を持たないマシンの場合、アセンブラで大小比較命令とゼロなら分岐する条件分岐命令(比較命令の結果を使用)に展開される擬似命令を用意したりする。多くの高機能アセンブラは豊富なマクロ言語機能を備えており、複雑なコード列やデータシーケンスを生成できる。

コンピュータ・アーキテクチャはそれぞれ独自の機械語を持つ。アーキテクチャが異なれば、サポートする命令の数や種類が異なり、レジスタの大きさや個数が異なり、データの格納形式が異なる。汎用コンピュータの多くは機能的にほぼ同等だが、実装は異なるので、アセンブリ言語にはその差異が反映されている。

機械語の命令セットは、プロセッサによって異なる。命令セットが同じでも様々なニーモニックやアセンブリ言語の文法が存在しうる。一般にプロセッサの設計者あるいは製造者によって定義されたニーモニックが標準とされるが、アセンブラによってはこれと異なるニーモニックを用いる場合もある(GNUアセンブラのgasのインテルプロセッサ用など)。

言語設計[編集]

基本要素[編集]

アセンブラの開発者によって用語の使い方に大きな差異があり、文の分類などが異なる。例えば、マシンのニーモニックや拡張ニーモニック以外は全て擬似命令と呼ぶ場合もある。典型的なアセンブリ言語は、プログラムの操作の定義に使われる命令文を以下の3種類に分類する。

  • オペコードのニーモニック
  • データセクション
  • アセンブリディレクティブ

オペコードのニーモニックと拡張ニーモニック[編集]

アセンブリ言語の命令文は一般に非常に単純で、高水準言語のそれとは異なる。一般にニーモニックは1つの機械語命令(オペコード)のシンボル名であり、個々の機械語命令には少なくとも1つのオペコード・ニーモニックが対応している。命令は一般に「オペコード」と0以上の「オペランド」で構成される。多くの命令は1つまたは2つの値を参照する。オペランドには即値(命令内に置かれる値)、レジスタ(暗黙のうちに使用される場合もある)、記憶装置内のデータの位置を示すアドレスなどがある。「拡張ニーモニック」はオペコードと特定オペランドの組合せを表すのに使われることが多い。例えばSystem/360では、BC 命令にマスク15を組み合わせたものが BBC 命令にマスク0を組み合わせたものが NOP という拡張ニーモニックで表される。

「拡張ニーモニック」は命令の特殊な用途をサポートするのに使われることが多く、本来の命令の名称からはその用途が連想できないときに使うことが多い。例えば、多くのCPUは明示的にNOP命令を用意していないが、その用途に使える命令は存在する。8086では xchg ax,ax という命令が nop として使えるので、アセンブリ言語で nop を記述すると xchg ax,ax という命令に変換される。逆アセンブラにもこのあたりを認識し、xchg ax,axnop に変換するものがある。同様にIBMのSystem/360System/370のアセンブラでは、拡張ニーモニック NOPNOPR を使用し、それぞれ BCBCR のマスク0の命令に変換する。SPARCアーキテクチャでは、拡張ニーモニックを synthetic instructions と呼んでいる[10]

アセンブラによっては単純な組み込みマクロ命令を備えており、数個の機械語命令に展開される。例えば一部のZ80用アセンブラでは、ld hl,bc というマクロ命令を ld l,cld h,b という2命令に展開する[11]

データセクション[編集]

データと変数を保持するデータ要素を定義するのに使われる命令文がある。データの型、長さ、境界(アライメント)を定義する。また、そのデータがプログラム外部(別ファイルでアセンブルされたプログラム)からも利用可能なのか、それともデータセクションを定義したプログラム内でのみ使用可能なのかも定義できる。一部のアセンブラはこれを擬似命令に分類している。

アセンブリディレクティブ[編集]

アセンブリディレクティブは擬似命令とも呼ばれ、アセンブラがアセンブリ実施中に実行すべき命令となっている[3]。プログラマが入力するパラメータによって異なった形でアセンブルが行われるよう指示することができる。また、プログラムの見た目を操作して、可読性と保守性を向上させるのにも使われる。例えば、記憶装置の領域を予約し、その初期内容を指定するディレクティブなどがある。ディレクティブの名称はドットで始まることが多く、それによって通常のニーモニックと区別している。

擬似オペコード (pseudo-opcode) と言った場合、オブジェクトコードを実際に生成するディレクティブのみを指すこともある[12]

ラベル/シンボル[編集]

シンボリックアセンブラでは、任意の名前(ラベルまたはシンボル)とメモリ位置を対応付けることができる。通常、定数や変数に名前をつけることができ、命令文ではそれらの位置を名前で参照できる。実行コードではサブルーチンのエントリポイントと名前を関連付け、サブルーチンを名前で呼び出すことができる。サブルーチン内では、分岐命令の分岐先をラベルで示すことができる。一部のアセンブラは「ローカルシンボル」をサポートしており、通常のシンボルとは語彙的に区別する(例えば、"10$" を分岐先に使用するなど)。

一部のアセンブラは柔軟なシンボル管理を提供しており、複数の名前空間を管理したり、データ構造内のオフセットを自動的に計算したり、リテラル値やアセンブラが実施した単純な計算結果を参照するラベルを割り当てたりすることができる。ラベルは定数や変数をリロケータブルなアドレスで初期化するのにも使える。

コメント[編集]

他の言語と同様アセンブリ言語でもソースコードにコメントを付与でき、アセンブラはそれらを無視できる。高水準言語に比べて可読性が低いため、コメントの重要性は高い。

これらの機能を多用することで低水準のコードのコーディングや保守の問題を大幅に単純化することができる。コンパイラや逆アセンブラが生成するアセンブリソースはコメントがなく、自動生成されるシンボルが意味不明で、データ定義もないため、非常に可読性が低い。

マクロ[編集]

多くのアセンブラは事前定義されたマクロをサポートしており、中にはユーザーが定義可能なマクロをサポートしているものもある。マクロは命令列と変数や定数の定義を埋め込むことができ、その中にオペコードやディレクティブの列が含まれる。マクロが定義されると、その名前をニーモニックとして使用できる。アセンブラはソース内にマクロを発見すると、対応するコード列に置き換え、元からソースにそのコード列が存在したかのように処理をする(アセンブラによっては、マクロを展開した中にマクロがあれば、それも展開することができる)。

なお、このような「マクロ」の定義は、例えばC言語でのマクロとは若干異なる。C言語のマクロは一般に #define というディレクティブで定義され、1行または多くても数行で済ませることが多い。アセンブラのマクロはそれ自体が長い「プログラム」であり、アセンブラがアセンブル時に解釈して実行する。

マクロは短い名前だが、数行からかなり長い行数のコードに展開されるので、アセンブリ言語のプログラムの見た目を短くすることができる。また、マクロによってアセンブリ言語プログラムに高水準の構造を追加でき、パラメータ付きのデバッグ用コードを埋め込むなどの利用法がある。

マクロアセンブラでは、マクロにパラメータを付与できる。中には洗練されたマクロ言語を備えたアセンブラもあり、オプションパラメータ、記号変数、条件文、文字列操作、算術演算などの高水準言語要素を持ち、マクロ実行中にそれらを使用でき、またマクロがコンテキストをセーブしたり情報を交換したりすることも可能である。したがってマクロの引数に基づいて大量のアセンブリ言語命令またはデータ定義を生成できる。例えば、レコード風のデータ構造や展開されたループを生成するのに使え、複雑なパラメータに基づいてアルゴリズム全体を生成することもできる。そのようなマクロで大いに拡張されたアセンブリ言語を使用すると、コンピュータの低水準の概念要素を扱う必要がなくなり、一種の高水準言語をつかっているのと同じことになる。

メインフレームの時代には、マクロは特定顧客の大規模ソフトウェアシステムのカスタマイズや、メーカーのオペレーティングシステムを顧客の要望に合わせた特注版にするのに使われていた。例えば、IBMVM/CMS、リアルタイムトランザクション処理用アドオン、CICSACP英語版/TPFコンピュータ予約システム (CRS) やクレジットカード会社で使われているトランザクションOS)などで使われてきた。

アセンブラのマクロ機能だけを全く異なる言語のコード生成に使うこともできる。例えば、COBOLのプログラムをマクロアセンブラのアセンブル時に実行されるオペレータで生成することができる。

というのも、1960年代に実用化された「マクロ処理」は「アセンブリ」とは独立した概念であり、マクロ処理は単なるオブジェクトコード生成というよりも現代的にはワードプロセッシングやテキストプロセッシングに近い。C言語にもマクロ処理の概念が導入されており、プリプロセッサと呼ばれる。ただし、アセンブラのマクロプロセッサはチューリング完全だったが、C言語のプリプロセッサはそうではない(Cのプリプロセッサにはループ機能や "goto" 機能がない)。

マクロ処理の能力は大きいが、アセンブラ以外の高水準言語ではあまり使われなくなった(例外としてC/C++とPL/Iがある)。

マクロのパラメータ置換は厳密に名前によってなされる。マクロ処理の際、パラメータ値がその名前を逐語的に置換する。そのため、パラメータとして式を指定したときよくあるバグが生じる。例えば次のようなマクロがあるとする。

foo: macro a
load a*b

このマクロは呼び出し側が変数名を指定し、広域変数または定数である b とその変数をかけることを想定している。しかし、foo のパラメータとして a-c を指定するとマクロは load a-c*b と展開されてしまう。これを防ぐにはマクロ定義内でパラメータを常に括弧で囲むか、呼び出し時にパラメータを括弧付きにするしかない[13]

構造化プログラミングサポート[編集]

構造化プログラミングの要素を取り入れたアセンブラもある。最初期の例として "Concept-14 macro set" がある。Dr. H.D. Mills (March, 1970) が提案し、IBMの連邦政府システム部門の Marvin Kessler が実装したもので、System/360 のマクロアセンブラに IF/ELSE/ENDIF などの制御構造を導入した[14]。これはアセンブリコードからGOTO操作を削減または排除するもので、本質的にスパゲッティプログラムになりやすいアセンブリ言語のコードを読みやすくするものだった。1980年代にはこの手法が広まった。

独特の設計として、Whitesmiths Ltd.Unix系OS IdrisCコンパイラで有名)が開発した8080/Z80プロセッサ用「ストリーム指向」アセンブラ A-natural がある。この言語はオペコードやレジスタ、メモリ参照といった要素をそのまま扱えるためアセンブラと呼ばれているが、実行順序を示す構文を取り入れていた。括弧やその他の記号でプログラムのブロック構造を指定したり、生成した命令列の実行順序を制御できる。A-natural は同社のCコンパイラが中間コードとしており、人間が直接使うものではなかったが、その論理的構文にはファンも存在した。

また構造化プログラミングとは若干異なるが、キャリーラボBASIC風の文法のアセンブリ言語 BASE を開発した。Z80用の BASE-80 とMC6809用の BASE-09 がある。BASEの表記例は下記の通り(BASE-09)

S[A,B,X,U
A=$80
A=A+$C0
S]A,B,X,U,PC

上記の記述は下記のアセンブラ表記に対応する。

PSHS A,B,X,U
LDA #$80
ADDA #$C0
PULS A,B,X,U,PC

その後、アセンブリ言語で大規模システムを開発することが少なくなり、アセンブリ言語の高機能化の需要が減っていった[15]。それでも、資源の制約が強い場合やターゲットシステムのアーキテクチャが高水準言語の効率的使用を妨げている場合、アセンブラは有用であり、高機能なアセンブラの開発も行われている[16]

利用[編集]

歴史的観点[編集]

アセンブリ言語はプログラム内蔵方式のコンピュータの黎明期に登場した。EDSAC (1949) には initial orders という1文字のニーモニックを採用したアセンブラが存在した[17]ナサニエル・ロチェスターは1954年に IBM 701 用アセンブラを書いている。1955年、Stan Poley が IBM 650 用アセンブり言語 SOAP (Symbolic Optimal Assembly Program) を開発した[18]

アセンブリ言語は、初期のコンピュータでのプログラミングでの入力ミス削減や時間短縮に貢献し、機械語コード参照やアドレス計算といった退屈な作業からプログラマを解放した。その後高水準言語へと移行していったが、ハードウェアの直接操作、特殊命令の使用、性能向上といった目的で今もアセンブリ言語が使われている。特にデバイスドライバ組み込みシステムリアルタイムシステムでよく使われている。

歴史的には多数のプログラムがアセンブリ言語だけで書かれてきた。ALGOLの方言であるESPOLで書かれた Burroughs MCP (1961) が登場するまで、オペレーティングシステムはアセンブリ言語で書くのが普通だった。商用アプリケーションもアセンブリ言語で書かれており、例えばIBMメインフレーム用ソフトウェアの多くはアセンブリ言語で書かれていた。COBOLFORTRANPL/I などが取って代わっていったが、1990年代になってもアセンブリ言語のコードベースを保守し続けていた大企業も少なくない。

初期のマイクロコンピュータではアセンブリ言語がよく使われ、OSやアプリケーションも当初はアセンブリ言語で書かれた。これはリソースの制約が厳しかったためであり、メモリやディスプレイのアーキテクチャが特殊だったためでもある。また、マイクロコンピュータ向けの高水準言語のコンパイラがなかったという面も重要である。また、初期のマイクロコンピュータのユーザーはホビーストが主であり、何でも自前で作るという精神もそれに影響していたと見られる。

1980年代から1990年代にかけてのホームコンピュータZX Spectrumコモドール64AmigaAtari ST など)でもアセンブリ言語がよく使われていた。というのもそれらのBASICは性能が低く、ハードウェアの全機能を利用できないことが多かったためである。例えばAmigaにはフリーウェアのアセンブリ言語統合開発環境 ASM-One assembler があり、Microsoft Visual Studio に匹敵する機能を備えていた。

Don French が開発した VIC-20 用アセンブラは 1,639 バイトという小ささで、世界一小さいアセンブラと言われている。アドレスをシンボルで表現でき、各種アドレス計算(四則演算、AND、OR、冪乗など)が可能だった[19]

商用製品でアセンブリ言語を使う最大の理由は、使用メモリ量を最小にし、オーバーヘッドを最小にし、性能と信頼性を向上させるためである。1980年代のビジネスソフトでは、例えば、IBM PCDOS表計算ソフト Lotus 1-2-3 などはアセンブリ言語で書かれていた。日本ではが有名である。

1990年代に入ってもコンシューマーゲームの多くはアセンブリ言語で書かれていた。ある業界関係者はセガサターンの最高性能を引き出してプレイステーションに対抗するにはアセンブリ言語を使うしかなかったとしている(プレイステーションにはソニーが提供するCライブラリが存在した)[20]。また、アーケードゲームのNBAジャム (1993) もアセンブリ言語で開発されている。ただし一方で、ファミコン時代すでにメタルスレイダーグローリーやスーパーファミコンのMOTHER 2シムシティ[21]、プレステのクラッシュ・バンディクー[22]、開発の一部にLISPが使われていたという話もあり、アセンブリ言語が全てという世界だった、と認識するのは誤りである。

現代における使用[編集]

アセンブリ言語と高水準言語を比較した有用性と性能についての議論は、これまでよく行われてきた。アセンブリ言語は後述するように特定の用途で重要な役割を演じている。しかし一般的には最適化コンパイラが人手で書かれたアセンブリ言語のコードと同等の性能を発揮すると言われている[23](例外もある[24][25][26])。最近のプロセッサやメモリサブシステムは複雑化してきたため、コンパイラでもアセンブリ言語でも効果的な最適化がますます困難になってきている[27][28]。さらに言えば、プロセッサが高性能化するにしたがって入出力ページングによる遅延が無視できないレベルとなったため、コーディングによる性能追求は多くのプログラマにとって大きな問題ではなくなってきている。

開発者がアセンブリ言語を選択する状況として、次のようなものがある。

計算機科学情報工学では、アセンブリ言語が今も教えられている。実際にアセンブリ言語を使用するプログラマは全体から見れば少ないが、その概念は非常に重要である。二進法メモリ管理スタック処理、文字コード割り込み処理、コンパイラ設計といった基本的トピックは、ハードウェアレベルでのコンピュータの動作を学ばなければ深く理解するのが困難である。コンピュータの動作は基本的には命令セットで定義されるので、アセンブリ言語を学ぶことでそのような概念を習得できる。最近のコンピュータの命令セットはどれも似ている。したがって、どれか1つのアセンブリ言語を学ぶだけで、基本概念、どんなときにアセンブリ言語を使用するのが適しているか、高水準言語から効率的な実行コードを生成する方法を学習できる[32]。これは、子どもが算数(筆算など)を学ぶ必要があるが、日常の計算には電卓を使っているのに似ている。

アセンブラとコンパイラ[編集]

  • 多くのコンパイラは高水準言語から直接機械語を生成せずにアセンブリ言語のコードを生成してからアセンブラに通す。それによりアセンブリ言語のコードをデバッグや最適化に用いることができる。その意味ではアセンブリ言語は、目に見えない形ではあるが最も利用頻度の高いプログラミング言語といえる。
  • 比較的低水準言語に近いC言語などでは、インラインアセンブラを使うことで、ソース中にアセンブリ言語による記述を含めることができる。例えばLinuxカーネルなどでそのような機能を利用しており、プログラムで実行時間の多くを占める部分をインラインアセンブラによる記述に置き換えることで、全体をアセンブリ言語で書いたプログラムに近い実行速度を実現できることもあるが、特定のCPUのアーキテクチャに依存する記述となるので互換性や移植性は大きく損なわれる。
  • 分割コンパイルで作成するプログラムの一部のモジュールをアセンブリ言語で書くこともある。この場合、コンパイラの呼出規約にしたがってアセンブリ言語のプロシージャを書き、コンパイラが生成したオブジェクトライブラリと、アセンブラが生成したそれらを、対応したリンカで結合する。

主なアセンブラ[編集]

Unix系システムでは、アセンブラを as と呼ぶのが一般的だが、実体はそれぞれのOSで異なる。GNUアセンブラを使っているものが多い。

同じ系統のプロセッサであっても、複数のアセンブリ言語の方言が存在する。アセンブラによっては他の方言のアセンブリ言語も使用可能な場合がある。例えば、TASMMASM用コードを入力として受け付け可能だが、逆は不可能である。FASM英語版NASMは文法がほぼ同じだが、サポートしているマクロが異なるため、相互の翻訳は困難である。いずれも基本機能は同じだが、追加機能に差異がある[33]

脚注[編集]

  1. ^ IBMはSystem/360から2011年現在まで一貫してアセンブラ言語(Assembler Language)と呼んでいる。例:IBM High Level Assembler
  2. ^ MIPSのアセンブラの一部など、命令の遅延分岐スロットへの移動を勝手に行うものもある。OPTASM(SLR社)という最適化アセンブラもあった。

出典[編集]

  1. ^ Stroustrup, Bjarne, The C++ Programming Language, Addison-Wesley, 1986, ISBN 0-201-12078-X: "C++ was primarily designed so that the author and his friends would not have to program in assembler, C, or various modern high-level languages." - assemblerassembly language の意味で使っている例
  2. ^ Saxon, James, and Plette, William, Programming the IBM 1401, Prentice-Hall, 1962, LoC 62-20615. - assembly program という用語を使っている例
  3. ^ a b David Salomon (1993). Assemblers and Loaders
  4. ^ Beck, Leland L. (1996). “2”. System Software: An Introduction to Systems Programming. Addison Wesley. 
  5. ^ Hyde, Randall. "Chapter 12 – Classes and Objects". The Art of Assembly Language, 2nd Edition. No Starch Press. © 2010.
  6. ^ (John Daintith, ed.) A Dictionary of Computing: "meta-assembler"
  7. ^ Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference. INTEL CORPORATION. (1999). http://download.intel.com/design/PentiumII/manuals/24319102.PDF 2010年11月18日閲覧。. 
  8. ^ a b c Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference. INTEL CORPORATION. (1999). pp. 442 and 35. http://download.intel.com/design/PentiumII/manuals/24319102.PDF 2010年11月18日閲覧。. 
  9. ^ Evans, David (2006年). “x86 Assembly Guide”. University of Virginia. 2010年11月18日閲覧。
  10. ^ The SPARC Architecture Manual, Version 8”. SPARC, International (1992年). 2012年10月27日閲覧。
  11. ^ http://www.z80.de/z80/z80code.htm
  12. ^ Microsoft Corporation. “MASM: Directives & Pseudo-Opcodes”. 2011年3月19日閲覧。
  13. ^ Macros (C/C++), MSDN Library for Visual Studio 2008”. Microsoft Corp.. 2010年6月22日閲覧。
  14. ^ Concept 14 Macros”. MVS Software. 2009年5月25日閲覧。
  15. ^ Answers.com. “assembly language: Definition and Much More from Answers.com”. 2008年6月19日閲覧。
  16. ^ NESHLA: The High Level, Open Source, 6502 Assembler for the Nintendo Entertainment System
  17. ^ Salomon. Assemblers and Loaders. p. 7. http://www.davidsalomon.name/assem.advertis/asl.pdf 2012年1月17日閲覧。. 
  18. ^ The IBM 650 Magnetic Drum Calculator”. 2012年1月17日閲覧。
  19. ^ Jim Lawless (2004年5月21日). “Speaking with Don French : The Man Behind the French Silk Assembler Tools”. 2008年8月21日時点のオリジナルよりアーカイブ。2008年7月25日閲覧。
  20. ^ Eidolon's Inn : SegaBase Saturn
  21. ^ Lispによるリターゲッタブルコードジェネレータの実装 (PDF)
  22. ^ http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview21.html
  23. ^ Rusling, David A.. “The Linux Kernel”. 2012年3月11日閲覧。
  24. ^ a b Writing the Fastest Code, by Hand, for Fun: A Human Computer Keeps Speeding Up Chips”. New York Times, John Markoff (2005年11月28日). 2010年3月4日閲覧。
  25. ^ Bit-field-badness”. hardwarebug.org (2010年1月30日). 2010年2月5日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  26. ^ GCC makes a mess”. hardwarebug.org (2009年5月13日). 2010年3月16日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  27. ^ Randall Hyde. “The Great Debate”. 2008年6月16日時点のオリジナルよりアーカイブ。2008年7月3日閲覧。
  28. ^ Code sourcery fails again”. hardwarebug.org (2010年1月30日). 2010年4月2日時点のオリジナルよりアーカイブ。2010年3月4日閲覧。
  29. ^ BLAS Benchmark-August2008”. eigen.tuxfamily.org (2008年8月1日). 2010年3月4日閲覧。
  30. ^ x264.git/common/x86/dct-32.asm”. git.videolan.org (2010年9月29日). 2010年9月29日閲覧。
  31. ^ 68K Programming in Fargo II”. 2008年7月2日時点のオリジナルよりアーカイブ。2008年7月3日閲覧。
  32. ^ Hyde, Randall (1996年9月30日). “Foreword ("Why would anyone learn this stuff?"), op. cit.”. 2010年3月25日時点のオリジナルよりアーカイブ。2010年3月5日閲覧。
  33. ^ Randall Hyde. “Which Assembler is the Best?”. 2007年10月18日時点のオリジナルよりアーカイブ。2007年10月19日閲覧。

参考文献[編集]

  • Jonathan Bartlett: Programming from the Ground Up. Bartlett Publishing, 2004. ISBN 0-9752838-4-7
    Also available online as PDF
  • Robert Britton: MIPS Assembly Language Programming. Prentice Hall, 2003. ISBN 0-13-142044-5
  • Paul Carter: PC Assembly Language. Free ebook, 2001.
    Website
  • Jeff Duntemann: Assembly Language Step-by-Step. Wiley, 2000. ISBN 0-471-37523-3
  • Randall Hyde: The Art of Assembly Language. No Starch Press, 2003. ISBN 1-886411-97-2
  • Peter Norton, John Socha, Peter Norton's Assembly Language Book for the IBM PC, Brady Books, NY: 1986.
  • Michael Singer, PDP-11. Assembler Language Programming and Machine Organization, John Wiley & Sons, NY: 1980.
  • Dominic Sweetman: See MIPS Run. Morgan Kaufmann Publishers, 1999. ISBN 1-55860-410-3
  • John Waldron: Introduction to RISC Assembly Language Programming. Addison Wesley, 1998. ISBN 0-201-39828-1

関連項目[編集]

外部リンク[編集]