11

インタープリターとして構築してきた言語がいくつかあります。「その次のステップ」を実行する準備ができたら、ネイティブではないコンパイル済み形式に最適なオプションは何ですか...それぞれの長所と短所は何ですか?

私は CLR または LLVM へのコンパイルを検討しており、C ミッドコンパイルを数回検討しましたが、完全には確信が持てません。

私が移植できることを望んでいるいくつかの機能は次のとおりです。

  1. REPL - 私が構築している言語の 1 つは、実行時のブロックレベルの評価をサポートしています。
  2. 堅牢なマクロ - 私が構築している言語の 1 つは、トークン化の前、およびトークン化と解析の中間段階でコードを個別にフィルタリングする機能を必要とします。

わかりました、実際には「少数」ではなく、2 つだけです。私は自分の言語がサポートする他の機能を「何でも」移植できると考えています。

私の最良の選択肢とその長所/短所は何ですか?

4

3 に答える 3

25

コード生成は私の仕事です:-)

いくつかのオプションに関するコメント:

  • CLR:

    • 長所: 産業サポート
    • 短所: 型システムをほぼ完全に受け入れる必要があります。タイプで何をしたいかによっては、これは問題ではないかもしれません
    • 短所: Windows プラットフォームだけが本当にゴールデンタイムの品質です

  • LLVM:

    • 長所: カリスマ的なリーダーによる熱狂的なユーザー コミュニティ
    • 長所: Apple からの本格的な支援
    • 長所: 多くの興味深いパフォーマンスの改善
    • 短所: やや複雑なインターフェース
    • 短所：エンジニアリングの穴の歴史。LLVM が成熟するにつれて、インターフェースの複雑さが増すことで、エンジニアリングの穴が塞がれることが期待されます。

  • C--

    • 長所: ターゲットは API ではなく、実際の記述言語です。C--コードを簡単に検査、デバッグ、編集できます
    • 長所: デザインは適度に成熟しており、適度にクリーン
    • 長所: 正確なガベージ コレクションをサポート
    • 長所: ほとんどのユーザーは、非常に使いやすいと報告しています。
    • 短所: 非常に小さな開発チーム
    • 短所: 2009 年初頭の時点で、3 つのハードウェア プラットフォーム (x86、PPC、ARM) しかサポートされていません。
    • 短所：ガベージコレクタが同梱されていません
    • 短所: プロジェクトに未来がない

  • ターゲット言語としての C

    • 長所：簡単に見える
    • 短所：まともなパフォーマンスを得ることがほぼ不可能
    • 短所：長期的にはあなたを狂わせます。このテクニックを使って Haskell、ML、Modula-3、Scheme などをコンパイルしようとしてきた人々の長い列に聞いてみてください。ある時点で、これらの人々はすべてあきらめて、独自のネイティブ コード ジェネレーターを構築しました。

要約: C 以外は妥当な選択です。柔軟性、品質、期待される寿命の最適な組み合わせについては、おそらく LLVM をお勧めします。

完全な開示: 私は C -- プロジェクトに所属しています。

于 2009-01-17T02:28:51.340 に答える
16

長所/短所：

  • CLR：

    • プロ：CLR環境はすぐに利用できます。バインドするものがたくさん
    • con：CLRにバインド（;-）; 一部のシステムをターゲットにすることは困難または不可能です（組み込み、メインフレームなど。非MSシステムではCLR実装の成熟度が低い可能性があります）

  • LLVM：

    • プロ：MSから独立しています。
    • 短所：一部のシステムをターゲットにするには、LLVM（？）の移植が必要になる場合があります。DOT-net、Javaなどへのインターフェースは面倒かもしれません（おそらくFFIが必要です）

  • ターゲット言語としてのC：

    • プロ：ほぼすべてのターゲットが可能です。簡単なコード生成
    • con：ランタイムライブラリとしていくつかのVMのものを実装する必要があります（GC、dynload、dynコンパイルなど）。Cでは難しいことがいくつかあります（継続、バックトラッキング、スタックトレース、例外）。Cで効率的かつ移植可能にするのが難しいものもあります（GC、動的タイプ、スタックレイアウト依存性）。

  • ターゲットとしてのJavaByteCode：

    • プロ：おそらく最大のターゲットプラットフォームのセット（携帯電話や組み込みのものでさえ）。周りの多くの既存のツール。既存のライブラリとの簡単なインターフェース
    • 短所：実装が難しい、または効率的に実装するのが難しいもの（動的タイプ、継続、バックトラック）

上記のすべてから、JavaByteCodeをターゲットにするのがおそらくあなたにとって最善だと思います。

編集：実際にはコメントへの回答ですが、300文字では十分ではありません。

JByteCode iffy-同意します（Smalltalkerであるため、JBytecodeは私には制限が多すぎます）。

VMに関しては、純粋な低速バイトコードインタープリターからハイエンドの洗練されたJITting VM（IBM）まで、JVMとして得られるパフォーマンスの範囲は比較的広いと思います。MSが遅かれ早かれすべてのイノベーションを盗んで統合し、動的変換を高速化する手法が公開されているため、CLR VMが追いつくと思います（たとえば、セルフペーパーを読んでください）。LLVMの進行はおそらく少し遅くなりますが、誰が知っていますか。Cを使用すると、より優れたコンパイラを無料で利用できますが、動的再翻訳などをCをターゲットとして実装するのは困難です。私自身のシステムでは、プリコンパイルされたコードと動的にコンパイルされたコードを組み合わせて使用​​しています（1つのメモリスペースに低速のバイトコードインタープリター、JITter、およびプリコンパイルされた静的Cコードがすべて含まれています）。

于 2009-01-15T14:48:45.767 に答える
3

LLVM は有望なようです。チームは、ネイティブと比較して、バックエンドを使用した gcc でのランタイム パフォーマンスが優れていると主張しています。AST からコンパイルする機能は非常に興味深いものです (チュートリアルを見てください)。実行時にコンパイルおよび最適化できます。これは動的には必須です。純粋なインタープリターとしても実行できます。

Tcl に似た言語を作成するプロジェクトで LLVM を使用することを検討しています。Tcl は非常に動的であるため、現時点ではこれが何を意味するのかはわかりませんが、現在のバイトコード ベースのコアよりも優れたパフォーマンスが得られると確信しています。

于 2009-01-15T14:32:33.770 に答える