2

高レベルのオブジェクト指向のガベージ コレクション プログラミング言語を設計していますが、テンプレートの作成方法に問題があります。.NET や JVM に似た VM タイプのシステムを作成する予定です (ただし、内部では LLVM を使用します)。問題は、強力な C++ ライクなテンプレートが必要であるが、動的リンクが必要なことです (そのため、テンプレート ライブラリを使用するすべてを再コンパイルせずにテンプレート ライブラリを置き換えることができます)。テンプレートの定義がなくてもソース ファイルをコンパイルできるようにしたいと考えています。JIT 時のコード生成は最小限に抑える必要があります。

私が考えているオプションは次のとおりです。

  • 各コンパイル単位に静的にリンクされたテンプレート ライブラリの概念を持っています。テンプレート ライブラリは基本的に、テンプレートがインスタンス化されるときに空白が埋められる AST のようなものです。これに関する問題は、2 つのファイルが異なるバージョンのテンプレート ライブラリでコンパイルされた場合、互換性がないか、テンプレート ライブラリにバグがある場合、すべてを再コンパイルする必要があることです。これが C++ のやり方です。
  • JIT 時にリンクされるテンプレート ライブラリを用意します。これはほとんどの問題を解決しますが、IR が基本的に AST である必要があります。IRのレベルをもっと低くしてほしい。これには、JIT を行うためにより多くの作業が必要です。
  • 型のみを引数として持つ弱い C# のようなジェネリックを使用します。これは非常に制限的ですが、単純なコード生成と動的リンクを可能にします。

私が考えていない他の良い方法はありますか?私は最初のオプションに傾いていますが、どのオプションもあまり好きではありません。最良の選択肢は何だと思いますか?

4

4 に答える 4

1

それはあなたが望む専門化の量、つまりテンプレートのコンパイラがどれだけ強力でなければならないかによると思います。

C++ を見ると、コンパイラはあらゆる種類の凝った処理を行うことができます (再帰によるサブクラスの生成、フラクタル継承グラフの計算、オンザフライでの Pi の計算など)。

そのパワーが必要な場合は、おそらく強力な高レベル JIT が必要です。FWIW、それはクールだと思います。(ランタイムに完全なコンパイラを含めるだけです。)

于 2009-04-30T21:41:43.800 に答える
0

あなたが達成しようとしていることは、ほとんど不可能です。テンプレート定義とそれらのテンプレートを使用するコードの両方について、言語の高レベル表現のほとんどすべてを残し、わずかに処理されたソース コードのほぼレベルから JIT コンパイルを実行する必要があります。それでよろしければ、コンパイラの残りの部分を非常に簡単に保つ必要があり、重いLLVM最適化を使用することはできません。テンプレートのメタプログラミングは、高レベルの情報の可用性に依存しています。

于 2011-09-21T19:27:24.227 に答える
0

言語の残りの部分に少し依存します... 演算子のオーバーロード、値の型などがある場合、C++ ルート: テンプレートを使用するコードに行かないことで、問題が本当に複雑になります (そして、最適化の機会を逃す可能性があります)。また、最大の特殊化を可能にするために、JIT 時間までの AST として表す必要があります。

C++ テンプレートは本質的にマクロの形式であるため、コードを生成する前に、複製によって生じるすべての肥大化の多くを減らすことができます。

テンプレート型 (少なくとも C++ では) は、他のすべてのコードの根底にある最もコアな型である傾向があります。そのため、変更された場合、他のコードと互換性があると仮定すると、最小の変更以外のすべてに当てはまるわけではありません。

于 2011-09-21T18:13:40.670 に答える
0

これらのテンプレートがどれほど強力になるかを考えてみてください。ジャスト イン タイムでコンパイルされる言語を使用するということは、読み込み時と実行時に多くの手間のかかる作業を行う必要があることを覚えておく必要があります。したがって、テンプレートを強力にすればするほど、テンプレートから得られるパフォーマンスは低下します。


あなたが本当にその道を行くなら、Mackeが提案したようにランタイムにコンパイラを含めることもできます. 実際、これを行う言語はたくさんあります。

これを行うことにより、言語の実装を「解釈された」または部分的に「解釈された」ものにしています。これらの用語では、テンプレートは match-replace-eval の仮装にすぎず、それには何か問題があります。テンプレートは動的言語でそのように機能することがよくあります。最終的にはパワー vs パフォーマンスになることを覚えておいてください。


注: この種の決定に直面したときは、少し後退する価値があるかもしれません。ユースケースを特定して優先順位を付け、実装方法を設計から分離して、実装が麻痺の原因になることなく設計を反復できるようにします。

反復ごとに設計を拡張して、より多くのユース ケースをカバーすると同時に、最適な設計を決定します。気に入ったデザインにたどり着いたら、反復できます。その後、実装も反復できます。この方法により、より重要なケースを最初にカバーできます。

はい、反復インクリメンタル手法を提案しています。この質問は言語の設計に関するものですが、実装について非常に懸念しているように見えるため、私はこれを行います。アイデアを根底に保つ必要があります。そうしないと、いずれかの極端な結果に陥ります (強力すぎてパフォーマンスが低下するか、高性能ソリューションのテンプレートがまったくない)。

于 2013-12-13T21:09:40.227 に答える