JavaRush /Java-Blog /Random-DE /Maschinencode und Bytecode: Welche Sprache spricht Ihr Pr...

Maschinencode und Bytecode: Welche Sprache spricht Ihr Programm?

Veröffentlicht in der Gruppe Random-DE
Diejenigen, die gerade erst anfangen, sich mit Java vertraut zu machen, sind oft verwirrt über die Konzepte von Maschinencode und Bytecode . Was sind Sie? Was sind die Unterschiede? In einer kurzen Anmerkung werden wir versuchen, ihre Funktionen so einfach und klar wie möglich zu beschreiben, um dieses Problem ein für alle Mal zu schließen.
Maschinencode und Bytecode: Welche Sprache spricht Ihr Programm?  - 1

Maschinensprache

Der Prozessor ist im Wesentlichen ein sehr komplexer und fortschrittlicher Rechner. Es verfügt über viele Speicherorte (Register genannt), auf und zwischen denen verschiedene mathematische und Byte-Operationen ausgeführt werden. Maschinencode ist genau eine Beschreibung der Abfolge von Vorgängen und der beteiligten Datenmenge. Tatsächlich ist es die einzige Sprache, die der Prozessor Ihres Computers versteht.

Angeborene Inkompatibilität

Darüber hinaus „sprechen“ nicht alle Prozessoren die gleiche Sprache. Es gibt Unterschiede nicht nur zwischen CISC- und RISC- Architekturen , sondern auch innerhalb dieser „Lager“.

CISC (Complex Instruction Set Computing) ist ein Prozessordesignkonzept, das sich durch die folgenden Eigenschaften auszeichnet:

  • viele Befehle unterschiedlicher Länge;
  • viele Adressierungsmodi;
  • komplexe Befehlscodierung.
RISC (Reduced Instruction Set Computing) – ein Prozessor mit reduziertem Befehlssatz. Die Befehle haben das gleiche Format, sind kurz und einfach codiert.
Neue Prozessorgenerationen führen zusätzliche Befehlssätze ein, die den Modellen älterer Generationen einfach unbekannt sind. Aus diesem Grund können Programme, die für eine Architektur (oder eine Prozessorgeneration) kompiliert wurden, nicht auf anderer Hardware ausgeführt werden. All dies zwingt uns dazu, Programme neu zu kompilieren, um sicherzustellen, dass sie auf anderen Computern funktionieren. Allerdings müssen Sie nicht nur aufgrund von Prozessoren neu kompilieren, sondern auch aufgrund von Unterschieden im Zusammenspiel von Programmen und Betriebssystem. Aus diesem Grund ist es unmöglich, ein „Windows“-Programm unter Linux und ein „Linux“-Programm unter Windows auszuführen.

Bytecode

Bytecode ähnelt in vielerlei Hinsicht dem Maschinencode, verwendet jedoch eine Reihe von Anweisungen nicht von einem realen, sondern von einem virtuellen Prozessor. Darüber hinaus kann es Abschnitte enthalten, die sich auf die Verwendung eines JIT-Compilers konzentrieren , der die Ausführung von Befehlen für den realen Prozessor optimiert, auf dem das Programm ausgeführt wird.
JIT-Kompilierung (Just-in-Time-Kompilierung, On-the-Fly-Kompilierung) oder dynamische Kompilierung (dynamische Übersetzung) ist eine Technologie zur Steigerung der Leistung von Softwaresystemen, die Bytecode verwenden, indem der Bytecode direkt währenddessen in Maschinencode oder in ein anderes Format kompiliert wird das Programm läuft. „Offiziell“ gab es in Java bis Version 9 nur einen JIT-Compiler. In Java 9 ist ein weiterer Compiler aufgetaucht, der vorzeitig kompiliert (AoT). Mit dieser Funktion können Java-Klassen in nativen Code kompiliert werden, bevor sie auf einer virtuellen Maschine ausgeführt werden. Diese Funktion wurde entwickelt, um die Startzeiten sowohl für kleine als auch für große Anwendungen zu verbessern, wobei die Auswirkungen auf die Spitzenleistung begrenzt sind.
Bei CISC- Prozessoren können einige Befehle zu komplexeren, vom Prozessor unterstützten Strukturen kombiniert werden, bei RISC hingegen können sie in einfachere Befehlsfolgen zerlegt werden.

Auch ein virtuelles Betriebssystem

Bytecode enthält jedoch nicht nur Prozessoranweisungen. Es enthält auch Logik für die Interaktion mit einem virtuellen Betriebssystem, wodurch das Verhalten der Anwendung unabhängig vom auf dem Computer verwendeten Betriebssystem wird. Dies ist in der JVM deutlich sichtbar , wo die Arbeit mit Systemaufrufen und der GUI oft unabhängig vom Betriebssystem ist, auf dem das Programm läuft. Im Großen und Ganzen emuliert die JVM den Start eines Programmprozesses, im Gegensatz zu Lösungen wie Virtual Box , die nur ein virtuelles System/eine virtuelle Hardware erstellen.

Ist JVM der einzige, der so ist?

Definitiv nicht. Die gleiche DotNet-CLI ist auch eine virtuelle Maschine, die am häufigsten auf Computern unter Windows mit x86- kompatiblen Prozessoren verwendet wird. Es gibt jedoch eine Implementierung für andere Systeme: Anwendungen dafür müssen unter Windows RT laufen, das auf ARM (RISC) -kompatiblen Prozessoren läuft, oder Sie können sie unter Linux/OSX in der Mono- Umgebung ausführen , die ein Drittanbieter ist (und daher nicht vollständig kompatibel) Implementierung von DotNet für diese Plattformen. Diese Plattform läuft also wie die JVM auf unterschiedlichen Prozessoren und unterschiedlichen Betriebssystemen. Es gibt viele weitere ähnliche Lösungen (sowohl alte als auch neue): LLVM , Flash SWF und andere. Einige Programmiersprachen verfügen über eigene virtuelle Maschinen. CPython kompiliert beispielsweise PY- Quellen in PYC- Dateien – kompilierter Bytecode, der für die Ausführung in PVM vorbereitet ist . Oder es gibt ein viel älteres Beispiel: Lisp kann in FASL- Dateien (Fast Load) kompiliert werden. Tatsächlich enthalten sie einen AST-Baum, der vom Generator aus dem Quellcode erstellt wurde. Diese Dateien können vom Lisp- Interpreter auf verschiedenen Plattformen gelesen und ausgeführt werden oder zum Generieren von Maschinencode für die aktuell verwendete Hardwarearchitektur verwendet werden.
Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION