コンピューティングにおいて、コンパイラとは、あるプログラミング言語（ソース言語）で書かれたコンピュータコードを別の言語（ターゲット言語）に変換するソフトウェアです。「コンパイラ」という名称は、主に、高水準プログラミング言語のソースコードを低水準プログラミング言語（アセンブリ言語、オブジェクトコード、マシンコードなど）に変換し、実行可能プログラムを作成するプログラムに用いられます。[1] [2] : p1  [3]

コンパイラには様々な種類があり、それぞれ異なる有用な形式で出力を生成します。クロスコンパイラは、自身が実行されるCPUやオペレーティングシステムとは 異なるCPUやオペレーティングシステム用のコードを生成します。ブートストラップコンパイラは、多くの場合、一時的なコンパイラであり、特定の言語向けに、より永続的またはより最適化されたコンパイラをコンパイルするために使用されます。

関連ソフトウェアには、低レベル言語から高レベル言語に変換するプログラムであるデコンパイラ、高レベル言語間の変換プログラム（通常はソース間コンパイラまたはトランスパイラと呼ばれる）、言語リライタ（通常は言語を変更せずに式の形式を変換するプログラム）、およびコンパイラ コンパイラ（多くの場合汎用的で再利用可能な方法でコンパイラ（またはその一部）を作成し、多くの異なるコンパイラを作成できるようにするコンパイラ）などがあります。

コンパイラは、前処理、字句解析、構文解析、意味解析（構文に基づく翻訳）、入力プログラムから中間表現への変換、コード最適化、マシン固有のコード生成といった、フェーズと呼ばれる操作の一部またはすべてを実行します。コンパイラは通常、これらのフェーズをモジュールコンポーネントとして実装し、効率的な設計とソース入力からターゲット出力への変換の正確性を促進します。コンパイラの誤った動作によって引き起こされるプログラム障害は、追跡して回避することが非常に困難な場合があります。そのため、コンパイラの実装者は、コンパイラの正確性を確保するために多大な労力を費やしています。[4]

通訳との比較

ソースコードを実行可能にするという点では、インタプリタはコンパイラと同様の機能を提供しますが、そのメカニズムは異なります。インタプリタはコードを機械語に変換せずに実行します。[2] : p2 そのため、ソースコードを実行するインタプリタもあれば、バイトコードなどの中間形式を実行するインタプリタもあります。

したがって、ネイティブコードにコンパイルされたプログラムは、インタープリタで実行された場合よりも高速に実行される傾向があります。バイトコード中間形式を使用する環境では、中間速度になる傾向があります。一方、ジャストインタイムコンパイルでは、一度の起動処理にかかるコストを犠牲にして、ネイティブ実行速度を実現します。

アセンブリ言語やC言語などの低水準プログラミング言語は、特に速度が重視される場合、クロスプラットフォーム対応ではなくコンパイルされるのが一般的です。そのため、このような言語では、ソースコードと生成されるマシンコードの間に1対1の対応関係がより多く存在し、プログラマーがハードウェアの使用を制御しやすくなります。

理論上、プログラミング言語はコンパイラまたはインタプリタを介して使用できますが、実際には、各言語はどちらか一方のみで使用される傾向があります。しかしながら、一般的にインタプリタで実行される言語用のコンパイラを作成することは可能です。例えば、Common LispはJavaバイトコードにコンパイルされ（その後Java仮想マシンによってインタプリタ処理されます）、Cコードにコンパイルされ（その後ネイティブマシンコードにコンパイルされます）、または直接ネイティブコードにコンパイルできます。

歴史

典型的な多言語、マルチターゲットコンパイラの動作図

科学者、数学者、エンジニアによって開発された理論的な計算概念は、第二次世界大戦中のデジタル現代計算の発展の基礎を形成しました。デジタル機器は1と0、そして基礎となるマシンアーキテクチャの回路パターンしか理解できなかったため、原始的なバイナリ言語が進化しました。1940年代後半には、コンピュータアーキテクチャをより実用的な抽象化するためにアセンブリ言語が作成されました。[5]初期のコンピュータはメモリ容量が限られていたため、最初のコンパイラの設計時には大きな技術的課題がありました。そのため、コンパイルプロセスを複数の小さなプログラムに分割する必要がありました。フロントエンドプログラムは、バックエンドプログラムがターゲットコードを生成するために使用する分析製品を生成します。コンピュータ技術がより多くのリソースを提供するにつれて、コンパイラの設計はコンパイルプロセスとよりよく一致するようになりました。

プログラマーにとって、高水準言語を使用する方が生産性が高い場合が多いため、デジタルコンピュータの機能向上に伴い、高水準言語の開発は自然な流れで進みました。高水準言語とは、高水準言語アーキテクチャを構成する 構文と意味論によって厳密に定義された形式言語です。これらの形式言語の要素には、以下のものがあります。

  • アルファベット、任意の有限の記号の集合。
  • 文字列、有限の記号のシーケンス。
  • 言語、アルファベット上の任意の文字列のセット。

言語における文は、文法と呼ばれる一連の規則によって定義されることがあります。[6]

バッカス・ナウア記法（BNF）は、言語の「文」の構文を記述する記法です。ジョン・バッカスによって開発され、 Algol 60の構文に使用されました。[7]この概念は、言語学者ノーム・チョムスキーの文脈自由文法の概念に由来しています。[8]「BNFとその拡張は、プログラミング記法の構文を記述するための標準的なツールとなっています。多くの場合、コンパイラの一部はBNF記述から自動的に生成されます。」[9]

1942年から1945年にかけて、コンラート・ツーゼはコンピュータ用の最初の（アルゴリズム的）プログラミング言語であるプランカルキュル（Plankalkül、「平面計算」）を設計しました。ツーゼはまた、プログラムの数学的定式化を機械可読なパンチフィルムに自動的に変換するプランフェルティグングスゲレット（ Planfertigungsgerät 、「平面組立装置」）を構想しました。[10]実際の実装は1970年代まで行われませんでしたが、後にケン・アイバーソンが1950年代後半に設計したAPLに見られる概念を提示しました。 [11] APLは数学計算のための言語です。

1949年から1951年にかけて、ハインツ・ルティスハウザーは高級言語と自動翻訳機であるスーパープランを提案した。 [12]彼のアイデアは後にフリードリヒ・L・バウアーとクラウス・ザメルソンによって改良された。[13]

デジタルコンピューティングの形成期における高水準言語設計は、さまざまなアプリケーションに役立つプログラミング ツールを提供しました。

コンパイラ技術は、高水準ソースプログラムをデジタルコンピュータ用の低水準ターゲットプログラムへと厳密に定義された変換を行う必要性から発展しました。コンパイラは、ソースコードの解析を行うフロントエンドと、解析結果をターゲットコードに合成するバックエンドとして捉えることができます。フロントエンドとバックエンド間の最適化により、より効率的なターゲットコードを生成することができます。[17]

コンパイラ技術開発における初期のマイルストーンは次のとおりです。

初期のオペレーティングシステムとソフトウェアはアセンブリ言語で書かれていました。1960年代から1970年代初頭にかけては、リソースの制約から、システムプログラミングにおける高級言語の使用は依然として議論の的となっていました。しかし、いくつかの研究と産業界の取り組みにより、BCPL、BLISS、B、Cといった高級システムプログラミング言語への移行が始まりました。

1966年にケンブリッジ大学のマーティン・リチャーズによって設計されたBCPL（Basic Combined Programming Language）は、もともとコンパイラ作成ツールとして開発されました。 [30]いくつかのコンパイラが実装されており、リチャーズの著書では、言語とそのコンパイラに関する洞察が提供されています。[31] BCPLは、現在でも研究に使用されている影響力のあるシステムプログラミング言語であるだけでなく、 [32] B言語とC言語の設計の基礎も提供しました。

BLISS（システムソフトウェア実装用基本言語）は、WA Wulf率いるカーネギーメロン大学（CMU）の研究チームによって、Digital Equipment Corporation（DEC）のPDP-10コンピュータ向けに開発されました。CMUチームは1年後の1970年にBLISS-11コンパイラを開発しました。

Multics (Multiplexed Information and Computing Service) は、 MIT、ベル研究所、ゼネラル・エレクトリック(後のハネウェル)が参加したタイムシェアリング・オペレーティング・システム・プロジェクトで、MIT のFernando Corbatóがリーダーを務めた。[33] Multics は、IBM と IBM ユーザー・グループが開発したPL/I言語で書かれた。 [34] IBM の目標は、ビジネス、科学、システム・プログラミングの要件を満たすことだった。検討できた言語は他にもあったが、PL/I は実装されていなかったものの、最も完全なソリューションを提供した。[35] Multics プロジェクトの最初の数年間は、ベル研究所の Doug McIlory と Bob Morris による Early PL/I (EPL) コンパイラーを使用して、言語のサブセットをアセンブリ言語にコンパイルすることができた。[36] EPL は、完全な PL/I 用のブートストラッピング・コンパイラーが開発されるまでプロジェクトをサポートした。[37]

ベル研究所は1969年にMulticsプロジェクトから離脱し、BCPLのコンセプトに基づいたシステムプログラミング言語Bを開発しました。これはデニス・リッチーとケン・トンプソンによって書かれました。リッチーはB用のブートストラップコンパイラを開発し、 PDP-7用のUnics（Uniplexed Information and Computing Service）オペレーティングシステムをBで記述しました。Unicsは最終的にUnixと綴られるようになりました。

ベル研究所はBとBCPLをベースにCの開発と拡張を開始しました。BCPLコンパイラはベル研究所によってMulticsに移植されており、BCPLはベル研究所で推奨言語でした。[38]当初、Cコンパイラの開発中はベル研究所のBコンパイラのフロントエンドプログラムが使用されました。1971年、新しいPDP-11がBの拡張を定義し、コンパイラを書き直すためのリソースを提供しました。1973年までにC言語の設計は実質的に完了し、PDP-11用のUnixカーネルはCで書き直されました。スティーブ・ジョンソンは、Cコンパイラを新しいマシンに再ターゲットするためのポータブルCコンパイラ（PCC）の開発を開始しました。[39] [40]

オブジェクト指向プログラミング（OOP）は、アプリケーションの開発と保守にいくつかの興味深い可能性をもたらしました。OOPの概念はさらに古くから存在していましたが、LISPとSimula言語科学の一部でした。[41]ベル研究所はC++の開発をきっかけにOOPに興味を持つようになりました。[42] C++は1980年にシステムプログラミングに初めて使用されました。初期の設計では、C言語のシステムプログラミング機能とSimulaの概念が活用されていました。オブジェクト指向機能は1983年に追加されました。[43] Cfrontプログラムは、C84言語コンパイラ用のC++フロントエンドを実装しました。その後、C++の人気が高まるにつれて、いくつかのC++コンパイラが開発されました。

多くのアプリケーション分野において、高水準言語を使用するという考え方が急速に広まりました。新しいプログラミング言語がサポートする機能の拡大と、コンピュータアーキテクチャの複雑さの増大により、コンパイラはより複雑になりました。

1970年、 DARPA（国防高等研究計画局）はウルフのCMU研究チームと共同でコンパイラプロジェクトを後援した。Production Quality Compiler-Compiler PQCC設計は、ソース言語とターゲットの形式定義からProduction Quality Compiler（PQC）を生成するものであった。[44] PQCCは、コンパイラ-コンパイラという用語を、従来のパーサージェネレータ（ Yaccなど）の意味を超えて拡張しようとしたが、あまり成功しなかった。PQCCは、より正確にはコンパイラジェネレータと呼ぶべきかもしれない。

PQCC のコード生成プロセスの研究では、真に自動化されたコンパイラ作成システムの構築を目指しました。この取り組みにより、PQC のフェーズ構造が発見され、設計されました。BLISS-11 コンパイラが最初の構造を提供しました。[45]フェーズには、分析 (フロントエンド)、仮想マシンへの中間変換 (ミドルエンド)、ターゲットへの変換 (バックエンド) が含まれます。TCOL は、中間表現で言語固有の構成要素を処理するために PQCC 研究用に開発されました。[46] TCOL のバリエーションはさまざまな言語をサポートしました。PQCC プロジェクトでは、自動コンパイラ構築の手法を調査しました。設計コンセプトは、コンパイラの最適化や、(1995 年以降はオブジェクト指向) プログラミング言語Ada用のコンパイラに役立つことが証明されました。

Ada STONEMAN文書[a]は、プログラム支援環境（APSE）に加え、カーネル（KAPSE）と最小限の環境（MAPSE）を公式化した。AdaインタープリタであるNYU/EDは、米国規格協会（ANSI）および国際標準化機構（ISO）との開発・標準化活動を支援していた。米軍による初期のAdaコンパイラ開発には、STONEMAN文書に沿った完全な統合設計環境に組み込まれたコンパイラが含まれていた。陸軍と海軍はDEC/VAXアーキテクチャを対象としたAda言語システム（ALS）プロジェクトに取り組み、空軍はIBM 370シリーズを対象としたAda統合環境（AIE）に着手した。これらのプロジェクトは期待された成果をもたらさなかったものの、Ada開発全体の取り組みに貢献した。[47]

その他の Ada コンパイラの開発は、イギリスのヨーク大学やドイツのカールスルーエ大学でも始まりました。米国では、Verdix (後に Rational に買収された) が陸軍に Verdix Ada 開発システム (VADS) を提供しました。VADS はコンパイラを含む開発ツールのセットを提供しました。Unix/VADS は DEC Ultrix や、陸軍 CECOM 評価で Motorola 68020 をターゲットとした Sun 3/60 Solaris など、さまざまな Unix プラットフォームでホストできました。[48] Ada 検証テストに合格した多くの Ada コンパイラがすぐに登場しました。フリーソフトウェア財団の GNU プロジェクトは、複数の言語とターゲットをサポートするための中核機能を提供するGNU コンパイラ コレクション(GCC) を開発しました。Ada バージョンのGNATは、最も広く使用されている Ada コンパイラの 1 つです。GNAT は無料ですが、商用サポートもあり、たとえば AdaCore は 1994 年に Ada 用の商用ソフトウェア ソリューションを提供するために設立されました。 GNAT Pro には、統合開発環境を提供するツール スイートを備えた GNU GCC ベースの GNAT が含まれています。

高水準言語は、コンパイラの研究開発を牽引し続けました。重点分野には、最適化と自動コード生成が含まれていました。プログラミング言語と開発環境の動向は、コンパイラ技術に影響を与えました。より多くのコンパイラが、言語ディストリビューション（PERL、Java Development Kit）やIDE（VADS、Eclipse、Ada Pro）のコンポーネントとして含まれるようになりました。技術間の相互関係と相互依存性が高まりました。Webサービスの出現は、Web言語とスクリプト言語の成長を促進しました。スクリプトは、ユーザーがシステムに実行させるコマンドを入力できるコマンドラインインターフェース（CLI）の初期の時代にまで遡ります。ユーザーシェルの概念は、シェルプログラムを記述するための言語によって発展しました。初期のWindows設計は、シンプルなバッチプログラミング機能を提供していました。これらの言語の従来の変換には、インタープリタが使用されていました。広くは使用されていませんが、BashとBatchコンパイラが開発されました。最近では、洗練されたインタープリタ型言語が開発者ツールキットの一部となっています。最新のスクリプト言語には、PHP、Python、Ruby、Luaなどがあります（Luaはゲーム開発で広く使用されています）。これらはすべて、インタープリタとコンパイラをサポートしています。[49]

「1950年代後半にコンパイルの分野が始まった当初、その焦点は高級言語プログラムを機械語に変換することに限られていました。…コンパイラ分野は、コンピュータアーキテクチャ、プログラミング言語、形式手法、ソフトウェア工学、コンピュータセキュリティといった他の分野とますます密接に絡み合っています。」[50]「コンパイラ研究：今後50年」の記事では、オブジェクト指向言語とJavaの重要性が指摘されています。セキュリティと並列コンピューティングは、将来の研究目標として挙げられています。

コンパイラの構築

コンパイラは、高水準ソースプログラムから低水準ターゲットプログラムへの形式的な変換を実装します。コンパイラ設計では、エンドツーエンドのソリューションを定義することも、プリプロセッサ、アセンブラ、リンカーなどの他のコンパイルツールとインターフェースする定義済みのサブセットに取り組むこともできます。設計要件には、コンパイラコンポーネント間の内部インターフェースと、サポートツールセット間の外部インターフェースの両方において、厳密に定義されたインターフェースが含まれます。

初期のコンパイラ設計のアプローチは、処理対象となるコンピュータ言語の複雑さ、設計者の経験、そして利用可能なリソースに直接影響されていました。リソースの制約により、ソースコードを複数回検証する必要がありました。

比較的単純な言語のコンパイラであれば、一人で書いたものは単一のモノリシックなソフトウェアになるかもしれません。しかし、ソース言語が複雑になるにつれて、設計は相互に依存する複数のフェーズに分割されることがあります。これらのフェーズでは、コンパイルプロセスの機能に重点を置いた設計改善が行われます。

ワンパスコンパイラとマルチパスコンパイラ

コンパイラをパス数で分類する背景には、コンピュータのハードウェアリソースの限界があります。コンパイルには多くの作業が必要であり、初期のコンピュータには、これらすべての作業を実行するプログラムを1つ格納できるだけのメモリがありませんでした。その結果、コンパイラは小さなプログラムに分割され、各プログラムはソース（またはその表現）をパスすることで、必要な解析と変換の一部を実行しました。

シングルパスでコンパイルできる機能は、コンパイラの作成作業を簡素化し、また、シングルパスコンパイラはマルチパスコンパイラよりも一般的にコンパイル速度が速いため、従来から利点と考えられてきました。そのため、初期のシステムのリソース制限もあって、多くの初期の言語はシングルパスでコンパイルできるように特別に設計されていました（例：Pascal）。

言語機能の設計によっては、コンパイラがソースコードを複数回処理する必要がある場合もあります。例えば、ソースコードの20行目に出現する宣言が、10行目の文の翻訳に影響を与えるとします。この場合、最初のパスでは、影響を受ける文の後に出現する宣言に関する情報を収集し、実際の翻訳は後続のパスで行われます。

シングルパスでコンパイルするデメリットは、高品質なコードを生成するために必要な高度な最適化の多くを実行できないことです。最適化コンパイラが実行するパス数を正確に数えることは困難です。例えば、最適化の異なるフェーズで、ある式は複数回解析される一方で、別の式は1回しか解析されない場合があります。

コンパイラを小さなプログラムに分割することは、証明可能な正しさを持つコンパイラの開発に関心を持つ研究者が用いる手法です。小さなプログラム群の正しさを証明する方が、単一の同等の大きなプログラムの正しさを証明するよりも労力が少なくなることがよくあります。

3段階コンパイラ構造

コンパイラ設計

コンパイラ設計におけるフェーズの正確な数に関わらず、フェーズは3つのステージのいずれかに割り当てることができます。これらのステージには、フロントエンド、ミドルエンド、バックエンドが含まれます。

  • フロントエンドは入力をスキャンし、特定のソース言語に従って構文と意味を検証します。静的型付け言語の場合、型情報を収集することで型チェックを実行します。入力プログラムに構文上の誤りや型エラーがある場合、エラーメッセージや警告メッセージを生成し、通常はソースコード内で問題が検出された箇所を特定します。場合によっては、実際のエラーはプログラムの（かなり）前の部分にあることもあります。フロントエンドの機能には、字句解析、構文解析、意味解析が含まれます。フロントエンドは入力プログラムを中間表現（IR）に変換し、ミドルエンドでさらに処理できるようにします。このIRは通常、ソースコードに対するプログラムの低レベル表現です。
  • ミドルエンドは、対象となるCPUアーキテクチャに依存しないIRの最適化を実行します。このソースコードとマシンコードの独立性は、異なる言語やターゲットプロセッサをサポートするコンパイラのバージョン間で汎用的な最適化を共有できるようにすることを目的としています。ミドルエンドの最適化の例としては、不要なコード（デッドコード除去）や到達不可能なコード（到達可能性分析）、定数値の検出と伝播（定数伝播）、実行頻度の低い場所（ループ外など）への計算の再配置、コンテキストに基づいた計算の特化などが挙げられ、最終的にはバックエンドで使用される「最適化された」IRが生成されます。
  • バックエンドは、ミドルエンドから最適化されたIRを受け取ります。ターゲットCPUアーキテクチャに固有の追加の分析、変換、最適化を実行する場合があります。バックエンドは、ターゲット依存のアセンブリコードを生成し、その過程でレジスタ割り当てを実行します。バックエンドは命令スケジューリングを実行し、遅延スロットを埋めることで並列実行ユニットをビジー状態に保つために命令の順序を変更します。ほとんどの最適化問題はNP困難ですが、それらを解決するためのヒューリスティックな手法は十分に開発されており、製品品質のコンパイラに実装されています。通常、バックエンドの出力は、特定のプロセッサとオペレーティングシステムに特化したマシンコードです。

このフロント/ミドル/バックエンドのアプローチにより、ミドルエンドの最適化を共有しながら、異なる言語のフロントエンドと異なるCPUのバックエンドを組み合わせることができます。 [51]このアプローチの実際の例としては、GNUコンパイラコレクション、Clang（LLVMベースのC/C++コンパイラ）、[52]アムステルダムコンパイラキットなどがあり、これらは複数のフロントエンド、共有最適化、複数のバックエンドを備えています。

フロントエンド

Cの字句解析器とパーサーの例。スキャナは文字列 " " からトークンのシーケンスを作成し、それぞれを識別子、予約語、数値リテラル、演算子などに分類します。後者のシーケンスはパーサーによって構文木に変換され、残りのコンパイラフェーズで処理されます。スキャナとパーサーは、それぞれC の文法の正規表現部分と文脈自由部分を処理します。if(net>0.0)total+=net*(1.0+tax/100.0);

フロントエンドはソースコードを解析し、中間表現（IR）と呼ばれるプログラムの内部表現を構築します。また、ソースコード内の各シンボルを位置、型、スコープなどの関連情報にマッピングするデータ構造である シンボルテーブルを管理します。

フロントエンドは、スキャナレス パーサのように単一のモノリシックな関数またはプログラムにすることもできますが、伝統的には複数のフェーズとして実装および分析され、順次または同時に実行されることがあります。 この方法は、モジュール性と関心の分離のために好まれています。 最も一般的には、フロントエンドは、字句解析(字句分析またはスキャンとも呼ばれる)、構文解析(スキャンまたは解析とも呼ばれる)、および意味解析の3 つのフェーズに分けられます。 字句分析と解析は、構文解析 (それぞれ単語構文と句構文) を構成し、単純なケースでは、これらのモジュール (字句解析器とパーサ) は言語の文法から自動的に生成できますが、より複雑なケースでは手動で変更する必要があります。 字句文法と句文法は通常、文脈自由文法であり、これにより分析が大幅に簡素化され、文脈依存性は意味解析フェーズで処理されます。意味解析フェーズは一般的に複雑で手作業で記述されますが、属性文法を用いることで部分的または完全に自動化できます。これらのフェーズ自体はさらに細分化できます。字句解析はスキャンと評価、構文解析は具体的な構文木（CST、構文木）の構築と抽象構文木（AST、構文木）への変換です。場合によっては、行再構成や前処理などの追加のフェーズが用いられますが、これはまれです。

フロントエンドの主なフェーズは次のとおりです。

  • 行再構成は、入力文字列をパーサーが処理できる標準的な形式に変換します。キーワードをストロップするトップダウン、再帰降下、テーブル駆動型のパーサーは、通常、ソースコードを1文字ずつ読み取り、トークン化フェーズを別途必要としませんでした。AtlasAutocodeとImpALGOLとCoral 66の一部の実装行再構成が含まれるストロップ言語の例です。
  • 前処理はマクロ置換と条件付きコンパイルをサポートします。通常、前処理フェーズは構文解析または意味解析の前に実行されます。例えばC言語の場合、前処理は構文形式ではなく語彙トークンを操作します。ただし、 Schemeなどの一部の言語では、構文形式に基づくマクロ置換をサポートしています。
  • 字句解析（字句解析またはトークン化とも呼ばれる）は、ソースコードテキストを字句トークンと呼ばれる一連の小さな断片に分解します。 [53]このフェーズは2つの段階に分けられます。1つはスキャンで、入力テキストを語彙素と呼ばれる構文単位に分割してカテゴリを割り当てます。もう1つは評価で、語彙素を処理済みの値に変換します。トークンは、トークン名とオプションのトークン値で構成されるペアです。 [54]一般的なトークンカテゴリには、識別子、キーワード、セパレータ、演算子、リテラル、コメントが含まれますが、トークンカテゴリのセットはプログラミング言語によって異なります。語彙素構文は通常、正規言語であるため、正規表現から構築された有限状態オートマトンを使用して認識できます。字句解析を行うソフトウェアは、字句解析装置と呼ばれます。これは別個のステップではない可能性があり、スキャナレス解析の解析ステップと組み合わせることができます。その場合、解析はトークン レベルではなく文字レベルで実行されます。
  • 構文解析（構文解析とも呼ばれる）は、トークン列を解析してプログラムの構文構造を特定することを含む。このフェーズでは通常、構文解析木が構築される。構文解析木は、トークンの線形列を、言語の構文を定義する形式文法の規則に従って構築された木構造に置き換える。構文解析木は、コンパイラの後続のフェーズで解析、拡張、変換されることが多い。 [55]
  • セマンティック解析は、構文解析ツリーにセマンティック情報を追加し、シンボルテーブルを構築します。このフェーズでは、型チェック（型エラーのチェック）、オブジェクトバインディング（変数および関数参照をその定義に関連付ける）、明確な代入（すべてのローカル変数を使用前に初期化する必要があること）、不正なプログラムの拒否、警告の発行などのセマンティックチェックを実行します。セマンティック解析には通常、完全な構文解析ツリーが必要です。つまり、このフェーズは論理的には構文解析フェーズの後に続き、論理的にはコード生成フェーズの前にあります。ただし、コンパイラ実装では、複数のフェーズをコード上の1回のパスにまとめることが可能な場合が多くあります。

ミドルエンド

ミドルエンドはオプティマイザとも呼ばれ、中間表現に対して最適化を実行し、生成されるマシンコードのパフォーマンスと品質を向上させます。[56]ミドルエンドには、対象となるCPUアーキテクチャに依存しない最適化が含まれています。

ミドルエンドの主なフェーズは次のとおりです。

コンパイラ解析はあらゆるコンパイラ最適化の前提条件であり、両者は密接に連携して動作します。例えば、依存関係解析はループ変換に不可欠です。

コンパイラの分析と最適化の範囲は多岐にわたります。その範囲は、基本ブロック内の動作から、プロシージャ全体、さらにはプログラム全体まで多岐にわたります。最適化の粒度とコンパイルコストの間にはトレードオフがあります。例えば、ピープホール最適化はコンパイル中に高速に実行されますが、コードの小さなローカルフラグメントにのみ影響し、コードフラグメントが出現するコンテキストとは独立して実行できます。一方、プロシージャ間最適化はより多くのコンパイル時間とメモリ空間を必要としますが、複数の関数の動作を同時に考慮することによってのみ実現可能な最適化を可能にします。

プロシージャ間解析と最適化は、HP、IBM、SGI、Intel、Microsoft、Sun Microsystemsなどの最新の商用コンパイラでは一般的です。フリーソフトウェアの GCCは、強力なプロシージャ間最適化が不足していると長年批判されてきましたが、この点は改善されつつあります。完全な解析および最適化インフラストラクチャを備えた別のオープンソースコンパイラはOpen64で、多くの組織で研究目的および商用目的で使用されています。

コンパイラの解析と最適化には余分な時間とメモリが必要となるため、一部のコンパイラではデフォルトでこれらの処理を省略しています。ユーザーは、コンパイルオプションを使用して、どの最適化を有効にするかをコンパイラに明示的に指示する必要があります。

バックエンド

バックエンドはCPUアーキテクチャ固有の最適化とコード生成を担当します。[56]

バックエンドの主なフェーズは次のとおりです。

コンパイラの正確性

コンパイラの正確性は、コンパイラが言語仕様に従って動作することを示すソフトウェアエンジニアリングの分野です。[58]技術には、形式手法を使用してコンパイラを開発することや、既存のコンパイラに対して厳密なテスト（コンパイラ検証と呼ばれることが多い）を使用することが含まれます。

コンパイル型言語とインタープリタ型言語

高水準プログラミング言語は通常、何らかの翻訳を念頭に置いて設計されており、コンパイル言語またはインタプリタ言語として設計されています。しかしながら、実際には、実行時に再解釈を必要とする言語を設計することは可能ですが、言語がコンパイルのみ、またはインタプリタのみで実行されることを要求するケースは稀です。この分類は通常、言語の最も普及した実装を反映しています。例えば、BASICはインタプリタ言語、Cはコンパイル言語と呼ばれることがありますが、これはBASICコンパイラとCインタプリタが存在するにもかかわらずです。[59]

インタプリタはコンパイルを完全に置き換えるものではありません。コンパイルをユーザーから隠蔽し、段階的に実行させるだけです。インタプリタ自体もインタプリタとして解釈可能ですが、実行スタックの最下部のどこかに、直接実行される機械語命令の集合が必要です（機械語を参照）。

さらに、最適化のためにコンパイラにインタープリタ機能を持たせることができ、インタープリタには事前コンパイル技術が組み込まれる場合があります。例えば、コンパイル中に式を実行し、その結果を出力プログラムに挿入することで、プログラム実行のたびに式を再計算する必要がなくなり、最終的なプログラムの実行速度を大幅に向上させることができます。ジャストインタイムコンパイルやバイトコード解釈といった近年のトレンドは、コンパイラとインタープリタの従来の区分をさらに曖昧にすることがあります。メタトレーシングは、これをさらに発展させた自動コンパイラ合成手法であり、言語インタープリタからコンパイラを合成するために使用できます。

一部の言語仕様では、実装にコンパイル機能を含まなければならないと明記されています。たとえば、 Common Lispです。しかし、Common Lisp の定義には、インタープリタで実行できないようにする固有の要素はありません。他の言語では、インタープリタで実装するのは非常に簡単ですが、コンパイラの作成がはるかに難しくなります。たとえば、APL、SNOBOL4、[60]、および多くのスクリプト言語では、プログラムが実行時に通常の文字列操作を使用して任意のソースコードを作成し、そのコードを特別な評価関数に渡すことで実行できます。コンパイルされた言語でこれらの機能を実装するには、通常、コンパイラ自体のバージョンを含む ランタイムライブラリとともにプログラムが出荷される必要があります。

種類

コンパイラの分類方法の一つは、生成されたコードが実行されるプラットフォームによって分類することです。これはターゲットプラットフォームと呼ばれます。

ネイティブコンパイラまたはホストコンパイラとは、コンパイラ自体が動作するのと同じ種類のコンピュータおよびオペレーティングシステム上で直接実行することを目的とした出力を生成するコンパイラです。クロスコンパイラの出力は、異なるプラットフォーム上で実行されるように設計されています。クロスコンパイラは、ソフトウェア開発環境のサポートを意図していない 組み込みシステム向けのソフトウェアを開発する際によく使用されます。

仮想マシン（VM）用のコードを生成するコンパイラの出力は、それを生成したコンパイラと同じプラットフォーム上で実行される場合とそうでない場合があります。そのため、このようなコンパイラは通常、ネイティブコンパイラやクロスコンパイラとして分類されません。

コンパイラのターゲットとなる低レベル言語は、それ自体が高レベルプログラミング言語である場合があります。C は、ある種の移植可能なアセンブリ言語と見なされることもあり、このようなコンパイラのターゲット言語となることがよくあります。たとえば、C++のオリジナルコンパイラであるCfront は、C をターゲット言語として使用していました。このようなコンパイラによって生成される C コードは、通常、人間が読んだり保守したりすることを目的としていないため、インデントスタイルや見栄えの良い C 中間コードの作成は無視されます。C を優れたターゲット言語にする特徴には、元のソースのデバッグをサポートするためにコンパイラによって生成できるディレクティブや、C コンパイラで利用できる幅広いプラットフォームのサポートなどがあります。 #line

一般的なコンパイラ タイプはマシン コードを出力しますが、他にも多くのタイプがあります。

  • ソース・ツー・ソース・コンパイラは、高水準言語を入力として高水準言語を出力するコンパイラの一種です。例えば、自動並列化コンパイラは、高水準言語プログラムを入力として受け取り、コードを変換し、並列コード注釈（例：OpenMP）や言語構成要素（例：FortranのDOALLステートメント）を付与します。ソース・ツー・ソース・コンパイラは、トランスコンパイラまたはトランスパイラとも呼ばれます。[61]
  • バイトコードコンパイラは、 Prolog実装 のような理論上のマシンのアセンブリ言語にコンパイルします。
  • ジャストインタイムコンパイラ（JITコンパイラ）は、コンパイルを実行時まで延期します。JITコンパイラは、 Python、JavaScript、Smalltalk、Java、Microsoft .NETの共通中間言語（CIL）など、多くの最新言語で利用可能です。JITコンパイラは通常、インタープリタ内で実行されます。インタープリタがコードパスが「ホット」、つまり頻繁に実行されることを検出すると、JITコンパイラが呼び出され、「ホット」なコードをコンパイルすることでパフォーマンスを向上させます。
    • Javaなどの一部の言語では、アプリケーションはまずバイトコードコンパイラを用いてコンパイルされ、マシンに依存しない中間表現で提供されます。バイトコードインタプリタはバイトコードを実行しますが、パフォーマンスの向上が必要な場合は、JITコンパイラがバイトコードをマシンコードに変換します。[62] [非一次資料が必要]
  • ハードウェア コンパイラ(合成ツールとも呼ばれる) は、入力がハードウェア記述言語であり、出力がネットリストなど の形式でハードウェア構成の記述であるコンパイラです。
  • 低水準言語を高水準言語に変換するプログラムはデコンパイラである。[67]
  • コンパイルマシンでサポートされていないオブジェクトコード形式に変換するプログラムはクロスコンパイラと呼ばれ、組み込みソフトウェアアプリケーションで実行するためのコードを準備するためによく使用されます。[68] [より良い出典が必要]
  • 最適化と変換を適用しながらオブジェクト コードを同じタイプのオブジェクト コードに書き換えるプログラムは、バイナリ リコンパイラです。

人間が読めるアセンブリ言語をハードウェアで実行される機械語命令に変換するアセンブラは、コンパイラとはみなされません。[69] [b] （機械語をアセンブリ言語に変換する逆プログラムは逆アセンブラと呼ばれます。）

参照

注釈と参考文献

  1. ^ 米国国防総省（1980年2月18日）ストーンマン要件
  2. ^ 「前節で説明した多くのソース言語機能により、コンパイラとアセンブラの間には多くの顕著な違いが生じます。いずれの項目においても、その違いは明確ではないかもしれません。さらに、シンプルなコンパイラと強力なマクロアセンブラを区別することは難しいかもしれません。しかし、通常、その違いは十分に大きく、アセンブラとコンパイラの間には質的な違いが存在します。」
  1. ^ 「百科事典：コンパイラの定義」PCMag.com . 2022年7月2日閲覧。
  2. ^ ab コンパイラ：原理、テクニック、ツール、 Alfred V. Aho、Ravi Sethi、Jeffrey D. Ullman著 - 第2版、2007年
  3. ^ Sudarsanam, Ashok; Malik, Sharad; Fujita, Masahiro (2002). 「マシン依存型コード最適化ライブラリを用いた組み込みデジタル信号プロセッサ向けリターゲット可能なコンパイル手法」. Readings in Hardware/Software Co-Design . Elsevier. pp.  506– 515. doi :10.1016/b978-155860702-6/50045-4. ISBN 9781558607026コンパイラは、Cなどの高級言語（HLL）で書かれたプログラムを同等のアセンブリ言語プログラムに変換するコンピュータプログラムです[2]。
  4. ^ Sun, Chengnian; Le, Vu; Zhang, Qirun; Su, Zhendong (2016). 「GCCとLLVMにおけるコンパイラバグの理解に向けて」.第25回国際ソフトウェアテスト・分析シンポジウム議事録. ISSTA 2016. ACM. pp.  294– 305. doi :10.1145/2931037.2931074. ISBN 9781450343909. S2CID  8339241。
  5. ^ Baghai, Christian (2023年4月4日). 「プログラミング言語の進化：プリミティブバイナリから高レベル抽象化へ」. Medium . 2024年7月10日閲覧。
  6. ^ 講義ノート。コンパイラ：原理、手法、ツール。Jing-Shin Chang。国立曁南大学コンピュータサイエンス・情報工学科
  7. ^ Naur, P. 他「ALGOL 60に関する報告」 Communications of the ACM 3（1960年5月）、299–314。
  8. ^ チョムスキー、ノーム、ライトフット、デイヴィッド・W. (2002).統語構造. ウォルター・デ・グリュイター. ISBN 978-3-11-017279-9。
  9. ^ Gries, David (2012). 「付録1：バッカスナウア記法」.プログラミングの科学. Springer Science & Business Media. p. 304. ISBN 978-1461259831。
  10. ^ ヘリゲ、ハンス・ディーター編。 (2004) [2002 年 11 月]。ドイツのブレーメンで書かれました。Geschichten der Informatik - Visionen、Paradigmen、Leitmotive (ドイツ語) (第 1 版)。ベルリン / ハイデルベルク、ドイツ: Springer-Verlag。 pp. 45、104、105。土井：10.1007/978-3-642-18631-8。ISBN 978-3-540-00217-8. ISBN 3-540-00217-0。（12+514ページ）
  11. ^ アイバーソン、ケネス・E. (1962). 『プログラミング言語』 ジョン・ワイリー・アンド・サンズ. ISBN 978-0-471430-14-8。 {{cite book}}: ISBN / Date incompatibility (help)
  12. ^ ルティシャウザー、ハインツ(1951)。 「Über automatische Rechenplanfertigung bei Programmgesteuerten Rechenanlagen」。Zeitschrift für Angewandte Mathematik und Mechanik (ドイツ語)。31 : 255.土井:10.1002/zamm.19510310820.
  13. ^ フォーテ、マイケル;トーマス・ウィルク編。 (2015) [2014-11-14]。ドイツのイエナで書かれました。 Keller、Stack und automatisches Gedächtnis – eine Struktur mit Potenzial [ セラー、スタック、自動メモリ - 可能性のある構造] (PDF) (Tagungsband zum Kolloquium 14. 2014 年 11 月、イエナ)。 GI シリーズ: 情報学講義ノート (LNI) – テーマ (ドイツ語)。 Vol. T-7。ボン、ドイツ: Gesellschaft für Informatik (GI) / Köllen Druck + Verlag GmbH。ページ 20–21。ISBN​​ 978-3-88579-426-4. ISSN  1614-3213. 2020年4月12日時点のオリジナルよりアーカイブ（PDF） 。 2020年4月12日閲覧。[1] （77ページ）
  14. ^ Backus, John. 「FORTRAN I、II、IIIの歴史」(PDF) .プログラミング言語の歴史. 2022年10月10日時点のオリジナルよりアーカイブ(PDF) 。 {{cite book}}:|website=無視されました (ヘルプ)
  15. ^ ポーター・アダムス、ヴィッキー（1981年10月5日）「キャプテン・グレース・M・ホッパー：COBOLの母」InfoWorld. 3 (20): 33. ISSN 0199-6649.
  16. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (1960年3月). 「LISP I プログラマーズ・マニュアル」(PDF). マサチューセッツ州ボストン: MIT 人工知能グループ, 計算センター・リサーチ・ラボ.
  17. ^ コンパイラの原則、テクニック、ツール第2版、Aho、Lam、Sethi、Ullman著、 ISBN 0-321-48681-1
  18. ^ ホッパー、グレース・マレー (1952). 「コンピュータの教育」. 1952年ACM全国会議（ピッツバーグ）議事録 - ACM '52 . pp.  243– 249. doi : 10.1145/609784.609818 . S2CID  10081016.
  19. ^ Ridgway, Richard K. (1952). 「ルーチンのコンパイル」. 1952年ACM全国会議（トロント）議事録 - ACM '52 . pp.  1– 5. doi : 10.1145/800259.808980 . S2CID  14878552.
  20. ^ 「初期のコンパイラとアセンブラのリスト」。
  21. ^ ホッパー、グレース。「基調講演」。ACM SIGPLANプログラミング言語の歴史（HOPL）会議議事録、1978年6月。doi : 10.1145/800025.1198341。
  22. ^ ブルーダラー、ハーバート（2022年12月21日）「グレース・ホッパーは最初のコンパイラを作成したのか？」
  23. ^ Strawn, George; Strawn, Candace (2015). 「Grace Hopper: コンパイラとCOBOL」 . IT Professional . 17 (2015年1月-2月): 62– 64. doi :10.1109/MITP.2015.6.
  24. ^ ドナルド・E.・クヌース、ルイス・トラブ・パルド、「プログラミング言語の初期開発」、コンピュータサイエンスとテクノロジー百科事典（マルセル・デッカー）7: 419–493
  25. ^ Backus, John (1978年6月1日)、「Fortran I、II、IIIの歴史」、プログラミング言語の歴史、ニューヨーク、ニューヨーク州、米国：Association for Computing Machinery、pp.  25– 74、doi :10.1145/800025.1198345、ISBN 978-0-12-745040-7、 2024年10月9日閲覧
  26. ^ Hoare, CAR (1973年12月). 「プログラミング言語設計のヒント」(PDF) . p. 27. 2022年10月10日時点のオリジナルよりアーカイブ(PDF) 。(この発言は、最初の ALGOL 60 コンパイラの実装にも関わったEdsger W. Dijkstraによるものと誤って解釈されることがあります。)
  27. ^ Abelson, Hal; Dybvig, RK; 他. Rees, Jonathan; Clinger, William (編). 「アルゴリズム言語スキームに関する改訂報告書(3) (ALGOL 60の記念に捧ぐ)」. 2009年10月20日閲覧。
  28. ^ 「記号式の再帰関数と機械による計算」Communications of the ACM、1960年4月
  29. ^ マッカーシー, ジョン; エイブラハムズ, ポール W.; エドワーズ, ダニエル J.; ハート, ティモシー P.; レビン, マイケル I. (1965). Lisp 1.5 プログラマーズマニュアル. MIT 出版. ISBN 978-0-26213011-0。
  30. ^ 「BCPL: コンパイラ作成とシステムプログラミングのためのツール」M. Richards、ケンブリッジ大学数学研究所、イギリス、1969年
  31. ^ BCPL: 言語とそのコンパイラ、M Richards、ケンブリッジ大学出版局（初版1981年12月31日）
  32. ^ BCPL CintsysおよびCintposユーザーガイド、M. Richards、2017
  33. ^ Corbató, FJ; Vyssotsky, VA「MULTICSシステムの紹介と概要」1965年秋季合同コンピュータ会議. Multicians.org.
  34. ^ SHARE上級言語開発委員会報告書II、1964年6月25日
  35. ^ Multicians.org「PL/Iの選択」記事、編集者/tom Van Vleck
  36. ^ 「PL/I をシステムプログラミングのツールとして」、FJ Corbato、Datamation 1969年5月6日号
  37. ^ 「Multics PL/1 コンパイラ」、RA Freiburghouse、GE、1969 年秋の共同コンピュータ会議
  38. ^ デニス・M・リッチー、「C言語の開発」、ACM第2回プログラミング言語の歴史会議、1993年4月
  39. ^ SC Johnson、「ポータブルCコンパイラ：理論と実践」、第5回ACM POPLシンポジウム、1978年1月
  40. ^ A. Snyder、「言語 C 用のポータブル コンパイラ」、MIT、1974 年。
  41. ^ K. Nygaard、オスロ大学（ノルウェー）、「オブジェクト指向プログラミングの基本概念」、SIGPLAN Notices V21、1986年
  42. ^ B. Stroustrup：「オブジェクト指向プログラミングとは何か？」第 14 回 ASU カンファレンス議事録、1986 年。
  43. ^ Bjarne Stroustrup、「C++プログラミング言語の概要」、オブジェクト技術ハンドブック（編集者：Saba Zamir、ISBN 0-8493-3135-8）
  44. ^ Leverett、Cattell、Hobbs、Newcomer、Reiner、Schatz、Wulf：「製品品質コンパイラ・コンパイラ・プロジェクトの概要」、CMU-CS-89-105、1979
  45. ^ W. Wulf、K. Nori、「PQCC 生成コンパイラにおける遅延バインディング」、CMU 研究ショーケースレポート、CMU-CS-82-138、1982
  46. ^ Joseph M. Newcomer、David Alex Lamb、Bruce W. Leverett、Michael Tighe、William A. Wulf（カーネギーメロン大学）、David Levine、Andrew H. Reinerit（インターメトリクス社）「TCOL Ada：DOD標準プログラミング言語の中間表現に関する改訂報告書」、1979年
  47. ^ William A. Whitaker、「Ada - プロジェクト：DoD High Order Working Group」、ACM SIGPLAN Notices（第28巻、第3号、1991年3月）
  48. ^ CECOMソフトウェアエンジニアリング先端ソフトウェア技術センター、「最終報告書 - リアルタイムアプリケーション向けACECベンチマークスイートの評価」、AD-A231 968、1990年
  49. ^ P.Biggar、E. de Vries、D. Gregg、「スクリプト言語コンパイラのための実用的なソリューション」、Science of Computer Programmingへの投稿、2009年
  50. ^ M.Hall、D. Padua、K. Pingali、「コンパイラ研究：今後50年」、ACM Communications 2009 Vol 54 #2
  51. ^ クーパーとトルソン 2012、8ページ
  52. ^ Lattner, Chris (2017). 「LLVM」. Brown, Amy; Wilson, Greg (編). 『オープンソースアプリケーションのアーキテクチャ』 . 2016年12月2日時点のオリジナルよりアーカイブ。 2017年2月28日閲覧。
  53. ^ アホ、ラム、セティ、ウルマン、2007、p. 5-6、109-189
  54. ^ アホ、ラム、セティ、ウルマン、2007、p. 111
  55. ^ アホ、ラム、セティ、ウルマン、2007、p. 8、191-300
  56. ^ ab Blindell, Gabriel Hjort (2016年6月3日).指導選択：原則、方法、および応用. スイス: Springer. ISBN 978-3-31934019-7. OCLC  951745657.
  57. ^ クーパーとトクゾン (2012)、p. 540
  58. ^ 「S1-A Simple Compiler」、Java、JavaCC、Yaccを使用したコンパイラ構築、米国ニュージャージー州ホーボーケン：John Wiley & Sons、Inc.、pp.  289– 329、2012年2月28日、doi：10.1002/9781118112762.ch12、ISBN 978-1-118-11276-2、 2023年5月17日閲覧
  59. ^ 「プログラミングにおけるコンパイラとインタープリタ」。Built In . 2025年5月25日閲覧。
  60. ^ 「SNOBOL4プログラミング言語」SourceForge . 2023年10月27日. 2025年5月25日閲覧。
  61. ^ Ilyushin, Evgeniy; Namiot, Dmitry (2016). 「ソースツーソースコンパイラについて」International Journal of Open Information Technologies . 4 (5): 48– 51. 2022年9月13日時点のオリジナルよりアーカイブ。 2022年9月14日閲覧。
  62. ^ Aycock, John (2003). 「ジャストインタイムの簡潔な歴史」. ACM Comput. Surv . 35 (2): 93– 113. doi :10.1145/857076.857077. S2CID  15345671.
  63. ^ Swartz, Jordan S.; Betz, Vaugh; Rose, Jonathan (1998年2月22日～25日). 「FPGA向け高速ルーティングドリブンルータ」(PDF) . 1998 ACM/SIGDA 第6回国際フィールドプログラマブルゲートアレイシンポジウム - FPGA '98 議事録. カリフォルニア州モントレー: ACM . pp.  140– 149. doi :10.1145/275107.275134. ISBN 978-0897919784. S2CID 7128364. 2017年8月9日時点のオリジナルより アーカイブ（PDF） 。
  64. ^ Xilinx Staff (2009). 「XST Synthesis Overview」. Xilinx, Inc. 2016年11月2日時点のオリジナルよりアーカイブ。2017年2月28日閲覧。
  65. ^ Altera Staff (2017). 「Spectra-Q™ Engine」. Altera.com. 2016年10月10日時点のオリジナルよりアーカイブ。 2017年2月28日閲覧。
  66. ^ Jurkans, K; Fox, C (2023).ロボットとIoT向けデジタルロジックデータフローコンパイラのPythonサブセット. IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom-2023).
  67. ^ Metula, Erez (2011). 「Tools of the Trade」.マネージドコードルートキット. pp.  39– 62. doi :10.1016/B978-1-59749-574-5.00003-9. ISBN 978-1-59749-574-5。
  68. ^ Chandrasekaran, Siddharth (2018年1月26日). 「Cross Compilation Demystified」. embedjournal.com . 2023年3月5日閲覧。
  69. ^ カリンガートとホロウィッツ 1979、186-187ページ

さらに読む

無料辞書のウィクショナリーで「コンパイラ」を調べてください。
Wikibooksには「コンパイラ構築」に関する書籍があります。
ウィキメディア コモンズには、コンパイラに関連するメディアがあります。
  • コンパイラ構築への増分アプローチ - PDFチュートリアル
  • Wayback Machineの「コンパイラ設計の基礎」（2018 年 5 月 15 日アーカイブ）
  • コンパイラとインタープリタの主な概念的な違いを説明するYouTubeの短いアニメーション
  • YouTubeでの構文解析と LL1 構文解析
  • コンパイラを作ろう、ジャック・クレンショー著
  • Wayback Machineのコンパイラ開発に関するフォーラム(2014 年 10 月 10 日アーカイブ)