クロスコンパイル

Question

明確化

私は（GWTと思う）私はある言語から別の言語を意味クロスコンパイルを言及するときではなく、対象プラットフォームにホストプラットフォームから。

背景私はJavaへのクロスコンパイルアラビア語のプログラミング言語を開発しています

が、これは私のプラットフォーム固有の激論を救いました。これを保留にして、さまざまな理由でCにクロスコンパイルする必要がありました。

コンパイル時に実行されているシステムの同等のライブラリに置き換えられる単一のライブラリを開発したいと考えています。

例えば、プログラマーがアラビア語プログラミング言語でGUI描画関数を書いてコンパイルすると、Windowsの下でコンパイルされた場合はwin32コードに、GnomeではGTK +、KDEではQtなどにクロスコンパイルされます。他のライブラリにも使用できます。質問

は、それがコンパイルされた実行可能で終わるか、私は仮想マシンのアプローチとのほうだし、すべてのこのトラブルを通過する価値がありますか？いずれかを選ぶことの利点と欠点（言語を使用するプログラマーではなく、言語開発者の観点から）？私が考慮する必要がある他の要因はありますか？

さらに読書のための任意の参照リンクはいただければ幸いです:)あなたが最良のあなたの言語の基礎となる仮定および考えをサポートしている言語にクロスコンパイルする必要があります

Answer 1

。あなたの言語がガベージコレクトされている場合、すべての関数呼び出しはメソッド呼び出しであり、アドレスとしてデータを扱うことはできません。そして、Javaはコンパイルする言語です。

Javaコードをネイティブにコンパイルするコンパイラがあります。したがって、プログラムをネイティブに実行したい場合は、それらを使用することができます。

自分の言語用に独自の完全コンパイラを作成する準備ができたら、Javaなどから自分自身を離れることができます。

この基本的なアプローチは、多くの言語で使用されています。通常、ターゲット言語はCです。他の言語ではできない低レベルの処理を行うことができ、成熟した最適化コンパイラがあり、ネイティブで非常に高速に動作するからです。 Cのシンボル、ライブラリ、呼び出し規約の仕組みもよく理解されており、厳密に定義され、特定のプラットフォームで複数の言語でサポートされる傾向があります。これにより、新しい言語は、C言語用に書かれたライブラリの全ホストに即座にアクセスできるようになります。

C++はこのように（このコンパイラはcfrontと呼ばれていました）このように開始しました。私はあなたが少し掘り出すなら、これが本当である他の多くの言語を見つけることができると思います。

しかし、Csの低レベル機能が必要ない場合、これらの引数の多くはJavaにも当てはまります。より新しい言語（Scalaなど）では、このようにJVMを使用します。

Answer 2

私は@Omnifariousの回答が好きですが、代わりにどのトレードオフをしたいのかを考えなければならないことを強調したいと思います。高性能を望むなら、CやC++にクロスコンパイルすることを選ぶかもしれません。ライブラリが利用できるようにするには、やはりCやC++が良い選択です。言語の相互運用性が必要な場合は、LLVMアセンブラまたはJVMまたは.NETアセンブラを使用します。

実際の質問は次のとおりです。バックエンドをプラガブルにする必要がありますか？私はこれが実際に であることを警告する必要があります。実際にそれを行ういくつかの製品を見てみましょう：explplarはもちろんgccです。これは広範囲の入力言語をサポートするだけでなく、幅広いターゲットCPU用のコードを生成するように設計されています。さまざまなアセンブラ言語を生成するクロスコンパイラと見なすことができます。

バックエンドをプラグイン可能にする秘訣は、入力言語をさまざまなバックエンド言語に変換するのに十分簡単で、入力をエンコードするのに十分なほど簡単な適切な中間言語です。

基本的に問題は：ILをあまりにも抽象的にすると、あまりにも多くの前提をロックすると容易に変更できないということです。それをあまりにも具体的にすると、複数のバックエンドに翻訳するのが難しくなります。

ILの設計を導くユースケースとして機能する、少なくとも3つの潜在的なバックエンドターゲット言語がある場合にのみ、これを行うことを検討するべきだと思います。