为什么在llvm上没有一个好的方案/ lisp？

Question

有Gambit计划，麻省理工学院计划，PLT计划，鸡计划，Bigloo，Larceny，......;然后有所有的lisps。

然而，（据我所知）LLVM上没有一个流行的方案/ lisp，尽管LLVM提供了很多很好的东西，如：

• 比x86
更容易生成代码
• 轻松拨打C FFI电话 ...

那么为什么LLVM上没有好的方案/ lisp呢？

Answer 1

LLVM提供了很多功能，但它仍然只是功能语言所需的运行时的一小部分。并且C FFI调用并不复杂，因为LLVM使内存管理由其他人处理。交互垃圾收集器是使用诸如Scheme之类的语言使FFI调用困难的原因。

您可能对HLVM感兴趣，但此时它仍然不仅仅是实验性的。

Answer 2

这里有一个非常小且显然未被优化的Scheme编译器：

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

从字面上理解你的问题，

• 编写编译器很难。
• 像上面链接的那样糟糕的实现可以阻止新的实现。进入LLVM页面的人看到已经有一个Scheme，并且不打算写一个。
• 编写和使用Scheme的人数有限（我是一个人，不是仇恨者，顺便说一句）。
• 有许多现有的Scheme解释器和编译器，并没有急需一个新的。
• 使用LLVM编写新的解释器并没有立竿见影的明显好处。它会比其他几十种Scheme实现更快，更容易，更灵活，更好吗？
• LLVM项目使用另一种语言（C）来演示他们的技术，并且没有看到需要实施其他许多语言。

我认为有人建立一个基于LLVM的Scheme编译器会很有趣。 SICP和PAIP中的Scheme编译器都是很好的例子。

Answer 3

对于CL：Clasp是LLVM上的Common Lisp实现，mocl在LLVM上实现Common Lisp的子集。

对于Scheme：有self-hosting Scheme->LLVM demo和a prototype LLVM backend for Bigloo Scheme。

对于Clojure：有Rhine，这是一个受Clojure启发的lisp。

Answer 4

要记住的一件事是，许多这些实现都有C FFI和本机代码编译器，这些编译器远远早于LLVM。

Answer 5

也许我完全误解了问题或上下文，但我相信你可以使用ECL，这是一个编译为C的Common Lisp，并使用Clang编译器来定位LLVM （而不是GCC）。

我不确定这会给你带来什么（如果有的话），但它会给你一个在LLVM上运行的Lisp =]。

Answer 6

CL-LLVM为LLVM提供Common Lisp绑定。它采用FFI方法，而不是直接尝试输出LLVM汇编或bitcode。

此库可通过Quicklisp获取。

Answer 7

mocl是Common Lisp的相对静态子集的编译器。它通过LLVM / Clang编译。

Answer 8

  

没有（据我所知）单身   LLVM上流行的scheme / lisp

目前，llvm-gcc与LLVM上任何语言的流行实现最接近。特别是，还有没有成熟的基于LLVM的语言实现与垃圾收集。我确信LLVM将被用作许多令人兴奋的下一代语言实现的基础，但这需要花费大量的时间和精力，而LLVM在这种情况下还处于早期阶段。

我自己的HLVM项目是唯一一个基于LLVM的垃圾收集实现之一，它的GC具有多核能力，但松散绑定：我使用了一个阴影堆栈来实现“不合作的环境”，而不是攻击C ++ LLVM中的代码，用于集成实际堆栈行走。

Answer 9

有一个 Scheme2LLVM，显然是基于 SICP：

<块引用>

该代码与 SICP（计算机程序的结构和解释）一书第五章中的代码非常相似，不同之处在于它实现了 SICP 假定显式控制评估器（虚拟机）已经具有的额外功能.编译器的许多功能都在方案的子集 llvm-defines 中实现，这些方案被编译为 llvm 函数。

我不知道它是否“好”。

Answer 10

GHC正在尝试一个方案后端，并通过其本机代码编译器获得非常令人兴奋的初步结果。当然，这是哈斯克尔。但他们最近推动了LLVM的新变化，使尾部呼叫更容易IIRC。这可能对某些方案实施有利。