-
Die
Erfindung betrifft allgemein das technische Gebiet der Optimierung
eines Programms und der Ausführung
des optimierten Programms durch eine Maschine, die insbesondere
eine virtuelle Maschine, aber auch ein unmittelbar in Hardware implementierter
Prozessor sein kann. Spezieller betrifft die Erfindung die Programmoptimierung
durch Verwendung von Makrooperationen, um den für das optimierte Programm benötigten Speicherplatz
zu verringern. Ein bevorzugtes Einsatzgebiet der Erfindung ist die
Programmausführung
durch einen tragbaren Datenträger,
der beispielsweise als Chipkarte in unterschiedlichen Bauformen
oder als Chipmodul ausgestaltet sein kann.
-
Bei
tragbaren Datenträgern
und anderen ressourcenbeschränkten
Systemen ist der zur Aufnahme von ausführbarem Programmcode vorgesehene
Speicherplatz in der Regel nur knapp bemessen. Dies gilt insbesondere
dann, wenn der Programmcode nicht in einem maskenprogrammierten ROM,
sondern in einem nicht-flüchtigen,
beschreibbaren EEPROM abgelegt werden soll, da auf heute gebräuchlichen
Datenträgern
wesentlich mehr ROM-Speicher als EEPROM-Speicher vorgesehen ist.
Die Speicherung von Programmcode im EEPROM ist jedoch wünschenswert,
weil dann eventuelle Änderungen
des Programmcodes mit viel geringerem Aufwand in die Fertigung neuer
Datenträger einfließen können.
-
Es
ist bekannt, den zur Speicherung eines Programms benötigten Speicherplatz
("footprint" des Programms) durch
einen Optimierungsdurchlauf zu reduzieren. Der Artikel "Liebling, ich habe
den Code geschrumpft" von
Christian Ferdinand und Reinhold Heckmann, erschienen in der Zeitschrift
Design und Elektronik, Heft 01/2001, Seiten 113 bis 115, verfügbar unter
http://www.elektroniknet.de/fachthemen/pdf/pdf_due_0101/DE0101113.pdf, beschreibt ein
Optimierungsverfahren, bei dem wiederholt vorkommende Codestücke aus
einem zu optimierenden Programm herausgezogen und durch ein gemeinsames
Unterprogramm als Stellvertreter ersetzt werden. Ein ähnlicher
Artikel in englischer Sprache von Christian Ferdinand mit dem Titel "Post Pass Code Compaction
at the Assembly Level for C16x" ist
gegenwärtig
unter http://www.spacetools.com/site/contact_v3_9/V3_9p35.pdf verfügbar.
-
Das
aus den gerade genannten Artikeln bekannte Verfahren ist jedoch
darauf angewiesen, Befehlsgruppen zu finden, die sowohl hinsichtlich
ihrer Befehlscodes als auch hinsichtlich der jedem Befehlscode zugeordneten
Operanden übereinstimmen.
Dies schränkt
die Optimierungsmöglichkeiten erheblich
ein, da Befehlsgruppen, die z.B. identische Berechnungsfunktionen
auf unterschiedlichen Daten ausführen,
nicht als wiederholt vorkommende Codestücke angesehen werden. Es wäre daher
wünschenswert,
eine Codegrößenoptimierung
auch für solche
Befehlsgruppen zu ermöglichen.
-
Die
Erfindung hat demgemäß die Aufgabe, die
Probleme des Standes der Technik zumindest zum Teil zu vermeiden
und eine Technik zur Optimierung und Ausführung eines Programms bereitzustellen,
die den zur Speicherung des Programms erforderlichen Speicherplatz
möglichst
stark verringert. In bevorzugten Ausgestaltungen soll die Erfindung
relativ leicht zu implementieren sein und keinen oder allenfalls
geringen Zusatzaufwand bei der Programmentwicklung verursachen.
-
Erfindungsgemäß wird diese
Aufgabe ganz oder zum Teil gelöst
durch ein Verfahren zur Erzeugung eines optimierten Programms gemäß Anspruch 1,
ein Verfahren zum Ausführen
eines Programms gemäß Anspruch
9, ein Computerprogrammprodukt gemäß Anspruch 14 und eine Vorrichtung
gemäß Anspruch
15, die insbesondere als tragbarer Datenträger ausgestaltet sein kann.
Die abhängigen
Ansprüche
betreffen bevorzugte Ausführungsformen
der Erfindung.
-
Die
Erfindung beruht auf der Grundidee, bei der Optimierung und bei
der Ausführung
des optimierten Programms die Befehlscodes von den Operanden zu
trennen. Das optimierte Programm enthält mindestens einen Befehlscodestrang
mit Befehlscodes und mindestens einen Operandenstrang mit Operanden.
Bei der Optimierung werden Befehlsgruppen des ursprünglichen
Programms gesucht, deren Befehlscodes sich durch je einen Makrobefehl zusammenfassen
lassen. Die Operanden einer solchen Befehlsgruppe werden als Operanden
des Makrobefehls in den Operandenstrang übernommen. Auf diese Weise
ergeben sich deutlich mehr Optimierungsmöglichkeiten als im Stand der
Technik, weil Befehlsgruppen schon dann zu Makrobefehlen zusammengefaßt werden
können,
wenn nur die Befehlscodefolgen – und
nicht notwendigerweise auch die in den Befehlsgruppen enthaltenen
Operanden – übereinstimmen.
-
Zur
Ausführung
des optimierten Programms ist erfindungsgemäß eine Maschine mit zwei Befehlszählern vorgesehen,
von denen der erste dem Befehlscodestrang und der zweite dem Operandenstrang
zugeordnet ist. Während
oder vor oder nach der Ausführung
jedes Befehls wird der erste Befehlszähler entsprechend der Anzahl
der Befehlscodes im Befehlscodestrang weitergeschaltet, und der
zweite Befehlszähler
wird entsprechend der Anzahl der Operanden im Operandenstrang weitergeschaltet. Bei
Befehlen, die keine Operanden aufweisen, ist diese "Weiterschaltung" des zweiten Befehlszählers natürlich nur
konzeptuell zu verstehen, weil der Befehlszähler dann um "null Operanden" weitergeschaltet,
also im Ergebnis nicht verändert
wird. Dieses Programmausführungsverfahren
liefert die technischen Grundlagen, um Programme verarbeiten zu können, die
gemäß der oben
genannten Grundidee optimiert worden sind.
-
In
bevorzugten Ausgestaltungen der Erfindung enthält das optimierte Programm
Makrobefehle, die jeweils mehrere Befehle des ursprünglichen Programms
ersetzen. Unter dem Begriff "Makrobefehl" soll im vorliegenden
Dokument insbesondere jeder Befehl verstanden werden, der in seiner
Wirkung der Wirkung mehrerer Einzelbefehle des ursprünglichen
Programms entspricht. Ein Makrobefehl kann beispielsweise als spezielle
Instruktion implementiert werden, die bereits in ihrem Befehlscode
eine Information über
die auszuführenden
Einzelbefehle enthält,
oder als allgemeine Instruktion, die erst in einem zweiten Befehlscodewort
oder in einem Operanden die auszuführenden Einzelbefehle codiert.
Insbesondere kann der Makrobefehl einen Unterprogrammaufruf oder
einen Fangaufruf (trap) oder einen Befehlscode umfassen, der in
einem vorgegebenen Befehlssatz für
Erweiterungen reserviert ist.
-
Bei
dem erfindungsgemäßen Optimierungsverfahren
wird die Befehlscodefolge einer zu optimierenden Befehlsgruppe in
einem Makrobefehl codiert. Dies bedeutet in der Regel nicht, daß sich die
Befehlscodes ohne weitere Informationen aus dem Makrobefehl ableiten
lassen. Der Makrobefehl enthält vielmehr
vorzugsweise lediglich eine Referenz auf eine Makrodefinition, die
ihrerseits die auszuführende
Folge von Befehlscodes beinhaltet. In Ausführungsformen, bei denen der
Makrobefehl als Unterprogrammaufruf ausgestaltet ist, wird das aufgerufene
Unterprogramm als Makrodefinition angesehen.
-
In
manchen Ausgestaltungen der Erfindung wird ein fest vorgegebener
Satz von Makrodefinitionen verwendet, die Befehlssequenzen entsprechen, wel che
erfahrungsgemäß häufig benötigt werden. Bevorzugt
werden jedoch die Makrodefinitionen – ausschließlich oder zusätzlich zu
vorgegebenen Makrodefinitionen – beim
Optimierungsvorgang erstellt. Solche beim Optimierungsvorgang erzeugten
Makrodefinitionen sollen insbesondere Folgen von Befehlscodes codieren,
die im ursprünglichen
Programm möglichst
häufig
auftreten.
-
Die
erfindungsgemäße Trennung
des optimierten Programms in mindestens einen Befehlscodestrang
und mindestens einen Operandenstrang entsteht vorzugsweise erst
bei der Optimierung. In bevorzugten Ausführungsformen weist das ursprüngliche
Programm diese Trennung nicht auf, sondern besteht aus einer Befehlsfolge,
in der sich Befehlscodes und gegebenenfalls vorhandene Operanden im
wesentlichen abwechseln. Dieser an sich übliche Wechsel zwischen Befehlscodes
und Operanden ist im optimierten Programm gemäß der vorliegenden Erfindung
aufgelöst.
-
Was
die effektiv ausgeführten
Befehle – nach Auflösung der
Makrobefehle – angeht,
entspricht der Programmfluß im
optimierten Programm vorzugsweise dem Programmfluß im ursprünglichen
Programm. Es werden daher bei der Programmoptimierung vorzugsweise
Sprungbefehle und sonstige den Programmablauf beeinflussende Befehle
derart erzeugt, daß sie
sowohl ein Sprungziel im Befehlscodestrang als auch ein entsprechendes
Sprungziel im Operandenstrang definieren.
-
Bestehende
Prozessorarchitekturen können so
angepaßt
werden, daß sie
erfindungsgemäß optimierte
Programme als Maschinensprache ausführen. Grundsätzliche
Schwierigkeiten sind damit nicht verbunden, wenngleich natürlich gewisse
Arbeiten für die
Entwicklung geänderter
Hardwarestrukturen erforderlich sind. Mit besonders geringem Aufwand kann
die Erfindung jedoch in einer virtuellen Maschine implementiert
werden. Insbesondere ist vorgesehen, eine Java Card Virtual Machine
an die erfindungsgemäß optimierte
Programmstruktur anzupassen. Die genannte virtuelle Maschine ist – soweit
die Ausführung
nicht-optimierter Programme betroffen ist – gut bekannt; ausführliche
Spezifikationen finden sich auf den Internet-Seiten der Firma Sun
Microsystems, Inc., Palo Alto, USA, unter http://java.sun.com.
-
Der
erfindungsgemäße Optimierungsprozeß kann prinzipiell
in jeder Stufe der automatischen Programmumsetzung vorgenommen werden,
beispielsweise durch einen Compiler, einen Konverter oder ein gesondertes
Optimierungsprogramm. Besonders bevorzugt wird der Optimierungsvorgang
jedoch von einem Ladeprogramm ausgeführt, das z.B. in einem tragbaren
Datenträger,
in den auch das auszuführende
Programm eingeschrieben werden soll, enthalten ist. In diesem Fall
braucht bei der gesamten Programmentwicklung keinerlei Rücksicht
auf das erfindungsgemäße Optimierungsverfahren
genommen zu werden; es wird vielmehr ein völlig normales unoptimiertes
Programm – z.B.
in Form einer sogenannten CAP-Datei – erzeugt, das auch von einem
gewöhnlichen
Datenträger
ohne weiteres ausgeführt
werden könnte.
Wenn dieses Programm in einen erfindungsgemäß ausgestalteten Datenträger eingelesen
wird, erfolgt automatisch die Optimierung.
-
Das
erfindungsgemäße Computerprogrammprodukt
weist Programmbefehle auf, um das erfindungsgemäße Optimierungs- und/oder Ausführungsverfahren
zu implementieren. Ein derartiges Computerprogrammprodukt kann ein
körperliches Medium
sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder
eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-körperliches
Medium sein, beispielsweise ein über
ein Computernetzwerk übermitteltes
Signal. Das Computerprogrammprodukt kann z.B. ein Compiler oder ein
Konverter oder ein Optimierungsprogramm zur Ausführung durch einen gewöhnlichen
Arbeitsplatzcomputer oder ein optimierender Lader oder eine virtuelle
Maschine zur Ausführung
durch einen Prozessor eines tragbaren Datenträgers sein.
-
In
bevorzugten Ausgestaltungen weisen der Datenträger und/oder das Computerprogrammprodukt
Merkmale auf, die den gerade beschriebenen und/oder den in den abhängigen Verfahrensansprüchen genannten
Merkmalen entsprechen.
-
Weitere
Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden
genauen Beschreibung eines Ausführungsbeispiels
und mehrerer Ausführungsalternativen
hervor. Es wird auf die schematischen Zeichnungen verwiesen, in
denen zeigen:
-
1 ein Blockdiagramm mit
Funktionseinheiten eines tragbaren Datenträgers nach einem Ausführungsbeispiel
der Erfindung,
-
2 eine schematische Darstellung
des Speicherinhalts bei der Ausführung
eines Befehls in einem optimierten Programm,
-
3 beispielhafte Ausschnitte
eines ursprünglichen
und des daraus erzeugten optimierten Programms,
-
4 eine schematische Darstellung
des Datenflusses bei der Programmerzeugung durch einen Compiler
und bei der Optimierung.
-
Der
in 1 dargestellte Datenträger 10 ist im
vorliegenden Ausführungsbeispiel
als Chipkarte gemäß dem Java-Card-Standard
ausgestaltet. Der Datenträger 10 weist
auf einem einzigen Halbleiterchip einen Prozessor 12, mehrere
in unterschiedlichen Technologien ausgestaltete Speicherfelder und eine
Schnittstellenschaltung 14 zur kontaktlosen oder kontaktgebundenen
Kommunikation auf. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder
ein Arbeitsspeicher 16, ein Festwertspeicher 18 und
ein nichtflüchtiger
Speicher 20 vorgesehen. Der Arbeitsspeicher 16 ist
als RAM, der Festwertspeicher 18 als maskenprogrammiertes
ROM und der nichtflüchtige
Speicher 20 als elektrisch lösch- und programmierbares EEPROM
ausgestaltet. Insgesamt ist der zur Verfügung stehende Speicherplatz
relativ knapp bemessen.
-
Im
Festwertspeicher 18 – und
zum Teil auch im nicht-flüchtigen
Speicher 20 – sind
Systemprogramme 22 enthalten. In an sich bekannter Weise umfassen
die Systemprogramme 22 ein Betriebssystem 24,
das eine Vielzahl von hardwarenahen Funktionen und Diensten bereitstellt.
Ein Codemodul 26 implementiert eine virtuelle Maschine,
und zwar im vorliegenden Ausführungsbeispiel
eine JCVM (Java Card Virtual Machine). Eine Klassenbibliothek 28 enthält eine
Reihe vordefinierter Anwendungsprogrammierschnittstellen. Die im
folgenden beschriebenen Optimierungsvorgänge werden im vorliegenden
Ausführungsbeispiel
von einem internen Ladeprogramm 30 durchgeführt, das
sich im nicht-flüchtigen
Speicher 20 befindet und das konzeptuell teils dem Betriebssystem 24 und
teils dem JCVM-Codemodul 26 zuzuordnen ist.
-
Der
betriebsbereite Datenträger 10 enthält im nicht-flüchtigen
Speicher 20 ein optimiertes Programm 32, das mindestens
einen Befehlscodestrang 34 und mindestens einen Operandenstrang 36 aufweist.
Das Programm 32 ist hinsichtlich des im nicht-flüchtigen
Speicher 20 statisch benötigten Speicherplatzes ("footprint") durch die Verwendung
von Makrobefehlen optimiert worden. Makrodefinitionen 38,
die die Bedeutung jedes Makrobefehls angeben, befinden sich ebenfalls
im nicht-flüchtigen
Speicher 20.
-
Bei
der Ausführung
des optimierten Programms 32 auf dem Datenträger 10 verwaltet
die durch das Codemodul 26 implementierte virtuelle Maschine
einen zusammengesetzten Befehlszähler 40 im
Arbeitsspeicher 16. Der zusammengesetzte Befehlszähler 40 enthält einen
ersten Befehlszähler 42,
dessen Stand den jeweils aktuellen Befehlscode im Befehlscodestrang 34 angibt,
und einen zweiten Befehlszähler 44,
dessen Stand den jeweils aktuellen Operanden im Operandenstrang 36 angibt.
-
Die
Verwendung des zusammengesetzten Befehlszählers 40 ist in 2 genauer dargestellt. Es ist
dort beispielhaft ein erster Befehl 46 gezeigt, der sich
aus einem Befehlscode OC1 im Befehlscodestrang 34 und zwei
Operanden OD1.1 und OD1.2 im Operandenstrang 36 zusammensetzt.
Ein zweiter Befehl 48 weist einen Befehlscode OC2 und einen einzigen
Operanden OD2.1 auf.
-
Vor
der Ausführung
des ersten Befehls 46 zeigen der erste und der zweite Befehlszähler 42, 44 auf
den Befehlscode OC1 sowie auf den ersten Operanden OD1.1. Bei der
Befehlsausführung
werden die Befehlszähler 42, 44 weitergeschaltet,
und zwar für
den Befehlscodestrang 34 und den Operandenstrang 36 getrennt
je nach der Anzahl der Befehlscodes bzw. Operanden im ausgeführten Befehl.
In dem Beispiel von 2 erfolgt
bei der Ausführung des
Befehls 46 also eine Weiterschaltung des ersten Befehlszählers 42 um
ein Speicherwort und eine Weiterschaltung des zweiten Befehlszählers 44 um zwei
Speicherwörter.
Hierdurch wird der in 2 durch
gestrichelte Pfeile angedeutete Zustand erreicht, in dem die Befehlszähler 42, 44 auf
den Befehlscode OC2 bzw. den Operanden OD2.1 des nächsten auszuführenden
Befehls 48 zeigen. Bei Befehlen, die keine Operanden aufweisen,
wird der Wert des zweiten Befehlszählers 44 natürlich nicht verändert.
-
3 zeigt größere Ausschnitte
aus dem Befehlscodestrang 34 und dem Operandenstrang 36 des
optimierten Programms 32. Die ersten beiden Befehle mit
den Befehlscodes OC1, OC2 und den Operanden OD1.1, OD1.2, OD2.1
wurde bereits beschrieben. Ein dritter Befehl enthält lediglich
den Befehlscode OC3 und keinen Operanden. Es folgen ein vierter
Befehl mit dem Befehlscode OC4 und zwei Operanden OD4.1 und OD4.2,
ein fünfter
Befehl mit dem Befehlscode OC5 und zwei Operanden OD5.1 und OD5.2
sowie ein sechster Befehl, der nur den Befehlscode OC6 und keinen
Operanden enthält.
-
Der
zweite Befehl 48 (2)
sowie die Befehle mit den Befehlscodes OC3, OC4 und OC6 werden unmittelbar
von der durch das Codemodul 26 implementierten virtuellen
Maschine ausgeführt.
Diese Befehle werden daher auch als "native" Befehle bezeichnet. Der erste Befehl 46 (2) und der Befehl mit dem
Befehlscode OC5 sind dagegen Makrobefehle, deren Wirkung jeweils
durch eine Folge mehrerer nativer Befehle definiert ist. Die zur
Ausführung
eines Makrobefehls benötigten
Zusatzinformationen sind in den Makrodefinitionen 38 enthalten; 3 zeigt beispielhaft eine
Definition 50, die dem Makrobefehlscode "MAC1" des Befehls 46 die
native Befehlscodefolge "ILOAD", "ILOAD", "IADD" zuordnet.
-
Im
vorliegenden Ausführungsbeispiel
ist die durch das Codemodul 26 implementierte virtuelle Maschine
so ausgestaltet, daß sie
Makrobefehle gemäß den jeweiligen
Makrodefinitionen 38 in eine Folge nativer Befehle auflöst und letztere
ausführt.
Genauer greift die virtuelle Maschine bei der Ausführung eines
Makrobefehls auf die entsprechende Makrodefinition – z.B. die
Definition 50 – zu
und arbeitet die darin enthaltenen Befehlscodes der Reihe nach ab, wobei
je nach Bedarf – ebenfalls
der Reihe nach – die im
Operandenstrang 36 gespeicherten Operanden herangezogen
werden. Die Auswahl der jeweiligen Makrodefinition kann über den
Befehlscode selbst oder über
einen Zeiger oder Indexwert erfolgen, der entweder als ergänzender
Befehlscode im Befehlscodestrang 34 oder als ergänzender
Operand im Operandenstrang 36 gespeichert sein kann.
-
In
Ausführungsalternativen
kann auch vorgesehen sein, bei der Optimierung statt der Makrodefinitionen 38 eine
geeignete Erweiterung für
das Codemodul 26 zu erzeugen, so daß effektiv der Befehlssatz
der virtuellen Maschine um die benötigten Makrobefehle – die dann
wie native Befehle ausgeführt werden – ergänzt wird.
-
In 3 ist ferner ein Ausschnitt
aus einem ursprünglichen
Programm 52 gezeigt, durch dessen Optimierung das optimierte
Programm 32 und die Makrodefinitionen 38 erzeugt
wurden. Dieser Vorgang ist in 3 durch
zwei dicke Pfeile angedeutet. Das ursprüngliche Programm 52 liegt
in dem für
virtuelle Maschinen nach dem Java-Card-Standard üblicherweise verwendeten Format
vor. In 3 sind zehn
Befehle U1 – U10
des ursprünglichen
Programms 52 gezeigt, die jeweils mit einem Befehlscode
beginnen. Die Befehle U1, U2, U4, U6, U7 und U8 weisen ferner je
einen Parameter auf, der jeweils unmittelbar auf den Befehlscode
folgt.
-
Aufgabe
des Optimierungsvorgangs ist es, Befehlsgruppen zu finden, die im
ursprünglichen
Programm 52 möglichst
häufig
vorkommen und die hinsichtlich ihrer Befehlscodefolgen übereinstimmen.
In 3 sind beispiels weise
zwei solche Befehlsgruppen 54, 56 enthalten, die
jeweils die Befehlscodefolge "ILOAD", "ILOAD", "IADD" aufweisen. Diese
Befehlsgruppen 54, 56 werden bei der Optimierung durch
jeweils einen Makrobefehl im Befehlscodestrang 34 ersetzt,
und ein entsprechender Eintrag 50 in den Makrodefinitionen 38 wird
erzeugt. Die in der Befehlsgruppe 54, 56 enthaltenen
Operanden werden in den Operandenstrang 36 übernommen.
Im Ergebnis wird z.B. der Makrobefehl 46 (2) aus den ursprünglichen Befehlen U1 – U3 gebildet,
und die Operanden der zweiten Befehlsgruppe 56 werden als Operanden
OD5.1 und OD5.2 in den Operandenstrang 36 übernommen.
-
Das
Ziel der Optimierung ist es, möglichst viele
und gleichzeitig möglichst
große übereinstimmende
Befehlsgruppen im ursprünglichen
Programm 52 zu identifizieren. Hier ist in der Regel eine
Abwägung
erforderlich, weil mit steigender Größe normalerweise die Anzahl
der übereinstimmenden
Befehlsgruppen abnimmt. Durch an sich bekannte Techniken – z.B. geeignete
Heuristiken oder Techniken der linearen Programmierung – kann jedoch
eine hinreichend gute Lösung
gefunden werden. Da die Operanden der optimierten Befehlsgruppen 54, 56 nicht übereinzustimmen
brauchen, ist bei praxisnahen Anwendungen eine erhebliche Codegrößenreduktion möglich, die
weit über
die relativ geringe Einsparung bei dem Beispiel von 3 hinausgeht.
-
Befehle
des ursprünglichen
Programms 52, die bei der Optimierung nicht durch Makrobefehle
ersetzt werden konnten, werden in der Regel unverändert in
das optimierte Programm 32 übernommen, wobei eine Aufspaltung
in den Befehlscode und – falls
vorhanden – den
oder die Operanden erfolgt. So entspricht beispielsweise der Befehl 48 (2) dem ursprünglichen
Befehl U4, und der ursprüngliche
Befehl U10 wurde mit dem Befehlscode OC6 unverändert in den Befehlscodestrang 34 übernommen.
-
Eine
Ausnahme von der gerade genannten Regel besteht bei Sprungbefehlen,
deren Zieladressen an die Verwendung des zusammengesetzten Befehlszählers 40 angepaßt werden
müssen.
So wird beispielsweise der Sprungbefehl U6 des ursprünglichen
Programms 52 mit einem Sprungzielversatz von 8 Byte bei
der Optimierung in den Sprungbefehl mit dem Befehlscode OC4 umgewandelt,
der in seinem ersten Operanden OD4.1 einen Versatz von 3 Byte für den ersten
Befehlszähler 42 und
in seinem zweiten Operanden OD4.2 einen Versatz von 4 Byte für den zweiten
Befehlszähler 44 angibt.
Statt dieser relativ einfachen Ausgestaltung kann in Ausführungsalternativen
eine kompaktere Darstellung von Sprungzieladressen vorgesehen sein,
durch die neue Zählerstände der
beiden Befehlszähler 42, 44 mit
möglichst
wenig Speicherbedarf definiert werden können.
-
Es
versteht sich, daß bei
der gesamten Ausführung
des optimierten Programms 32 die Trennung zwischen dem
Befehlscodestrang 34 und dem Operandenstrang 36 sowie
die Existenz von zwei Befehlszählern 42, 44 berücksichtigt
werden muß.
Dies betrifft z.B. auch die Verwaltung von Rücksprungadressen in einem Stapelspeicher
und die Ausführung sonstiger
Befehle, die den Programmfluß steuern.
-
In 4 ist der Vorgang der Programmerzeugung
und -optimierung dargestellt, der mit der bekannten Übersetzung
eines Java-Quellprogramms 58 durch einen Compiler 60 in
eine Klassendatei 62 beginnt. Ein Konverter 64,
der oft auch als "Off-Card Virtual
Machine" bezeichnet
wird, wandelt die Klassendatei 62 – sowie gegebenenfalls benötigte Export-Dateien – in eine
CAP-Datei (CAP = Converted Applet) um. Im vorliegenden Ausführungsbeispiel stellt
die CAP-Datei das ursprüngliche
Programm 52 dar, während
in Ausführungsalternativen
die oben beschriebenen Optimierungsschritte bereits durch den Compiler 60 und/oder
den Konverter 64 durchgeführt werden.
-
Das
ursprüngliche
Programm 52 wird bei der Herstellung oder der Initialisierung
oder der Personalisierung des Datenträgers 10 von einem
externen Ladeprogramm 66 über die Schnittstellenschaltung 14 in
den Datenträger 10 eingespielt.
Das interne Ladeprogramm 30 steuert den Schreibvorgang
in den nicht-flüchtigen
Speicher 20.
-
Im
vorliegenden Ausführungsbeispiel
führt das
interne Ladeprogramm 30 überdies die oben beschriebenen
Optimierungsschritte, also die Erzeugung des optimierten Programms 32 und
der Makrodefinitionen 38 aus dem ursprünglichen Programm 52,
aus. Dies hat den Vorteil, daß die
hier beschriebene Optimierung für
den Anwender völlig
transparent ist; der Datenträger 10 nimmt
also alle üblichen CAP-Dateien
an. In Ausführungsalternativen
kann dagegen die Optimierung des ursprünglichen Programms 52 auch
von dem externen Ladeprogramm 66 oder von einem weiteren
Zusatzprogramm durchgeführt
werden. In diesem Fall wird die Optimierung auf einem externen Computer
ausgeführt,
der in der Regel erheblich höhere
Rechenleistung als der Datenträger 10 zur
Verfügung
stellt.