インタープリターとして構築してきた言語がいくつかあります。「その次のステップ」を実行する準備ができたら、ネイティブではないコンパイル済み形式に最適なオプションは何ですか...それぞれの長所と短所は何ですか?
私は CLR または LLVM へのコンパイルを検討しており、C ミッドコンパイルを数回検討しましたが、完全には確信が持てません。
私が移植できることを望んでいるいくつかの機能は次のとおりです。
わかりました、実際には「少数」ではなく、2 つだけです。私は自分の言語がサポートする他の機能を「何でも」移植できると考えています。
私の最良の選択肢とその長所/短所は何ですか?
コード生成は私の仕事です:-)
いくつかのオプションに関するコメント:
CLR:
LLVM:
ターゲット言語としての C
要約: C 以外は妥当な選択です。柔軟性、品質、期待される寿命の最適な組み合わせについては、おそらく LLVM をお勧めします。
完全な開示: 私は C -- プロジェクトに所属しています。
長所/短所：
CLR：
LLVM：
ターゲット言語としてのC：
ターゲットとしてのJavaByteCode：
上記のすべてから、JavaByteCodeをターゲットにするのがおそらくあなたにとって最善だと思います。
編集：実際にはコメントへの回答ですが、300文字では十分ではありません。
JByteCode iffy-同意します（Smalltalkerであるため、JBytecodeは私には制限が多すぎます）。
VMに関しては、純粋な低速バイトコードインタープリターからハイエンドの洗練されたJITting VM（IBM）まで、JVMとして得られるパフォーマンスの範囲は比較的広いと思います。MSが遅かれ早かれすべてのイノベーションを盗んで統合し、動的変換を高速化する手法が公開されているため、CLR VMが追いつくと思います（たとえば、セルフペーパーを読んでください）。LLVMの進行はおそらく少し遅くなりますが、誰が知っていますか。Cを使用すると、より優れたコンパイラを無料で利用できますが、動的再翻訳などをCをターゲットとして実装するのは困難です。私自身のシステムでは、プリコンパイルされたコードと動的にコンパイルされたコードを組み合わせて使用しています（1つのメモリスペースに低速のバイトコードインタープリター、JITter、およびプリコンパイルされた静的Cコードがすべて含まれています）。
LLVM は有望なようです。チームは、ネイティブと比較して、バックエンドを使用した gcc でのランタイム パフォーマンスが優れていると主張しています。AST からコンパイルする機能は非常に興味深いものです (チュートリアルを見てください)。実行時にコンパイルおよび最適化できます。これは動的には必須です。純粋なインタープリターとしても実行できます。
Tcl に似た言語を作成するプロジェクトで LLVM を使用することを検討しています。Tcl は非常に動的であるため、現時点ではこれが何を意味するのかはわかりませんが、現在のバイトコード ベースのコアよりも優れたパフォーマンスが得られると確信しています。