我所说的混合语言是指由混合编译器（如 Java）编译的语言。我知道这是不切实际的，因为 C 旨在轻松映射到机器指令，但我不知道是否有任何原因导致有人无法为其编写混合编译器。
【问题讨论】：
创建一个专为运行 C 而设计的自定义虚拟机当然可以工作，而且工作得非常好，许多字节码指令与真实 CPU 指令之间存在 1-1 映射，因此也可以轻松快速地JITing。其实比如LLVM其实很像这样。
针对 JVM 进行 C 编译器可能需要使 C 堆成为 Java byte[] 数组，并且指针将成为该数组的索引。堆栈中的 C 变量也可能需要使用模拟的 byte[] 堆栈来完成，因为必须能够获得指向它们的指针（与堆指针兼容）。
这是必需的，因为使用直接 Java 引用，不可能在 C 中进行指针算术和整数指针强制转换。优化这一点的一种选择是使 C char 为 32 位，这是 C 标准所允许的，但它会使 C 实现非常难以用于处理例如文本文件或任何真正带有字节数据的东西......无论如何，编译成 Java 字节码的 C 会非常慢，因为 Java 字节码不能做很多 C 的事情“本地”使用单字节代码指令。
【讨论】：
byte[] 数组的引用与该数组中的索引的组合来表示。这可以防止堆需要成为一个庞大的数组：您可以使用多个，这意味着您可以在需要时添加更多堆。您仍然可以实现指针 -> 整数转换并返回，您只需为每个数组分配一个不同的整数值。也许通过一些外部地图。
intptr_t 和uintptr_t 是可选类型。所以你不必让整数 -> 指针转换做任何有价值的事情，如果你不被打扰，你可以将所有整数值映射到空指针:-) 显然这会破坏依赖 1-1 的 C 代码指针和整数之间的映射，但是该代码并不严格符合。
C 编译器适用于许多体系结构。 Java 使用的字节码可能可以简单地看作只是一个指令集，那么为什么不可能呢？指针可能不是“真正的指针”，而是一些内部 VM 引用。
曾经是 axiomsol 提供的商业编译器，但现在所有指向它的链接都显示为死 (404)。
将 C 编译成 Java 代码然后编译 Java 是可能的，但许多人认为似乎确实以次优方式解决了。使用 byte[]，您甚至无法一次读取整数。 C 可能会受益于它自己的更简单的虚拟机（因为不需要垃圾收集器）。或者，至少，C 必须直接编译成字节码。谁知道 C 可以研究JamVM 项目，这可能会提供一个有趣的开始。它是一个运行 Java 字节码的简单虚拟机。
【讨论】：
byte[] 数组，并且指针将成为该数组的索引。堆栈中的 C 变量也可能需要使用模拟的 byte[] 堆栈来完成，因为必须能够获得指向它们的指针（与堆指针兼容）。使用直接的 Java 引用，不可能在 C 中进行指针算术和整数指针转换。因此，编译为 Java 字节码的 C 会非常慢，因为 Java 字节码不能用单字节码指令“原生”地做很多 C 事情.