-
Die
Erfindung betrifft ein Verfahren zum Ausführen eines Quellenprogramm
auf einer Verarbeitungseinheit, die einen zuvor bestimmten Mikrocontrollerkern
zum Ausführen
nativer Befehle aus einem zuvor bestimmten Satz von mikrocontrollerspezifischen
Befehlen umfasst; wobei das Verfahren umfasst:
- – einen
Vorverarbeitungsschritt zum Ausdrücken von Programmanweisungen
des Quellenprogramms als eine Sequenz von Befehlen, die virtuelle
Maschinenbefehle umfassen und Speichern der Sequenz von Befehlen
in einem Befehlsspeicher und
- – einen
Ausführungsschritt
zum Abrufen von Befehlen aus dem Befehlsspeicher; unter Verwendung
von Umsetzungsmitteln der Verarbeitungseinheit zum Umsetzen aus
dem Befehlsspeicher abgerufener virtueller Befehle in native Befehle;
und Zuführen
der nativen Befehle zum Mikrocontrollerkern zur Ausführung.
-
Die
Erfindung betrifft weiterhin eine Verarbeitungseinheit zum Ausführen von
Befehlen einer virtuellen Maschine, welche Befehle als virtuelle
Maschinenbefehle bezeichnet werden; wobei die Verarbeitungseinheit umfasst:
- – einen
zuvor bestimmten Mikrocontrollerkern zum Ausführen nativer Befehle aus einem
zuvor bestimmten Satz von mikrocontrollerspezifischen Befehlen;
wobei die nativen Befehle sich von den virtuellen Maschinenbefehlen
unterscheiden
- – einen
Befehlsspeicher zum Speichern von Befehlen einschließlich zumindest
eines der virtuellen Maschinenbefehle
- – einen
Umsetzer, der Umsetzungsmittel umfasst, zum Umsetzen eines aus dem
Befehlsspeicher abgerufenen virtuellen Maschinenbefehls in zumindest
einen nativen Befehl zur Ausführung
durch den Mikrocontrollerkern.
-
Zunehmend
werden Quellenprogramme in Befehlen einer virtuellen Maschine ausgedrückt (in
sie kompiliert) statt in nativen Befehlen eines Mikrocontrollers,
auf dem das Programm auszuführen
ist. Ein Hauptgrund für
die Verwendung einer virtuellen Maschine ist die Portabilität von Programmen
zwischen unterschiedlichen Maschinen (Plattformen). Ein in virtuellen
Maschinenbefehlen der virtuellen Maschine ausgedrücktes Programm
kann relativ einfach auf mehreren konkreten Maschinen ausgeführt werden,
bei Verwendung geeigneter Interpreter, die auf diesen Maschinen
arbeiten. Eine treibende Kraft, portable Programme zu verwenden,
ist derzeit Java, wobei Java-Programme über Internet ausgetauscht werden
und auf unterschiedlichen nativen Maschinen unter Verwendung von
Prozessoren mit unterschiedlichen Befehlssätzen ausgeführt werden können. Mit
Hilfe eines Compilers werden Java-Programme in Java-Bytecodes (JBCs)
ausgedrückt,
die die Befehle der „ Java
Virtual Machine" bilden.
Der resultierende Code wird üblicherweise
als Java-Applet bezeichnet.
-
Herkömmlicherweise
werden Programme, die in virtuellen Maschinenbefehlen ausgedrückt sind,
mit Hilfe von Softwareinterpretation ausgeführt. Der Prozessor (CPU) führt ein
spezielles Interpreter-Programm aus, wobei der Prozessor in einer
Schleife einen virtuellen Maschinenbefehl abruft, ihn in eine Sequenz
aus nativen Befehle des Mikrocontrollerkerns des Prozessors decodiert
und jeden nativen Befehl ausführt.
Diese Technik ist langsam und erfordert ein zusätzliches Interpreter-Programm,
das relativ groß sein
kann. Zur Erhöhung
der Ausführungsgeschwindigkeit
wird die sogenannte Just-In-Time-(JIT)-Kompiliertechnik verwendet. Kurz vor
dem Starten der Ausführung
eines in virtuellen Maschinenbefehlen ausgedrückten Softwaremoduls, wird
das Modul in nativen Code kompiliert (d.h. in nativen Maschinenbefehlen
ausgedrückt).
Auf diese Weise muss das Modul zusätzlich zu dem Code für den Compiler
zweimal gespeichert werden. Die zusätzlichen Speicheranforderungen
der Softwareinterpretation sind für eingebettete Systeme unerwünscht. Um
Leistungs- und Speicheraufwand zu vermeiden, wird vorgezogen, einen
Hardware-Interpreter zu verwenden. Ein Hardware-Interpreter ist
an sich in Form eines Prolog-Vorprozessors für den abstrakten Befehlssatz
von Warren bekannt. In dem Beitrag "A Prolog pre-processor for Warren's abstract instruction
set" von B. Knödler und
W. Rosenstiel, Microprocessing and Microprogramming 18 (1986) S.
71–81,
wird ein Vorprozessor zum Interpretieren von Programmen beschrieben,
die in der Prolog-Programmiersprache zum Laufen auf einem 68000-Prozessor
von Motorola (MC68000) geschrieben sind. Zum Übersetzen des Prolog-Quellenprogramms
in Befehle, die von Herrn Warren definiert worden sind und die im
Allgemeinen zum Ausführen
von Prolog-Programmen verwendet werden, wird ein Compiler verwendet.
Der Satz Warren-Befehle bildet eine virtuelle Maschine, die zum
Ausführen
von Prolog-Programmen entworfen ist. Die Sequenz aus Warren-Befehlen,
die sich aus der Kompilation ergibt, wird in einen RAM geladen und
von dem MC68000 mit Hilfe des Vorprozessors ausgeführt. Nach
dem Einschalten führt der
MC68000 zuerst einen Bootvorgang durch, indem er native MC68000-Befehle ausführt. Am
Ende des Bootvorgangs ist der MC68000 bereit, um die Ausführung eines
Prolog-Programms zu initiieren. Dieses wird durch Springen zu einem
zuvor bestimmten Adressenbereich gestartet. Der Vorprozessor ist
eine speicherabgebildete Einrichtung, die auf diesen Bereich abgebildet
ist. Wenn der Vorprozessor adressiert wird, liest er einen Warren-Befehl
(des übersetzten
Prolog-Programms) aus seinem eigenen RAM, synthetisiert adaptiv
eine Sequenz aus MC68000-Befehlen und Konstanten und sendet diese
direkt zur CPU zur Ausführung.
Die MC68000-Befehle für
jeden Warren-Befehl sind im ROM des Vorprozessors gespeichert. Im
Allgemeinen übersetzt
der Vorprozessor einen Warren-Befehl
in eine Sequenz aus MC68000-Befehlen. Der Vorprozessor enthält seinen
eigenen RAM-Controller und ROM-Controller, die die Adressen für den RAM
und ROM des Vorprozessors generieren. Der RAM-Controller verwaltet
den RAM-Befehlszeiger. Jede aufeinander folgende Lese-Operation
des MC68000 führt
dazu, dass der Vorprozessor den nächsten Befehl (und optionale Konstanten)
der Sequenz zur CPU sendet. Wenn die Sequenz abgeschlossen ist,
führt eine
nächste
Lese-Operation dazu, dass der erste Befehl der Sequenz dem nächsten Warren-Befehl
des zur CPU gesendeten Programms entspricht. Der bekannte Vorprozessor
unterstützt
genau eine virtuelle Maschine (die Warren-Maschine).
-
WO
97/27537 offenbart einen Prozessor mit doppeltem Befehlssatz, der
sowohl von einem Netz empfangenen Codes als auch anderen, von einem
lokalen Speicher gelieferten Code decodieren und ausführen kann.
Der von dem Netz empfangene Code besteht aus virtuellen Maschinenbefehlen,
d.h. einem Befehlssatz für
eine virtuelle Rechenmaschinenarchitektur. Der andere von dem lokalen
Speicher gelieferte Code wird auf einer Computerprozessorarchitektur
ausgeführt,
die sich von der virtuelle Rechenmaschinenarchitektur unterscheidet.,
d.h. der andere Code besteht aus nativen Befehlen. Bei einer Ausführungsform
werden die virtuellen Maschinenbefehle von einer Übersetzungseinheit
verarbeitet. Die Übersetzungseinheit
setzt jeden virtuellen Maschinenbefehl in einen nativen Befehl,
native Befehle oder eine Mikrocoderoutine für eine Ausführungseinheit eines herkömmlichen
Prozessors um.
-
WO
97/23823 offenbart ein Verfahren und ein Gerät zum Generieren und Verteilen
von Programmcode, der anfänglich
in Termen eines virtuellen Prozessors geschrieben ist und dann in
den nativen Code eines Zielprozessorsystems übersetzt worden ist. Der virtuelle
Maschinencode enthält
Pseudobefehle, die bei der Compilerstufe erzeugt und in den Codestrom
eingefügt
werden. Diese Pseudobefehle werden nicht in den nativen Code des
Zielprozessors übersetzt,
sondern bieten stattdessen eine Führung für die Arbeitsweise des Übersetzungsprozesses.
Die Pseudobefehle wirken als "Hinweise" für eine Übersetzungseinheit
und verbessern dadurch die Effizienz der Übersetzung. Beispielsweise
können
diese Pseudobefehle aus einer Anzahl möglicher Übersetzungsoperationen diejenige
angeben, die nachfolgend am wahrscheinlichsten auftritt, so dass
möglich
wird, dass zumindest ein Teil des Übersetzungsprozesses eher prädiktiv als
reaktiv auftritt. Bei einer anderen Ausführungsform kann ein Pseudobefehl
angeben, dass ein bestimmter Schritt bei der Übersetzung mehr als einmal
ausgeführt
werden muss, z.B. um zu vermeiden, dass die Befehle in einer Schleife
für jeden
Durchlauf dieser Schleife übersetzt
werden müssen.
-
US 5.586.323 offenbart ein Übersetzersystem
zum Übersetzen
von Quellenprogrammen in Maschinenspracheprogramme in einem elektronischen
Computersystem. Ein für
eine Vielzahl von unterschiedlichen Maschinentypen von Computern
gemeinsames Objektprogramm wird generiert, während Ausführleistungsvermögen implementiert
wird, das den computereigenen Objektprogrammen gleichwertig ist.
Ein Compiler übersetzt
ein Quellenprogramm in ein abstraktes Objektprogramm, das eine abstrakte
Maschinenbefehlssequenz und eine Angabe hinsichtlich der Zuweisung
abstrakter Register enthält.
Ein Installer setzt das abstrakte Objektprogramm auf Basis von ausführbarer
Computerspezifikationsinformation einschließlich Registergebrauchsangabe
und Maschinenbefehl-Auswahlregeln in ein Maschinensprachenprogramm
eines Zielcomputers um.
-
Die
in WO 97/27537, WO 97/23823 und
US
5.586.323 offenbarten Einrichtungen und Systeme verschaffen
ein gewissen Abstraktionsniveau und daher ein gewisses Niveau der
Codeportabilität
zwischen Computern verschiedener Typen. Sie verschaffen auch ein
gewisses Niveau an Codekompression, weil der Code, der virtuelle
Maschinenbefehle oder das abstrakte Objektprogramm enthält, typischerweise
geringere Speicheranforderungen stellt als native Befehle oder ein
Maschinensprachenprogramm. Die erreichbare Codekompression ist jedoch
noch begrenzt und für
eingebettete Anwendungen ist es wünschenswert, eine bessere Codekompression
zu erreichen.
-
Der
Erfindung liegt als Aufgabe zugrunde, ein Verfahren und eine Verarbeitungseinheit
der dargelegten Art zu verschaffen, die flexibler sind. Eine weitere
Aufgabe der Erfindung ist, ein Verfahren und eine Verarbeitungseinheit
der dargelegten Art zu verschaffen, wobei das Programm in einer
kompakteren Form dargestellt wird.
-
Zur
Lösung
der Aufgabe der Erfindung ist das Verfahren dadurch gekennzeichnet,
dass das Verfahren die folgenden Schritte umfasst: Definieren – für die Programmanweisungen
des Quellenprogramms – einer programmspezifischen
virtuellen Maschine mit einem entsprechenden Satz virtueller Maschinenbefehle,
sodass der Ausdruck der Programmanweisungen in der Befehlssequenz
im Vergleich zur alleinigen Verwendung von nativen Befehlen zum
Ausdrücken
der Progranmanweisungen weniger Speicherplatz in dem Befehlsspeicher
erfordert;
Definieren – für die programmspezifische
virtuelle Maschine – eines
zugehörigen
Umsetzungsmittels zum Umsetzen von virtuellen Maschinenbefehle der
programmspezifischen virtuellen Maschine in native Befehle des Mikrocontrollerkerns
und
Darstellen der zugehörigen
Umsetzungsmittel in der Verarbeitungseinheit.
-
Erfindungsgemäß ist eine
programmspezifische virtuelle Maschine für ein Programm so definiert,
dass das Programm in einer kompakteren Form ausgedrückt werden
kann, als wenn es in nativen Befehle des Kerns ausgedrückt worden
wäre. Auch
ein zugehöriges
Umsetzungsmittel ist definiert. Das Umsetzungsmittel kann beispielsweise
unter Verwendung einer Umsetzungstabelle oder eines in einem ROM
gespeicherten Mikrocodes oder mit anwendungsspezifischer Logik,
wie z.B. einer PLD, implementiert sein. Das definierte Umsetzungsmittel
wird in der Verarbeitungseinheit dargestellt. Auf diese Weise wird
eine schnelle Ausführung
des Programms beibehalten, während
gleichzeitig eine kompakte Darstellung erreicht wird. Dieses Verfahren
ist besonders zur Verwendung bei eingebetteten Anwendungen geeignet.
In diesem Fall bezieht sich das Quellenprogramm auf alle Programmanweisungen,
die anfänglich
in dem eingebetteten System dargestellt sind (beispielsweise das
in dem System vorhandene Programm, wenn der Benutzer das System
kauft). Das Programm kann in einem Festwertspeicher, wie z.B. ROM,
oder in einem wiederprogrammierbare Speicher, wie z.B. EEPROM, gespeichert
sein. Für
eingebettete Anwendungen ist es sehr erwünscht, dass der zum Darstellen
des eingebetteten Anwendungsprogramms verwendete Code kompakt ist
und dass das Leistungsvermögen
beim Ausführen
des Codes gut ist. Typischerweise beruhen für eingebettete Anwendungen
verwendete Verarbeitungseinheiten auf einem Familienkonzept, wobei
für eine
spezielle Anwendung eine für
die Anwendung benötigte
Verarbeitungseinheit aus einem gegebenen Mikrocontrollerkern und
E/A- oder Speicherkomponenten kreiert wird. Wünschenswert ist, keine oder
zumindest keine wesentlichen Abwandlungen am Kern oder den Komponenten
vorzunehmen, um Kosten zu reduzieren. Erfindungsgemäß werden
einerseits virtuelle Maschinenbe fehle speziell für das Programm definiert, was
eine vollständige
Flexibilität
beim Erzielen von Codekompression bietet, während anderseits ein Standardkern
zum Ausführen
des Programms verwendet wird. Die geforderte Umsetzung aus virtuellen
Maschinenbefehlen in native Befehle wird von einem Umsetzungsmittel
durchgeführt,
das als eine Art Vorprozessor angesehen werden kann.
-
Der
Artikel "Optimizing
an ANSI C Interpreter with Superoperators", Todd A. Proebsting, POPL'95:322–332, 1/95
beschreibt den Einsatz von Superoperatoren als Optimierungstechnik
für bytecodierte Interpreter.
Als erster Schritt wird ein Compiler verwendet, um das Programm
in virtuellen Maschinenbefehlen auszudrücken. Die virtuellen Maschinenbefehle
werden so gewählt,
dass die Darstellung des Programms bei Verwendung der virtuellen
Maschinenbefehle kompakter ist. Ein Beispiel für eine solche virtuelle Maschine
ist eine Stapelmaschine, die für
ihre kompakte Darstellung bekannt ist. Als nächstes werden Sequenzen aus
virtuellen Maschinenbefehlen, die häufig in dem kompilierten Code
auftreten, identifiziert und durch neu definierte zusätzliche
virtuelle Maschinenbefehle ersetzt, wobei z.B. ein einziger neuer
Befehl (ein sogenannter Superoperator) eine Sequenz aus vier vorhandenen
Befehlen ersetzt. Ein Superoperator kann auch definiert werden, indem
während
der Analysephase des Compilers die am häufigsten auftretenden Terme
im Ausdruck-Baum, der während
einer Zwischendarstellung im Compiler aufgebaut wird, identifiziert
werden. Nur eine begrenzte Anzahl Superoperatoren wird definiert,
z.B. weit weniger als 256. Dies erlaubt eine kompakte Codierung
der Superoperatoren (z.B. Verwendung eines Einzel-Byte-Codes). Ein
Teil des Codebereichs wird dann zum Darstellen der ursprünglichen
virtuellen Maschinenbefehle angewiesen und ein Teil des Bereichs
zum Darstellen von neu zugefügten
virtuellen Maschinenbefehlen, die die Superoperatoren repräsentieren.
Bei Verwendung von nur 20 Superoperatoren kann bereits eine wesentliche
Codekompression erzielt werden. Die viruellen Maschinenbefehle werden
mit Hilfe eines Software-Interpreters interpretiert, der auf einem
MIPS-R3000- oder SPARC-Prozessor läuft. Es wird kein Hardware-Interpreter
eingesetzt, der in Kombination mit einem gegebenen eingebetteten
Mikrocontrollerkern Codekompression eines gegebenen eingebetteten
Anwendungsprogramms ohne Nachteil für das Leistungsvermögen verschafft.
-
Bei
einer Ausführungsform,
wie im Unteranspruch 2 definiert, kann ein gutes Niveau an Codekompression
für verschiedene
Gruppen Programmanweisungen erzielt werden. Vorzugsweise werden
Programmanweisungen, die sich im Wesentlichen auf eine gleiche Teilmenge
von nativen Befehlen beziehen, zusammen gruppiert und für eine solche Gruppe
wird eine virtuelle Maschine definiert. Beispielsweise kann für Ganzzahloperationen
eine andere virtuelle Maschine definiert sein als für Gleitkomma-Operationen.
Vorzugsweise werden Programmanweisungen gruppiert, die sich auf
nahezu die gleiche Teilmenge von nativen Befehlen beziehen, aber
die Befehle bei mit einer sich beträchtlich unterscheidenden Häufigkeit
verwenden, was die Definition spezieller virtueller Maschinenbefehle
für die
am häufigsten
auftretenden (Sequenzen von) Befehle(n) erlaubt. Für ein Multitasking-System
werden vorzugsweise Programmanweisungen genau einer Task genau einer
virtuellen Maschine zugeordnet. Dies vereinfacht die Entwicklung
des eingebetteten Programms, da gewöhnlich Programmanweisungen
für eine
einzige Task unter Kontrolle durch einen einzigen Ingenieur erzeugt werden
und bei diesem Ansatz die Kontroll-Rolle erweitert werden kann,
sodass die Kontrolle über
die Erzeugung von komprimiertem Code und einem zugehörigen Umsetzungsmittel
darin enthalten ist. Je nach der gewählten Implementation könnte Selektion
des mit dem auszuführenden
virtuellen Maschinenbefehl verknüpften
Umsetzungsmittels eine Verzögerung
der Ausführung
auf sich ziehen. Statt dann ein Umsetzungsmittel für einzelne
virtuelle Maschinenbefehle zu selektieren, kann der Aufwand reduziert
werden, indem die Umsetzungsmittel als Teil des Task-Umschaltens
umgeschaltet werden. Solange dann die gleichen Tasks ununterbrochen
ausgeführt
werden, ist mit dem Selektieren des geeigneten Umsetzungsmittels
kein Aufwand verbunden. Es wird deutlich sein, dass die gleiche
virtuelle Maschine auch für
mehrere Tasks verwendet werden kann, die eine ähnliche Mischung nativer Befehle
in ähnlicher
Häufigkeit
verwenden. Wenn andererseits das Programm für eine Task mehr als ein Programmmodul
umfasst, wobei zumindest zwei der Programmmodule sich im Wesentlichen
auf unterschiedliche Teilmengen von nativen Befehle beziehen oder
Befehle einer ähnlichen Teilmenge
von Befehlen in wesentlich unterschiedlichen Häufigkeiten verwenden, dann
wird vorgezogen, unterschiedliche virtuelle Maschinen für diese
Module zu verwenden. Ebenso kann, wenn eine objektorientierte Programmiertechnik
verwendet wird, für
jedes Objekt oder eine Gruppe gleichartiger Objekte eine virtuelle
Maschine definiert werden.
-
Bei
einer Ausführungsform,
wie im Unteranspruch 3 definiert, werden ein Befehlsmodul und Umsetzungsdaten
zum Umsetzen der Befehle des Moduls in native Befehle empfangen.
Die Verarbeitungseinheit kann beispielsweise mit einem zusätzlichen
oder einen Ersatz-Programmmodul geliefert sein. Die Lieferung kann
lokal erfolgen, z.B. durch Hinzufügen oder Ersetzen eines ROM
mit dem Programmmodul, oder Laden des Programmmoduls aus einem tragbaren
Speichermedium, wie z.B. einer Diskette, in einen programmierbaren
Speicher. Die Lieferung kann auch über ein Netz erfolgen, entweder
ein lokales Netz oder ein Weitverkehrsnetz, wie z.B. Internet. Zunehmend
ist erwünscht,
dass eingebettete Systeme "offen" sind, um zusätzliche
Software oder Software, die einen Teil der vorhandenen Software
zu einem Zeitpunkt nach dem anfänglichen
Programmieren des Systems ersetzt, zu akzeptieren. Während die
anfängliche
Software bei Verwendung einer anwendungsspezifischen virtuellen
Maschine optimal komprimiert war, wird die Verwendung dieser Maschine
für den
neu empfangenen Code nicht immer zu guten Ergebnissen führen oder
könnte
sogar unmöglich sein.
Selbst wenn der Lieferant der ursprünglichen Software auch die
neue Software liefert, kann die Beschaffenheit der Software unterschiedlich
sein, was mit sich bringt, dass eine bessere Komprimierung durch
Definieren einer gesonderten virtuellen Maschine für die neue
Software erzielt werden kann. Zunehmend wird die empfangene Software
von vollständig
anderer Beschaffenheit sein als die ursprüngliche Software. Als Beispiel kann
die neue Software ein in Java-Bytecodes ausgedrücktes Java-Applet sein, während die ursprüngliche Software
in "C" geschrieben war
und optimal für
eine virtuelle Maschine kompiliert war, die zu dem ursprünglichen
Programm zusammen mit einem entsprechenden Umsetzungsmittel passte.
Es versteht sich, dass das definierte Umsetzungsmittel nicht zum
Umsetzen der Java-Bytecodes verwendet werden kann, da diese Codes
mit Hilfe einer unterschiedlichen virtuellen Maschine ausgedrückt sind.
-
Zur
Lösung
der Aufgabe der Erfindung ist die Verarbeitungseinheit dadurch gekennzeichnet,
dass der Umsetzer ausgebildet ist, die Umsetzung für eine Vielzahl
unterschiedlicher virtueller Maschinen durchzuführen.
-
Beispielsweise
kann ein eingebettetes System anfänglich mit einem eingebetteten
Programm geliefert sein, dass mit Hilfe einer einzigen virtuellen
Maschine ausgedrückt
ist, das vorzugsweise für
das spezielle Programm definiert ist. Zu einem späteren Zeitpunkt
wird ein Software-Update benötigt,
das nahezu die gesamte oder einen Teil der Software ersetzt oder
ein Softwaremodul hinzufügt.
Für das
gesamte Anwendungsprogramm, das dann kreiert wird, kann es erwünscht sein,
eine neue virtuelle Maschine zu verwenden, die das dann gültige Programm
(das noch immer Teile des alten Programms enthalten kann) besser
wiederspiegelt. Insbesondere kann, da die benötigte Menge an Software dazu
neigt, im Laufe der Zeit anzuwachsen, für das neu kreierte Anwendungsprogramm
ein höheres
Niveau an Codekompression (durch eine andere virtuelle Maschine
wiedergespiegelt) gefordert werden. Auf diese Weise werden im Lauf
der Zeit unterschiedliche virtuelle Maschinen verwendet, wobei zu
jedem Zeitpunkt nur eine einzige virtuelle Maschine genutzt wird.
Alternativ können,
wie oben beschrieben, unterschiedliche virtuelle Maschinen gleichzeitig
für unterschiedliche
Teile eines eingebetteten Anwendungsprogramms verwendet werden.
Auch können
unterschiedliche virtuelle Maschinen für Programme mit unterschiedlichem
Ursprung verwendet werden, wie z.B. ein in "C" geschriebenes eingebettetes
Programm, das mit Hilfe einer programmspezifischen virtuellen Maschine
und einem Programm, wie z.B. einem Java-Applet, ausgedrückt unter
Verwendung einer anderen und gewöhnlich
zuvor bestimmten virtuellen Maschine, komprimiert worden ist. Es
wird deutlich sein, dass auch mehrfache virtuelle Maschinen in der
Verarbeitungseinheit zur gleichen Zeit vorhanden sein können, wobei
im Lauf der Zeit neue virtuelle Maschinen hinzugefügt oder
vorhandene virtuelle Maschinen ersetzt werden.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 5 definiert, ist
das Umsetzungsmittel von einem wiederprogrammierbaren Typ. Dies
erlaubt immer, wenn ein neues Programm geladen wird, "Herunterladen" eines neuen Umsetzungsmittels
in die Verarbeitungseinheit. Das wiederprogrammierbare Umsetzungsmittel
kann beispielsweise unter Verwendung einer wiederprogrammierbaren
Umsetzungstabelle oder eines Mikrocodes, z.B. in einem (E)EPROM
gespeichert, oder mit Hilfe anwendungsspezifischer wiederprogrammierbarer
Logik, wie z.B. einer E-PLD, implementiert werden.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 6 definiert, umfasst
der Umsetzer anwendungsspezifische Umsetzungsmittel für jede der
virtuellen Maschinen. In dieser Ausführungsform wird die Verarbeitungseinheit
mit mehreren anwendungsspezifischen Umsetzungsmitteln kreiert. Im
Prinzip ist es möglich,
eine einzige große
virtuelle Maschine mit einem einzigen entsprechenden Umsetzungsmittel zu
verwenden. Bei Verwendung mehrerer virtueller Maschinen kann ein
kompakterer Code erzielt werden. Beispielsweise sei angenommen,
dass ein eingebettetes Programm durch zwei Programmmodule gebildet
wird, von denen das eine Modul hauptsächlich an Benutzerschnittstellenaspekten
des eingebetteten Systems beteiligt ist, was hauptsächlich native
Ganzzahl-Befehle erfordert, während
das zweite Modul hauptsächlich
an Signalverarbeitung beteiligt ist, was hauptsächlich Gleitkomma-Befehle erfordert.
Weiterhin sei angenommen, dass optimale virtuelle Maschinen für jedes
der zwei Module je 256 virtuelle Maschinenbefehle umfassen und die
Programmmodule mit Hilfe von 8-Bit-Codes ausgedrückt sind. Eine einzige virtuelle
Maschine, die beide Module abdeckt, kann erstellt werden, indem
die Befehle der zwei virtuellen Maschinen kombiniert werden, was
bis zu 512 virtuelle Maschinenbefehle ergibt (zumindest mehr als
256). Folglich wird die Codegröße zuneh men,
da jetzt 9-Bit-Codes benötigt
werden. Eine derartige Zunahme kann gewöhnlich nicht durch die Tatsache
kompensiert werden, dass eine kombinierte Umsetzungstabelle aufgrund
einer möglichen Überlappung der
Befehle kleiner sein kann als zwei separate Umsetzungstabellen.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 7 definiert, unterscheidet der
Umsetzer zwischen Umsetzungsmitteln für unterschiedliche virtuelle
Maschinen auf Basis der Stelle in dem Befehlsspeicher, wo der auszuführende virtuelle
Befehl gespeichert ist. Wenn beispielsweise außer nativen Befehlen auch virtuelle
Maschinenbefehle von zwei unterschiedliche virtuelle Maschinen verwendet
werden, kann der Speicher in drei Regionen unterteilt werden; eine
Region für
jeden Befehlstyp. Durch Ermitteln, in welcher Region die Adresse
des auszuführenden
Befehls liegt, kann der Umsetzer leicht erkennen, ob Umsetzung gefordert
ist oder nicht (native Befehle brauchen nicht umgesetzt zu werden)
und welche Umsetzungsmittel für
die Umsetzung verwendet werden sollten.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 8 definiert, wird
ein separater Anzeiger (z.B. ein oder mehr Bits) verwendet, um zwischen
der nativen und der virtuellen Maschine und/oder zwischen unterschiedlichen
virtuellen Maschinen zu differenzieren. Für jeden Befehl kann ein separater
Anzeiger verwendet werden. Alternativ kann ein einziger globaler
Anzeiger (z.B. ein Register) verwendet werden, der jedes Mal, wenn
eine Maschinenänderung
auftritt, gesetzt wird.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 9 definiert, wird
genau ein virtueller Maschinenbefehl in genau einen entsprechenden
nativen Befehl umgesetzt, der kompakter codiert ist. Auf diese Weise
kann die Umsetzung sehr einfach sein.
-
Bei
einer Ausführungsform
der Verarbeitungseinheit, wie im Unteranspruch 10 definiert, wird
genau ein virtueller Maschinenbefehl in eine zuvor bestimmte Sequenz
aus einer Vielzahl von nativen Befehlen umgesetzt, was ein weiteres
Niveau an Kompression ergibt. Zur Steuerung der Zuführung der
Sequenz von nativen Befehlen zum Mikrocontrollerkern wird eine Ablaufsteuerung
verwendet, beispielsweise durch Verhinderung eines Inkrements des
Befehlszeigers (Programmzählers)
des Mikrocontrollers, während
die Sequenz zugeführt
wird, und Freigeben eines Inkrements, wenn eine Sequenz abgeschlossen
ist. Alternativ umfasst die Verarbeitungseinheit einen Befehlsabrufer
zum Abrufen eines Befehls aus dem Befehlsspeicher unter Steuerung
seines eigenen Befehlszählers.
Immer wenn eine Sequenz abgeschlossen ist, wird Ändern des Zählers freigegeben und der Befehlszähler in
Reaktion auf eine Änderung
eines Befehlszeigers (Programmzählers) des
Mikrocontrollerkerns auf einen anderen Wert eingestellt. Während der
Verarbeitung einer Sequenz wird eine Änderung des Wertes des Befehlszählers verhindert.
-
Ausführungsbeispiele
der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden
näher beschrieben.
Es zeigen:
-
1 vier mögliche Architekturen für das Anordnen
des Vorprozessors in der Verarbeitungseinheit;
-
2 den
Prozess des Definierens der virtuellen Maschine und des zugehörigen Umsetzers;
-
3 den
Prozess für
ein aus mehreren zusammenhängenden
Gruppen von Programmanweisungen gebildetes Programm und
-
4 ein
Blockschaltbild des Umsetzers;
-
1 veranschaulicht vier mögliche Architekturen
für das
Anordnen des Vorprozessors in der Verarbeitungseinheit 100.
Drei Hauptbestandteile der Verarbeitungseinheit 100 sind
der Mikrocontroller 110, der Befehlsspeicher 120 und
der Vorprozessor 130. Der Vorprozessor 130 umfasst
den Umsetzer 132. In allen Figuren umfasst der Mikrocontroller 110 den
Befehlsspeicher 120 und den Vorprozessor 130.
Die Verarbeitungseinheit 100 an sich wird nicht explizit
dargestellt. Durch Kombinieren aller Hauptelemente im Mikrocontroller 110,
der vorzugsweise eine Einzelchip-Anordnung ist, kann optimales Leistungsvermögen erreicht
werden. Es wird deutlich sein, dass auf Wunsch der Befehlsspeicher 120 und/oder
der Vorprozessor 130 außerhalb des Mikrocontrollers 110 angeordnet
werden können,
wo der Mikrocontrollerbus 140 außerhalb des Mikrocontrollers 110 verläuft und
beispielsweise an einen externen Bus wie z.B. PCI gekoppelt ist.
-
Der
Befehlsspeicher 120 enthält virtuelle Maschinenbefehle,
wie z.B. Befehle für
eine Stapelmaschine. Der Befehlsspeicher kann auch zum Speichern
von Daten verwendet werden. Die Erfindung beschränkt sich nicht auf eine Harvard-Architektur,
in der Daten und Befehle getrennt sind. Der Mikrocontroller 110 umfasst
einen Prozessor 112 mit einem zuvor bestimmten Mikrocontrollerkern 114,
als native Maschine bezeichnet, zum Ausführen nativer Befehle aus einem
zuvor bestimmten Satz von mikrocontrollerspezifischen Befehlen.
Ein Beispiel für
einen zum Ausführen
eingebetteter Software geeigneten Mikrocontroller ist ein RISC-Mikrocontroller,
wie z.B. die Mikroprozessorreihe MIPS PR3001. Die nativen Befehle
des Mikrocontrollerskerns 114 unterscheiden sich von den
virtuellen Maschinenbefehlen der virtuellen Maschine. An sich ist
der Mikrocontroller 110 nicht imstande, im Befehlsspeicher 120 gespeicherte
virtuelle Maschinenbefehle direkt auszuführen. In Reaktion darauf, dass
der Prozessor 110 einen Befehl anfordert, gibt der Vorprozessor 130 den
nativen Befehl aus. Um den nativen Befehl erzeugen zu können, kann
der Vorprozessor 130 unter Verwendung von Abrufmitteln 134 einen
virtuellen Maschinenbefehl aus dem Befehlsspeicher 120 abrufen.
Der Umsetzer 132 des Vorprozessors 130 wird zum
Umsetzen eines aus dem Befehlsspeicher 120 abgerufenen
virtuellen Maschinenbefehls in zumindest einen nativen Befehl verwendet.
Im Allgemeinen wird ein virtueller Maschinenbefehl in eine Sequenz
aus nativen Befehlen umgewandelt. Der Vorprozessor 130 umfasst
weiter ein Zuführmittel 136,
um dem Mikrocontrollerkern native Befehle der Sequenz zur Ausführung zuzuführen. Bei
Ausführen
eines virtuellen Maschinenprogramms führt der Mikrocontroller 110 praktisch
ein vom Vorprozessor 130 generiertes natives Programm aus.
Wo normalerweise ein Befehlszeiger des Mikrocontrollers 110 den
nächsten
Befehl in dem Befehlsspeicher 120 anzeigt, den der Mikroprozessor 110 benötigt, um
ihn als nächsten
auszuführen,
zeigt jetzt der Befehlszeiger dem Vorprozessor 130 an,
dass ein nächster
nativer Befehl benötigt
wird (oder eine Wiederzuführung
eines vorhergehenden Befehls). Folglich verwaltet der Vorprozessor 130 einen
unabhängigen
virtuellen Maschinenbefehlszeiger, der den derzeitigen (oder nächsten)
virtuellen Maschinenbefehl in dem Befehlsspeicher 120 anzeigt.
Der Mikrocontroller benötigt
keine (explizite) Kenntnis des virtuellen Maschinenbefehls oder
des virtuellen Maschinenbefehlszeigers.
-
In 1A sind
die Hauptbestandteile der Verarbeitungseinrichtung über einen
allgemeinen Peripherie-Bus 140, wie z.B. den PI-Bus (PI:
peripheral interconnect), miteinander verbunden. Der Vorprozessor 130 ist
ein Peripheriegerät
auf dem Bus. Der Vorprozessor 130 kann als speicherabgebildetes
Peripheriegerät
wirken, wo ein zuvor bestimmter Adressenbereich dem Vorprozessor
zugewiesen wird. In Reaktion darauf, dass der Prozessor 110 auf
dem Bus 140 eine Anforderung für einen Befehl mit einer Adresse
in diesem Bereich ausgibt, gibt der Vorprozessor 130 den
nativen Befehl auf dem Bus 140 aus. Nötigenfalls ruft der Vorprozessor 130 einen
virtuellen Maschinenbefehl aus dem Befehlsspeicher 120 über den
Bus 140 ab.
-
In 1B und 1C liegt
der Vorprozessor 130 zwischen dem Prozessor 112 und
dem Befehlsspeicher 120. Falls der Vorprozessor 130 zwischen
nativen und virtuellen Maschinenbefehlen unterscheiden muss, können diese
Konfigurationen die Ausführung
von in dem Befehlsspeicher 120 gespeicherten nativen Befehlen verzögern. Der
Deutlichkeit halber werden nicht alle in 1A gezeigten
Elemente in 1B, 1C und 1D wiederholt.
-
In 1D ist
der Vorprozessor 130 im Mikrocontroller 110 eingebettet.
Der Vorprozessor 130 liegt vorzugsweise zwischen einem
Befehlscache 116 des Mikrocontrollers 110 und
dem Kern 114. Diese Konfiguration berücksichtigt optimales Leistungsvermögen, aber
erfordert, im Unterschied zu den Konfigurationen von 1A, 1B und 1C Änderungen
am Mikrocontroller 110 und als solcher kann der Vorprozessor 130 nicht
für verschiedene
Prozessortypen mit dem gleichen Typ Kern 114 als Standardentwurf
verwendet werden.
-
In
einem Vorverarbeitungsschritt wird für die Programmanweisungen eines
Quellenprogramms, das von der Verarbeitungseinheit 100 ausgeführt werden
muss, eine programmspezifische virtuelle Maschine mit einem entsprechenden
Satz von virtuellen Maschinenbefehlen definiert. Darüber hinaus
wird für
die programmspezifische virtuelle Maschine ein zugehöriger Umsetzer 132 definiert,
um virtuelle Maschinenbefehle in native Befehle des Mikrocontrollerkerns
umzusetzen. Der Umsetzer 132 verschafft für jeden
der virtuellen Maschinenbefehle genau einen oder, gewöhnlich,
eine Sequenz entsprechender nativer Befehle, die zum Ausführen des
virtuellen Maschinenbefehls des nativen Kerns 114 benötigt werden. 2 veranschaulicht
den Prozess des Definierens der virtuellen Maschine und des zugehörigen Umsetzers.
In Schritt 205 wird das Quellenprogramm 200 analysiert.
Auf Basis der Analyse (z.B. Auftrittshäufigkeit von Operationen) wird
in Schritt 210 eine programmspezifische virtuelle Maschine 215 definiert.
In Schritt 220 wird für
die virtuelle Maschine ein zugehöriger
Umsetzer 225 definiert und in Schritt 230 wird
das Quellenprogramm in Befehlen der virtuellen Maschine ausgedrückt, was
Code 235 ergibt. Die virtuelle Maschine wird so definiert,
dass der Code im Befehlsspeicher im Vergleich zur Verwendung nur
von nativen Befehlen zum Ausdrücken
der Programmanweisungen weniger Speicherplatz benötigt.
-
Vorzugsweise
wird die programmspezifische virtuelle Maschine definiert, indem
das Programm in virtuelle Maschinenbefehle einer zuvor bestimmten
virtuellen Maschine übersetzt
wird. Als Ausgangspunkt wird eine virtuelle Maschine wie z.B. eine
Stapelmaschine gewählt,
von der bekannt ist, dass sie eine kompakte Darstellung liefert.
Aufgrund der Tatsache, dass eine Stapelmaschine zum Speichern von
Operanden nicht explizit Register verwendet, sondern dass stattdessen
Operanden auf dem Stapel gespeichert werden und Operatoren immer
auf obere Elemente) des Stapels wirken, ist die Anzahl verwendbare
Operanden weniger eingeschränkt
und die Verwaltung der Operanden ist für eine Stapelmaschine einfacher.
Dies macht es leichter, einen Compiler für eine stapelbasierte Maschine
zu bauen als für
eine registerbasierte Maschine. Darüber hinaus haben Stapelmaschinenbefehle
eher eine einfachere Struktur als die meisten registerbasierten
Maschinen. Es versteht sich jedoch, dass auch eine geeignete registerbasierte
Maschine verwendet werden kann. Zur Veranschaulichung der Erfindung
wird die Stapelmaschine von Anhang A verwendet. Ein in der Programmiersprache "C" geschriebenes Musterprogramm (das das
Acht-Damen-Problem löst)
ist im Anhang B gezeigt. Die Übersetzung
des Programms in den Stapelcode der virtuellen Maschine von Anhang
A ist in Anhang C gezeigt. Durch Analysieren des Codes werden häufig auftretende
Sequenzen von Befehlen identifiziert und zusätzliche virtuelle Maschinenbefehle
definiert, die je eine der identifizierten Sequenzen repräsentieren.
Anhang D zeigt eine Liste geeigneter zusätzlicher Maschinenbefehle.
Ein derartiger zusätzlicher
Maschinenbefehl kann als "supervirtueller
Maschinenbefehl" betrachtet
werden. Die programmspezifische virtuelle Maschine wird dann durch
die Grundbefehle von Anhang A in Kombination mit den Superbefehlen
von Anhang D gebildet. Anhang E zeigt das Ausdrücken des Programms von Anhang
B in der virtuellen Maschine von Anhang A und D. Als Nächstes wird
für die
programmspezifische virtuelle Maschine ein zugehöriger Umsetzer 132,
wie in 1 gezeigt, definiert, um virtuelle
Maschinenbefehle in native Befehle des Mikrocontrollerkerns umzusetzen.
Der Umsetzer 132 verschafft für jeden der virtuellen Maschinenbefehle
(in dem Beispiel für
die Kombination der Befehle in Anhang A und D) genau einen oder,
gewöhnlich,
eine Sequenz entsprechender nativer Befehle, die zum Ausführen des
virtuellen Maschinenbefehls des nativen Kerns 114 benötigt werden.
Mit diesem Ansatz wird durch Verwendung relativ weniger virtueller
Maschinenbefehle (in dem Beispiel 38 Grundbefehle und 40 Superbefehle)
eine Kompression des Codes erzielt, was eine Kurz-Darstellung (z.B.
7 Bits) für
jeden nicht parametrisierten Befehl zulässt, im Vergleich zu 16 oder
32 Bits, die gewöhnlich
zum Darstellen nativer Befehle verwendet werden. Die Verwendung
der Superbefehle führt
auch dazu, dass weniger Befehle zum Darstellen des Programms benötigt werden.
In dem Beispiel werden für
das Ausdrücken
des Programms in den Befehlen der virtuellen Basis-Maschine 356 Anweisungen
benötigt.
Mit Hilfe von Superbefehlen reduziert sich dies auf 262 benötigte Anweisungen.
Dies ist günstig
im Vergleich zu der Situation, in der das Programm in nativen Befehlen
ausgedrückt
wird, wobei für
einen MIPS-Prozessor 608 Anweisungen benötigt werden.
-
Vorzugsweise
wird eine programmspezifische virtuelle Maschine folgendermaßen definiert.
Das Quellenprogramm wird in eine Zwischenebenen-Darstellung sogenannter
Ausdruck-Bäume
umgesetzt, die auf einer zuvor bestimmten virtuellen Maschine basiert.
Ein Ausdruck-Baum ist aus Knoten aufgebaut, die Grundoperationen
der virtuellen Maschine repräsentieren.
Der Ausdruck-Baum repräsentiert
die Berechnung, die sich aus dem Durchführen der Grundoperationen der
Knoten des Baumes in einer gegebenen Sequenz (z.B. Postfix-Reihenfolge)
ergibt. Die Umsetzung des Programms in Ausdruck-Bäume
kann unter Verwendung der Analysephase eines Compilers, wie z.B.
des Little-C-Compilers
lcc' von Fraser
und Hanson, durchgeführt
werden. Als Nächstes
werden die Ausdruck-Bäume
und zusammenhängende
Baumfragmente (die eine Sequenz von Operationen repräsentieren)
identifiziert. Jeder der Bäume
und Fragmente ist ein durch einen Superbefehl zu repräsentierender
Kandidat. Ausgehend von den virtuellen Maschinengrundbefehlen wird
der Baum oder das Baumfragment, das die größte Codegrößeneinsparung ergibt, durch
einen Superbefehl repräsentiert.
Der Superbefehl wird zu der virtuellen Maschine hinzugefügt. Das
Programm wird in dem neuen Satz von virtuellen Maschinenbefehlen
ausgedrückt,
um die Einsparung zu ermitteln. Neue Superbefehle werden hinzugefügt, solange
noch Platz zum Hinzufügen
neuer Befehle verfügbar
ist (wenn z.B. die virtuellen Maschinenbefehle als Bytes gespeichert
werden müssen,
ist die Anzahl Befehle auf 256 begrenzt) oder bis keine
Einsparung mehr erreicht wird. Schließlich wird das Quellenprogramm
in Befehlen der programmspezifischen virtuellen Maschine ausgedrückt und
werden Umsetzungsdaten erzeugt.
-
Sobald
das Programm in virtuellen Maschinenbefehlen ausgedrückt ist,
wird der resultierende Code in dem Befehlsspeicher 120 gespeichert.
Für eingebettete
Systeme wird der Code gewöhnlich
in einem ROM gespeichert, der maskenprogrammiert ist, oder in einem
programmierbaren ROM, wie z.B. ein PROM oder (E)EPROM. Ebenso werden
die erzeugten Umsetzungsdaten in dem Umsetzer 132 der Verarbeitungseinheit 100 dargestellt.
Der Umsetzer 132 kann beispielsweise mit Hilfe einer Umsetzungstabelle
oder in ROM gespeichertem Mikrocode implementiert werden. Der Umsetzer 132 kann
auch unter Verwendung einer Logik, wie z.B. einer PLD, implementiert
werden. Für
einen wiederprogrammierbaren Umsetzer kann der gleiche Ansatz, basiert
auf den jeweiligen wiederprogrammierbaren Techniken, wie z.B. (E)EPROM
oder E-PLD, verwendet werden.
-
3 veranschaulicht
eine weitere Ausführungsform
gemäß der Erfindung,
bei der das Quellenprogramm 300, z.B. in "C" programmiert, in Schritt 310 in
mehre re zusammenhängende
Gruppen von Programmanweisungen, wie z.B. Programmmodule, Objekte
oder taskspezifischen Code aufgeteilt wird. Es werden Module 312 und 316 gezeigt.
Es wird deutlich sein, dass keine explizite Aufteilung gefordert
zu werden braucht und das Quellenprogramm bereits in einer geeigneten
modularen Ordnung verfügbar
sein kann. In gleichartiger Weise wie in den Schritten 205 und 210 von 2 wird
für jede
der Gruppen 312 und 316 eine programmgruppenspezifische
virtuelle Maschine definiert (Schritt 330) mit einem entsprechenden
Satz von virtuellen Maschinenbefehlen. Es werden die jeweiligen
virtuellen Maschinen 332 und 336 gezeigt. In Schritt 340 werden die
Programmanweisungen der Gruppen 312 und 316 in
Befehlen der jeweiligen virtuellen Maschinen 332 und 336 ausgedrückt, was
die jeweiligen Codemodule 342 und 346 ergibt.
Die Codemodule werden in Schritt 350 in dem Befehlsspeicher 120 gespeichert.
In Schritt 360 werden für
die programmgruppenspezifischen virtuellen Maschinen 332 und 336 jeweilige
Umsetzungsmittel 362 und 366 erzeugt, um virtuelle
Maschinenbefehle in native Befehle des Mikrocontrollerkerns umzusetzen.
In Schritt 370 werden die Umsetzungsmittel 362 und 366 in
der Verarbeitungseinheit 100 dargestellt, beispielsweise
durch Programmieren einer Umsetzungstabelle oder Logik in der Verarbeitungseinheit 100.
Daher umfasst der Umsetzer 132 ein spezielles Umsetzungsmittel für jede der
Programmgruppen. Um zu ermöglichen,
dass die Verarbeitungseinheit 100 das einem abgerufenen
virtuellen Befehl zugeordnete gruppenspezifische Umsetzungsmittel
selektiert, werden in Schritt 390 Selektionsdaten in der
Verarbeitungseinheit gespeichert. Während des Ausführens wird
ein virtueller Maschinenbefehl aus dem Befehlsspeicher 120 abgerufen.
Die Selektionsdaten werden dann verwendet, um das mit der virtuellen
Maschine, zu der der virtuelle Maschinenbefehl gehört, verknüpfte Umsetzungsmittel
zu lokalisieren.
-
4 zeigt
ein Blockschaltbild des Umsetzers 132, in dem der Umsetzer 132 mehrere
Umsetzungsmittel umfasst (gezeigt werden 400, 410 und 420).
Jedes der Umsetzungsmittel wird zum Umsetzen virtueller Maschinenbefehle
einer speziellen virtuellen Maschine verwendet. Es wird deutlich
sein, dass der Umsetzer 132 vollständig autonome Umsetzungsmittel
umfassen kann, die jeweils fähig
sind, die vollständige
Umsetzung durchzuführen.
Alternativ kann der Umsetzer 132 für jede der virtuellen Maschinen
miteinander geteilte Logik unter der Steuerung separater Umsetzungsdaten
(wie z.B. einer Tabelle) verwenden. Die Verarbeitungseinheit 100 umfasst
die Selektionsdaten 430. Die Selektionsdaten können in
beliebiger geeigneter Weise dargestellt werden, z.B. im Befehlsspeicher 120 gespeichert,
oder, wenn das Umsetzungsmittel (teilweise) als Daten gespeichert
ist, in Kombination mit dem Umsetzungsmittel gespeichert. Die Selektionsdaten 430 können auch
die Form eines aus einem Speicher geladenen Registers in dem Umsetzer 132 haben.
Verschiedene Formen von Selektionsdaten können verwendet werden.
-
Bei
einer weiteren Ausführungsform
ist der Adressenbereich des Befehlsspeichers 120 in mehrere Teilbereiche
unterteilt. Ein Adressenteilbereich ist zum Speichern virtueller
Maschinenbefehle von nur einer virtuellen Maschine reserviert. Vorzugsweise
kann ein Adressenteilbereich auch zum Speichern nativer Befehle reserviert
sein. Solche nativen Befehle können
beispielsweise zum Initialisieren des Systems verwendet werden oder
um zu ermöglichen,
dass gewisse Softwaremodule, wie z.B. Treiber oder spezielle Teile
der eingebetteten Softwareanwendung, für optimales Leistungsvermögen in native
Befehle kompiliert werden. In dieser Ausführungsform geben die Selektionsdaten
für jeden
der definierten Adressenteilbereiche an, welches der Umsetzungsmittel 400, 410 oder 420 zum
Umsetzen eines vom Befehlsabrufer 134 abgerufenen Befehls
in native Befehle verwendet werden sollte. Hierzu umfasst der Umsetzer 132 einen
Detektor 440, um auf Basis der Selektionsdaten einen aus
einer Stelle in dem Befehlsspeicher 120 abgerufenen Befehl
selektiv zu einem der Umsetzungsmittel 400, 410 oder 420 zu
lenken. Wenn auch native Befehle in dem Befehlsspeicher 120 gespeichert
sind, sorgt der Detektor 440 dafür, dass diese Befehle zur Lieferung
an den Mikrocontrollerkern 114 direkt zu der Zuführeinrichtung 136 geliefert
werden.
-
Als
Alternative für
ein Basieren der Entscheidung auf der Adresse des abgerufenen Befehls
kann die Information auch in direktem Zusammenhang mit dem Befehl
gespeichert werden. Beispielsweise können ein oder mehrere Bits
jedes Eintrags in dem Befehlsspeicher 120 reserviert sein,
um zwischen virtuellen Maschinen und/oder zwischen nativem Code
oder virtuellem Code zu differenzieren. Wenn beispielsweise nur
zwei virtuelle Maschinen verwendet werden, wobei die Befehle 7 Bits
benötigen,
kann ein achtes Bit verwendet werden, um die virtuelle Maschine
anzugeben, zu der der Befehl und das zugehörige Umsetzungsmittel gehört. Offensichtlich
kann diese Technik mit auf Adressen basiertem Differenzieren kombiniert
werden.
-
Als
weitere Alternative können
die Selektionsdaten in einem Register gespeichert werden, wobei
das Register so gesetzt ist, dass es jedes Mal, wenn zwischen virtuellen
Maschinen ein Schalten auftritt, ein anderes Umsetzungsmittel angibt.
Zum Setzen des Registers kann ein spezieller Befehl (z.B. eine Art
Sprungbefehl) verwendet werden.
-
Solche
die Implementation unterstützenden
Befehle können
mit den virtuellen Maschinenbefehlen/nativen Befehlen in dem Befehlsspeicher
gemischt werden.
-
Wie
oben beschrieben, wird typischerweise ein virtueller Maschinenbefehl
in eine Sequenz von nativen Befehlen umgesetzt. Um die Lieferung
von Befehlen an den Kern zu regeln, umfasst die Verarbeitungseinheit 100 eine
zwischen den Umsetzer 132 und den Mikrocontrollerkern 114 geschaltete
Ablaufsteuerung 450 für
ein sequentielles Zuführen
der Sequenz von nativen Befehlen zum Mikrocontrollerkern 114.
Die Ablaufsteuerung 450 kann mit Hilfe herkömmlicher
Bauteile, wie z.B. einem Zähler,
der beispielsweise infolge eines Auslösers aus dem Mikrocontrollerkern,
der angibt, dass ein neuer Befehl benötigt wird, inkrementiert werden
kann (z.B. ein Inkrement des Befehlszählers des Kerns), implementiert
werden. Bei einer herkömmlichen Verarbeitungseinheit
führt eine Änderung
des Befehlszeigers (auch als Programmzähler bezeichnet) des Mikrocontrollerkerns
dazu, dass der Abrufer 134 einen Befehl aus dem Befehlsspeicher 120 abruft
und die Zuführein- richtung 136 den
Befehl an den Mikrocontrollerkern 114 liefert. Um die Verbindung
zwischen automatischem Abrufen und Zuführen zu unterbrechen, umfasst
die Verarbeitungseinheit 100 weiterhin Verhinderungsmittel 460,
um während
des Zuführens
der Sequenz das Abrufen eines Befehls aus dem Befehlsspeicher zu
verhindern
-
Es
wird deutlich sein, dass die Ablaufsteuerung und das Verhindern
auf mehrere Weisen durchgeführt werden
können.
Bei einer weiteren Ausführungsform
ist das Verhinderungsmittel 460 ausgebildet, das Verhindern
durch Behinderung eines Inkrements eines Befehlszeigers des Mikrocontrollerkerns 114 durchzuführen. Dies
kann eine kleine Modifikation für
den Kern 114 erfordern. Beispielsweise kann eine zusätzliche
Steuerungsleitung in den Kern 114 hinein selektives Verhindern
des Befehlszählers
zulassen, wobei das Verhinderungsmittel 460 immer, wenn
Befehle aus der Sequenz geliefert werden, das Inkrement verhindert
und ein Inkrement freigibt, wenn eine Sequenz vollständig geliefert
worden ist.
-
Bei
einer alternativen Ausführungsform
behält
der Befehlsabrufer 134 seinen eigenen Befehlszähler 135 bei,
getrennt vom Befehlszeiger des Mikrocontrollerkerns 112.
Das Verhinderungsmittel 460 steuert, wann ein Inkrement
(oder allgemeiner eine Änderung)
des Befehlszeigers des Mikrocontrollers zu einer Änderung des
Befehlszählers 135 des
Befehlsabrufers 134 führt. Ähnlich wie
oben beschrieben verhindert das Verhinderungsmittel 460 immer,
wenn Befehle aus der Sequenz geliefert werden, eine Änderung
des Befehlszählers 135 und
gibt eine Änderung
frei, wenn eine Sequenz vollständig
geliefert worden ist. Als Folge einer Änderung des Befehlszählers 135 wird
der Befehlsabrufer 134 normalerweise einen neuen Befehl
aus dem Befehlsspeicher 112 abrufen, aus einer von dem
Befehlszähler
angegebenen Adresse. Vorteilhafterweise, insbesondere im Hinblick
auf die kompakte Darstellung von virtuellen Maschinenbefehlen, kann
der Befehlsabrufer 134 mehrere Befehle aus dem Speicher
in einer einzigen Lese-Operation abrufen (z.B. können vier Ein-Byte-Befehle als
ein 32-Bit-Wort gelesen werden). Auf diese Weise braucht nicht jede Änderung
des Befehlszählers 135 zum
tatsächlichen
Abrufen eines neuen Befehls zu führen.
-
Bei
einer weiteren Ausführungsform
gemäß der Erfindung
wird ein Programmmodul in virtuellen Maschinenbefehlen einer weiteren
virtuellen Maschine empfangen, z.B. über ein Netz oder aus einem
lokalen Hintergrundspeicher. Ein Beispiel für ein solches Programmmodul
ist ein Java-Applet. Das empfangene Programmmodul wird in dem Befehlsspeicher 120 gespeichert.
Um Umsetzung der weiteren virtuellen Maschinenbefehle in native
Befehle zu ermöglichen,
werden auch Umsetzungsdaten empfangen. Die Umsetzungsdaten können beispielsweise
eine Umsetzungstabelle für
ein tabellenbasiertes Umsetzungsmittel oder E-PLD-Programmierdaten
für ein
PLD-basiertes Umsetzungsmittel spezifizieren. Die Umsetzungsdaten
werden in der Verarbeitungseinheit für nachfolgenden Gebrauch durch
ein weiteres Umsetzungsmittel des Umsetzers 132 gespeichert.
Um während
der Ausführung
das geeignete Umsetzungsmittel selektieren zu können, werden auch Selektionsdaten
in der Verarbeitungseinheit gespeichert, die jeden weiteren virtuellen
Maschinenbefehl mit den Umsetzungsdaten verknüpfen. Während der Ausführung wird,
für einen
abgerufenen weiteren virtuellen Maschinenbefehl, das weitere Umsetzungsmittel
unter der Steuerung der von den Selektionsdaten angegebenen Umsetzungsdaten
betrieben.
-
Wie
oben beschrieben, kann der Umsetzer 132 eine Tabelle zum
Umsetzen eines virtuellen Maschinenbefehls in eine Sequenz aus nativen
Befehlen umfassen. Es kann eine eindimensionale Tabelle verwendet werden,
bei der jede Zelle der Tabelle eine Sequenz aus nativen Befehlen
für einen
einzigen entsprechenden virtuellen Maschinenbefehl umfasst. Die
Zellennummer kann dem Wert des entsprechenden virtuellen Maschinenbefehls
entsprechen. Als Beispiel kann die Sequenz aus nativen Befehlen
für die
Java-Ganzzahladdition (0 × 60) in
Zelle 96 (= 0 × 60
in Hexadezimal-Schreibweise) lokalisiert sein. Da die Länge der
Sequenz aus nativen Befehlen für
die verschiedenen virtuellen Befehle erheblich variieren kann, sind
die Sequenzen vorzugsweise in einer eindimensionalen Tabelle ohne
explizite Zellen lokalisiert, wo die Sequenzen einander unmittelbar
folgen.
-
Eine
derartige Übersetzungstabelle 500 wird
in 5 gezeigt, wo die impliziten Zellengrenzen mit
gestrichelten Linien angedeutet sind. Um eine Sequenz für einen
virtuellen Maschinenbefehl lokalisieren zu können, kann eine Code-Indextabelle 510 verwendet
werden, die für
jeden virtuellen Maschinenbefehl (VMI 1 bis VMI N) den Anfangspunkt
der entsprechenden Sequenz in der Übersetzungstabelle 500 angibt.
Für die
Zelle der Übersetzungstabelle 500,
die VMI 3 entspricht, wird die zugehörige Sequenz 520 aus
nativen Befehlen NI 1 bis NI M gezeigt.
-
Ein
weiteres Beispiel für
eine Umsetzung wird für
den Java-Bytecode bipush n (zur Vorzeichenerweiterung von Byte n
und zum Platzieren des Ergebnisses auf der Spitze des Stapels verwendet)
gegeben. Dieser virtuelle Maschinenbefehl besteht aus zwei Bytes
{0 × 16
und n}, wobei das erste Byte die Operation spezifiziert und das
zweite Byte den Parameter n verschafft. Der Befehl kann in die folgende
Sequenz aus nativen MIPS-Befehlen
umgesetzt werden:
| ori
$a0, $0, n | /*
Register $a0 mit Konstante n* laden/ |
| sll
$a0, $a0, 24 | /*
um 24 Bits nach links schieben*/ |
| sra
$a0, $a0, 24 | /*
arithmetisch nach rechts schieben, was Vorzeichenerweiterung bewirkt,
durch Nachbilden des letzten am weitesten linken Bit */ |
| sw
$a0, 0 ($tosp) | /*
Ergebnis auf der neuen Stapelspitze speichern*/ |
| addi
$tosp, -4 | /*
Stapelgröße erhöhen */ |
-
Dieses
Beispiel veranschaulicht, dass ein virtueller Maschinenbefehl parametrisiert
sein kann, wobei einem Operationscode zumindest ein Operand folgt.
Vorteilhafterweise umfasst der Umsetzer 132 eine Übersetzungstabelle 500,
wo native Befehle entweder durch den vollständigen Code oder durch ein
Befehlsgerippe repräsentiert
werden. Beispielsweise enthält
der Befehl addi $tosp, -4 (letzter Befehl der Sequenz des vorhergehenden
Beispiels) keine variablen Teile und kann vollständig als 4-Byte-Eintrag in
der Tabelle lokalisiert sein.
-
Der
Befehl ori $a0, $0, n (erster Befehl der Sequenz des vorhergehenden
Beispiels) enthält
einen variablen Teil und kann in der Tabelle als Gerippe lokalisiert
sein, wobei der variable Teil (der n ist) nicht spezifiziert ist.
Vorzugsweise hat der Eintrag in der Tabelle für ein Befehlsgerippe die gleiche
Breite wie ein vollständiger
Befehl (z.B. 4 Bytes für
einen MIPS-Prozessor), was eine uniforme Tabelle zulässt. Weitere
Information kann in der Tabelle (oder in (einer) separaten Tabelle(n))
lokalisiert sein, um anzugeben, wie der nicht spezifizierte Teil
des nativen Befehlsgerippes ausgefüllt werden sollte. Vorteilhafterweise wird
Mikroprogrammierung verwendet, um die nicht spezifizierten Teile
auszufüllen.
Die weitere Information kann dann Mikrocode umfassen oder angeben.
Es versteht sich, dass es vorteilhaft ist, für ein Befehlsgerippe eine gleiche
Struktur (Breite und Zusammensetzung) zu verwenden wie für einen
vollständigen
nativen Befehl. Es können
jedoch ebenso gut andere Strukturen verwendet werden.
-
Wenn
die virtuelle Maschine eine stapelorientierte Maschine ist, werden
vorzugsweise der Stapel oder zumindest die oberen Elemente des Stapels
auf Register des Mikrocontrollers 110 abgebildet. Auf diese
Weise wird der Speicherstapel (mit dem virtuellen Maschinenstapel)
auf den Registerstapel abgebildet. Unter der Annahme, dass die Register
$r1, $r2 und $r3 drei aufeinander folgende Elemente des Speicherstapels
enthalten, wobei anfangs $r1 der ersten leeren Stelle des Speicherstapels
(über der
Spitze des Stapels) entspricht, $r2 die Spitze des Speicherstapels
und $r3 das zweite Element des Speicherstapels enthält, kann
der Java-Bytecode bipush n in die folgende Sequenz aus nativen MIPS-Befehlen umgesetzt
werden:
ori $r1, $0, n
sll $r1, $r1, 24
sra $r1,
$r1, 24
-
Nach
dieser Operation enthält
$r1 die Spitze des Speicherstapels.
-
Ebenso
kann der Java-Bytecode (ein virtueller Maschinenbefehl) für Ganzzahladdition
(0 × 60)
in die folgende Sequenz aus nativen MIPS-Befehlen umgesetzt werden,
ausgehend von der gleichen Position, wo anfangs $r1 der ersten leeren
Stelle des Speicherstapels (über
der Spitze des Stapels) entspricht, $r2 die Spitze des Speicherstapels
und $r3 das zweite Element des Speicherstapels enthält:
add
$r3, $r2, $r3
-
Nach
dieser Operation enthält
$r3 die Spitze des Speicherstapels.
-
In
den obigen Beispielen wird vorzugsweise die Position der Spitze
des Speicherstapels (d.h. welches Register die Spitze des Speicherstapels
enthält)
mittels eines Registers
138 des Umsetzers
132 angegeben. Der
Umsetzer nutzt das Register
138, das als Registerstapelzeiger
(RSP) bezeichnet wird, um die geeigneten nativen Befehle zu erzeugen.
Vorzugsweise wird Mikroprogrammierung verwendet, um die Registeroperanden der
nativen Befehle zu spezifizieren. Auf diese Weise sind auch feste
native Befehle variabel geworden, da die Registeroperanden durch
den Umsetzer
132 spezifiziert werden müssen. Vorzugsweise werden solche
Operanden auch in der Übersetzungstabelle
500 unter
Ver wendung von Befehlsgerippen gespeichert. Unter der Annahme, dass
RSP auf das erste freie Register weist, kann der Java-Bytecode bipush
n in die folgende Sequenz aus nativen MIPS Befehlen unter Steuerung
des entsprechenden Mikrocodes umgesetzt werden:
| Mikrocode | Befehle |
| rsp
= 1; ftg = rsp + 1 | ori
$(rsp + 1), $0, n |
| ftg = rsp + 1; fao =
rsp + 1 | sll
$(rsp + 1), $(rsp + 1), 24 |
| ftg = rsp + 1; fao =
rsp + 1 | sra
$(rsp + 1), $(rsp + 1), 2 |
wobei f
tg das Zielregister
für den
Befehl angibt, und f
a0 und f
a1 das
erste bzw. zweite Argumentregister für den Befehl angeben. Ein folgender
Java-Bytecode iadd zum Addieren der zwei oberen Elemente des Stapels
würde zu
dem folgenden Mikrocode und Befehl führen:
f
tg =
rsp + 2; f
ao = rsp + 2; f
a1 =
rsp + 1; rsp += 1 add $(rsp + 2), $(rsp + 2), $(rsp + 1)
-
Anhang
A. virtuelle Maschinengrundbefehle
-
-
Suffix
-
-
- B
- Boolean (Boolsch)
- C
- Char (Zeichen)
- D
- Double (Doppel)
- I
- Integer (Ganzzahl)
- F
- Floating point (Gleitkomma)
- P
- Pointer (Zeiger)
- S
- Short (Kurz)
- U
- Unsigned integer (vorzeichenlose
Ganzzahl)
- V
- Label
-
Anhang
B. Muster-"C"-Programm
-
-
Anhang
C. Musterprogramm, ausgedrückt
in standardmäßiger virtueller
Maschine
-
-
-
-
-
-
Anhang
E. Musterprogramm, ausgedrückt
in programmspezifischer virtueller Maschine
-
-
-
1
- 112
- PROZ.
- 114
- KERN
- 136
- ZUFÜHR.
- 132
- UMSETZ.
- 134
- ABRUF.
- 116
- CACHE
- 120
- B.S.
-
2
- 200
- QUELL.
- 205
- ANALYSIEREN
- 220
- DEFINIEREN
UMS.
- 210
- DEFINIEREN
V.M.
- 215
- V.M.
- 225
- UMSETZ.
- 230
- KOMPILIEREN
- 235
- CODE
-
3
- 300
- QUELL.
- 310
- AUFTEILEN
- 312
- MOD.
1
- 316
- MOD.
2
- 330
- DEFINIEREN
V.M.
- 332
- V.M.I
- 336
- V.M
2
- 360
- DEFINIEREN
UMS. UMS. 1
- 390
- SEL.D.
SPEICHERN
- 370
- DARSTELLEN
- 342
- CM
1
- 346
- CM
2
- 340
- KOMPILIEREN
- 350
- CM
SPEICHERN
-
4
- 460
- VERHIND.
- 135
- B.ZÄHLER
- 430
- SEL.D.
- 440
- DET.
- 400
- UMS
1
- 410
- UMS
2
- 420
- UMS
3
- 450
- ABLAUF.
- 136
- ZUFÜHR.
