为什么 llvm 上没有好的方案/lisp？
有“Gambit计划”、“MIT计划”、“PLT计划”、“鸡计划”、“Bigloo计划”、“盗窃计划”……；然后就是口齿不清。
然而，（据我所知）LLVM 上还没有一个流行的方案/lisp，尽管 LLVM 提供了很多好东西，例如：
- 比 x86 更容易生成代码
- 易于进行 C FFI 调用 ...
那么为什么 LLVM 上没有好的方案/lisp 呢？
There is Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; then there are all the lisps.
Yet, there's not (to my knowledge) a single popular scheme/lisp on LLVM, even though LLVM provides lots of nice things like:
- easier to generate code than x86
- easy to make C FFI calls
...
So why is it that there isn't a good scheme/lisp on LLVM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
LLVM 提供了很多功能，但它仍然只是函数式语言所需的运行时的一小部分。 C FFI 调用并不复杂，因为 LLVM 将内存管理留给其他人来处理。与垃圾收集器交互是使得在诸如Scheme之类的语言中进行FFI调用变得困难的原因。
您可能对 HLVM 感兴趣，但目前它仍处于实验阶段。
LLVM provides a lot, but it's still only a small part of the runtime a functional language needs. And C FFI calls are uncomplicated because LLVM leaves memory management to be handled by someone else. Interacting the Garbage Collector is what makes FFI calls difficult in languages such as Scheme.
You might be interested in HLVM, but it's still more than experimental at this point.
对于 CL：Clasp 是 LLVM 上的 Common Lisp 实现，而 mocl 在 LLVM 上实现 Common Lisp 的子集。
对于方案：有一个 自托管方案-> LLVM 演示 和Bigloo 方案的原型 LLVM 后端< /a>.
对于 Clojure：有 Rhine，它是受 Clojure 启发的 lisp。
For CL: Clasp is a Common Lisp implementation on LLVM, and mocl implements a subset of Common Lisp on LLVM.
For Scheme: there's a self-hosting Scheme->LLVM demo and a prototype LLVM backend for Bigloo Scheme.
For Clojure: there's Rhine, which is a Clojure-inspired lisp.
这里有一个非常小的且显然未优化的Scheme编译器：
http://www.ida.liu。 se/~tobnu/scheme2llvm/
从字面上看你的问题，
我认为构建一个基于 LLVM 的 Scheme 编译器对于某人来说可能会很有趣。 SICP和PAIP中的Scheme编译器都是很好的例子。
There's a very small and apparently unoptimised Scheme compiler here:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Taking your question literally,
I think that it could be a lot of fun for someone to build an LLVM-based Scheme compiler. The Scheme compilers in SICP and PAIP are both good examples.
也许我完全误解了问题或上下文，但我相信您可以使用 ECL，这是一个常见的Lisp 编译为 C，并使用 Clang 编译器来定位 LLVM（而不是 GCC）。
我不确定这会给你带来什么（如果有的话）好处，但它会给你一个在 LLVM 上运行的 Lisp =]。
Maybe I'm completely misunderstanding the question or context, but I believe that you could use ECL, which is a Common Lisp that compiles down to C, and use the Clang compiler to target LLVM (instead of GCC).
I'm not sure what (if any) benefit this would give you, but it would give you a Lisp running on LLVM =].
需要记住的一件事是，其中许多实现都具有明显早于 LLVM 的 C FFI 和本机代码编译器。
One thing to keep in mind is that many of these implementations have C FFIs and native-code compilers that significantly predate LLVM.
CL-LLVM 为 LLVM 提供 Common Lisp 绑定。它采用 FFI 方法，而不是尝试直接输出 LLVM 程序集或位码。
该库可通过 Quicklisp 获得。
CL-LLVM provides Common Lisp bindings for LLVM. It takes the FFI approach, rather than attempting to output LLVM assembly or bitcode directly.
This library is available via Quicklisp.
mocl 是 Common Lisp 相对静态子集的编译器。它通过 LLVM/Clang 编译。
mocl is a compiler for a relatively static subset of Common Lisp. It compiles via LLVM/Clang.
目前，
llvm-gcc是最接近 LLVM 上任何语言的流行实现的东西。特别是，目前还没有成熟的带有垃圾收集功能的基于 LLVM 的语言实现。我确信 LLVM 将被用作许多令人兴奋的下一代语言实现的基础，但这将需要大量的时间和精力，而且在这种情况下 LLVM 还处于早期阶段。我自己的 HLVM 项目是唯一具有垃圾收集及其 GC 的基于 LLVM 的实现之一具有多核功能，但绑定松散：我使用影子堆栈来实现“不合作环境”，而不是破解 LLVM 中的 C++ 代码来集成真正的堆栈遍历。
Currently,
llvm-gccis the nearest thing to a popular implementation of any language on LLVM. In particular, there are no mature LLVM-based language implementations with garbage collection yet. I am sure LLVM will be used as the foundation for lots of exciting next-generation language implementations but that will take a lot of time and effort and it is early days for LLVM in this context.My own HLVM project is one of the only LLVM-based implementations with garbage collection and its GC is multicore-capable but loosely bound: I used a shadow stack for an "uncooperative environment" rather than hacking the C++ code in LLVM to integrate real stack walking.
有一个Scheme2LLVM，显然是基于SICP：
不知道这样算不算“好”。
There is a Scheme2LLVM, apparently based on SICP:
I don't know if it's "good".
GHC 正在试验一个方案后端，并通过其本机代码编译器获得了非常令人兴奋的初步结果。当然，那是 haskell。但他们最近对 LLVM 进行了新的更改，使尾部调用更容易 IIRC。这可能有利于某些计划的实施。
GHC is experimenting with a scheme backend and getting really exciting preliminary results over their native code compiler. Granted, that's haskell. But they've recently pushed new changes into LLVM making tail calls easier IIRC. This could be good for some scheme implementation.