Java是移动设备中最重要的语言，因为它通过在字节码和机器之间插入虚拟JVM层，允许相同的二进制/字节码在每台机器上执行。
我们能否构建一个Java物理机器，它将接受字节码而不是传统的X86 / arm操作码和操作数？这样就可以使用Java构建实际的操作系统，并且它将比在当前操作系统上安装JVM更有效率/快速。
我猜想它将限制安装新版本的JVM，但许多移动设备确实支持有限版本的JVM，因此可能不是问题？
为什么没有人尝试将相同的概念应用到硬件上呢？
5个回答
14
这已经存在。第一次尝试是Sun的PicoJava规范，其中有一个开源实现曾经发布过。
目前可以直接运行Java字节码的CPU示例：
- aJile：http://www.ajile.com/
- Imsys：http://www.imsystech.com/
- 带有Jazelle扩展的ARM处理器
- JOP：http://www.jopdesign.com/index.jsp
- Grodriguez
1
此外，http://www.azulsystems.com/ 提供了一个生产就绪的解决方案，但他们奇怪地阻止人们调查他们的产品，要求他们跳过荒谬的障碍才能获取基本信息。 - Mikael Gueck
8
我们能建造这样的野兽吗？当然可以。我们也可以试着用一根芹菜棒子砍倒一棵卡里树，但这并不是一个好主意 :-)
很久以前（我想叫它Novix），Forth也做过类似的事情。我怀疑在这种特定情况下，由于许多原因，它会失败。
很久以前（我想叫它Novix），Forth也做过类似的事情。我怀疑在这种特定情况下，由于许多原因，它会失败。
- 创建Java CPU的成本远远超过创建Java解释器的成本。这就是为什么没有一百万个不同的CPU制造商，但有一百万种不同的计算机语言（也许没有那么多，但也很多）。
- JIT编译器消除了Java硅中需要的大量内容，因为它们最终编译为汇编语言。
- 与第1点相关，想象一下修复CPU中的错误与修复解释器中的错误的成本。除非您的CPU具有某种形式的可升级性（例如可替换的微码），否则成本将变得非常昂贵。而且，如果您使用微码，则已失去了Java-on-silicon的某些优势，因为现在您在芯片上拥有一个解释器，而不是在常规操作系统上运行。
- 已经有大量的人使用拥有Java的机器。您将面临市场转向您解决方案的巨大阻力。
- paxdiablo
3
2错误在于第三点。这实际上取决于处理器的设计。通常，微处理器中的逻辑复杂度远比典型程序简单得多。与软件不同，硬件在设计过程中通常会出现惊人的故障。 - ATL_DEV
@user148298，你可能想要谷歌一下“CPU勘误表”并查看其中的800,000个结果 :-) 处理器在制造后确实会有很多错误，虽然没有软件那么多，但我的观点是修复它们的成本通常要高得多。 - paxdiablo
@user148298，除非您在EEPROM模型上设计了可刷写微码的处理器，否则您无法在不重新制造的情况下修复错误。但是，拥有微码模型也有缺点，并且过去并没有取得很大的商业成功。 - Asad Hasan
1
据我所知，这已经完成了（请参阅PSC 1000微处理器参考手册）。引用：
PSC1000微处理器和Java虚拟机的堆栈架构非常相似。这导致只需要一个相对简单的字节码转换器（20K）即可从Java字节码生成可执行本机代码，而不是完整的即时编译器（200-400K）。结果是Java程序的初始执行速度更快，内存需求显著减小。此外，大多数现代语言都是基于堆栈模型实现的。允许PSC1000有效运行Java的功能同样适用于其他语言，如C、Forth和Postscript。
- Niki
1
Jazelle（http://en.wikipedia.org/wiki/Jazelle）也提供了类似的功能。 - ide
1
问题在于你没有规模经济。
与这些处理器相比，Intel/AMD处理器更便宜、更快，直到它们被广泛应用于每个CPU。当前基于软件的JVM比硬件更快，随着CPU速度的不断提高，没有动力去改变。
时代已经改变。当前架构下的CPU不会变得更快，因此现在使用Java非常适合多核应用程序。
- Thorbjørn Ravn Andersen
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接