9

LLVM チュートリアルには、簡単な JIT コンパイラの書き方が説明されています。残念ながら、このチュートリアルのレクサーとパーサーは手動で作成されています。このようなソリューションは学習目的には適していますが、複雑で実稼働可能なコンパイラの作成には適していないと考えていました。ただし、GCC と他のいくつかの「大きなコンパイラ」は手書きのようです。しかし、これらすべてのパーサー ジェネレーターは、独自のコンパイラーを作成する場合 (特に、チームを組まずに 1 人で行う場合) に大きな効果を発揮すると思います。

Bison / Antlr / Packrat / Elkhound などの既存のパーサー ジェネレーターを LLVM と共に使用して JIT コンパイラを作成することは可能ですか? パーサーに式を (最初から 1 回ではなく) 常に "フィード" し、実行時にコンパイルできるようにしたいと考えています。

追加の「最高の最新」パーサージェネレーターに関する多くの質問を見つけました (このような: https://stackoverflow.com/questions/428892/what-parser-generator-do-you-recommend )。これらのツールを使用して LLVM JIT コンパイラを作成できる場合は、この特定のケースでのパフォーマンスと柔軟性の点でどのツールが最適かについて、追加のヒントと推奨事項を教えていただければ幸いです。

4

1 に答える 1

9

特に言語を開発しているときに、bisonやantlrのようなパーサジェネレータを使用することには多くの利点があります。間違いなく、文法に変更を加えることになり、最終的な文法のドキュメントを作成することになります。ドキュメントから自動的に文法を生成するツールは本当に便利です。また、言語の文法が（a）自分が考えているものであり、（b）あいまいではないという自信を与えるのにも役立ちます。

あなたの言語（C ++とは異なり）が実際にはLALR（1）、またはさらに良いのはLL（1）であり、LLVMツールを使用してASTとIRを構築している場合、書く以上のことをする必要はほとんどありません。文法を理解し、ASTを構築するためのいくつかの簡単なアクションを提供します。それはあなたをしばらく続けるでしょう。

「実際のプログラマーはパーサージェネレーターを使用しない」という偏見を除いて、人々が最終的に独自のパーサーを構築することを選択する通常の理由は、特にLR（1）構文解析では、構文エラーの適切な診断を提供するのが容易ではないためです。それが目標の1つである場合は、文法LL（k）を解析可能にして（LL（k）で適切な診断を提供するのはまだ簡単ではありませんが、少し簡単なようです）、LL（k）を使用する必要があります。 Antlrのようなフレームワーク。

別の戦略があります。それは、診断を提供しようとせずに、LL（1）よりも柔軟なLALR（1）パーサーを使用して、可能な限り単純な方法でプログラムテキストを最初に解析することです。解析が失敗した場合は、低速の、場合によってはバックトラッキングパーサーを使用して再度解析できます。このパーサーは、ASTの生成方法を認識していませんが、ソースの場所を追跡し、構文エラーからの回復を試みます。ASTを無効にせずに構文エラーから回復することは、単に解析を続行するよりもさらに難しいため、試行しないことについては多くのことが言われています。また、ソースの場所を追跡するのは非常に遅く、診断を生成する必要がない場合はあまり役に立ちません（デバッグ注釈を追加するために必要な場合を除く）。そのため、煩わしさを気にせずに解析をかなり高速化できます。位置追跡。

個人的には、PEGによって解析される実際の言語が何であるかが明確でないため、packratの解析に偏っています。他の人はこれをそれほど気にしません、そしてYMMV。

于 2013-02-07T01:05:44.097 に答える