インタプリタ

インタプリタのしくみ

プログラミング言語処理系には、コンパイラ、 アセンブラ以外にインタプリタと呼ばれるものもある。

コンパイラを用いた場合、 ソースプログラムは CPU が直接理解可能な機械語に変換されるので、 コンパイル後にできたプログラムはそれ単独で動く。 つまり、実行時には処理系(コンパイラ)の介在を必要としない。

            ┌─────────┐ コンパイル ┌─────────┐
            │ ソースプログラム │─────→│ 機械語プログラム │
            └─────────┘            └─────────┘
                                                        ↑
                                                    CPU が直接
                                                    実行

これに対して、インタプリタはソースプログラムをコンパイルしない。 ソースプログラムを読んでその内容を解釈しながら実行する。 従って、実行時にインタプリタ処理系がなければプログラムを動かすことができない。

            ┌─────────┐ 
            │ ソースプログラム │
            └─────────┘
                      ↑
                      │解釈しながら実行
                      │ 
            ┌─────────┐ 
            │   インタプリタ   │
            └─────────┘

例えば、z = x + y; という文を、コンパイラは

    addu $t2, $t0, $t1          # レジスタだけを使う場合

とか、あるいは

    addu $v0, $t0, $t1          # z をスタックフレームに置く場合
    sw $v0, -8($fp)

といったアセンブリ言語で表される機械語に変換する。変換後のプログラム は直接CPUによって実行される。

これに対し、同じ z = x + y; という文をインタプリタが実行する場合、 概略次のようなことが起こる(詳細は個々のインタプリタによって多少異なる):

• まず、文はインタプリタの持っているメモリ領域に読み込まれ、解釈される。
• 解釈の際に文法エラーが見つかれば、 エラーメッセージを出してインタプリタは終了する。
• 解釈の結果、上の例の文は代入文であることがわかる。 インタプリタは、インタプリタ自身が持っている、 代入文処理のためのルーチンを呼び出す。
• 代入文処理ルーチンは、左辺を計算するルーチン (これももちろんインタプリタ内に用意されている)を呼び出す。
• インタプリタでは、 変数の値を入れるための場所は、 インタプリタの持っているメモリ領域のどこかに置かれる。 そこで、左辺を計算するルーチンは、 変数 z のための領域を見つけ出してきて、そのアドレスをリターンする。
• 処理は再び代入文処理ルーチンに戻る。 代入文処理ルーチンは、左辺計算ルーチンが求めたアドレスを適当な所に記憶する。 そのあと、右辺の値を計算するために、 式の値を求めるルーチンを呼び出す。
• 式の値を求めるルーチンは、右辺の x + y という形を見て、 加算だと判断する。 x の値をまず取り出し、次に y の値を取り出して、 インタプリタ内の加算ルーチンを呼び出し、結果をリターンする。
• 制御は再び代入文処理ルーチンに戻る。 先程求めておいた z のための領域のアドレスに、 上で求まった右辺の値をしまう。 それから、自分を呼び出したルーチンにリターンする。
• かくして、最初のルーチンに制御が戻ってきた。 インタプリタはプログラムの次の文を読んで実行しようとする。 以下同様に続く。

  前の文の解釈実行終了
          ↓
  z = x + y; が読まれる
          ↓
  代入文処理ルーチン呼出し ──→[代入文処理ルーチン]
                                         ↓
                                 左辺計算ルーチン呼出──→[左辺計算ルーチン]
                                                                ↓
                                                            z の場所を求めて
                                                            リターン
                                          ←──────────┘
                                         ↓
                                 右辺計算のため、
                                 式計算ルーチン呼出し──→[式計算ルーチン]
                                                                ↓
                                                            x + y を求める
                                          ←──────────┘
                                         ↓
                                 z の場所に x + y の
                                 値をしまって
                                 リターンする
           ←──────────────┘
          ↓
       次の文へ
          ↓
          ：
          ：

コンパイラとインタプリタの比較

プログラムの実行形態

• コンパイラ: ソースプログラムをコンパイルして機械語ルーチンを得る。 その機械語ルーチンが CPU によって直接実行される。
• インタプリタ: ソースプログラムの内容に応じて、 次々とインタプリタ内のルーチンを呼び出して実行。

対話性(interactiveness)

• コンパイラ: コンパイルが終了するまではプログラムの実行ができない。 大きなプログラムではコンパイルに時間がかかり、 その間ユーザは待たねばならないから、対話性はよくない。
• インタプリタ: プログラムを読むそばから実行して行くことができるので、 実行開始まで待たなくて済む。 (あまり待たなくてもすぐに実行が開始される、ということ。) プログラムを少しずつ書いてはすぐ実行してみる、 といったことが簡単にできるので、対話性がよく、 デバッグの時などは楽。

例えて言えば、コンパイル後のプログラムを走らせるのは、 翻訳された本を読むのに似ている。 翻訳が必要なのは最初だけであり、その際は時間がかかるが、 その後は何度読もうが翻訳のコストはかからない。 一方、インタプリタは(同時)通訳に似ている。 通訳は毎回その場にいなければ役に立たない。

コンパイラのことを日本語で「翻訳系」ということがある。インタプリタを 「通訳系」とか「解釈系」ということがある。(でもカタカナで呼ぶことのほ うがはるかに多い。)

実行効率

• コンパイラ: コンパイル後のプログラムは一般に高速に実行できる。 (プログラムの解釈はコンパイル時に一回だけ行ない、 実行時には行なわない。) プログラムは CPU によって直接的に実行されるので、 高速に実行される。
• インタプリタ: 解釈しながら実行するので、 コンパイラが吐いたプログラムの実行より遅くなる。 (何倍くらい遅いかは、個々のコンパイラやインタプリタの性能、 対象とするプログラミング言語の違いなどに左右される。 Lisp という言語の場合、 コンパイラはインタプリタの15倍くらい速いコードを出せると言われる。)

開発効率(プログラムの開発のしやすさ)

• コンパイラ: 対話性がよくないために、 プログラム開発に手間がかかることがある。
• インタプリタ: 対話性がよいのでプログラミングは楽になることが多い。 また、試行錯誤がやりやすいので、初心者教育向きであることが多い。

効率について一言:

プログラムの効率については、実行時のことだけを考えていてはいけない。 できたプログラムが高速でも、 プログラミングにひどく時間がかかったので は、現実の問題解決には間に合わないことがある。 特に、一度だけしか実行しないプログラムの場合は、実行速度が遅くても 「開発時間＋実行時間」 が短かければそれでよいと考えられる。 世の中には一度だけ実行すれば済む「使い捨てプログラム」 が思った以上に多いものである。

筆者は日常の仕事をこなすのにそういうプログラムをしょっちゅう書いている。 くり返し使うプログラムよりずっと多い。

逆に、何度もくり返し使うプログラムの場合、実行速度が速いことのメリッ トが大きくなるので、多少開発に時間をかけても高速なプログラムを作る価 値があるケースが多くなる。

開発中、完成が近くなるまでインタプリタで開発し、 ほとんどバグが取れたらコンパイラにかける、というアプローチもある。

こうしたことを考えに入れて、コンパイラ・インタプリタの使い分け、 あるいはプログラミング言語そのものの使い分けをすべきである。 (開発時間を短くしやすいが、実行効率が少し悪い処理系、 といったものもある。)

処理系の作りやすさ

• コンパイラ: コンパイラを作るのは、 一般にインタプリタを作るのよりかなり難しい。 特に、性能のよいもの(速い機械語コードを吐くもの)を作るのは難しい。 また、機械語はコンピュータごとに異なるので、 コンパイラもコンピュータごとに作らねばならず、手間がかかる。
• インタプリタ: コンパイラを作るのよりかなりやさしい。 (簡単な言語のインタプリタなら、大学2・3年生くらいでも書けるだろう。) また、すでにコンパイラが一つでもあれば、 そのコンパイラを使ってインタプリタを作ればよい。 例えば、C コンパイラがあれば、C のプログラムとしてインタプ リタを作ればよい。C のプログラムなら、 別のマシンにも移植しやすいので、 一つの種類のマシンで動くインタプリタが作れたら、 他の多くの種類のマシンでも動くようにするのは大抵難しくない。

簡単なインタプリタの一つくらいは作っておくと非常に勉強になります。 色々なアルゴリズムやプログラミングテクニックを学べます。 Lisp 言語のインタプリタあたりが一番楽。

注意

インタプリタかコンパイラか、という違いは、処理系の違いであって、言語 の違いではない。 よく、「C はコンパイラだから速い」という言い方がされることがあるが、 本当は正しくない言い方。 C 言語自体の規格には、処理系をコンパイラにしなければいけない、 ということはない。 実際、C のインタプリタも存在する。 ただ、C の処理系のほとんどがコンパイラなのは確かであり、 また、大抵のコンピュータ上には速いコードを吐く C コンパイラが用意されているのも事実だろう。 (C や Fortran のコンパイラ作成技術は歴史が長いためよく研究されているし、 速いコンパイラを作りやすい言語なのは確か。)

また、一つの処理系がインタプリタとコンパイラを兼ねていることもある。 例えば、Lisp 言語の処理系の場合、インタプリタの機能を持つと同時に、 インタプリタの中からコンパイル機能も呼び出すことができるものが多い。 大抵、一つ一つの関数ごとにコンパイルできるから、 コンパイルされた関数とされていない関数を混ぜこぜに使うことができる。 (デバッグに便利。)

コンパイラ・インタプリタ以外の方式

ある意味でインタプリタとコンパイラの中間にあたるような実行方式もある。 そのような実行方式については、 それを採用している言語処理系を習う授業で教わると思うので、 ここでは細かい話は省略する。

例

1. Java 言語の処理系(「マルチメディアプログラミング」で解説)。
2. Standard ML 言語の New Jersey コンパイラと呼ばれる処理系 (「プログラミング言語学」で解説)。

Java の処理系は、ソースプログラムを仮想機械の機械語に変換(翻訳)する。 実行時にこの翻訳系は要らないので、そのような意味ではコンパイラ。 また、仮想機械の機械語は、ソースプログラムの言語よりも低級言語と考えられるので、 その意味でもコンパイラである。 しかし、実行の際には、 このコンパイラとは別のプログラムとして用意されているインタプリタが必要。 (あるいは、仮想機械と同じ動作をするハードウェアがあれば、 それを使ってもよい。) つまり、変換後のプログラムは、仮想的な機械の機械語であるが、 インタプリタによって解釈実行される。

Standard ML 言語の New Jersey コンパイラ はインクリメンタルコンパイラ(←今覚えなくてよい)である。 一見インタプリタだが、ユーザが入力した式は、 入力されるそばから逐一コンパイルされ、即座に実行される。 コンパイラの実行時効率とインタプリタの対話性を両立させようとしたもの。