Teoretycznie o kodzie bajtowym, JVM i mikrokontrolerach | Kod Java dla MK

Projekt artykułu. Docelowo napiszę kilka artykułów typu wiki, według następującego schematu:

Temat: Gdzie i jak działa Java
- O strukturze Java
- O sprzęcie
- Jak to oprogramowanie działa na sprzęcie

Artykuł dotyczył problemów, które napotkałem. Po przestudiowaniu informacji uzupełniłem je odpowiedziami.
Jest to mieszanka powyższych tematów.

Cześć!

Przedmowa (Offtopic)
Miałem i nadal mam rosnące pragnienie zbudowania jakiejś całkowicie fizycznej jednostki.
Jednostka oparta na jednym prostym pomyśle, który pochłonął mnie całkowicie.
Pomysł, który wyznaczył kierunek mojego rozwoju na kolejne dziesięć lat.
Teoretycznie konstrukcja urządzenia jest już w połowie gotowa, realizując jedynie odrobinę możliwości planowanego kolosa.

W tej chwili, finalizując półgotowy projekt, po bardziej szczegółowym zapoznaniu się z komponentami, stanąłem przed koniecznością sterowania serwomotorami i odpowiednio zaprogramowania niektórych „mózgów”.

W tym miejscu pojawia się seria pytań, które można podsumować w artykule „Czy i jak można zmusić MK do wykonania kodu Java?”



Ciało. Szczegóły dotyczące pytań.
Pamiętamy, że kod Java, który piszemy, jest konwertowany na kod bajtowy, który z kolei jest interpretowany przez JVM na kod maszynowy, kod składający się z poleceń rozumianych przez sprzęt. Każdy rozumie przyczynę tej szczególnej sytuacji - przenośność/przenośność w połączeniu z większą szybkością (w porównaniu do języków po prostu interpretowanych).

Kiedy się o tym dowiedziałem, pojawiły się pytania, które pozostały bez odpowiedzi, a teraz zostały uzupełnione nowymi.
1. Czy przy użyciu standardowych narzędzi JVM można całkowicie przekonwertować cały kod bajtowy na raz na kod maszynowy/skompilować go?
jeśli fałszywe. Czy istnieją narzędzia innych firm? Przynajmniej w jakiś sposób?

2. Czy JVM obsługuje mikrokontrolery/kontrolery? (Nie wiem zbyt wiele o żelaznych „mózgach”; jeśli ktoś wie, proszę mi powiedzieć).
jeśli to prawda. Czy są jakieś różnice/specjalne funkcje w porównaniu z pracą na naszych zwykłych komputerach PC?




Zaktualizowano! 09.04
O 1. Nie jest możliwe uruchomienie kodu z szybkością maszyny przy użyciu standardowego narzędzia (czyli JVM), przynajmniej tak mówi nam wiki , ale stamtąd stało się jasne, że istnieje narzędzie strony trzeciej - GCJ . Jest alternatywą dla JVM i ma taki fajny bonus w swoim arsenale. Nie udało mi się znaleźć dokładnych informacji na temat platform (sprzętu), dla których obsługiwana jest kompilacja – „wiele”.
Różnica pomiędzy kodem bajtowym a kodem natywnym:
1) natywny uruchamia się szybciej
2) Nie ma gwarancji, że natywny będzie działał szybciej
3) Według mnie natywny nie będzie przenosił systemu operacyjnego i JVM, co znacząco wpływa na ilość wymaganą do działanie programu ROM .

Być może rozwiązanie to może pełnić funkcję alternatywy dla wersji ME .
(Duże pytanie, ponieważ:
1) Nie wiadomo, czy GCJ obsługuje tak słabą platformę sprzętową.
2) Brak informacji o działaniu tego kodu.

Zaktualizowano. 11.04
Informacje 2. Dowolna wersja języka Java, czy to ME, SE czy Embedded, współpracuje z interpretowanym środowiskiem JRE. Z wyjątkiem przypadku powyżej i dwóch przyszłych opisanych poniżej.
Po pierwsze, próbowano wycisnąć system operacyjny z łańcucha, zastępując go własnym, wyłącznie zorientowanym na Javę narzędziem. O tym, co to jest, tutaj .
Po drugie, okazało się, że istnieją procesory zorientowane na Javę, ich cechą jest wbudowany koprocesor, który interpretuje kod bajtowy sprzętowo (! nie programowo) i wysyła go do wykonania.
Przeczytaj więcej o Jazelle .
Jest tu bogato .


Offtopic
Pomysł, o którym mowa, to „sprzężenie zwrotne”, typ specjalnie zaimplementowany w przyszłym prototypie - ciśnienie/odporność na ciśnienie.
Skorzystaj z tej okazji żeby. Czytając ludzi na poziomie 15-25, stwórzmy małą społeczność do komunikacji/tete-a-tete. Bo w pojedynkę nie ma w ogóle odwagi, a co więcej – kompletna groza.