可能重复:
在 JVM 之上运行/解释 C?
我所说的混合语言是指由混合编译器(如Java)编译的语言。我知道这是不切实际的,因为 C 旨在轻松映射到机器指令,但我不知道是否有任何原因无法为它编写混合编译器。
可能重复:
在 JVM 之上运行/解释 C?
我所说的混合语言是指由混合编译器(如Java)编译的语言。我知道这是不切实际的,因为 C 旨在轻松映射到机器指令,但我不知道是否有任何原因无法为它编写混合编译器。
许多体系结构都存在 C 编译器。Java 使用的字节码可能可以简单地看作只是一个指令集,那么为什么不可能呢?指针可能不是“真正的指针”,而是一些内部 VM 引用。
曾经是 axiomsol 提供的商业编译器,但现在所有指向它的链接都显示为死 (404)。
将 C 编译成 Java 代码然后编译 Java 是可能的,但许多人认为似乎确实以次优方式解决了问题。使用 byte[],您甚至无法一次读取整数。C 可能会受益于它自己的更简单的虚拟机(因为不需要垃圾收集器)。或者,至少,C 必须直接编译成字节码。谁知道 C 可以研究一下JamVM项目,它可能会提供一个有趣的开始。它是一个运行 Java 字节码的简单虚拟机。
创建一个专为运行 C 设计的自定义虚拟机当然可以工作,并且工作得非常好,许多字节码指令与真实 CPU 指令的 1-1 映射,因此也可以轻松快速地进行 JIT。实际上,例如LLVM实际上非常像这样。
以 JVM 为目标的 C 编译器可能需要使 C 堆成为 Java byte[] 数组,并且指针将成为该数组的索引。堆栈中的 C 变量也可能需要使用模拟的 byte[] 堆栈来完成,因为必须有可能获得指向它们的指针(与堆指针兼容)。
这是必需的,因为使用直接 Java 引用,不可能在 C 中进行指针算术和整数指针强制转换。优化这一点的一种选择是使 C char 为 32 位,这是 C 标准所允许的,但它会使 C 实现很难用于处理例如文本文件或任何真正带有字节数据的东西......无论如何,编译成 Java 字节码的 C 会非常慢,因为 Java 字节码不能“本机”做很多 C 的事情用单字节码指令。