很好奇，为什么软件要直接运行在CPU上？ 第1页

软件本来就是运行在操作系统上的。所谓的中间抽象层确实存在。

但即便如此，你的设想也并不成立。

多加一个中间层其实解决不了根本问题。不同硬件始终是需要独立调试的。哪怕是Java这种跑虚拟机的代码，不同硬件不同操作系统依然还是存在一些表现上的不同。也不可能所有软件都完全意义上的跨平台。

也就是说，跨平台无论如何都需要付出人力，只不过不同架构的情况下付出的人力多还是少有区别。

就算根本没有中间层，事实上大多数编程语言都是源码级跨平台的。软件只需要重新编译一下就可以。可是没有人维护，没有人做这个工作，就不行。

换cpu就有一批软件不能用的根本原因，在于软件没有人维护。而不在于有没有中间抽象层。有人维护的软件才能持续使用。换CPU这些都是小问题。

旁友，你知道Java吗？

在我指出他的逻辑思维能力存在瑕疵后，提问者表示，他一开始问的就是：

不要转移话题OK？ 我一开始问的是 系统为什么不承担虚拟机的职责，

所以我重新把问题排查了一下，在当前时刻，问题是长这个样子的：

很好奇，为什么软件要直接运行在CPU上？
为什么现在的软件都要直接运行在CPU上， 导致出现了很多问题，比如这次苹果换M1，就有很多软件运行不起来了。
为什么不干脆让系统作为一个平台，让软件在这个系统上运行呢，这样软件跟CPU就不用直接打交道了， 也就不存在上面的问题了。

我觉得，这进一步的表达了其逻辑思维和表达能力的瑕疵。

很显然问题的描述中描述的是：

为什么不让系统作为一个平台，让软件在这个系统上运行。

而不是：

为什么系统不是一个平台，让软件都在这个系统上运行。

很显然这两者存在着巨大的差异。

当你问为什么你不去厕所拉屎的时候，我当然只能回答你，我可以去厕所拉屎，但是现在我并没有排泄物。也就是说，软件当然可以跑在Java上，只不过现阶段他们没有跑在Java上。

当我告诉他，软件当然能够跑在JRE上的时候。他竟然提出了一个更蠢的问题，为什么现在没有跑在JRE上的软件不能跑在JRE上……这让我语塞……

抱歉，我真的很难和无法区分能不能和是不是的人沟通。

当问题的逻辑理清后，事实上问题并不复杂，无非是历史遗留和口味选择。

虚拟机技术的性能在很长一段时间里面是被人所诟病的，而操作系统在很长一段时间内并不像如今的手机操作系统一样大包大揽。很大程度上来说，早期的桌面操作系统和其他应用并没有本质的区别，各种架构图上会画出操作系统作为应用和硬件设备的中间层，这没错，除了驱动程序之外，应用在大部分情况下的确是通过操作系统和硬件设备打交道的，但也只有访问外部设备的时候才通过操作系统。业务逻辑是应用自己写的，也就是说CPU和内存这种非外部设备是不由操作系统管理的，如果CPU推出了新的指令集，也必须升级应用自身才能享受到性能的提升。

这就是历史遗留问题，桌面操作系统本来就只提供最基本的服务，在这种环境下应用当然会面向CPU研发，而CPU产商甚至在CPU内部隔离出了虚拟层（也就是指令集，没错，指令集并不是最终执行的微码，译码器说白了其实就是个中间层），使得应用可以在同一指令集架构下的CPU上正常运行。

更进一步的也不难想到，如果操作系统把CPU虚拟化，那还有什么Wintel联盟，微软说了算就好了啊。这种事情大家都不想的嘛，苹果他一直不能自己造CPU，所以没办法老换架构。现在苹果自己能造CPU了，直接CPU内部隔离中间层不就够了没必要软件层面上隔离啊。

第二个原因就是口味选择，有没有把CPU虚拟化来兼容应用的做法？有啊，很多解决方案都是这么干的，譬如说模拟器，但是指令集之间的软翻译性能相当感人。更重要的是指令集过于低级了，所以在程序编译成指令集之前做了太多的优化，而在虚拟化CPU上这些优化很可能有毒或者毫无意义。

更好的方式是重新设计一套像Java字节码那样的中间语言，让应用都跑在中间层上，这就是.NET战略，当然这个事情最终来讲连微软都没有将自家的应用彻底虚拟化。原因有很多，性能是其中一个重要的原因但是并不能笼统的说就是性能问题……

所以我更倾向于说，这是一个口味的问题。而我觉得随着算力的过剩，事实上中间层带来的性能问题也可以在很大程度上得到解决，毕竟现在UI渲染基本都用浏览器引擎了也没觉得有啥大问题……

这个问题透着一股邪乎味儿，怎么看怎么危险啊……

建议专业机构给予支援。