通用机器代码语言？ [关闭]答案

【问题标题】：Universal Machine Code Language? [closed]通用机器代码语言？ [关闭]
【发布时间】：2013-01-16 01:25:11
【问题描述】：

我一直在思考机器代码是如何特定于架构的，以及 Javascript 如何在（几乎）每个浏览器中工作。我一直在从事一个必须进行一些严肃计算的项目，它是基于 Javascript 的，需要一整分钟才能完成计算。它让我渴望 C 的速度。但项目使用 Javascript 的全部原因是为了简单和可移植。

这给了我这个想法，如果有一种类似于 Javascript 的语言在每个架构上都可移植并作为可执行文件运行，那会怎样？大多数人会指向 Java，但我在想一些开销更少并由操作系统处理的东西。不是字节码，而是本机机器码。

做了一些研究和思考来解决这个任务的不可能性。您如何使可执行文件与针对特定架构的普通 C 编写的应用程序一样小，并且在每个架构上都以与在 C 中针对该架构进行本地编译一样的速度运行？

这是我的下一个想法。本机机器代码是特定于架构的，每种架构都有某些特殊功能，有时处理相同的任务会有所不同。此外，某些优化是特定于每个架构的。如果有通用机器码怎么办？当操作系统将指令加载到内存中时，它会自动转换指令以适应架构。或者也许（更疯狂的想法）CPU 可以包含接收通用机器码并自动将通用机器码适应其本机机器码的能力？

通用机器码规范必须足够通用以涵盖正常的机器码功能。

当然，如果通用机器代码确实有效，那么人们可能会想要一种可以被所有操作系统处理的通用可执行格式。这样，可执行文件不需要跨操作系统更改。这导致需要专门制作跨机器通用的框架。更重要的是操作系统特定的功能，以及超出我所知的输入和输出能力。

通用机器码编译可执行文件：

优点：

与本地编译的可执行文件几乎相同的大小
与本地编译的可执行文件的性能几乎相同

缺点：

加载速度稍慢（希望不存在），因为它在将可执行文件加载到 ram 中时会将通用机器代码转换为本机机器代码

可行吗？

编辑：

我用过Java，用它做了一个游戏。它不像我想要的那样普遍，也不友好。 * 它是它自己的编程语言，由 Oracle 维护。专有的，有点太大了。需要在某些机器上安装。

更具体地说，我不是在谈论拥有一种新的编程语言。我说的是拥有一种新的机器代码语言，它包含足够的额外信息，当执行时，会发生将其转换为体系结构机器代码的非常简单的过程。这样，C 编译器就可以将其可执行文件编译成通用机器代码，并且可执行文件可以在任何地方运行。

【问题讨论】：

“不是字节码而是本地机器码”——但你已经认识到不同的机器有不同的机器码。所以，至少，你说的是发生了某种程度的翻译。
您如何看待“加载速度稍慢（希望不存在），因为它在将可执行文件加载到 ram 中时将通用机器代码转换为本机机器代码”，在质量上与“加载”不同（Java？）字节码，编译成机器码”
C 编译器已经这样做了，对吗？每个操作系统都有编译器，对吗？
这就是 Java 虚拟机的本意。它没有达到理想。
哦，这是不断提出的问题（我要提出更多问题）。不同的操作系统为其用户模式程序提供不同的功能。一个操作系统可能“内置”的东西可能只在另一个操作系统的库中可用。您希望如何处理？

标签： assembly computer-science computer-architecture machine-code

【解决方案1】：

已经有类似的东西了，叫做 p-code

http://en.wikipedia.org/wiki/P-code_machine

这些天来，虚拟机基本上扮演着这个角色

【讨论】：

不是我要问的，我想得更低。这不需要解释器，而是将通用机器代码转换为本地机器代码，因为它在应用程序执行时将指令集加载到 ram 中。这个想法是让它以与不需要翻译的本地编译机器代码相同的速度运行。
你可以使用 p-code 来做到这一点，这也几乎是 VM 所做的，但是，VM 通常允许它不能立即直接转换为机器代码的功能（比如反射，动态代码）
虚拟机似乎有点极端。我正在考虑一个非常薄的层来从一种机器代码类型转换为另一种。同样据我了解，虚拟机运行程序的速度要慢得多。
大多数 VM 使用 JIT，它可以提供本机速度性能。见stackoverflow.com/questions/145110/c-performance-vs-java-c
这是有用的知识。现在，如果有人会为较低级别的语言制作 VM 就好了——比如可以实现与本机代码相同性能的程序集。这几乎可以解决所有兼容性问题。如果 C/C++/Haskell/ect 的编译器可以将他们的程序编译到该程序集 VM。随处运行，本机速度，文件小。

【解决方案2】：

Lambda 演算和/或图灵机。其他一切都只是语法糖。

【讨论】：

这是一个可爱的答案，但我无法决定是投赞成票还是反对票:-)
我在等你决定...
我确信这意味着一些深刻的东西......如果我能把它与我的问题联系起来。

【解决方案3】：

您不会让芯片供应商就通用机器代码达成一致。一个供应商无法用一个新的机器代码接管世界，否则他们将拥有（ARM 几乎拥有，但最终它不会）。

在今天的专利诉讼中，你甚至无法制造 VLIW 处理器，并且在一个薄的软件层中模拟各种指令集，而且你无论如何也无法用它来接管世界，你能说 transmeta 吗？

所以你被软件中的解释器困住了。因此，它可以追溯到 JAVA 的“已经尝试过”和过去几十年的 p 代码（pascal），以及 python 在做什么等等。甚至 llvms 字节码也是如此。

您对“每台机器的速度相同”的要求不会发生。

您已经在使用 javascript 中最便携的语言，而且它的速度和它一样快。 C 是您所追求的通用语言，它相当快并且可以在任何地方运行（比任何其他语言都多），问题在于操作系统，而不仅仅是用户界面。

【讨论】：

同意供应商会在规范上达成一致是难以置信的，但难道不能有一种方法让通用机器代码（即加载时翻译的软件）与本机编译一样快吗？就像假设有一个输出本机机器代码的 C 编译器和一个输出通用机器代码的相同 C 编译器，在应用程序执行时，指令将被加载到 ram 并（通用机器代码）转换为本机架构，在运行时将两者的性能不一样吗？
动态二进制翻译已经存在了一段时间并且可以工作，但不会像本机编译那样快，但比解释更快，比模拟另一个指令集更快。我记得一个在 alpha windows 机器上运行的 x86 windows 程序的演示，每次运行都会翻译一点，直到最终整个东西都被翻译了，至少市场上是这样的。
基本上你要问的是 llvm 做了什么，及时编译，字节码是通用的，但字节码的源可以/确实根据最终目标而有所不同。您可能可以选择一个足够通用的目标或任何具有足够好/可移植的字节码，在任何地方都能很好地工作。
请记住，机器代码只是问题的一部分，操作系统调用和外围设备也发挥了作用，您必须使用 hal 或 vm 制作通用系统层以配合通用指令集。（这里又是看JAVA，做过那个，没接过）
听起来很酷。我只能希望当量子计算流行时，事情会变得普遍。