创建LLVM的原因是什么？
LLVM 和常规编译器有什么区别？
它是否更加动态，因此可以用来将通常非常动态的语言（即Javascript）编译为静态二进制代码？ 创建它背后的原则是什么？
我知道关于编译器的《龙书》，但是对于 LLVM 有这样的东西吗？
编辑： 我发现这个有趣的项目。
What are the differences between an LLVM and a regular compiler?
Is it more dynamic and thus can be used to compile normally very dynamic languages (i.e. Javascript) into static binary code?
What are the principles behind creating one?
I know the Dragon Book for compilers, but is there such a thing for a LLVM?
EDIT:
I have found this interesting project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
LLVM 和“常规编译器”之间有一些区别，我假设它的意思是“gcc”：
至于 Javascript 和其他动态语言，我们在动态语言社区中看到了很多对 LLVM 的兴趣，Python 和 Ruby 实现都在尝试。然而，这些编译器并不试图成为静态编译器。他们专注于使用 JIT。特别是，他们使用“混合模式解释器”优化长时间运行的可执行文件，首先解释程序，然后在运行时使用 LLVM 编译它们。我还没有见过使用 LLVM 的 javascript 引擎，但可能有一个。它只是不会创建静态可执行文件，除非在特殊情况下，或者对于 Javascript 的缩减版本。
至于创建 LLVM 的原因，它是作为 Vikram Adve 的研究小组在终身编译（这意味着 JIT 和链接时优化）方面的工作。获得博士学位后，Chris Lattner 转到 Apple，这极大地推动了该项目的发展（可能是因为它是 BSD 许可的，这在过去给他们带来了 gcc（即 GPL）问题）。
There are a couple of difference between LLVM and "a regular compiler", which I'll assume to mean "gcc":
As for Javascript and other dynamic languages, we're seeing a lot of interesting in LLVM from the dynamic language community, with Python and Ruby implementations trying it out. However, these are not attempting to be static compilers. They are focussed on using the JIT. In particular, the are optimizing long running executables using a "mixed mode interpreter", where they initially interpret the programs, and then compile them using LLVM at run-time. I haven't seen a javascript engine using LLVM, but there probably is one. It just won't create static executables, except in unusual circumstances, or for cut down versions of Javascript.
As for the reason for the creation of LLVM, it started as part of Vikram Adve's research group's work on life long compilation (which means JITs and link-time optimization). After his PhD, Chris Lattner moved to Apple, which is moving the project forward greatly (probably because it is BSD licenced, which has caused them problems in the past with gcc, which is GPL).
没什么，它是一个常规编译器。创建它的主要原因是为编译器研究创建一个平台。因此，它被设计得非常模块化，以便您可以处理编译器中处理您的研究的部分，而不必担心编译器的其他部分。没有 Dragon 编译器，就像没有 LLVM 书籍一样（您在 Dragon 书籍或任何其他编译器书籍中阅读的任何理论都应该直接适用）。事实上，虽然我有一段时间没有查看 LLVM，但他们的文档相当糟糕。
Nothing it is a regular compiler. Its primary reason for creation was to create a platform for compiler research. Therefore it is designed to be very modular so that you can work on that part of the compiler that deals with your research and not have to worry about other parts of the compiler. There is no dragon compiler just as there is no LLVM book(any theory you read in the dragon book or any other compiler book should be directly applicable). In fact while I haven't looked in on LLVM in a while their documentation was pretty poor.
我根本不是开发人员，但是：即使 gpl 迫使 NeXt 在 80 年代发布其 ObjC 运行时，苹果资助另一个编译器（无论是否是 GPL）的主要原因是它愿意与 IDE 集成。事实证明，GCC 在这方面有太大的惯性，并且 GCC 的模块化程度不够高，无法实现代码部分的重用（xcode“修复它”功能）。
这就是我从阅读中了解到的
I am not developper at all, but : even if gpl forced NeXt to publish its ObjC runtime in the 80's, the main reason for apple to fund another compiler (GPL or not) is its will to integrate with the IDE. GCC proved to have too much inertia in this area, and GCC is not modular enough to enable reuse of code parts (xcode "fix it" feature).
That's what I understood from my readings