编译到LLVM的问题

问题在于C++而不是LLVM。

使用为元编程设计的语言,例如 OCaml 您的编译器将大大缩小。例如, this OCaml Journal article describes an 87-line LLVM-based Brainfuck compiler , this mailing list post describes complete programming language implementation including parser 它可以编译fibonacci函数(以及其他程序),整个编译器使用llvm在100行ocaml代码下,并且 HLVM is a high-level virtual machine with multicore-capable garbage collection in under 2,000 lines of OCaml code using LLVM .

LLVM是否会根据后端实现的特定体系结构来优化IR?红外编码不能直接按1:1转换成最终的二进制码。据我所知,这就是它的工作原理。然而,我只是开始在后端上玩(我将它移植到一个定制的处理器上)。

LLVM确实需要一些样板代码,但是一旦您理解了它,它就非常简单了。尝试寻找一个简单的GCC前端,你会发现LLVM是多么干净。我绝对会推荐LLVM而不是C或ASM。asm根本不可移植,生成源代码通常是一件坏事,因为它会使编译速度变慢。

与非虚拟汇编程序相比,中间表示可能有点冗长。我了解到看着.NET IL,尽管我从来没有像现在这样做过。我对LLVM不太熟悉,但我想是同一个问题。

但是,当你想到它的时候,它是有意义的。一个很大的区别是IRS必须处理大量的元数据。在汇编程序中,几乎没有什么——处理器隐式地定义了很多,函数调用之类的约定留给程序员/编译器来定义。这很方便,但是它产生了很大的可移植性和互操作性问题。

诸如.NET和llvm之类的中间表示关心的是确保单独编译的组件可以一起工作——甚至是用不同语言编写并由不同编译器前端编译的组件。这意味着需要元数据来描述在更高级别上发生的事情,例如,可能是参数处理,但可能只是任何事情的任意推送、弹出和加载。回报是相当大的,但要付出代价。

还有其他问题。中间的表示并不真正意味着由人类来写,而是意味着可读性。此外,它还具有足够的通用性,可以在许多版本中生存下来,而不需要完全不兼容的从头重新设计。

基本上,在这种情况下,显式几乎总是比隐式好,所以很难避免冗长。