-
Diese Erfindung betrifft im allgemeinen
Zwischensprachen und insbesondere das Ableiten von Operandentypen
innerhalb solcher Zwischensprachen.
-
Zwischensprachen-Typmodelle für Programmiersprachen
sind zunehmend populär
geworden. In einem Zwischensprachen-Modell wird ein Quellcode im
allgemeinen in eine gewünschte
im wesentlichen Plattform-unabhängige
Zwischensprache kompiliert. Wenn gewünscht wird, dass der Code auf
einer bestimmten Plattform läuft,
interpretiert oder kompiliert dann ein Ausführungsmechanismus auf der Plattform den
Zwischensprachencode in systemeigenen Code, der für die Plattform
verständlich
ist. Beispiele von Systemen, die Zwischensprachen verwenden, schließen die
virtuelle Java-Maschine ein.
-
Das Dokument "Code Generation Using
an Orthogonal Model"; James R. Cordy, Richard C. Holt; SOFTWARE – PRACTICE
AND EXPERIENCE; Vol. 20(3), 301–320
(März 1990)
zeigt ein abstraktes Modellverfahren, um Quellcode einer oder mehrerer Programmiersprachen
in solch eine Zwischensprache zu übersetzen. Insbesondere beschreibt
das Dokument einen Ansatz, um Quellcode zu übersetzen, der eine Implementation
von Operatoren der Sprachebene und Adressoperatoren (Operanden)
zeigt, indem ein Satz an Implementationsvorlagen für jeden Operator
(oder Quellcode-Merkmal) kodiert wird, die auf der Bewertung der
Operanden in Verbindung mit Entscheidungsbäumen und Einschränkungen
für die Anwendung
von Entscheidungsbäumen
basiert. Der Übersetzungsprozess
wird durch zwei unabhängige Bearbeitungssequenzen
bearbeitet, wobei jede einen Satz an Entscheidungsbäumen für die Kodierung
verwendet, wobei jeder den Operatoren der Sprachebene bzw. Adressoperatoren
gewidmet ist. Das dargestellte Verfahren zum Codeerzeugen ist auf
eine Plattformunabhängigkeit über eine
große Zahl
an verschiedenen Zielcomputern erweiterungsfähig.
-
Es soll als ein Beispiel eines systemeignen Codes
bemerkt werden, dass Prozessoren wie zum Beispiel Stand der Technik
Prozessoren vom x86-Typ im allgemeinen eine separate Anweisung für eine Operation
benötigen,
wenn die Operation auf jeweils unterschiedliche Datentypen angewendet
wird. Zum Beispiel wird eine "add" Operation eine separate "add-integer"
Anweisung für
Ganzzahl-Datentypen und eine "add real" Anweisung für reelle
(d. h. Fließkomma-)
Datentypen aufweisen. Andere Datentypen, für die separate Anweisungen
benötigt
werden können,
schließen
"short" (bzw. kurze) Ganzzahlen, "long" (bzw. lange) Ganzzahlen
etc. ein.
-
Ausführungsgeschwindigkeit und Codegröße sind
wichtige Überlegungen
bei der Verwendbarkeit von in irgendeiner Programmiersprache beschriebenem
Code im allgemeinen und in einer Zwischensprache im besonderen.
Diese zwei Größen vertragen
sich im allgemeinen nicht miteinander. Da zum Beispiel Zwischensprachen-Code
im allgemeinen in systemeigenen Code kompiliert wird, wenn er ausgeführt wird,
ist seine Ausführungsgeschwindigkeit
normalerweise langsamer als vergleichbare Programme, die in systemeigenen
Code vor-kompiliert sind. Wenn verglichen mit traditionelleren Computerprogrammen
ist der Zwischensprachen-Code auf der anderen Seite geeigneter,
um in einer kleinen Konsumentenelektronik-Vorrichtung (bzw. Unterhaltungselektronik-Vorrichtung)
gespeichert zu werden, und für eine Übertragung über das
Internet geeigneter vorgesehen, wobei die Codegröße sich als eine wichtigere
Größe in der
Verwendbarkeit des Zwischensprachen-Codes als verglichen mit mehr
systemeigenen Computerprogrammen erweist, die normalerweise zum
Beispiel auf voluminösen
CD-ROMs und Festplattenlaufwerken gespeichert sind.
-
Wie die meisten Computersprachen
weisen Zwischensprachen Anweisungssätze auf, wobei jede Anweisung
einen entsprechenden "Befehlscode" bzw. "Opcode" aufweist, der die
Anweisung identifiziert. Zur Ausdrucksfähigkeit und zur Einfachheit
der Programmierung ist eine große
Zahl an Anweisungen und damit entsprechenden Befehlscodes wünschenswert.
Wenn jedoch mehr als 256 Anweisungen oder Befehlscodes vorhanden
sind, bedeutet das, dass mehr als ein Byte notwendig ist, um jede Anweisung
zu identifizieren. Wenn mehr als 256 Anweisungen gewünscht werden,
muss also ein anderes Byte zugefügt
werden, um jeden Befehlscode zu identifizieren.
-
Wenn ein umfangreicherer Anweisungssatz ermöglicht wird,
sind jedoch mehr als 256 Anweisungen nachteilig, wenn die Ausführungsgeschwindigkeit
und die Codegröße berücksichtigt
werden. Wenn jede Anweisung zwei Bytes anstatt einem Byte beansprucht,
wird die Größe des resultierenden
Codes vergrößert. Überdies
impliziert die Extragröße mehr Speicherzugriffe
(Seitenfehler) und benötigt
somit länger
als Verarbeitungsanweisungen, die eine kürzere Länge aufweisen. Es gibt also
einen Bedarf für einen
robusten Anweisungssatz, der trotzdem für die Ausführungsgeschwindigkeits- und
die Codegrößen-Vorteile
sorgt, die Ein-Byte-Befehlscodes
vorsehen. Aus diesen und anderen Gründe gibt es einen Bedarf für die vorliegende
Erfindung.
-
Die Erfindung ist in den angefügten Ansprüchen definiert
und betrifft ein Ableiten von Operanden-Typen innerhalb einer Zwischensprache.
In einer Ausführungsform
gibt ein Computer-implementiertes Verfahren zuerst einen Zwischensprachen-Code
ein, der typ- indefinite
Befehlscodes einschließt.
Das Verfahren übersetzt
den Eingabecode in einen zweiten Strom an Befehlscodes, in dem die
Typen jedes Typ-indefiniten Befehlscodes kontextuell abgeleitet wurden.
Das Verfahren erzeugt schließlich
systemeigenen Code aus dem Typ-Befehlscode-Strom.
-
In einer Ausführungsform zum Beispiel kann ein
schon im Zwischensprachen-Code vorliegendes Programm eine "add"
Anweisung aufweisen, um zwei Zahlen wie 4 und 5 oder 4,5 und 5,5
zu addieren. In dem ersteren Fall sind beide dieser Zahlen Ganzzahlen,
während
in dem letzteren Fall beide reelle Zahlen sind. Deshalb würde eine
Ausführungsform
der Erfindung bemerken, dass in dem ersten Fall die Addieranweisung
ein Addieren zweier Granzzahlen ist und würde diese Anweisung in eine
spezifische "add integer" Anweisung auflösen – während in dem letzteren Fall
die Ausführungsform
bemerken würde,
dass die Addieranweisung ein Addieren zweier reeller Zahlen ist
und die Anweisung in eine spezifische "add real" Anweisung auflösen würde, die
eine zu der "add integer" Anweisung verschiedene Anweisung ist.
Wenn systemeigener Code erzeugt wird, der der spezifische durch
den Prozessor des Computers ausgeführte Code ist, würde zum
Beispiel das Verfahren deshalb einen entsprechenden systemeigenen
"add integer" Befehlscode für
die typisierte "add integer" Anweisung und einen entsprechenden
systemeigenen "add real" Befehlscode für die typisierte "add real"
Anweisung erzeugen.
-
Die Erfindung liefert Vorteile, die
nicht in dem Stand der Technik gefunden werden. Zum Beispiel ermöglicht die
Erfindung einen robusten Anweisungssatz, der weiterhin eine relativ
geringe Gesamtzahl an Befehlscodes aufweist. Zum Beispiel benötigt eine
Ausführungsform
der Erfindung eher als eine "add" Anweisung für jeden Typ von Operand – z. B. eine
"add floating point (real)" Anweisung, eine "add short (integer)"
Anweisung, eine "add long (integer)" Anweisung, eine "add integer"
Anweisung etc. –, stattdessen
nur eine einzelne "add" Anweisung, da der spezifische Typ dieser
Anweisung später
durch die Erfindung aufgelöst
wird. Ein Anweisungssatz kann deshalb weiterhin robust sein, während nichtsdestotrotz
nur ein einzelnes Byte verwendet wird, um jeden Befehlscode zu identifizieren – wobei
dadurch die Geschwindigkeits- und Größenvorteile gewährleistet
sind, die aus Verwendung eines einzelnen Bytes resultieren.
-
Die Erfindung schließt Computer-implementierte
Verfahren, Maschinen-lesbare Medien, computerisierte Systeme, Vorrichtungen
und Computer variierender Schutzbereiche ein. Andere Aspekte, Ausführungsformen
und Vorteile der Erfindung neben jenen hier beschriebenen werden
durch Lesen der dealliierten Beschreibung und unter Bezugnahme auf die
Zeichnungen ersichtlich werden.
-
1 ist
ein Diagramm einer Betriebsumgebung, in Verbindung mit der Ausführungsformen
der Erfindung angewendet werden können;
-
2 ist
ein Diagramm einer Zwischensprachen-Umgebung gemäß einer Ausführungsform
der Erfindung, von der ein Teil davon innerhalb eines Systems oder
einer Vorrichtung gemäß einer
Ausführungsform
der Erfindung implementiert werden kann;
-
3 ist
ein Diagramm, das den Betrieb einer Ausführungsform der Erfindung darstellt;
-
4 ist
ein Diagramm. das darstellt, wie ein gegenwärtiger Typstatus eine Funktion
eines Anweisungszeigers gemäß einer
Ausführungsform
der Erfindung ist; und
-
5 ist
ein Flussdiagramm gemäß einer Ausführungsform
der Erfindung.
-
In der folgenden detaillierten Beschreibung exemplarischer
Ausführungsformen
der Erfindung wird Bezug zu den begleitenden Zeichnungen genommen,
die ein Teil davon bilden und in denen in beispielhafter Darstellung
spezifische exemplarische Ausführungsformen
gezeigt sind, in denen die Erfindung angewendet werden kann. Diese
Ausführungsformen
werden in ausreichendem Detail beschrieben, um Fachleuten zu ermöglichen,
die Erfindung anzuwenden und es soll verstanden werden, dass andere
Ausführungsformen
genutzt werden können und
dass logische, mechanische, elektrische und andere Änderungen
durchgeführt
werden können
ohne den Schutzbereich der vorliegenden Erfindung zu verlassen.
Die folgende detaillierte Beschreibung ist daher nicht in einem
limitierenden Sinne zu erfassen und der Schutzbereich der vorliegenden
Erfindung wird nur durch die angehängten Ansprüche definiert.
-
Einige Teile der folgenden detaillierten
Beschreibungen werden in Form von Algorithmen und symbolischen Darstellungen
von Operationen an Datenbits innerhalb eines Computerspeichers gezeigt. Diese
algorithmischen Beschreibungen und Darstellungen sind die Mittel,
die von Fachleuten in der Datenverarbeitung verwendet werden, um
den Gehalt ihrer Arbeit anderen Fachleuten am effektivsten zu vermitteln.
Ein Algorithmus ist hier und im allgemeinen sich vorzustellen, eine
selbst-konsistente Abfolge an Schritten zu sein, die zu einem gewünschten Resultat
führt.
Die Schritte sind diejenigen, die physikalische Manipulationen an
physikalischen Größen erfordern.
Gewöhnlicherweise
aber nicht notwendigerweise nehmen diese Größen die Form elektrischer oder
magnetischer Signale ein, die geeignet sind, gespeichert, übertragen,
kombiniert, verglichen und anders manipuliert zu werden.
-
Es hat sich günstigerweise mit der Zeit prinzipiell
aus Gründen
des gemeinsamen Gebrauch erwiesen, diese Signale als Bits, Werte,
Symbole, Zeichen, Terme, Zahlen oder dergleichen zu bezeichnen.
Es soll jedoch nicht vergessen werden, dass alle diese und ähnliche
Ausdrücke
mit den geeigneten physikalischen Größen zu assoziieren sind und
lediglich günstige
Bezeichnungen sind, die auf diese Größen angewendet werden. Wenn
nicht anders als aus den folgenden Diskussionen ersichtlich spezifisch dargelegt,
soll verstanden werden, dass in der ganzen vorliegenden Erfindung
Diskussionen, die Ausdrücke
wie zum Beispiel Bearbeiten oder Datenverarbeiten oder Berechnen
oder Bestimmen oder Anzeigen oder dergleichen sich auf die Aktion
und Prozesse eines Computersystems oder ähnlicher elektronischer Datenverarbeitungsvorrichtungen
beziehen, die Daten, die als physikalische (elektronische) Größen innerhalb
der Register des Computersystems und Speicher dargestellt werden,
in andere Daten manipulieren oder umwandeln, die ebenso als physikalische
Größen innerhalb
der Computersystem-Speichern oder Registern oder anderer derartiger
Informationsspeicher, Übertragungs-
oder Anzeigevorrichtungen dargestellt werden.
-
Betriebsumgebung
-
Unter Bezugnahme auf 1 wird ein Diagramm der Hardware und
Betriebsumgebung gezeigt, in Verbindung mit denen Ausführungsformen der
Erfindung angewendet werden können.
Die Beschreibung von 1 ist
bestimmt, eine kurze allgemeine Beschreibung geeigneter Computerhardware und
einer geeigneten Datenverarbeitungsumgebung bereitzustellen, in
Verbindung mit denen die Erfindung implementiert sein kann. Obwohl
nicht benötigt, wird
die Erfindung in dem allgemeinen Kontext Computer-ausführbarer
Anweisungen, wie zum Beispiel Programmmodule beschrieben, die durch
einen Computer ausgeführt
werden, wie zum Beispiel einen Personalcomputer. Programmmodule
schließen im
allgemeinen Routinen, Programme, Objekte, Komponenten, Datenstrukturen
etc. ein, die bestimmte Aufgaben durchführen oder bestimmte abstrakte
Datentypen implementieren.
-
Zudem werden Fachleute verstehen,
dass die Erfindung mit anderen Computersystemkonfigurationen angewendet
werden kann, die programmierbare Konsumentenelektronik (bzw. Unterhaltungselektronik),
Netzwerk-PCs, Minicomputer, Großrechner
und dergleichen einschließen.
Die Erfindung kann ebenso in verteilten Datenverarbeitungsumgebungen
angewendet werden, in denen Aufgaben durch Fern-Verarbeitungsvorrichtungen
durchgeführt werden,
die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten
Datenverarbeitungsumgebung können
Programmmodule in sowohl lokalen als auch Fern-Speichervorrichtungen lokalisiert sein.
-
Die exemplarische Hardware und Betriebsumgebung
von 1 zur Implementierung
der Erfindung schließt
eine Allzweck-Datenverarbeitungsvorrichtung in der Form eines Computers 20 ein,
der eine Verarbeitungseinheit 21, ein Systemspeicher 22 und
ein Systembus 23 einschließt, der verschiedene Systemkomponenten
operativ koppelt, die den Systemspeicher bis zu der Verarbeitungseinheit 21 einschließen. Es
kann nur eine oder es kann mehr als eine Verarbeitungseinheit 21 vorhanden sein,
so dass der Prozessor von Computer 20 eine einzelne Zentralverarbeitungseinheit
(CPU) oder eine Vielzahl an Verarbeitungseinheiten umfasst, auf die
herkömmlich
als eine Parallel-Verarbeitungsumgebung Bezug genommen wird. Der
Computer 20 kann ein herkömmlicher Computer, ein verteilter Computer
oder irgendein anderer Computertyp sein; die Erfindung ist nicht
derart beschränkt.
-
Der Systembus 23 kann irgendeine
von mehreren Typen an Busstrukturen sein, die einen Speicherbus
oder Speichersteuereinheit, einen Peripheriebus und einen lokalen
Bus einschließen,
der irgendeine einer Auswahl an Busarchitekturen verwendet. Auf
den Systemspeicher kann ebenso einfach als Speicher Bezug genommen
werden und schließt
Nur-Lese-Speicher (ROM) 24 und Speicher mit wahlfreiem
Zugriff (RAM) 25 ein. Ein grundlegendes Eingabe-/Ausgabe-System (BIOS) 26,
das die grundlegenden Routinen enthält, die helfen, Informationen
zwischen Elementen innerhalb des Computers 20 zu übertragen,
wie zum Beispiel während
des Starts, ist in dem ROM 24 gespeichert. Der Computer 20 schließt ferner
ein Festplattenlaufwerk 27 zum Lesen von und Schreiben
auf eine Festplatte, nicht gezeigt, ein Magnetplattenlaufwerk zum
Lesen von oder Schreiben auf eine wechselbare Magnetplatte 29 und
ein optisches Plattenlaufwerk 30 zum Lesen von oder Schreiben
auf eine wechselbare optische Platte 31 wie zum Beispiel
eine CD ROM oder andere optischen Medien ein.
-
Das Festplattenlaufwerk 27,
Magnetplattenlaufwerk 28 und optische Plattenlaufwerk 30 sind durch
ein Interface 32 für
ein Festplattenlaufwerk, ein Interface 33 für ein Magnetplattenlaufwerk
bzw. ein Interface 34 für
ein optisches Plattenlaufwerk mit dem Systembus 23 verbunden.
Die Laufwerke und ihre zugeordneten Computer-lesbaren Medien stellen
nicht-flüchtigen
Speicher von Computer-lesbaren Anweisungen, Datenstrukturen, Programmmodulen oder
anderer Daten für
den Computer 20 bereit. Es soll von Fachleuten verstanden
werden, dass irgendein Typ an Computer-lesbaren Medien, die Daten
speichern können,
die durch einen Computer zugreifbar sind, wie zum Beispiel Magnetkassetten, Flash-Speicherkarten,
digitale Videodisks, Bernoulli-Cartridges,
Speicher mit wahlfreiem Zugriff (RAMs), Nur-Lese-Speicher (ROMs)
und dergleichen in der exemplarischen Betriebsumgebung verwendet werden
kann.
-
Eine Zahl an Programmmodulen kann
auf der Festplatte, Magnetplatte 29, optischen Platte 31, ROM 24 oder
RAM 25 gespeichert sein, die ein Betriebssystem 35,
ein oder mehrere Anwendungsprogramme 36, andere Programmmodule 37 und
Programmdaten 38 einschließen. Ein Benutzer kann Kommandos
und Informationen in den Personalcomputer 20 durch Eingabevorrichtungen
wie zum Beispiel eine Tastatur 40 und eine Zeigervorrichtung 42 eingeben.
Andere Eingabevorrichtungen (nicht gezeigt) können ein Mikrophon, Joystick, Gamepad, Satellitenschüssel, Scanner
oder dergleichen einschließen.
Diese und andere Eingabevorrichtungen werden oft mit der Verarbeitungseinheit 21 durch
ein Interface 46 für
einen seriellen Anschluss verbunden, das mit dem Systembus gekoppelt
ist, können
aber durch andere Interfaces wie zum Beispiel einen parallelen Anschluss,
Spiel-Anschluss bzw. Gameport, oder universeller serieller Bus (USB)
verbunden werden. Ein Monitor 47 oder anderer Typ an Anzeigevorrichtung
ist ebenso mit dem Systembus über
ein Interface wie zum Beispiel ein Video-Adapter 48 verbunden.
Zusätzlich
zu dem Monitor schließen
Computer typischerweise andere periphere Ausgabevorrichtungen (nicht
gezeigt) wie zum Beispiel Lautsprecher und Drucker ein.
-
Der Computer 20 kann in
einer vernetzten Umgebung unter Verwendung von logischen Verbindungen
mit einem oder mehreren Computern wie zum Beispiel einem Fern-Computer 49 betrieben werden.
Diese logischen Verbindungen können durch
eine Kommunikationsvorrichtung erzielt werden, die an den oder an
einen Teil des Computers 20 gekoppelt sind; die Erfindung
ist nicht auf einen bestimmten Typ an Kommunikationsvorrichtung
beschränkt.
Der Fern-Computer 49 kann ein anderer Computer, ein Server,
ein Router, ein Netzwerk-PC, ein Client, eine Peer-Vorrichtung oder
ein anderer allgemeiner Netzwerkknoten sein und schließt typischerweise
viele oder alle der Elemente ein, die vorstehend bezüglich des
Computers 20 beschrieben sind, obwohl nur eine Speichervorrichtung 50 in 1 illustriert wurde. Die
logischen Verbindungen, die in 1 dargestellt
sind, schließen
ein lokales Netzwerk (LAN) 51 und ein Weitverkehrsnetzwerk (WAN) 52 ein.
Solche Netzwerkumgebungen sind alltäglich in Büronetzwerken, Unternehmens-weiten Computernetzwerken,
Intranets und dem Internet, die alle Typen von Netzwerken sind.
-
Der Computer 20 ist, wenn
in einer LAN-Netzwerkumgebung eingesetzt, mit dem lokalen Netzwerk 51 durch
ein Netzwerk-Interface oder Adapter 53 verbunden, das/der
ein Typ einer Kommunikationsvorrichtung ist. Der Computer 20 schließt typischerweise,
wenn in einer WAN-Netzwerkumgebung
verwendet wird, ein Modem 54, ein Typ einer Kommunikationsvorrichtung
oder irgendeinen anderen Typ einer Kommunikationsvorrichtung zum
Aufbauen von Kommunikation über
das Weitverkehrsnetzwerk 52 wie zum Beispiel das Internet
ein. Das Modem 54, das ein internes oder externes sein
kann, ist mit dem Systembus 23 über das Interface 46 für den seriellen
Port verbunden. In einer vernetzten Umgebung können Programmmodule, die bezüglich des
Personalcomputers 20 dargestellt sind, oder Teile davon
in der Fern-Speichervorrichtung
gespeichert werden. Es wird verstanden, dass die gezeigten Netzwerkverbindungen
beispielhaft sind und andere Mittel für und Kommunikationsvorrichtungen
zum Ausbauen einer Kommunikationsverbindung zwischen den Computern
verwendet werden können.
-
Zwischensprachenumgebung
-
In diesem Abschnitt ist in der Beschreibung ein Überblick über eine
Zwischensprachenumgebung gemäß einer
Ausführungsform
der Erfindung bereitgestellt. Unter Bezug auf 2 ist ein Diagramm einer Zwischensprachenumgebung
gemäß einer
Ausführungsform
der Erfindung gezeigt. Die Umgebung von 2 schließt einen Ausführungsmechanismus 200 ein,
von dem ein just-in-time (JIT) Compiler 202 Teil ist. Vielfache
Quellcode-Sprachenquellen wie zum Beispiel Visual Basic (VB), Visual C++
(CV++) und andere Quellen werden durch Compiler wie zum Beispiel
Compiler 204 in Zwischensprachen (IL) Code kompiliert.
Der Ausführungsmechanismus 200 kompiliert,
interpretiert oder just-in-time kompiliert dann mittels eines Mechanismus
wie zum Beispiel ein Compiler, Interpreter oder just-in-time Compiler
(der letztere, der der spezifische in 2 gezeigte
Fall ist, als Folge der Einschließung des JIT Compilers 202 in
den Mechanismus 200) den IL-Code in ausführbaren
Code (basierend auf dem Zwischencode), der systemeigen für eine bestimmte Plattform
ist. Dieser ausführbare
Code wird ebenfalls als systemeigener Code bezeichnet. Das heißt, dass der
Ausführungsmechanismus 200 den
Zwischensprachencode in den ausführbaren
Code zur Ausführung übersetzt. Überdies
schließt
in einer Ausführungsform
der Ausführungsmechanismus 200 einen Mechanismus
ein, um einen typ-indefiniten Befehlscode eines IL-Codes in einen
typisierten Befehlscode aufzulösen,
wie in folgenden Abschnitten der detaillierten Beschreibung beschrieben.
Der Mechanismus ist in einer Ausführungsform Teil des Compilers 202.
-
Jeder der Compiler 204,
des Ausführungsmechanismus 200 und
der Bestandteile des Ausführungsmechanismus
(wie zum Beispiel Compiler 202) kann in einer Ausführungsform
ein Computerprogramm sein, das durch einen Prozessor von einem Computer-lesbaren
Medium wie zum Beispiel einem Speicher ausgeführt wird. Compiler wie zum
Beispiel Compiler 204 sind im Stand der Technik bekannt.
Jeder der Vielfachen Quellcode-Sprachenquelle, des IL-Codes und
des ausführbaren
Codes kann in einer Ausführungsform
als Daten auf einem Computer-lesbaren Medium wie zum Beispiel einem
Speicher oder einem Festplattelaufwerk gespeichert sein. Die Erfindung
ist jedoch nicht derart beschränkt.
-
In einer Ausführungsform ist der Ausführungsmechanismus 200 Teil
eines Systems, das nicht die Compiler 204 einschließt, so dass
die Compiler 204 den Quellcode in IL-Code vor-kompilieren, der
dann auf einem Computer-lesbaren Medium innerhalb des Systems gespeichert
wird. In einer anderen Ausführungsform
sind der Ausführungsmechanismus
und seine Bestandteile Teil einer Vorrichtung, wie zum Beispiel
des in dem nachfolgenden Abschnitt der detaillierten Beschreibung
beschriebenen Computers. Andere Vorrichtungen, die zu der Erfindung
ergänzbar sind,
umfassen: eine Set-Top-Box für
ein Fernsehgerät,
eine von Hand haltbare Vorrichtung (Handheld), ein Fernsehgerät, eine
Konsumentenelektronik-Vorrichtung, ein Laptop-Computer, ein von
Hand haltbarer Computer, ein Hilfsmittel, ein Desktop-Computer und
eine Automobilelektronik-Vorrichtung. Die Erfindung ist nicht derart
beschränkt.
Solche Vorrichtung umfassen typischerweise einen Prozessor und ein
Maschinen-lesbares Medium, wie zum Beispiel einen Speicher, so dass
der Ausführungsmechanismus 200 und
seine Bestandteile von dem Medium durch den Prozessor ausgeführt werden.
-
Überblick
-
In diesem Abschnitt der detaillierten
Beschreibung wird ein Überblick
beschrieben, über
wie zumindest einige Ausführungsformen
der Erfindung arbeiten. Diese Beschreibung bildet eine Grundlage zum
Verständnis
von Verfahren und Systemen verschiedenen Ausführungsformen der Erfindung,
die in den folgenden Abschnitten der detaillierten Beschreibung
vorgestellt werden. Der Überblick
wird unter Bezug auf 3 und 4 beschrieben.
-
Als Hintergrund wird zuerst die Formulierung "Typstatus"
beschrieben. Der gegenwärtige
Typstatus betrifft im allgemeinen in einer Ausführungsform eine oder mehrere
von: dem Typstatus eines Befehlscode-Stapelspeichers, wie er gegenwärtig für ein Verfahren
(so wie der Ausdruck Verfahren innerhalb des Stands der Technik
bekannt ist) existiert, der Typstatus der Argumente für das Verfahren
(so wie solche Argumente innerhalb des Stands der Technik bekannt
sind) und der Typstatus der lokalen Variablen für das Verfahren (so wie solche
Variablen innerhalb des Stands der Technik bekannt sind). Es ist
zu bemerken, dass die letzten zwei Typstatus über die Bestandsdauer einer
Instantiierung des Verfahrens festgelegt sind.
-
Umgekehrt ändert sich der Typstatus des
Befehlscode-Stapelspeichers kontinuierlich, wenn eine Instantiierung
des Verfahrens läuft.
Zum Beispiel bei Start mit einem frischen (leeren) Stapelspeicher, wenn
zwei Ganzzahlen auf den Stapelspeicher "geschoben" werden, dann
ist der Typstatus dieses Stapelspeichers derart, dass die ersten
zwei Plätze
des Stapelspeichers vom Typ Ganzzahl sind. Die Werte der Ganzzahlen
sind jedoch für
den gegenwärtigen Typstatus
nicht wichtig – nur
die Typen der Daten selbst sind für Ausführungsformen der Erfindung wichtig.
Der Typstatus des Stapelspeichers ist daher ständig wechselnd, insofern als
kontinuierlich Werte auf den Stapelspeicher "geschoben" und von
dem Stapelspeicher "entnommen" werden, wie im Stand der Technik
bekannt. Wie nachfolgend beschrieben wird der gegenwärtige Typstatus
verwendet, um zumindest einige Ausführungsformen der Erfindung
zu implementieren.
-
In einer Ausführungsform wird der gegenwärtige Typstatus
wie folgt bestimmt. Da der Typstatus der Argumente für ein Verfahren
und der Typstatus der lokalen Variablen für das Verfahren festgelegt sind,
können
diese Typstatus durch Bezugnahme auf ein entsprechendes Feld bzw.
Array bestimmt werden. Zum Beispiel könnte ein Feld an Argumenten existieren,
so dass durch Heraussuchen eines spezifischen Arguments sein Typ
bereitgestellt wird und es könnte
ein Feld an lokalen Variablen existieren, so dass durch Heraussuchen
einer lokalen Variablen ihr Typ bereitgestellt wird. Überdies
wird die Bestimmung des Typstatus des Stapelspeichers durch Überprüfen des
Stapelspeichers selbst oder durch Heranziehen einer Funktion des
Typstatus des Stapelspeichers als eine Funktion des Anweisungszeigers
(so wie der Ausdruck Anweisungszeiger innerhalb des Stands der Technik
bekannt ist) erreicht, wie später
in der detaillierten Beschreibung beschrieben wird. Es ist jedoch
zu bemerken und wie von Fachleuten verstanden werden kann, dass
die Erfindung nicht speziell auf eine spezifische Weise den gegenwärtigen Typstatus
zu bestimmen beschränkt
ist.
-
Zuerst bezugnehmend auf 3 wird ein Diagramm gezeigt,
das die Arbeitsweise einer Ausführungsform
der Erfindung illustriert. In 300 tritt ein Befehlscode
für eine
Anweisung innerhalb der Zwischensprache auf. Im Detail tritt der
Befehlscode für die
typ-indefinite Anweisung ADD (bzw. ADDIERE) auf. Die Anweisung ADD
ist typ-indefinit, derart dass sie nicht den Typ der Operanden spezifiziert,
die sie bearbeiten wird. Das heißt, sie ist nicht ein Befehlscode,
der spezifisch auf einen bestimmten Typ an Operand wie zum Beispiel
ADD_R8, ADD_I4 (d. h. kurze Ganzzahl mit einer Länge von vier Bytes), ADD_I8
(d. h. lange Ganzzahl mit einer Länge von acht Bytes), ADD_INTEGER
(d.h. Ganzzahlen, die eine durch den Zielcomputer bestimmte Größe aufweisen)
etc. gerichtet ist. Mittels Vergleich sind Anweisungen wie zum Beispiel
ADD_R8, ADD_I4, ADD_I8, ADD_INTEGER typisierte Anweisungen, da sie
den bestimmten benötigten
Typ an Operanden spezifizieren (z. B. Fließkommazahl, kurze Ganzzahl, lange
Ganzzahl, Ganzzahl etc.).
-
Die Operanden für die ADD Anweisung in 300 sind
I1 und I2, die eine Kurzformel für
eine erste Ganzzahl bzw. eine zweite Ganzzahl sind. In 302 werden
diese Operanden auf einen Stapelspeicher 304 geschoben.
I1 wird zuerst darauf geschoben und befindet sich deshalb schließlich in
dem zweiten Platz 306 des Stapelspeichers 304,
während
I2 später
darauf geschoben wird und sich deshalb in dem obersten Platz 308 des
Stapelspeichers 304 befindet. Wenn die ADD Anweisung zu
kompilieren oder in systemeigenen Code zu interpretieren ist – das heißt, wenn
ein entsprechender systemeigener Code für den Zwischensprachen-Befehlscode
für die
ADD Anweisung zu erzeugen ist – ist
der gegenwärtige
Typstatus daher derart, dass der Stapelspeicher 304 in jedem
der Plätze 306 und 308 Ganzzahlen
aufweist.
-
In 310 werden die Typen
der Operanden abgeleitet, die durch die ADD Anweisung bearbeitet werden.
Dies erfolgt in einer Ausführungsform
durch indirektes Ableiten des Typs der Operanden auf dem Stapelspeicher 304 – das heißt, der
Typ der Operanden in Plätzen 306 und 308 – zum Beispiel
durch Untersuchung des gegenwärtigen
Typstatus, wenn die ADD Anweisung auftritt, um in systemeigenen
Code zu kompilieren und eventuell auszuführen. Das heißt, in einer
Ausführungsform
wird der Stapelspeicher selbst nicht direkt untersucht, sondern
eher die Operanden darauf werden durch Kenntnis eines Typstatus
indirekt abgeleitet, wenn die bestimmte ADD Anweisung auftritt.
-
In 312 wird die typ-indefinite
ADD Anweisung in eine typisierte ADDI (addiere Ganzzahlen) Anweisung
basierend auf der Ableitung, die in 310 durchgeführt wurde,
aufgelöst.
Das heißt,
die Anweisung wird basierend auf dem Typ der zu bearbeitenden Operanden
wie in 310 abgeleitet typisiert. Da die Operanden auf dem
Stapelspeicher 304 selbst Ganzzahlen sind, das heißt, dass
die typ-indefinite ADD Anweisung bedeutet, Ganzzahlen zu addieren,
und deshalb wird sie in eine typisierte ADDI Anweisung aufgelöst. Die
Auflösung
typ-indefiniter Anweisungen in typisierte Anweisungen wird ebenfalls
als eindeutig Machen bezeichnet, da eine mehrdeutige Anweisung in
eine nicht-mehrdeutige Anweisung eindeutig gemacht wird. In 3 wird nicht gezeigt, dass
ein typisierter systemeigener Code dann erzeugt wird, der dem typisierten
IL-Code entspricht.
-
Wie in dieser Beschreibung unter
Bezugnahme auf 3 bemerkt,
ist ein wichtiger Aspekt des Auflösens typ-indefiniter Anweisungen
zu typisierten Anweisungen in einer Ausführungsform der Erfindung die
Ableitung der Operanden auf dem Stapelspeicher, wenn eine bestimmte
typ-indefinite Anweisung
in systemeigenen Code zu kompilieren ist. Wie in der Beschreibung
von 310 Bezug genommen benötig dies nicht notwendigerweise
eine direkte Untersuchung des Stapelspeichers, vielmehr kann der
gegenwärtige
Typstatus des Stapelspeichers indirekt abgeleitet werden. Diese
indirekte Ableitung des Typstatus der Operanden auf dem Stapelspeicher,
so dass eine typ-indefinite Anweisung in eine typisierte Anweisung
aufgelöst
werden kann, wird nun detaillierter beschrieben.
-
Unter Bezugnahme auf 4 wird ein Diagramm gezeigt, das illustriert,
wie der gegenwärtige Typstatus
eine Funktion eines Anweisungszeigers gemäß einer Ausführungsform
der Erfindung ist. Der IL-Code 400 ist der Code, der just-in-time
in systemeigenen (d. h. ausführbaren)
Code zu kompilieren ist, der dann ausgeführt werden kann. Ein Anweisungszeiger
(oder IP) 402 zeigt auf die gegenwärtige Anweisung innerhalb des
IL-Codes 400, die für
die Kompilierung berücksichtigt
wird. Der Anweisungszeiger 402 ist daher geeignet, auf
eine Anweisung innerhalb des IL-Codes 400 von Anfang bis
Ende Bezug zu nehmen.
-
Für
indirekte Ableitung des Typstatus der Operanden auf dem Stapelspeicher,
der Teil des gegenwärtigen
Typstatus wie beschrieben wurde ist, muss eine Invariante bezüglich des
IL-Codes in einer Ausführungsform
Gültigkeit
haben. Diese Invariante ist, dass der Typstatus des Systems unabhängig von dem
Pfad ist, der durch den IL-Code 400 genommen wird. Das
heißt,
ungeachtet der Reihenfolge, in der die Anweisungen innerhalb des
IL-Codes 400 verarbeitet werden, verbleit der Typstatus
der Operanden auf dem Stapelspeicher bei irgendeiner gegebenen Anweisung
immer der Gleiche. Wenn eine bestimmte Anweisung auftritt, wird
diese in anderen Worten immer Operanden des selben Typs bearbeiten.
-
Wie dargelegt ist diese Invariante
anders ausgedrückt,
dass der Typstatus des Systems eine Funktion des Anweisungszeigers 402 ist.
Wann immer der Anweisungszeiger 402 auf eine bestimmte Anweisung
innerhalb des IL-Codes 400 zeigt, ist der Typstatus des
Systems immer der Gleiche. Dies wird in 4 als eine gepunktete Linie 404 zu
dem Kreis 406 dargestellt, der den Typstatus der Operanden
auf dem Stapelspeicher für
den IP 402 darstellt, der auf eine gegebene Anweisung innerhalb
des IL-Codes 400 zeigt.
-
In einer Ausführungsform wird daher, wenn Zwischensprachen-Anweisungen
verwendet werden, ein Stapelspeicher an Typen kontinuierlich aktualisiert.
In anderen Worten, der Typstatus des Systems wird, solange eine
Funktion des IP-Zeigers, so dass er für jede Anweisung fest ist,
auf die durch den IP-Zeiger gezeigt wird, an der Verwendung eines
Stapelspeichers in dieser Ausführungsform
wie in dem Überblick
beschrieben wurde erkannt, der sich jedes Mal ändert, wenn der IP-Zeiger auf
verschiedene Anweisungen innerhalb des IL-Codes zeigt. Wenn eine typ-indefinite Anweisung
wie zum Beispiel ADD auftritt, sind die Informationen, die notwendig
sind, um die Anweisung in eine typisierte Anweisung aufzulösen, schon
auf den Typ-Stapelspeicher
vorhanden – und
der Stapelspeicher muss somit nicht direkt untersucht werden. In
anderen Worten sorgt der Unterhalt eines Typ-Stapelspeichers für ein Ableiten
des Typs der Operanden für
eine bestimmte typ-indefinite Anweisung in einer indirekten Weise.
Es ist zu bemerken, dass der Typstatus verwendet werden kann, um ebenso
den nächsten
Typstatus zu bestimmen.
-
Es ist ebenfalls zu bemerken, dass
eine notwendige Folgerung der Invarianten, dass der Typstatus des
Systems Pfad-unabhängig
ist, in einer Aufführungsform
der Erfindung ist, dass für
jede Anweisung der Typ irgendwelcher Werte, die auf dem Stapelspeicher
abgelegt sind, eine Eigenschaft der Anweisung alleine ist – und nicht
eine Funktion der Werte auf dem Stapelspeicher sein kann. Zum Beispiel
ist eine PUSH_VARIANT Anweisung nicht erlaubt, die ein Resultat
auf den Stapelspeicher schiebt, das einen Wert aufweist, der auf
dem Wert eines Operanden auf dem Stapelspeicher basiert. Wenn dies
nicht gültig
ist, dann würde
die Pfad-Unabhängigkeit
ebenso nicht gültig
sein – abhängig von
anfänglichen
Daten, auf die der IL-Code wirkt, könnte zum Beispiel der Typstatus
des Systems an irgendeiner bestimmten Anweisung unterschiedlich
sein.
-
Schließlich ist eine andere optionale
Invariante, die in einer Ausführungsform
der Erfindung eingesetzt werden kann, dass ein lexikalischer Pfad durch
den IL-Code von Anfang zu Ende ebenfalls von dem Standpunkt erlaubt
ist, dass der Typstatus des Systems weiterhin eine Funktion des
IP für
diesen lexikalischen Pfad ist. Dieser Pfad ist im Gegensatz zu Folgendem
jeder Zweig, der während
der Ausführung
auftritt. Diese Invariante ist nützlich,
da sie ermöglicht,
den Code in einem Durchlauf zu kompilieren und laufen zu lassen,
indem die IL verarbeitet wird. In solch einem Fall ist es wichtig,
dass der lexikalische Pfad durch den IL-Code erlaubt ist, so dass die
Typen von typ-indefiniten Anweisungen korrekt aufgelöst werden.
Es ist zu bemerken, dass nach einer unbedingten Verzweigung der
Stapelspeicher angenommen wird, leer zu sein, es sei denn, es ist
ein Ziel einer Verzweigung, das schon erkannt worden ist.
-
Verfahren
-
In diesem Abschnitt der detaillierten
Beschreibung werden Computer-implementierte Verfahren gemäß verschiedenen
Ausführungsformen der
Erfindung beschrieben. Die Computerimplementierten Verfahren können zumindest
teilweise als ein oder mehrere Programme umgesetzt werden, die auf einem
Computer (wie zum Beispiel der Computer von 1) laufen – das heißt, als ein Programm, das von einem
Computer-lesbaren Medium wie zum Beispiel einem Speicher durch einen
Prozessor eines Computers ausgeführt
wird. Die Programme sind wünschenswerterweise
auf einem Maschinen-lesbaren Medium wie zum Beispiel einer Floppydisk
oder einer CD-ROM zum Vertrieb und Installation und Ausführung auf
einem anderen Computer speicherbar.
-
Unter Bezugnahme auf 5 wird ein Computer-implementiertes Verfahren
gemäß einer
Ausführungsform
der Erfindung gezeigt. In 500 wird ein IL-Code eingegeben. Der IL-Code
weist einen typ-indefiniten Befehlscode auf, der einer typ-indefiniten Anweisung
wie zum Beispiel ADD, wie vorstehend beschrieben wurde, entspricht.
Die Weise, durch die der IL-Code eingegeben wird, ist durch die
Erfindung nicht beschränkt.
Zum Beispiel kann der IL-Code über
das Internet empfangen werden oder von einem Computer-lesbaren Medium
wie zum Beispiel einem Festplattenlaufwerk oder einem nicht-flüchtigen Speicher
gelesen werden.
-
In einer Ausführungsform der Erfindung ist der
IL-Code für
ein System geschrieben, das eine Invariante Vorschrift aufweist,
dass ein gegenwärtiger Typstatus
des Systems vorstehend beschrieben Pfad-unabhängig ist. Eine andere Invariante
Vorschrift, dass ein lexikalischer Pfad durch den Code von Anfang
bis Ende erlaubt ist, kann ebenso auf das System angewendet werden.
Die Erfindung ist aber nicht notwendigerweise derart beschränkt.
-
Es wird ebenso in dem Verfahren von 5 angenommen, dass der IL-Code
dann wie im Stand der Technik bekannt verarbeitet wird, bis der
typ-indefiniten Befehlscode des IL-Codes auftritt. In solch einem
Fall wird dann 502 durchgeführt. Zum Beispiel zeigt ein
Anweisungszeiger oder nimmt Bezug auf den typ-indefiniten Befehlscode
unmittelbar vor Durchführung
von 502, wie beschrieben wurde.
-
In 502 wird der typ-indefinite
Befehlscode in einer typisierten Befehlscode aufgelöst. Dies
kann in Übereinstimmung
mit der Beschreibung in dem vorstehenden Abschnitt der detaillierten
Beschreibung erreicht werden. Zum Beispiel wird diese Auflösung in
einer Ausführungsform
durch zuerst Ableiten des Typs von einem oder mehreren Operanden,
auf die der typ-indefinite Befehlscode Bezug nimmt, und dann Auflösen des
typ-indefiniten Befehlscodes in einen typisierten Befehlscode erreicht,
der einen Typ aufweist, der auf dem Typ der Operanden basiert. Das
heißt,
auf einen gegenwärtigen
Typstatus kann, wie beschrieben wurde, als eine Funktion des IP
Bezug genommen werden, der auf den typ-indefiniten Befehlscode Bezug
nimmt. Oder auf den Typ der Operanden, wenn die Operanden auf einem
Stapelspeicher liegen, kann indirekt in einer verschiedenen Weise
Bezug genommen werden.
-
In 504 wird systemeigener
(oder ausführbarer)
Code aus dem IL-Code zur Ausführung
auf einer bestimmten Plattform erzeugt. Der systemeigene Code schließt einen
Befehlscode ein, der dem typisierten Befehlscode entspricht, der
in 502 aus dem typ-indefiniten Befehlscode des IL-Codes
aufgelöst wurde.
In einer Ausführungsform
für ein
Installations-Zeit Compiler, ein just-in-time Compiler oder ein Interpreter
sowohl 502 als auch 504 durch, obwohl die Erfindung
nicht derart beschränkt
ist.
-
Schließlich wird in 506 der
systemeigene Code ausgegeben. Die Erfindung ist nicht durch die Weise,
wie der systemeigene Code ausgegeben wird, beschränkt. In
einer Ausführungsform
wird der systemeigene Code durch Speichern des systemeigenen Codes
auf einem Computer-lesbaren Medium wie zum Beispiel einem Speicher
oder einer Festplatte ausgegeben. In einer anderen Ausführungsform bildet
die Ausführung
des systemeigenen Codes die Ausgabe davon.
-
Wie Fachleute verstehen können, kann
zumindest ein Teil des Verfahrens von 5 durch
eine Komponente der Zwischensprachen-Umgebung wie in Verbindung
mit 2 beschrieben ausgeführt werden.
Zum Beispiel kann ein Mechanismus innerhalb eines Systems wie zum
Beispiel ein just-in-time Compiler den Zwischensprachen-Code in
systemeigenen Code übersetzen,
der Auflösen
eines typ-indefiniten Befehlscodes in einen typisierten Befehlscode
einschließt.
Als ein anderes Beispiel kann ein Mechanismus innerhalb eines Systems
durch einen Prozessor von einem Computer-lesbaren Medium ausgeführt werden,
um einen typ-indefiniten Befehlscode in einen typisierten Befehlscode
aufzulösen – in einer Ausführungsform
durch Ableiten des Typs der Operanden, auf die der typ-indefinite
Befehlscode Bezug nimmt. Die Erfindung ist jedoch nicht derart beschränkt.
-
Schlussfolgerung
-
Obwohl spezifische Ausführungsformen
dargestellt und hier beschrieben wurden, ist für Fachleute zu verstehen, dass
irgendeine Anordnung, die darauf abzielt, den gleichen Zweck zu
erfüllen,
durch die gezeigten spezifischen Ausführungsformen ersetzt werden
kann. Diese Anmeldung ist beabsichtigt, irgendwelche Adaptionen
und Variationen der vorliegenden Erfindung abzudecken. Daher ist
offenkundig beabsichtigt, dass diese Erfindung nur durch die folgenden
Ansprüche
und Äquivalente
davon beschränkt
ist.