通訳(コンピューティング)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
W3sDesignインタープリターデザインパターンUML

コンピュータサイエンスではインタプリタは、プログラミングまたはスクリプト言語で記述された命令を直接実行するコンピュータプログラムであり、事前に機械語プログラムにコンパイルさている必要はありません。インタプリタは通常、プログラムの実行に次のいずれかの戦略を使用します。

  1. ソースコードを解析し、その動作を直接実行します。
  2. ソースコードを効率的な中間表現またはオブジェクトコードに変換し、すぐに実行します。
  3. コンパイラによって作成され、インタプリタ仮想マシンと照合された、保存されたプリコンパイル済みバイトコード[1]を明示的に実行します。

Lispプログラミング言語の初期バージョンミニコンピューターおよびマイクロコンピューターのBASIC方言は、最初のタイプの例です。PerlRakuPythonMATLABRubyは2番目の例であり、UCSDPascalは3番目のタイプの例です。ソースプログラムは事前にコンパイルされ、マシンに依存しないコードとして保存されます。その後、実行時にリンクされ、インタプリタやコンパイラ(JITシステムの場合)によって実行されます。Smalltalkや最新バージョンのBASICJavaなどの一部のシステム2つと3つを組み合わせることもできます。[2] AlgolFortranCobolCC ++など、従来コンパイルに関連付けられていた多くの言語用に、さまざまなタイプのインタープリターも構築されています

通訳とコンパイルはプログラミング言語を実装するための2つの主要な手段ですが、ほとんどの通訳システムもコンパイラと同じようにいくつかの翻訳作業を実行するため、相互に排他的ではありません。解釈された言語」または「コンパイルされた言語」という用語は、その言語の標準的な実装がそれぞれインタプリタまたはコンパイラであることを意味します。高水準言語は、理想的は特定の実装に依存し ない抽象化です。

歴史

インタープリターは、1952年には、当時のコンピューターの制限内でプログラミングを容易にするために使用されていました(たとえば、プログラムストレージスペースの不足、または浮動小数点数のネイティブサポートなし)。インタプリタは、低レベルの機械語間の翻訳にも使用され、まだ構築中であり、既存のコンピュータでテストされているマシンのコードを記述できるようにしました。[3]最初に解釈された高級言語はLispでした。Lispは、1958年にSteveRussellによってIBM704コンピューターに最初に実装されました。ラッセルはジョン・マッカーシーの論文を読んでいて、(マッカーシーの驚いたことに)Lispeval関数を機械語で実装できることに気づきました。[4]その結果、Lispプログラムを実行したり、より適切には「Lisp式を評価」したりするために使用できるLispインタプリタが機能しました。

コンパイラとインタプリタ

リンクプロセスの図。オブジェクトファイルと静的ライブラリは、新しいライブラリまたは実行可能ファイルにアセンブルされます

高水準言語で記述されたプログラムは、ある種のインタプリタによって直接実行されるか、 CPUが実行するためにコンパイラ(およびアセンブラリンカ)によってマシンコードに変換されます。

コンパイラ(およびアセンブラ)は通常、コンピュータハードウェアによって直接実行可能なマシンコードを生成しますが、多くの場合(オプションで)オブジェクトコードと呼ばれる中間形式を生成できます。これは基本的に同じマシン固有のコードですが、実行可能ブロック(またはモジュール)を識別および再配置できるようにするために、名前とタグが付いたシンボルテーブルが追加されています。コンパイルされたプログラムは通常、そのようなオブジェクトコードモジュールのライブラリに保持されているビルディングブロック(関数)を使用します。リンカー_(事前に作成された)ライブラリファイルをアプリケーションのオブジェクトファイルと組み合わせて、単一の実行可能ファイルを形成するために使用されます。したがって、実行可能ファイルを生成するために使用されるオブジェクトファイルは、多くの場合、異なる時間に生成され、場合によっては異なる言語(同じオブジェクト形式を生成できる)によっても生成されます。

低水準言語(アセンブリなど)で記述された単純なインタプリタには、高水準言語の関数を実装する同様のマシンコードブロックが格納され、ルックアップテーブルの関数のエントリがそのコードを指しているときに実行される場合があります。ただし、高水準言語で記述されたインタプリタは、通常、解析ツリーを生成してからウォークする、中間のソフトウェア定義命令を生成して実行する、またはその両方など、別のアプローチを使用します。

したがって、コンパイラとインタプリタはどちらも一般にソースコード(テキストファイル)をトークンに変換し、両方とも解析ツリーを生成する場合と生成しない場合があり、両方が即時命令を生成する場合があります(スタックマシン4倍コード、またはその他の手段)。基本的な違いは、(組み込みまたは個別の)リンカーを含むコンパイラシステムがスタンドアロンのマシンコードプログラムを生成するのに対し、インタプリタシステムは代わりに高レベルプログラムによって記述されたアクション を実行することです。

したがって、コンパイラはソースコードセマンティクスからマシンレベルへのほぼすべての変換を一度に(つまり、プログラムを変更する必要があるまで)行うことができますが、インタプリタはステートメントまたは関数が実行されるたびにこの変換作業の一部を実行する必要があります。ただし、効率的なインタプリタでは、翻訳作業の多く(型の分析などを含む)が除外され、プログラム、モジュール、関数、さらにはステートメントが初めて実行されたときにのみ実行されるため、コンパイラは動作します。ただし、コンパイラがコードを最適化するように設計されていることもあり、コンパイルされたプログラムは、ほとんどの状況ではるかに高速に実行され、そのための十分な時間が与えられる可能性があります。これは、(多くの)動的データ構造、チェック、またはタイプチェック

従来のコンパイルでは、リンカーの実行可能出力(.exeファイルまたは.dllファイルまたはライブラリ。図を参照)は、通常、オブジェクトコードモジュールと同様に、一般的なオペレーティングシステムで実行すると再配置可能ですが、この再配置が異なります。実行時、つまりプログラムが実行のためにロードされるときに動的に実行されます。一方、小さな組み込みシステム用にコンパイルおよびリンクされたプログラムは、通常、静的に割り当てられ、多くの場合、 NORフラッシュメモリにハードコーディングされます。これは、この意味でセカンダリストレージやオペレーティングシステムがない場合が多いためです。

歴史的に、ほとんどのインタプリタシステムには自己完結型のエディタが組み込まれています。これはコンパイラ(当時はIDEと呼ばれることもあります)でも一般的になりつつありますが、一部のプログラマは選択したエディタを使用してコンパイラ、リンカなどを実行することを好みます。手動でツール。歴史的に、コンパイラはインタプリタよりも前から存在していました。当時のハードウェアはインタプリタとインタプリタコードの両方をサポートできず、当時の典型的なバッチ環境はインタプリタの利点を制限していたからです。[5]

開発サイクル

ソフトウェア開発サイクル、プログラマーはソースコードに頻繁に変更を加えます。コンパイラを使用する場合、ソースコードに変更が加えられるたびに、コンパイラが変更されたソースファイルを変換してリンクするのを待つ必要があります。プログラムを実行する前に、すべてのバイナリコードファイルをまとめてください。プログラムが大きいほど、待機時間が長くなります。対照的に、インタープリターを使用するプログラマーは、通常、作業中のコードを中間表現に変換する(またはまったく変換しない)必要があるため、待機時間が大幅に短縮されます。したがって、変更を行う前に必要な時間ははるかに短くなります。テスト済み。ソースコードを保存してプログラムをリロードすると、効果が明らかになります。編集、コンパイル、およびリンクは、適切なコマンドセットを使用して適切な順序で実行する必要がある順次プロセスであるため、コンパイルされたコードは一般にデバッグが容易ではありません。このため、多くのコンパイラには、Makeと呼ばれるエグゼクティブエイドもあります。ファイルとプログラム。Makeファイルには、コンパイラとリンカのコマンドラインとプログラムのソースコードファイルが一覧表示されますが、命令の3番目のグループ(セット)を選択してコンパイラにコマンドを発行する単純なコマンドラインメニュー入力(「Make3」など)を使用する場合があります。指定されたソースコードファイルにフィードするリンカー。

配布

コンパイラは、ソースコードを特定のプロセッサのアーキテクチャ用のバイナリ命令に変換するため、移植性が低下します。この変換は、開発者の環境で1回だけ行われ、その後、同じバイナリをユーザーのマシンに配布して、さらに変換せずに実行することができます。クロスコンパイラは、コードがコンパイルされるマシンとは異なるプロセッサを使用している場合でも、ユーザーマシンのバイナリコードを生成できます

インタプリタされたプログラムは、ソースコードとして配布できます。最終的なマシンごとに変換する必要があります。これには時間がかかりますが、プログラムの配布はマシンのアーキテクチャに依存しなくなります。ただし、解釈されるソースコードの移植性は、実際に適切なインタプリタを備えているターゲットマシンに依存します。インタプリタをソースと一緒に提供する必要がある場合、インタプリタ自体がインストールする必要があるものの一部であるため、全体的なインストールプロセスはモノリシック実行可能ファイルの配信よりも複雑です。

インタプリタされたコードが人間によって簡単に読み取られてコピーされるという事実は、著作権の観点から懸念される可能性がありますただし、暗号化難読化のさまざまなシステムが存在します。バイトコードなどの中間コードの配信は、難読化と同様の効果がありますが、バイトコードは逆コンパイラーまたは逆アセンブラーでデコードできます[要出典]

効率

インタプリタの主な欠点は、通常、インタプリタされたプログラムの実行速度が、コンパイルされた場合よりも遅くなることです。速度の違いは小さい場合も大きい場合もあります。多くの場合、1桁、場合によってはそれ以上です。一般に、コンパイルされたコードを実行するよりもインタプリタでプログラムを実行する方が時間がかかりますが、コンパイルして実行するのに必要な合計時間よりも解釈にかかる時間は短くなります。これは、編集-解釈-デバッグサイクルが編集-コンパイル-実行-デバッグサイクルよりもはるかに短いことが多い場合に、コードのプロトタイピングとテストを行うときに特に重要です。[要出典]

コードの解釈は、コンパイルされたコードの実行よりも遅くなります。これは、インタープリターが実行されるたびにプログラム内の各ステートメントを分析してから目的のアクションを実行する必要があるのに対し、コンパイルされたコードは、コンパイルによって決定された固定コンテキスト内でアクションを実行するだけだからです。この実行時分析は、「解釈オーバーヘッド」として知られています。識別子の保存場所へのマッピングはコンパイル時ではなく実行時に繰り返し実行する必要があるため、インタプリタでは変数へのアクセスも遅くなります[要出典]

インタプリタを使用する場合の開発速度とコンパイラを使用する場合の実行速度の間には、さまざまな妥協点があります。一部のシステム(一部のLispなど)では、解釈およびコンパイルされたコードが相互に呼び出し、変数を共有できます。これは、ルーチンがインタプリタの下でテストおよびデバッグされると、コンパイルできるため、他のルーチンが開発されている間、より高速な実行の恩恵を受けることができることを意味します。[要出典]多くの通訳者は、ソースコードをそのままでは実行せず、よりコンパクトな内部形式に変換します。多くのBASICインタープリターは、キーワードをシングルバイト トークンに置き換えますこれは、ジャンプテーブルで命令を見つけるために使用できますPBASICインタープリターなどのいくつかのインタープリターは、バイト指向ではなくビット指向のプログラムメモリ構造を使用することで、さらに高いレベルのプログラム圧縮を実現します。コマンドトークンはおそらく5ビットを占め、名目上「16ビット」の定数が格納されます。3、6、10、または18ビットを必要とする可変長コードでは、アドレスオペランドに「ビットオフセット」が含まれます多くのBASICインタープリターは、独自のトークン化された内部表現を格納して読み戻すことができます。

インタプリタは、コンパイラと同じ字句アナライザパーサーを使用して、結果の抽象構文ツリーを解釈する場合があります。後者のデータ型定義の例と、C式から取得した構文木のおもちゃのインタプリタがボックスに示されています。

回帰

インタプリタを唯一の実行方法として使用することはできません。インタプリタ自体を解釈できる場合でも、解釈されるコードは定義上、と同じではないため、スタックの最下部のどこかに直接実行されるプログラムが必要です。 CPUが実行できるマシンコード。[6] [7]

バリエーション

バイトコードインタプリタ

プログラムが実行される前に実行される分析の量に応じて、解釈とコンパイルの間にはさまざまな可能性があります。たとえば、Emacs Lispバイトコードにコンパイルされます。バイトコードは、Lispソースの高度に圧縮され最適化された表現ですが、マシンコードではありません(したがって、特定のハードウェアに関連付けられていません)。この「コンパイルされた」コードは、バイトコードインタープリター(それ自体はCで記述されています)によって解釈されます。この場合のコンパイル済みコードは、仮想マシンのマシンコードであり、ハードウェアではなくバイトコードインタープリターに実装されています。このようなコンパイルインタプリタは、コンパイラと呼ばれることもあります[8] [9]バイトコードインタープリターでは、各命令は1バイトで始まるため、バイトコードインタープリターには最大256個の命令がありますが、すべてを使用できるわけではありません。一部のバイトコードは複数のバイトを使用する場合があり、任意に複雑になる場合があります。

制御テーブル(必ずしもコンパイルフェーズを通過する必要はありません)は、バイトコードインタープリターと同様の方法で、カスタマイズされたインタープリターを介して 適切なアルゴリズム制御フローを指示します。

スレッド化されたコードインタープリター

スレッドコードインタープリターはバイトコードインタープリターに似ていますが、バイトの代わりにポインターを使用します。各「命令」は、関数または命令シーケンスを指す単語であり、その後にパラメータが続く場合があります。スレッド化されたコードインタープリターは、命令のフェッチとそれらが指す関数の呼び出しをループするか、最初の命令をフェッチしてそれにジャンプし、すべての命令シーケンスはフェッチで終了して次の命令にジャンプします。バイトコードとは異なり、使用可能なメモリとアドレス空間以外の異なる命令の数に効果的な制限はありません。スレッドコードの典型的な例は、 Open Firmwareシステムで使用されるForthコードです。ソース言語は「Fコード」(バイトコード)にコンパイルされ、その後、仮想マシン[要出典]

抽象構文木インタプリタ

解釈とコンパイルの間のスペクトルでは、別のアプローチは、ソースコードを最適化された抽象構文ツリー(AST)に変換し、このツリー構造に従ってプログラムを実行するか、それを使用してネイティブコードをジャストインタイムで生成することです。[10]このアプローチでは、各文を1回だけ解析する必要があります。バイトコードに対する利点として、ASTはグローバルプログラム構造とステートメント間の関係(バイトコード表現では失われます)を維持し、圧縮するとよりコンパクトな表現を提供します。[11]したがって、ASTの使用は、バイトコードよりもジャストインタイムコンパイラの優れた中間形式として提案されています。また、実行時にシステムがより適切な分析を実行できるようにします。

ただし、インタープリターの場合、ASTはバイトコードインタープリターよりも多くのオーバーヘッドを引き起こします。これは、構文に関連するノードが有用な作業を実行しないため、シーケンシャル表現が少なく(より多くのポインターのトラバースが必要)、ツリーにアクセスするオーバーヘッドが発生するためです。[12]

ジャストインタイムコンパイル

インタープリター、バイトコードインタープリター、およびコンパイルの区別をさらに曖昧にするのは、実行時に中間表現をネイティブマシンコードにコンパイルする手法であるジャストインタイム(JIT)コンパイルです。これにより、ネイティブコードの実行効率が向上しますが、起動時間とバイトコードまたはASTの最初のコンパイル時のメモリ使用量が増加します。最も初期に公開されたJITコンパイラは、一般に1960年にJohn McCarthyによってLISPで動作するとされています。 [13]適応最適化は、インタプリタが実行中のプログラムをプロファイリングし、最も頻繁に実行される部分をネイティブコードにコンパイルする補完的な手法です。後者の手法は数十年前のものであり、次のような言語で表示されます。 1980年代のSmalltalk[14]

ジャストインタイムコンパイルは、 Java.NET Framework、最新のJavaScript実装、およびJITコンパイラを含むMatlabを使用して、近年、言語実装者の間で主流の注目を集めています。[要出典]

テンプレートインタプリタ

コンパイラーとインタープリターをさらに曖昧にするのは、テンプレートインタープリターと呼ばれる特別なインタープリター設計です。テンプレートインタープリターは、ソフトウェアスタックまたはツリーウォークで動作しているときに、可能なすべてのバイトコードを含む大きなswitchステートメントを使用してコードの実行を実装するのではなく、に直接マップされたバイトコード(または効率的な中間表現)の大きな配列を維持します。ホストハードウェア上でキーと値のペアとして実行できる対応するネイティブマシン命令[15] [16]は、「テンプレート」と呼ばれます。特定のコードセグメントが実行されると、インタプリタはテンプレートにオペコードマッピングをロードし、ハードウェア上で直接実行します。[17] [18]テンプレートインタープリターは、その設計により、従来のインタープリターではなく、ジャストインタイムコンパイラーに非常によく似ていますが、コードを言語からネイティブコールに変換するだけであるため、技術的にはJITではありません。コードセグメント全体からCPU実行可能命令の最適化されたシーケンスを作成するのではなく、時間。インタプリタは、呼び出しを直接実装するのではなく、ハードウェアに直接渡すという単純な設計であるため、他のすべてのタイプ、さらにはバイトコードインタプリタよりもはるかに高速であり、バグが発生しにくい程度ですが、トレードオフとして、インタプリタは、プラットフォームに依存しない仮想マシン/スタックではなく、複数の異なるアーキテクチャへの変換をサポートする必要があるため、維持します。現在まで、[15]

自己通訳

自己通訳者は、自分自身を解釈できるプログラミング言語で書かれたプログラミング言語通訳者です。例として、BASICで記述されたBASICインタープリターがあります。セルフインタープリターは、セルフホスティングコンパイラーに関連しています。

解釈する言語のコンパイラが存在しない場合、自己インタプリタを作成するには、ホスト言語(別のプログラミング言語またはアセンブラの場合があります)で言語を実装する必要があります。このような最初のインタプリタを用意することで、システムがブートストラップされ、新しいバージョンのインタプリタを言語自体で開発できます。このようにして、ドナルド・クヌースは、業界標準のTeX植字システムの言語WEB用のTANGLEインタープリターを開発しました

コンピューター言語の定義は、通常、抽象マシン(いわゆる操作的意味論)に関連して、または数学関数(表示的意味論)として行われます。言語は、ホスト言語のセマンティクスが与えられているインタプリタによって定義される場合もあります。自己通訳による言語の定義は十分に根拠がありません(言語を定義することはできません)が、自己通訳は読者に言語の表現力と優雅さを伝えます。また、インタプリタがソースコードを解釈できるようにします。これは、リフレクティブ通訳に向けた最初のステップです。

自己通訳者の実装における重要な設計上の側面は、通訳された言語の機能が通訳者のホスト言語の同じ機能で実装されているかどうかです。例としてはLispのような言語のクロージャが、インタプリタ言語のクロージャを使用して実装されているか、環境を明示的に格納するデータ構造を使用して「手動で」実装されているかがあります。ホスト言語の同じ機能によって実装される機能が多いほど、インタープリターのプログラマーが持つ制御は少なくなります。算術演算がホスト言語の対応する演算に委任されている場合、数値オーバーフローを処理するための別の動作を実現することはできません。

LispPrologなどの一部の言語には、エレガントな自己通訳があります。[19]自己通訳者(特に反射通訳者)に関する多くの研究は、Lispの方言であるSchemeプログラミング言語で行われてきました。ただし、一般的に、チューリング完全言語では、独自の通訳者を書くことができます。Lispプログラムはシンボルのリストやその他のリストであるため、Lispはそのような言語です。XSLTプログラムはXMLで記述されているため、XSLTはそのような言語です。メタプログラミングのサブドメインは、ドメイン固有言語(DSL) の記述です。

Clive Giffordは、自己通訳者の測定品質(固有比率)を導入しました。これは、N個の自己通訳者のスタックの実行に費やされるコンピューター時間とN −1個の自己通訳者のスタック実行に費やされる時間の比率の限界です。 Nは無限大になります。この値は、実行中のプログラムに依存しません。

「コンピュータプログラムの構造と解釈」という本は、Schemeとその方言のメタサーキュラー解釈の例を示しています。自己通訳付きの言語の他の例は、ForthPascalです。

マイクロコード

マイクロコードは、「ハードウェアとコンピューターのアーキテクチャーレベルの間にインタープリターを課す」非常に一般的に使用される手法です。[21]このように、マイクロコードはハードウェアレベルの命令の層であり、多くのデジタル処理要素でより高いレベルのマシンコード命令または内部ステートマシンシーケンスを実装します。マイクロコードは、汎用の中央処理装置だけでなく、マイクロコントローラーデジタルシグナルプロセッサーチャネルコントローラーディスクコントローラーネットワークインターフェイスコントローラーなどのより特殊なプロセッサーでも使用されますネットワークプロセッサグラフィックスプロセッシングユニット、およびその他のハードウェア。

マイクロコードは通常、特別な高速メモリに常駐し、マシン命令、ステートマシンデータ、またはその他の入力を一連の詳細な回路レベルの操作に変換します。機械の命令を基礎となる電子機器から分離し、命令をより自由に設計および変更できるようにします。また、コンピュータ回路の複雑さを軽減しながら、複雑なマルチステップ命令の構築を容易にします。マイクロコードの記述はマイクロプログラミングと呼ばれることが多く、特定のプロセッサ実装のマイクロコードはマイクロプログラムと呼ばれることもあります

より広範なマイクロコーディングにより、小さくて単純なマイクロアーキテクチャは、より広いワード長、より多くの実行ユニットなどを備えたより強力なアーキテクチャエミュレートできます。これは、プロセッサフ​​ァミリのさまざまな製品間のソフトウェア互換性を実現する比較的簡単な方法です。

コンピュータプロセッサ

非マイクロコーディングコンピュータプロセッサ自体でさえ、マシンコード命令を解析してすぐに実行するシステムを作成するために、 VHDLなどの汎用ハードウェア記述言語で記述された解析即時実行インタプリタと見なすことができます。

アプリケーション

  • コマンド言語で実行される各オペレーターは通常、エディターやコンパイラーなどの複雑なルーチンの呼び出しであるため、インタープリターはコマンド言語を実行するために頻繁に使用され、言語接着します。[要出典]
  • 自己変更コードは、インタプリタ言語で簡単に実装できます。これは、Lispと人工知能の研究における解釈の起源に関連しています。[要出典]
  • 仮想化ハードウェアアーキテクチャ向けのマシンコードは、仮想マシンを使用して実行できます。これは、意図したアーキテクチャが利用できない場合、または他の用途の中でも、複数のコピーを実行するためによく使用されます。
  • サンドボックス:一部の種類のサンドボックスはオペレーティングシステムの保護に依存していますが、インタープリターまたは仮想マシンがよく使用されます。実際のハードウェアアーキテクチャと当初意図されていたハードウェアアーキテクチャは、同じである場合とそうでない場合があります。サンドボックスが処理しているソースコードのすべての命令を実際に実行するように強制されていないことを除いて、これは無意味に思えるかもしれません。特に、動作しているセキュリティ制約に違反するコードの実行を拒否する可能性があります。[要出典]
  • より近代的な機器で廃止され利用できないハードウェア用に作成されたコンピューターソフトウェアを実行するためのエミュレーター。

も参照してください

参考文献

  1. ^ この意味で、CPUは機械命令のインタプリタでもあります。
  2. ^ このスキーム(戦略2と3を組み合わせたもの)は、たとえばABC 80の効率的なBASICインタープリターなど、1970年代にすでに特定のBASICインタープリターを実装するために使用されました。
  3. ^ ベネット、JM; プリンツ、DG; ウッズ、ML(1952)。「解釈サブルーチン」。トロントのACM全国会議の議事録
  4. ^ ハッカーと画家のポール・グレアムによって報告されたものによると、p。 185、マッカーシーは言った:「スティーブラッセルは言った、見て、なぜ私はこの評価をプログラムしないのか...そして私は彼に言った、ホー、ホー、あなたは理論と実践を混同している、この評価は読むことを意図しているのではなくしかし、彼は先に進んでそれを実行しました。つまり、彼は私の論文のevalをIBM 704マシンコードにコンパイルし、バグを修正してから、これをLispインタープリターとしてアドバタイズしました。本質的には今日の形です...」
  5. ^ 「なぜ最初のコンパイラが最初のインタプリタの前に書かれたのですか?」ArsTechnica2014年11月8日2014年11月9日取得
  6. ^ Theodore H. Romer、Dennis Lee、Geoffrey M. Voelker、Alec Wolman、Wayne A. Wong、Jean-Loup Baer、Brian N. Bershad、Henry M. Levy、通訳者の構造とパフォーマンス
  7. ^ Terence Parr、Johannes Luber、ウェイバックマシンでアーカイブされたコンパイラとインタプリタの違い 2014-01-06
  8. ^ Kühnel、Claus(1987)[1986]。「4.Kleincomputer-EigenschaftenundMöglichkeiten」[4。マイクロコンピューター-特性と可能性]。Erlekampfでは、Rainer; ハンス・ヨアヒム・メンク(編)。Mikroelektronik in der Amateurpraxis [実用的なアマチュアのためのマイクロエレクトロニクス](ドイツ語)(3版)。ベルリン:MilitärverlagderDeutschenDemokratischen Republik  [ de ]、ライプツィヒ。p。222. ISBN 3-327-00357-27469332。
  9. ^ Heyne、R。(1984)。「Basic-CompreterfürU880」[U880(Z80)用のBASICコンピューター]。radio-fernsehn-elektronik  [ de ](ドイツ語)。1984(3):150–152。
  10. ^ AST中間表現、Lambda theUltimateフォーラム
  11. ^ キスラー、トーマス; フランツ、マイケル(1999年2月)。「Javaバイトコードのツリーベースの代替」(PDF)並列プログラミングの国際ジャーナル27(1):21–33。CiteSeerX10.1.1.87.2257_ 土井10.1023 / A:1018740018601ISSN0885-7458_ S2CID14330985 _ 2020年12月20日取得    
  12. ^ Surfin'Safari-ブログアーカイブ»SquirrelFishの発表Webkit.org(2008-06-02)。2013年8月10日に取得。
  13. ^ Aycock 2003、2。JITコンパイル手法、2.1ジェネシス、p。98。
  14. ^ L. Deutsch、 A。Schiffman 、Smalltalk-80システムの効率的な実装、第11回POPLシンポジウムの議事録、1984年。
  15. ^ a b "openjdk / jdk"GitHub2021年11月18日。
  16. ^ https://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Interpreter
  17. ^ 「JVMの謎を解く:JVMバリアント、CppinterpreterおよびTemplateInterpreter」metebalci.com
  18. ^ 「JVMテンプレートインタプリタ」ProgrammerSought
  19. ^ ボンドルフ、アンダース。 Logimix:Prologの自己適用可能な部分評価者。」ロジックプログラムの合成と変換。スプリンガー、ロンドン、1993年。214-227。
  20. ^ ギフォード、クライヴ。「自己通訳者の固有」ブロガー2019年11月10日取得
  21. ^ ケント、アレン; ウィリアムズ、ジェームズG.(1993年4月5日)。コンピュータサイエンスとテクノロジーの百科事典:第28巻-補足13ニューヨーク:Marcel Dekker、Inc。ISBN 0-8247-2281-72016年1月17日取得

外部リンク