關於字節碼、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級的人，讓我們創造一個用於交流/面對面交流的小社區。因為獨自一人根本沒有勇氣，甚至更徹底的恐怖。