Question

我创建了一个生成中间代码的编译器。我没有时间为我的项目编写后端。

我可以使用任何软件来评估生成的中间代码吗？我在哪里可以下载这个软件？

输出看起来像这样：

    t1 = 0.67596e-7
    sum = t1

    t1 = 2
    t2 = 3
    t3 = t2 + t1
    i = t3

L0:
    t1 = sum
    t2 = 20
t3 = compare(t1 <= t2)
    t4 = sum
    t5 = 12
t6 = compare(t4 ~= t5)
t7 = t3 | t6
    t8 = sum
    t9 = 20
t10 = compare(t8 > t9)
t11 = t7 & t10
if t11 true then goto L1 else goto L2
L1: 
    t1 = 2
    t2 = sum
    t3 = t2 + t1
    sum = t3

    t1 = 1
    t2 = i
    t3 = t2 + t1
    i = t3
    goto L0
L2:

感谢阅读。

Answer 1

代码生成是我的事： - ）

评论几个选项：

CLR：
- 专业：工业支持
- Con：你必须完全买入他们的打字系统;取决于你想对类型做什么，这可能无关紧要
- Con：只有Windows平台才是真正的黄金时段质量
LLVM：
- 专业：热情的用户社区与魅力领袖
- Pro：许多有趣的性能改进
- Con：有点复杂的界面
- Con：工程中的漏洞历史;随着LLVM的成熟，期望通过增加接口的复杂性来堵塞工程中的漏洞
C--
- Pro：target是一种实际的书面语言，而不是API;您可以轻松地检查，调试和编辑C--代码
- 亲：设计相当成熟，相当干净
- Pro：支持准确的垃圾收集
- Pro：大多数用户报告说它非常易于使用
- Con：非常小的开发团队
- Con：截至2009年初，仅支持三种硬件平台（x86，PPC，ARM）
- Con：不附带垃圾收集器
- Con：项目的未来不确定
C作为目标语言
- Pro：看起来很简单
- Con：几乎不可能获得不错的表现
- Con：从长远来看会让你疯狂;询问那些尝试使用这种技术编译Haskell，ML，Modula-3，Scheme等的人。在某些时候，这些人中的每一个都放弃并构建了自己的本机代码生成器。

摘要：除C 以外的任何内容都是合理的选择。为了实现灵活性，质量和预期寿命的最佳组合，我可能会推荐LLVM。但是你的示例代码非常接近C--，所以这可能是一个优势。

完全披露：我隶属于C--项目。

Answer 2

查看llvm compiler infrastructure project。它被用于许多现实世界的项目中。 LLVM是一个低级虚拟机，易于创建代码并易于转换为本机代码。

Answer 3

您发出的代码看起来非常接近C - 为什么不让您的编译器发出C并使用C编译器作为后端 - 这就是原始C ++前端编译器的工作方式。

Answer 4

我建议吐出Pascal代码并使用Free pascal。

它是本地编译的，编译速度非常快，你可以针对过多的平台。

Answer 5

为什么不将另一个高级语言作为中间输出，例如，您可以生成C代码，并使用任何C编译器来编译它。过去，它已被许多高级语言使用。

另一个稍低级别的选项是生成IL代码并使用.NET运行时。如果编译器是用.NET编写的，则可以使用Reflection.Emit命名空间生成.NET程序集，然后可以在任何.NET环境中运行。

Answer 6

您可以更好地选择编译器堆栈并使用该堆栈支持的中间代码。例如，gcc使用RTL，注册转移语言作为gcc支持的所有语言的共同标准。我怀疑.net有类似于IronPython之类的内容。

如果您想使用提供虚拟机来评估代码的内容，SPIM MIPS vm支持Motorola 68000架构，并且非常易于使用。

Answer 7

NekoVM旨在接受与您类似的高级IL，然后运行它。 Neil Butterworth建议使用C也是一个不错的选择。

Answer 8

如果您可以容忍对JVM的依赖，那么使用ASM生成字节码非常简单。

如果你不能，那么gnu lightning可以用于动态代码生成（比LLVM更小更简单，但没有优化）。

Answer 9

由于您的代码为C - ish，您可以尝试C--。它是编译器后端的C类似语言。 IIRC，它被一个主要的Haskell编译器使用。

Answer 10

强烈推荐llvm，一个平台交叉基础设施，支持机器代码生成和许多优化过程。 llvm.org上的教程非常简单。

Answer 11

另一个没有人提到的选择是QBE。

<块引用>

QBE 旨在成为一个纯 C 嵌入式后端，以 10% 的代码提供高级编译器 70% 的性能。

它就像 LLVM，但它作为依赖要轻得多。来自the comparison to LLVM：

<块引用>

QBE 适用于业余语言设计师。

它并没有解决构思行业级语言时面临的所有问题。如果你在玩弄一些语言的想法，使用 LLVM 就像用卡车拖着你的背包，但使用 QBE 感觉更像是骑自行车。

需要一个后端编译器

11 个答案: