最佳编译器目的地 [英] Best Compiler Destination
问题描述
我一直在构建几种语言作为口译员.当我准备好采取下一步"时，哪些选项最适合非本机编译格式...每种选项的优缺点是什么?
I've got a few languages I've been building as interpreters. When I'm ready to take "that next step", what options are best for non-native compiled formats... what are the pros and cons of each?
我一直在考虑编译到 CLR 或 LLVM，并考虑过 C-midcompile 几次，但我并不完全确定.
I've been looking at compiling to CLR or LLVM, and contemplated C-midcompile a few times, but I'm not completely certain.
我希望能够移植的一些功能如下:
A few features I'm hoping to be able to port are as follows:
- REPL - 我正在构建的一种语言在运行时支持块级评估.
- 强大的宏 - 我正在构建的一种语言需要能够在标记化之前以及在标记化和解析之间的中间阶段单独过滤代码.
好吧，不是真的几个"，只有两个.我喜欢认为我可以将我的语言支持的任何其他功能移植到任何东西".
Ok, not really "a few", just two. I like to think I can port any other features my languages support to "anything".
什么是我最好的选择，以及它们的优缺点?
What are my best options, and their pros/cons?
推荐答案
优点/缺点:
CLR:
CLR:
- pro:CLR 环境随时可用；很多东西要绑定
- con: 绑定到 CLR (;-);针对某些系统将很难或不可能(嵌入式、大型机等.CLR impl.在非 MS 系统上可能不太成熟)
LLVM:
- 专业人士:独立于 MS.
- con:针对某些系统可能涉及移植 LLVM(?)；与 DOT-net、Java 等接口可能会很麻烦(可能需要 FFI)
C 作为目标语言:
- pro:几乎所有可能的目标；轻松生成代码
- con:你将不得不实现一些 VM 的东西作为运行时库(GC、dynload、dyn 编译等)；有些事情在 C 中很难做到(延续、回溯、堆栈跟踪、异常)；在 C 语言中，有些事情很难高效且可移植(GC、动态类型、堆栈布局依赖).
Java ByteCode 作为目标:
Java ByteCode as target:
- pro:可能是最大的目标平台集(甚至是手机和嵌入式产品)；周围有很多现有的工具；与现有库的轻松接口
- 缺点:有些事情很难实现或很难有效地实现(动态类型、延续、回溯)
综上所述，我认为以 Java ByteCode 为目标可能最适合您.
From all the above, I think targeting Java ByteCode would probably be best for you.
实际上是对评论的回答，但 300 个字符还不够.
actually an answer to a comment, but 300chars are not enough.
JByteCode 不确定 - 我同意(作为 Smalltalker，JBytecode 对我来说太有限了).
JByteCode iffy - I agree (being a Smalltalker, JBytecode is too limiting for me).
在 VM 方面，我认为作为 JVM 可以获得相对广泛的性能，从纯慢字节码解释器到高端复杂的 JITting VM (IBM).我想，CLR VM 会迎头赶上，因为 MS 迟早会窃取和整合所有创新，并且发布了加速动态翻译的技术(例如，阅读 Self 论文).LLVM 的进展可能会慢一些，但谁知道呢.使用 C，您将免费受益于更好的编译器，但是动态重新翻译等事情很难以 C 作为目标来实现.我自己的系统混合使用了预编译代码和动态编译代码(在一个内存空间中包含所有:慢速字节码解释器、JITter 和预编译静态 C 代码).
VM-wise, I think there is a relatively wide range of performance you can get as JVM, starting at pure slow bytecode interpreters up to high end sophisticated JITting VMs (IBM). I guess, CLR VM's will catch up, as MS is stealing and integrating all innovation anyway sooner or later, and the techniques to speedup dynamic translation are published (read the Self papers, for example). LLVM will probably progress a bit slower, but who knows. With C, you will benefit from better compilers for free, but things like dynamic retranslation etc. are hard to implement with C as target. My own system uses a mixture of precompiled and dynamically compiled code (having all: a slow bytecode interpreter, JITter and precompiled static C-code in one memory space).
这篇关于最佳编译器目的地的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
