关于字节码、JVM 和微控制器的理论 | MK 的 Java 代码

文章草稿。最终，我将按照以下方案写几篇类似 wiki 的文章：

主题：Java 在哪里以及如何工作
-关于 Java 的结构
-关于硬件
-该软件如何在硬件上工作

这篇文章是关于我遇到的问题。研究完这些信息后，我补充了答案。
它是上述主题的混合体。

你好！

前言（题外话）
我曾经并且现在仍然越来越渴望构建某种完全物理的单元。
一个基于一个简单想法的单元完全吸引了我。
这个想法为我未来十年的发展指明了方向。
从理论上讲，设备的设计已经完成了一半，实现了该计划中的庞然大物的一小部分功能。

现在，当完成半成品设计时，我更详细地沉浸在组件中，我面临着控制伺服电机的需要，并相应地对一些“大脑”进行编程。

这就是一系列问题出现的地方，这些问题可以概括为“是否可能以及如何强制 MK 执行 java 代码？”



身体。有关问题的详细信息。
我们记得，我们编写的 java 代码被转换为字节代码，字节代码又被 JVM 解释为机器代码，即由硬件理解的命令组成的代码。每个人都明白这种特殊情况的原因 - 可移植性/可移植性加上更快的速度（与简单的解释语言相比）。

当我发现这一点后，我的一些问题仍然没有得到解答，突然出现并被新的问题补充。
1. 是否有可能使用标准的JVM工具，将所有字节码一次性完全转换为机器码/编译它？
如果错误。有第三方工具吗？至少以某种方式？

2. JVM支持微控制器/控制器吗？（我对铁“大脑”不太了解；如果有人知道，请告诉我）。
如果属实，与在我们常用的 PC 上工作有什么不同/特殊功能吗？




更新！09.04
关于 1. 使用标准工具（即 JVM）不可能以机器速度运行代码，至少wiki是这么告诉我们的，但从那里开始，很明显有一个第三方工具 - GCJ。它是 JVM 的替代品，并且在其武器库中拥有如此不错的优势。我找不到有关支持编译的平台（硬件）的确切信息 - “很多”。
字节码和本机代码之间的区别：
1）native启动速度更快
2）不能保证native运行速度更快
3）据我所知，native不会携带OS和JVM，这极大地影响了所需的数量ROM程序的运行。

也许这个解决方案可以作为ME 版本的替代方案。
（问题很大，因为：
1）尚不清楚GCJ是否支持这种低性能的硬件平台。
2) 没有关于此代码的性能的信息。

更新。11.04
关于 2. Java 语言的任何版本，无论是 ME、SE 还是嵌入式，都与被解释的 JRE 协同工作。除了上面的情况和下面描述的两种未来情况。
首先，有人试图将操作系统挤出链条，用他们自己的、专门面向 Java 的工具取而代之。关于它是什么，在这里。
其次，事实证明存在面向Java的处理器，它们的特点是内置协处理器，可以在硬件（而不是软件）中解释字节码并将其发送以执行。
了解有关贾泽尔的更多信息。这里
很丰富。


题外话
所讨论的想法是“反馈”，是未来原型中专门实现的类型——压力/压力阻力。
借此机会。阅读15-25级的人，让我们创建一个用于交流/面对面交流的小社区。因为独自一人根本没有勇气，甚至更彻底的恐怖。