web-dev-qa-db-ja.com

llvmに良いスキーム/ LISPがないのはなぜですか？

ガンビットスキーム、MITスキーム、PLTスキーム、チキンスキーム、ビッグルー、ラーセニーなどがあります。

しかし、LLVMには次のような多くの優れた機能がありますが、LLVMには（私の知る限り）単一の一般的なスキーム/ LISPはありません。

  • x86よりもコードの生成が簡単
  • c FFI呼び出しを行うのは簡単...

では、なぜLLVMには適切なスキーム/ LISPがないのでしょうか？

lispschemellvm
41
anon

LLVMは多くの機能を提供しますが、それでも関数型言語が必要とするランタイムのごく一部です。また、LLVMはメモリ管理を他の誰かが処理する必要があるため、C FFI呼び出しは複雑ではありません。ガベージコレクターとのやり取りは、Schemeなどの言語でFFI呼び出しを困難にするものです。

[〜＃〜] hlvm [〜＃〜] に興味があるかもしれませんが、現時点ではまだ実験的なものではありません。

23
Pascal Cuoq

非常に小さく、明らかに最適化されていないSchemeコンパイラがここにあります：

http://www.ida.liu.se/~tobnu/scheme2llvm/

あなたの質問を文字通り受け取り、

  • コンパイラを書くのは難しいです。
  • 上記のリンクのような貧弱な実装は、新しい実装をブロックする可能性があります。 LLVMページにアクセスする人々は、Schemeがすでにあることを知っています。
  • Schemeを書いて使用する人の数は限られています（私は嫌いではありません）。
  • 既存のSchemeインタプリタとコンパイラはたくさんあり、新しいものを用意する必要はありません。
  • LLVMを使用して新しいインタープリターを作成することには、すぐに明確な利点はありません。他の数十のScheme実装よりも、何らかの点でより速く、より簡単で、より柔軟で、より良いでしょうか？
  • LLVMプロジェクトは別の言語（C）で彼らの技術をデモしましたが、他の多くの言語を実装する必要はありませんでした。

誰かがLLVMベースのSchemeコンパイラを構築するのはとても楽しいことだと思います。 SICPとPAIPのSchemeコンパイラは両方とも良い例です。

13
Evan P.

CLの場合： Clasp はLLVMのCommon LISP実装であり、 mocl はLLVMのCommon LISPのサブセットを実装します。

Schemeの場合： 自己ホスティング方式-> LLVMデモ と Bigloo方式のプロトタイプLLVMバックエンド があります。

Clojureの場合： Rhine があり、これはClojureにヒントを得たLISPです。

11
Wilfred Hughes

たぶん私は質問やコンテキストを完全に誤解しているかもしれませんが、CにコンパイルされるCommon LISPである [〜＃〜] ecl [〜＃〜] を使用して、 Clang コンパイラー（GCCではなく）LLVMをターゲットにします。

これがどんなメリットをもたらすかはわかりませんが、LLVMでLISPを実行することでメリットが得られます=]。

7
andrew

心に留めておくべきことの1つは、これらの実装の多くに、LLVMよりもかなり古いC FFIとネイティブコードコンパイラがあることです。

7
Pillsy

CL-LLVM は、LLVMの一般的なLISPバインディングを提供します。 LLVMアセンブリまたはビットコードを直接出力するのではなく、FFIアプローチを採用しています。

このライブラリはQuicklispから入手できます。

3
masukomi

mocl は、Common LISPの比較的静的なサブセット用のコンパイラです。 LLVM/Clang経由でコンパイルします。

3
Rainer Joswig

（私の知る限り）LLVMには一般的な単一のスキーム/ LISPはありません

現在、 llvm-gccは、LLVMでのany言語の一般的な実装に最も近いものです。特に、ガベージコレクションを備えたno成熟したLLVMベースの言語実装がまだあります。 LLVMは多くのエキサイティングな次世代言語実装の基盤として使用されると確信していますが、これにはlotの時間と労力がかかり、この文脈におけるLLVMの初期の頃。

私自身の [〜＃〜] hlvm [〜＃〜] プロジェクトは、ガベージコレクションを備えた唯一のLLVMベースの実装の1つであり、そのGCはマルチコア対応ですが緩やかにバインドされています。実際のスタックウォーキングを統合するためにLLVMのC++コードをハッキングするのではなく、「非協力的な環境」。

3
Jon Harrop

GHCは、スキームバックエンドを実験しており、ネイティブコードコンパイラーを超える非常にエキサイティングな予備結果を得ています。確かに、それはhaskellです。しかし、最近、LLVMに新しい変更が加えられ、末尾呼び出しがより簡単になりました。これは、一部のスキームの実装に適している場合があります。

0
Golias