Virtuelle Maschine
Ein VM System ist ein Computerprogramm (Software), das eine virtuelle Maschine auf einem vorhandenen Prozessor emuliert. Der synonyme Gebrauch des Begriffs virtuelle Maschine für VM Systeme tritt besonders für Emulationssoftware von jenen VM Modellen auf, die dahingehend entworfen worden sind, sich besonders leicht auf realen CPUs emulieren zu lassen, anstatt die Grundlage einer Realisierung in Hardware zu sein. Man nennt diese plattformunabhängigen Modelle genauer portable VMs.
Es gab immer wieder Versuche, auch die besonders portablen VMs in Hardware auszuführen, womit deren Ausführung effizienter würde, diese Produkte konnten sich jedoch nicht am Markt durchsetzen. Wo ein VM System auch die Details der Hardware einer realen VM Umsetzung nachbildet, ist es äquivalent eines Hardware-Emulators. Die Begriffe VM System und CPU Emulator werden in vielen Fällen gleichwertig gebraucht.
| Inhaltsverzeichnis |
|
2 Systeme und Umgebung 3 Vorteile und Nachteile 4 Weitere virtuelle Maschinen 5 Siehe auch 6 Weblinks |
Systeme und Modelle
In der Entwicklung der Rechnerarchitekturen hat sich eine Trennung der typischen VM Modelle ergeben, mit denen Hardware CPUs und Software VMs entwickelt werden. Die große Mehrzahl realer CPUs verwalten mehrere Operanden in einer beschränkten Zahl direkt adressierbarer Register (Registermaschinen), die große Mehrzahl der portablen VM Systeme verwalten ihre Operanden in einem verschieblichen unbeschränkten Stapel (Stapelmaschinen). Dies ergab sich durch die verschiedenen Vorteile dieser Ansätze.
Bei VM Modellen nach Art von Stapelmaschinen entsprechen die obersten Stapelwerte jeweils dem Parameterblock eines Funktionsaufrufs, der nur einmal vorhanden ist. Die Registermaschinen kommen dagegen ohne Parameterblock aus, indem Schalter bestimmte Register für eine Operation an- und abschalten, wofür zusätzliche Schalter und Leiterbahnen gebraucht werden. Dies beschränkt die Zahl der Register und Recheneinheiten. Eine Emulation von Registermaschinen ersetzt nun die Recheneinheiten durch Funktionsblöcke, für deren Aufruf jeweils Parameterblöcke erstellt werden.
Virtuelle Maschinen mit Orientierung auf Ausführung in Software spielen heute eine bedeutende Rolle, da Microsoft mit der .NET Architektur dem Beispiel von Sun mit der Java-Virtuellen-Maschine (Java VM) folgt. Hintergrund ist jeweils die Orientierung auf plattformunbhängige Ausführung von Programmen auf verschiedenen Rechnern, die über ein Netzwerk (Internet) verbunden sind.
Die heutigen VM-Systeme besitzen eine große Zahl von Vorläufern, bei denen nutzerorientierte Darstellungen eines Programms (Programmiersprachen) nicht direkt in die maschinenorientierte Darstellung der CPU übersetzt wurde (Maschinencode), sondern in einen einfach strukturierten Zwischencode. Dieser Zwischencode wird dann auf dem Zielsystem durch einen Interpreter ausgeführt. Neben der direkten Ausführung stehen dabei auch verschiedene Optimierungen zur Verfügung, insbesondere die JIT-Compiler.
Die Speicherung des Zwischencodes kann unterschiedlich ausfallen, etwa als Bytecode oder als Baumstruktur. Technisch kann dies als Vorkompilierung betrachtet werden, bei der die Analyseschritte eines Compilers zum Verständnis der problemorientierten Programmiersprache durchlaufen werden (Frontend des Compilers), jedoch keine maschinenorientierte Anpassung an eine spezielle CPU erfolgt (Backend des Compilers), sondern die Anpassung an die abstrakten Ausführungseigenschaften der virtuellen Maschine erfolgt.
siehe auch: Interpreter und Compiler
Systeme und Umgebung
Neben der reinen Beschreibung des Rechenwerkes der VM sind für anwendbare VM Systeme die Festlegung der Ausführungsumgebung wichtig. Während bei der JavaVM hier keine sprachliche Unterscheidung getroffen wird (die Programmiersprache und die Bibliotheken bilden eine Einheit), benennt man sie bei .NET getrennt - der Zwischencode ist die CIL (Common Intermediate Language), die Ausführungsumgebung ist die CLR (Common Language Runtime), und weitere Bibliotheken werden als Framework zusammengefasst. Der Framework-Begriff findet sich bei Java übrigens nicht als Teil der Basisspezifikation, sondern erst bei Erweiterungen wie OSGi, die eine dynamische Service-Architektur auf Basis von Bundles (vergleichbar konventionellen Shared Libraries oder Plugins) realisieren.
Die CLR von .NET ist dabei der JavaVM so ähnlich, dass compilierte Java Programme darin ausgeführt werden könnten, sofern die verwendeten Bibliotheken zur Verfügung stünden; die praktische Verfügbarkeit der Bibliotheken beschränkt jedoch derzeit die direkte Ausführung, so dass bisher .NET'VM Systeme und JavaVM Systeme in der Praxis strikt getrennt auftreten. Und obwohl beide VM-Systeme auf Portabilität hin designt wurden, sind wegen der faktischen Verfügbarkeit der Bibliotheken bei Java die aktuelle Versionen meist zuerst für Windows und Unix-Derivate (z.B. Linux) verfügbar, sowie bei .NET intentionell auf die diversen Windows-Plattformen beschränkt.
Vorteile und Nachteile
Vorteile einer portablen virtuellen Maschine:
- Plattformunabhängigkeit: Programme für eine virtuelle Maschine laufen auf allen realen Maschinen, für die die virtuelle Maschine implementiert ist. Sie kann dadurch Architekturtransparenz schaffen.
- dynamische Optimierung ist möglich
- Programme auf einer virtuellen Maschine sind langsamer als Programme, die speziell für die Zielumgebung übersetzt wurden, da sich immer ein Mehraufwand durch Interpretation oder dynamische Übersetzung zur Laufzeit (JIT-Compiler) ergibt.
Weitere virtuelle Maschinen
Neben den Stapelmaschinen der JVM/CLR gibt es auch registerbasierte virtuelle Maschinen, etwa MMIX oder die Parrot-Implementierung von Perl6. Neben der Definition von virtuellen Maschinen für allgmeine Aufgaben gibt es auch spezielle Modelle wie etwa die VM Definition für Shaderprogramme in 3D-Systemen, die an den Grafikprozessor übergeben werden.
Eine verbreites aber unbekannt gebliebenes VM System ist OpenFirmware, auf der Basis einer Forth Stapelmaschine mit festgelegten F-Codes und Laufzeitumgebung für den speziellen Einsatz zur BIOS Programmierung. Eingesetzt wird dieses System heute überwiegend bei PowerPC-Rechnern auf CHRP-Basis.
Umgekehrt findet sich die Möglichkeit, die Hardware einer CPU um die Möglichkeit zur Ausführung mehrerer verschiedener VM Modelle zu erweitern. Wie bei einem Emulator in Software wird dabei meist eine fremde virtuelle Maschine in den internen Maschinencode (Microcode) der Hardware-CPU übersetzt und ausgeführt. Der Transmeta Prozessor besitzt keine äusserlich sichtbare eigene Modelldefinition.
Siehe auch
- Smalltalk
- Java
- Perl
- ScummVM
- LLVM
- Joe's Abstract Machine (JAM) VM für Erlang
- Warren's Abstract Machine (WAM) VM für Prolog
Weblinks
- Pascal-P-Code-Maschine (Das p-System war auch ein komplettes Betriebssystem; auch mit Compilern anderer Sprachen wie Basic und Fortran konnte man für dieses System p-Code erstellen)
- Smalltalk-80 Design
- Java
- OSGi
