交叉编译与虚拟机

Question

澄清

当我提到交叉编译时，我的意思是从一种语言到另一种语言（想想GWT），而不是从主机平台到目标平台。

背景

我正在开发一种阿拉伯语编程语言，我将其编译为Java，这为我节省了特定于平台的麻烦。现在我不得不暂时搁置，并因各种原因转而编译为 C 。

我想开发一个单独的库，它将被编译后运行的系统的等效库替换。

例如，如果程序员用阿拉伯语编程语言编写GUI绘图函数并编译，如果在Windows下编译，Gnome下的GTK +，KDE下的Qt等，它将被交叉编译为win32代码。同样的方法将是也用于其他图书馆。

问题

是否值得通过所有这些麻烦来结束编译后的可执行文件或者我最好使用虚拟机方法？选择的优点和缺点（从语言开发人员的角度而不是使用该语言的程序员）？还有其他因素需要考虑吗？

非常感谢任何进一步阅读的参考链接：）

Answer 1

您应该交叉编译为最能支持您的语言基础的假设和想法的语言。如果您的语言是垃圾收集的，那么所有函数调用都是方法调用，并且不允许您将地址用作数据，那么Java就是要编译的语言。

有编译器将Java代码编译为本机代码。因此，如果您希望您的程序本机运行，您可以使用它们。

当您准备为自己的语言编写自己的完整编译器时，您可以将自己与Java或您选择的任何内容分开。

这种基本方法已被多种语言使用。通常目标语言是C语言，因为你可以用C语言做低级别的东西，你不能用任何其他语言做它，它有成熟的优化编译器，并且本地运行速度非常快。 C的符号，库和调用约定的工作方式也很好理解，并且在任何给定的平台上都经过严格定义和支持。这允许新语言可以立即访问为C编写的大量库。

C ++以这种方式开始（原始编译器称为cfront），我相信OCaml也是这样开始的。我想如果你挖一点，你可以找到许多其他语言，这是真的。

但是如果你不需要Cs低级功能，那么很多这些参数也适用于Java。许多较新的语言（例如Scala）以这种方式使用JVM。

Answer 2

我喜欢@Omnifarious的答案，但我要强调你必须考虑你想要做出的权衡。如果你想要高性能，你可以选择交叉编译为C或C ++，如果你想要库的可用性，C或C ++也是一个不错的选择。如果您需要语言互操作性，可以使用LLVM汇编程序或JVM或.NET汇编程序。

现在，您的实际问题是：您是否应该将后端插入可插拔状态？我必须警告你，这真的真的 非常很难做到。让我们看看实际上做的一些产品：例如gcc。它不仅支持广泛的输入语言，而且还为各种目标CPU生成代码：您可以认为它是一个生成各种汇编语言的交叉编译器。

使后端可插入的秘诀是一种合适的中间语言，它足够简单，可以将输入语言翻译成简单到足以转换成各种后端语言，但又足够强大，可以对输入进行编码。

基本上问题是：如果你使你的IL过于抽象，那么锁定太多你的假设就无法轻易改变。如果你使它太混凝土，那么很难转化为多个后端。

所以我认为你应该考虑这样做，只要你有至少三种潜在的后端目标语言作为用例来指导你的IL设计。