DE69723286T2

DE69723286T2 - Echtzeitprogramm-sprachbeschleuniger

Info

Publication number: DE69723286T2
Application number: DE69723286T
Authority: DE
Inventors: Yair Raz
Original assignee: Paran Arik Sunnyvale
Current assignee: Paran Arik Sunnyvale
Priority date: 1996-11-13
Filing date: 1997-11-13
Publication date: 2004-05-13
Anticipated expiration: 2017-11-14
Also published as: EP0938703B1; DK0938703T3; US6606743B1; JP2000507015A; DE69723286D1; EP0938703A4; AU5507898A; WO1998021655A1; JP3330378B2; EP0938703A1; ATE244417T1

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft das Gebiet der Computerverarbeitung und insbesondere der Echtzeitinterpretation und Operation von Computercode unter Verwendung einer Kombination außergewöhnlicher Hardware und Software. Der vorliegende erfinderische Echtzeit-Programmiersprachen-Beschleuniger wird zurzeit überwiegend zur Ausführung von Java^TM-Code verwendet, wobei es wünschenswert ist, dass man einen solchen Code mit einer hohen Ausführungsgeschwindigkeit auf einer Vielfalt von verschiedenen Prozessoren laufen lassen kann.
HINTERGRUNDTECHNIK
Im Stand der Technik ist es bekannt, Interpretierer zum Umwandeln von Computersprachen höheren Niveaus in maschinenlesbaren Code in annähernd Echtzeit vorzusehen. Jedoch müssen solche Interpretierer die Operation des Programms bremsen, das zumindest bei einigen Punkten während des Ladens und Laufens des Programms laufen gelassen wird. Insbesondere hinsichtlich der Java^TM-Programmiersprache sind die verschiedenen erhältlichen Lösungen für laufende Java^TM-Programme, einschließlich des virtuellen Java^TM-Rechners ("Java^TM-Virtual-Machine"), Softwarebasierte Programme, die eine Ausführung erfordern, um ihre Aufgaben zu erfüllen.
Es wäre vorteilhaft, ein Verfahren und/oder Mittel zum Laufen bzw. Ablaufen von Java^TM-Code auf jedem erhältlichen Prozessortyp zu haben. Es wäre auch vorteilhaft, irgendein Verfahren und/oder Mittel zum Verarbeiten des Java^TM-Codes zu haben, so dass er tatsächlich schneller als sonst laufen würde oder dass zumindest der Gesamtprozess des Interpretierens und Ablaufens des Java^TM-Codes nicht verlangsamt wird. Jedoch existierte im Stand der Technik nach Kenntnis des Erfinders kein System, um diese Aufgaben zu lösen. Obwohl Softwarelösungen, wie z. B. der virtuelle Java^TM-Rechner, nicht versuchen, die Operation des Codes zu optimieren, waren die Eigenschaften des bestimmten Prozessors und Systems, auf dem der Code laufen sollte, tatsächlich eine Begrenzung.
OFFENBARUNG DER ERFINDUNG
Dementsprechend ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren und Mittel zum einfachen Laufen einer nicht-nativen Programmiersprache auf virtuell jedem Prozessortyp zu schaffen.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren und Mittel zum Beschleunigen der Operation von Java^TM-Programmcode zu schaffen.
Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren und Mittel zum Übersetzen und Ausführen von Java^TM-Code zu schaffen, der auf einfache Weise hardwaremäßig implementiert ist.
Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren und Mittel zum Übersetzen und Ausführen von Java^TM-Code zu schaffen, das bzw. die die Fähigkeit des Computersystems, nicht-Java^TM-Code auszuführen, nicht beeinträchtigen wird bzw. werden.
Kurz gesagt, die bevorzugte Ausführungsform der vorliegenden Erfindung ist ein "Programmiersprachen-Beschleunigungskern" vom Typ integrierte Schaltung, der als ein Teil eines CPU-Chips auf einem einzelnen Chip oder selbst auf einer einzelnen Leiterplatte verkörpert sein kann. Der Programmiersprachen-Beschleunigungskern weist einen zweckgebundenen Hardware-Stapelspeicher auf, um den Stapelspeicher direkt vorzusehen, der für die Ausführung von Java^TM-Code entweder vorhanden oder emuliert sein muss. Es wird auch ein direkter Speicherzugriffs-Controller ("direct memory access controller, DMA-Controller") zum Verschieben von Daten in den Speicherstapel hinein und aus dem Stapelspeicher heraus vorgesehen, da Überlauf- und Unterlaufbedingungen (oder andere spezielle Bedingungen) auftreten. Ein Softwareteil der Erfindung übersetzt den Java^TM-Code in einen Maschinen-nativen Sprachencode und optimiert auch den Code, um erforderlichenfalls außergewöhnliche erfinderische Funktionen durchzuführen, wie z. B. an eine Speicheradresse schreiben, die vorbestimmt ist, spezifizierte Funktionen durchzuführen. Auf diese Weise können Operationen, die sonst mehrere Taktzyklen dauern könnten, in einem einzigen (oder zumindest weniger) Taktzyklus bzw. -zyklen durchgeführt werden.
Ein Vorteil der vorliegenden Erfindung ist, dass die Ausführungsgeschwindigkeit von Java^TM-Code außerordentlich erhöht wird.
Ein weiterer Vorteil der vorliegenden Erfindung ist, dass Java^TM-Code leicht auf im Wesentlichen jedem Prozessortyp ausgeführt werden kann.
Noch ein weiterer Vorteil der vorliegenden Erfindung ist, dass sie auf eine einfache und billige Weise implementiert werden kann, so dass selbst erschwinglich ausgezeichnete Computer für die Ausführung von Java^TM-Code optimiert werden können.
Noch ein weiterer Vorteil der vorliegenden Erfindung ist, dass sie nicht schwierig oder teuer an neue Prozessortypen anzupassen ist, wie sie erhältlich werden könnten.
Diese und andere Aufgaben und Vorteile der vorliegenden Erfindung werden dem Fachmann angesichts der Beschreibung des besten zurzeit bekannten Ausführungsmodus der Erfindung und der industriellen Anwendbarkeit der bevorzugten Ausführungsform, wie sie hier beschrieben wird und in den verschiedenen Figuren der Zeichnungen veranschaulicht wird, klar werden wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm einer integrierten Schaltung, die darauf einen Programmiersprachen-Beschleunigungskern gemäß der vorliegenden Erfindung aufweist.
2 ist ein Blockdiagramm, das ein Beispiel zeigt, wie eine CPU, die gemäß der vorliegenden Erfindung verbessert ist, in ein Computersystem integriert werden könnte.
3 ist ein detaillierteres Blockdiagramm des intelligenten Stapels der 1.
4 ist ein Speicherabbild des intelligenten Stapels, der in den 1 und 3 verdeutlicht ist.
5 ist ein Flussdiagramm eines Aspekts des erfinderischen Prozesses.
6 ist ein Flussdiagramm eines/einer Wert-Einspeicherungsbefehls/-operation ("value push operation") gemäß der vorliegenden Erfindung.
7 ist ein Flussdiagramm einer Wert-Abhebungsanweisung bzw. -operation ("value pop operation") gemäß der vorliegenden Erfindung.
8 ist ein Flussdiagramm eines Konstanten-Einspeicherungsbefehls bzw. -operation ("constant push Operation") gemäß der vorliegenden Erfindung.
9 ist ein Flussdiagramm einer arithmetischen Operation gemäß der vorliegenden Erfindung.
10 ist ein Flussdiagramm einer Ladeoperation für lokale Variablen gemäß der vorliegenden Erfindung.
11 ist ein Flussdiagramm einer Speicheroperation für lokale Variablen gemäß der vorliegenden Erfindung.
BESTER AUSFÜHRUNGSMODUS DER ERFINDUNG
Die zurzeit beste bekannte Ausführungsform der Erfindung ist ein Echtzeit-Beschleunigungskern. Der erfinderische Echtzeit-Beschleunigungskern ist in einer blockdiagrammartigen Ansicht in 1 verdeutlicht und ist darin mit dem allgemeinen Bezugszeichen 10 bezeichnet.
Der Echtzeit-Beschleunigungskern 10 weist einen intelligenten Stapel 12 und einen intelligenten DMA-Controller 14 auf. Der Echtzeit-Beschleunigungskern 10 wird Echtzeitübersetzungen und -ausführungen von Java^TM-Objektcode durch irgendeine native Ziel-CPU zulassen, so dass die native CPU Java^TM-Programme ohne irgendeine zusätzliche Software-basierte Übersetzung oder Interpretation in einem viel höheren Leistungsmodus (verglichen mit dem gewöhnlichen Java^TM-Interpretierer oder JIT-Compilern) ausführen kann. Es ist festzustellen, dass im Beispiel der 1 der Programmiersprachen-Beschleunigungskern 10 und die CPU auf einem einzelnen CPU-Chip 18 verkörpert sind, obwohl, wie hier schon früher erläutert, dies kein notwendiger Aspekt der Erfindung ist.
2 ist ein diagrammartiges Beispiel eines typischen Computers, der für eine Operation mit dem CPU-Chip 18, der darin den Programmiersprachen-Beschleuniger 10 aufweist, konfiguriert ist. Es wird festgestellt werden, dass die Verbindungen des CPU-Chips 18 innerhalb des Computers sich nicht signifikant von denen eines vergleichbaren herkömmlichen Computers gemäß dem Stand der Technik (nicht gezeigt) unterscheiden. Ein Datenbus 22, ein Adressbus 24 und ein Steuerbus 26 werden jeweils mit den geeigneten Datenwegen 28 zum Kommunizieren mit dem CPU- Chip 18, einem (RAM-)Speicher 30 und einem Schnittstellenabschnitt 32 versehen.
Der Datenbus 22 ist der native CPU-Datenbus. Die Breite des Datenbus 22 sollte die natürliche Datenbusbreite der nativen CPU 16 (8, 16 oder 32 Bits) sein. Die Schnittstellenlogik im Programmiersprachen-Beschleunigungskern 10 wird sich um jede Aufgabe bezüglich der Datenbreite kümmern. Der Adressbus 24 ist der native CPU-Adressbus. Die Breite des Adressbus 28 sollte die natürliche Adressbusbreite der nativen CPU 16 sein. Der Steuerbus 26 wird die verschiedenen Steuersignale übertragen, die in jeder CPU vorgefunden werden können, wie z. B. Takt, Rücksetzen, Lesen und Schreiben, Unterbrechen von Leitungen, Busabfrage etc.
Es sollte festgestellt werden, dass das Beispiel der 2 lediglich vorgesehen ist, um den Kontext zu zeigen, in dem ein erfinderischer Programmiersprachen-Beschleunigungskern 10 verwendet werden könnte, und nicht dazu gedacht ist, einen erfinderischen Aspekt der Erfindung zu offenbaren. Im Betrieb wird der Speicher 30 die erforderliche Initialisierungssoftware für die native CPU 16 (1), ein Betriebssystem (falls verwendet), Schnittstellen-Gerätetreiber oder Steuercodes sowie eine Programmiersprachen-Beschleunigersoftware 34 enthalten, deren Funktionen nachfolgend detaillierter beschrieben werden. Außerdem kann der Speicher 30 jeden kompilierten Java^TM-Code enthalten, der benötigt wird (z. B. spezielle kundenspezifische Klassenbibliotheken).
Abhängig von der Anwendung des Endbenutzers kann der mit dem erfinderischen Programmiersprachen-Beschleunigungskern 10 und der Programmiersprachen-Beschleunigungssoftware 34 ausgestattete Computer 20 jeden Java^TM-Code ausführen, der schon in einem nicht-flüchtigen Speicher existiert, oder ihn über die anwendbaren Schnittstellenvorrichtungen (Kommunikationsports, Platten etc.) laden.
Der Programmiersprachen-Beschleunigungskern 10 nutzt dabei die Tatsache aus, dass der virtuelle Java^TM-Rechner eine Stapelbasierte Maschinenemulation ist und die meisten Stapeloperationen auf einer zeitgenössischen CPU (wie z. B. der native CPU-Kern 16 der 1) mehr als einen Taktzyklus zum Beenden brauchen. Der intelligente Stapel 12 ist im Wesentlichen ein großer virtueller Cache für den virtuellen Java^TM-Rechner-Stapel. Der DMA-Controller 14 (1) hält den Cache konsistent, falls ein Stapelüberlauf oder -unterlauf auf Grund der begrenzten Größe des tatsächlichen Caches auftritt, wie es nachfolgend detaillierter erläutert werden wird.
3 stellt ein detaillierteres Blockdiagramm des intelligenten Stapels 12 dar, der hier zuvor in Bezug auf 1 erläutert wurde. In der Ansicht der 3 kann gesehen werden, dass der intelligente Stapel 12 eine einfache innere arithmetische Logikeinheit ("arithmetic logic unit, ALU") aufweist, die das Einspeichern ("pushing") von Konstanten, wie durch die Spezifikation des virtuellen Java^TM-Rechners definiert, zusammen mit den Operationen erlaubt, die die Spitzen des Stapels aktualisieren, wie z. B. iadd oder iinc, die dem Fachmann für Implementierungen des virtuellen Java^TM-Rechners alle bekannt sein werden. Ein Cache 38 ist der tatsächliche Cache-Speicher innerhalb des intelligenten Stapels. Ein Stapel-Controller 40 weist einen Stapelzeiger 42 und einen Nächster-Stapel-Zeiger 44 auf, wie sie z. B. in herkömmlichen Stapelsteuervorrichtungen wie sie z. B. in herkömmlichen Stapelsteuervorrichtungen vorgefunden werden. Ein herkömmlicher Decodierer 46 wird zum Decodieren von Adressen und Befehlen vorgesehen, und ein Ausgabe-MUX 48 stellt eine Ausgabe von der Quelle innerhalb des intelligenten Stapels 12 bereit, die zur Operation passt.
Der intelligente Stapel 12 ist eine 64 × 32-Bit-Registerdatei, die konfiguriert ist, um als Stapel verwendet zu werden. Der intelligente Stapel 12 ist ein Speicher, der in den nativen CPU-16-Speicheradressraum abgebildet wird, und ermöglicht der nativen CPU 16 eine schnelle Stapeloperation (Einspeichern, Abheben) und auch einen zufälligen Zugriff auf jedes der Register. Der intelligente Stapel 12 stellt eine Schaltung für eine automatische Stapelüberlauf/Unterlauf-Erfassung bereit. Der intelligente DMA-Controller 14 ist konfiguriert, um den Inhalt des gesamten intelligenten Stapels 12 aus dem Speicher 30 zu lesen oder an den Speicher 30 zu schreiben, wie wenn es z. B. erforderlich ist, zwischen verschiedenen Aufgaben zu verschieben. Der intelligente DMA-Controller 14 korrigiert auch einen potentiellen Stapelüberlauf oder -unterlauf durch zeitweises Speichern jedes Datenüberschusses vom intelligenten Stapel 12 an den Speicher 30. Der intelligente DMA wird einen Wörterblock an einen Hauptspeicher 30 ausgeben, wenn der Stapel sich einem Überlauf nähert (bei einer Einspeicherungsoperation) oder wird einen Wörterblock aus dem Hauptspeicher 30 laden, wenn der Speicher sich einem Unterlauf nähert (bei einer Abhebeoperation). Der intelligente DMA-Controller kann eine lokale Variable aus dem Hauptspeicher 30 laden (bei einem Variablen-Ladefehlschlag), eine lokale Variable an den Hauptspeicher 30 speichern (bei einem Variablen-Speicherfehlschlag), den gesamten Cache 38 an den Hauptspeicher 30 ausgeben, um eine Kontext umschaltung vorzubereiten, oder den gesamten Cache 38 aus dem Speicher 30 laden, um eine Kontextumschaltung durchzuführen. Der intelligente DMA kann optional auch verwendet werden, um erforderlichenfalls ein Verkettungskontext-Umschalten ("thread context switching") durch Bewegen von Daten in und aus dem Cache 38 zu beschleunigen.
Es sollte festgestellt werden, dass der erfinderische Programmiersprachen-Beschleuniger 10 ausgelegt sein könnte, ohne den intelligenten DMA-Controller 14 betriebsbereit zu sein, obwohl die Hinzufügung des intelligenten DMA-Controllers 14 die Brauchbarkeit und Funktionalität des Programmiersprachen-Beschleunigers 10 signifikant erhöht.
Da Java^TM-Operationen auf einer Stapelrechnerarchitektur basieren, muss die Programmiersprachen-Beschleunigungssoftware 34 lediglich eine sehr einfache Übersetzung von Java^TM-Code in nativen CPU-Code durchführen. Die Übersetzung wird unter Verwendung der unterstützenden Sprachen-Beschleunigungssoftware 34 gemacht, vorzugsweise wenn der Java^TM-Code geladen wird. Eine Optimierung gemäß der vorliegenden Erfindung wird während der Übersetzung durch Verfahren ermöglicht werden, einschließlich des vorliegenden erfinderischen Verfahrens eines Sicherstellens, dass bestimmte Operationen an bestimmte Speicheradressen gerichtet werden, wie es nachfolgend detaillierter erläutert werden wird. Da die native CPU 16 sich nicht um eine Stapelverwaltung (die durch den intelligenten Stapel 12 gehandhabt wird) kümmern muss, ist eine Ausführung von Java^TM-Programmen mit sehr hoher Geschwindigkeit möglich.
Gemäß der vorliegenden Erfindung werden Daten vom Datenbus 22 kommen und auf die Spitze des Stapels fließen (wie eine herkömmliche Stapeloperation) oder werden sonst eine arithmetische Operation erfahren, einschließlich des Werts an der Spitze des Stapels, und dann die Spitze des Stapels ersetzen oder oben auf den Stapel gespeichert. Einzigartig an der vorliegenden Erfindung ist die Tatsache, dass all die Operationen durch die verwendeten Adressen bestimmt sind. Der intelligente Stapel 12 belegt den Adressraum des Cache 38 vier Mal. Das bedeutet, es werden vier Mal mehr Adressen auf einen Speicher des CPU-Chips 18 abgebildet, als benötigt werden, um vollständig alle der tatsächlichen Speicherstellen im intelligenten Stapel 12 zu adressieren. Die Größe des Cache bei der besten zurzeit bekannten Ausführungsform 10 der vorliegenden Erfindung ist 64 Wörter, so dass der intelligente Cache 12 256 Stellen bei dieser Ausführungsform belegt.
4 ist ein einfaches Speicherabbild 50 der durch den intelligenten Stapel 12 belegten Speicheradressen. In der Ansicht der 4 kann gesehen werden, dass das Speicherabbild 50 einen ersten Bereich 52, einen zweiten Bereich 54, einen dritten Bereich 56 und einen vierten Bereich 58 aufweist. von diesen bezieht sich lediglich der erste Bereich 52 direkt auf den physischen Cache 38. Eine vollständige Adresse 60 zum Adressieren des Speicherabbilds 50 wird zwei Auswahlbereichbits 62 zum Auswählen, welcher der Bereiche 52, 54, 56 oder 58 adressiert werden soll, und wird ein 8-Bit-Auswahlbyte 64 zum Adressieren spezieller Datenstellen innerhalb der jeweiligen Bereiche aufweisen. Da jeder der vier Bereiche 52 verschiedene auszuführende Operationen ermöglicht, indem eine Adresse darin gelesen oder an eine Adresse darin geschrieben wird, bestimmen die oberen zwei Adressen-Bits (das Auswahlbereichbit 62) des Programmiersprachen-Beschleunigerkerns 10, welcher Bereich 52, 54, 56 oder 58 adressiert ist, und bestimmt so den Hauptoperationsmodus der Vorrichtung.
Die unten gezeigte Tabelle 1 sieht eine allgemeine Beschreibung der Operationen vor, die durchgeführt werden, wenn die native CPU 16 jeden der vier Bereiche 52, 54, 56 und 58 des Speicherabbilds 50 adressiert.
TABELLE 1
Kurz gesagt, Werte, die an den ersten Bereich 52 des Speicherabbilds 50 geschrieben werden, könnten direkt durch die native CPU 16 bei der Basisadresse der Vorrichtung geschrieben oder gelesen werden. Der zweite Bereich 54 wird für die Konfi guration und die Steuerregister verwendet. Der dritte Bereich 56 wird für Einspeicherungs- und Abhebungsbefehle verwendet. Der vierte Bereich 58 wird für arithmetische Operationen verwendet, die den Wert an der Spitze des Stapels ersetzen. Der Decodierer 46 schaut auf die hereinkommende Adressabfrage und bestimmt dadurch automatisch die Operation, wobei die Korrelation zwischen Adresse und Operation zuvor während einer Übersetzung durch die Programmiersprachen-Beschleunigungssoftware 34 errichtet wurde. Die Datenbusse und ein Timing sind generische einfache Zyklusbusse ("cycle busses"), bei denen die Adress-, Lese- und Schreibsignale beim Takt gültig sind und Lesedaten vom folgenden Takt erwartet werden.
5 ist ein Flussdiagramm 68, das die allgemeine Operation des Computers 20 gemäß dem vorliegenden erfinderischen Verfahren verdeutlicht. Immer wenn der Computer 20 neu gestartet wird, wird von der nativen CPU 16 eine spezielle Initialisierung durchgeführt: Einrichten von Hardwarevorrichtungen, Initialisieren des Betriebssystems (falls verwendet), Ausführen jedes erforderlichen Startup-Programms, usw. Diese Programme sind in der nativen CPU-16-Sprache geschrieben (z. B. ein Befehlssatz) und werden durch die native CPU 16 direkt ausgeführt. Dies wird ohne jegliche Verbindung zu Java^TM und/oder einem Programmiersprachen-Beschleunigungskern 10 getan. Auch bei einer Einstelloperation 70 interner Register wird die native CPU Speicherregister initialisieren, einschließlich denen, die zum Adressieren des Programmiersprachen-Beschleunigungskerns 10 beiseite gesetzt sind. Dies ist die anfängliche Operationsphase, wenn der Benutzer die Java^TM-Ausführungsumgebung ("Java^TM Execution Environment") aufruft bzw. aktiviert und startet. Während einer Initialisierung des virtuellen Java^TM- Rechners wird der virtuelle Java^TM-Rechner das Vorhandensein eines Programmiersprachen-Beschleunigungskerns 10 und seiner Unterstützungssoftware erfassen (die Programmiersprachen-Beschleunigungssoftware 34) und beide initialisieren. Unter den zahlreichen während dieser Phase durchgeführten Initialisierungen sind einige der wichtigsten das Einstellen der verschiedenen Konfigurationsregister des Programmiersprachen-Beschleunigungskerns 10 (wie hier mit Bezug auf den zweiten Bereich 54 des Speicherabbilds 50 beschrieben).
Jedes erforderliche native Programm könnte dann vom Computer 20 ausgeführt werden. Dies wird auch direkt von der nativen CPU 16 ohne irgendeine Operation getan, die von dem Programmiersprachen-Beschleunigungskern 10 gebraucht wird. (Diese Operationen sind im Flussdiagramm 68 der 5 nicht gezeigt und werden hier nur genannt, um das Flussdiagramm 68 in den richtigen Kontext zu setzen).
Wenn eine Java^TM-Klassendatei ausgeführt werden muss (entweder existiert sie schon im Speicher oder sie muss von einer Platte geladen oder von einer Kommunikationsleitung empfangen werden), verwendet die native CPU 16 den JVM-Klassenlader ("JVM class loader") und die Programmiersprachen-Beschleunigungssoftware 34, um die erforderliche Datei zu laden, vorzubereiten, eine Übersetzung durchzuführen und eine Ausführung zu starten. Dieser Vorgang besteht aus mehreren Schritten, die detailliert in den folgenden Abschnitten beschrieben werden: Bei einer Klassendatei-Ladeoperation 72 wird eine Java^TM-Klassendatei geladen. Dieser Teil wird vollständig durch einen Standardcode für den virtuellen Java^TM-Rechner ausgeführt, wie in "The Java^TM Virtual Machine Specification" beschrieben. Bei einer Verbin dungs- und Verifikationsoperation 74 wird ein Verbinden, Verifizieren, Vorbereiten und Auflösen auf herkömmliche Weise vom virtuellen Java^TM-Rechner-Programmbinder ("Java^TM Virtual Machine linker") durchgeführt. Dieser Teil wird ebenfalls vollständig durch Standard-code für den virtuellen Java^TM-Rechner ausgeführt.
Nachfolgend lokalisiert die native CPU 16 bei einer Übersetzungsoperation 76 den Implementierungscode der Klassendatei (z. B. den Byte-Code des virtuellen Java^TM-Rechners, der die Klasse implementiert), übersetzt ihn in native Befehle und lädt ihn an einen Ausführungsbereich im Speicher 30. Dieser Teil wird vollständig durch die Programmiersprachen-Beschleunigungssoftware erledigt. Der Zweck der Übersetzungsphase ist, den Java^TM-Byte-Code (der in den vorherigen Phasen geladen und verbunden wurde) in die nativen CPU-Befehlsströme umzuwandeln, die geeignet sind, den Programmiersprachen-Beschleunigungskern 10 zu betreiben. Da, wie hier beschrieben, ein Lesen oder Schreiben von/an spezielle Speicherstellen alle Operationen des Programmiersprachen-Beschleunigungskerns 10 aufruft, wird der übersetzte native Code am häufigsten Lese- und Schreibbefehle von/an den/die verschiedenen Speicherbereiche des Programmiersprachen-Beschleunigungskerns 10 enthalten. Die spezifische Übersetzung von Byte-Code in nativen Code hängt von der nativen CPU ab, die mit dem Programmiersprachen-Beschleunigungskern 10 verbunden ist. Der übersetzte Code wird im Speicher 30 gespeichert. Wenn eine Klassendatei erst einmal vollständig übersetzt ist, kann das originale Byte-Code-Bild verworfen werden, und lediglich der übersetzte native Code wird verwendet werden.
Wenn der Ladevorgang erst einmal abgeschlossen ist, wird die native CPU 16 eine Abzweigung (einen Sprung) zum Eintrittspunkt des übersetzten nativen Codes durchführen und wird eine Ausführung des Klasseninitialisierungscodes beginnen, der nun ein natives Programm mit Befehlssequenzen ist, die eine zweckgebundene Hardware-Stapelung und -logik des Programmiersprachen-Beschleunigungskerns 10 nutzen, wie während dieser Offenbarung erläutert. Dies wird durch eine Operation 78 eines Ausführens nativen Codes im Flussdiagramm 68 der 5 angegeben.
Weitere Details der Operation des erfinderischen Verfahrens, die während der Operation 78 eines Ausführens nativen Codes auftreten, werden in Bezug auf zusätzliche Flussdiagramme nachfolgend erläutert werden. Diese Operationen und jeweilige Flussdiagramme stellen sich wie folgt dar: Eine Wert-Einspeicherungsoperation 80 (6) und eine Wert-Abhebeoperation 82 (7), die sich beide auf Operationen beziehen, die auftreten, wenn die native CPU 16 den zweiten Bereich 54 des Speicherabbilds 50 des intelligenten Stapels 12 adressiert. Eine Konstanten-Einlagerungsoperation 84 (8) betrifft auch Operationen, die auftreten, wenn die native CPU ausgewählte Stellen des zweiten Bereichs 54 des Speicherabbilds 50 des intelligenten Stapels 12 adressiert. (Jemand, der sich mit Java^TM auskennt, wird erkennen, dass eine äquivalente "Konstanten-Abhebungs"-Operation nicht notwendig ist.)
Ein Flussdiagramm einer arithmetischen Operation 86 (9) beschreibt Operationen, die im Programmiersprachen-Beschleunigungskern 10 auftreten, wenn ausgewählte Bereiche des dritten Bereichs 54 des Speicherabbilds 50 adressiert werden. Eine Ladeoperation 88 für lokale Variablen (10) und eine Spei cheroperation 90 für lokale Variablen (11) beschreibt diese jeweiligen Funktionen und wird mehr Details über die Operation des intelligenten DMA-Controllers 14 liefern.
Zurückkehrend zur Erläuterung des verschiedenen Funktionierens der vier Bereiche 52, 54, 56 und 58 des Speicherabbilds 50, das hier früher eingeführt wurde, wird man sich daran erinnern, dass bei der besten zurzeit bekannten Ausführungsform 10 der vorliegenden Erfindung der Programmiersprachen-Beschleunigungskern 10 64 Wörter in seinem intelligenten Hardware-Stapel 12 enthält. Dieser Adressraum wird in vier Hauptbereiche 52, 54, 56 und 58 geteilt, wobei jeder unterschiedliche auszuführende Operationen durch ein Lesen einer Adresse oder Schreiben an eine Adresse darin ermöglicht. Hinsichtlich des ersten Bereichs 52 des Speicherabbilds 50 wirkt dieser Bereich, wie es ein Fachmann erwarten würde, dass sich das Speicherabbild 50 verhält, wäre dies der einzige Bereich des Speicherabbilds – d. h., falls es eine Eins-zu-Eins-Korrelation zwischen den Adressen des Speicherabbilds 50 und dem Cache 38 gäbe. Der erste Bereich 52 des Speicherabbilds 50 ist vorgesehen, um einen Lese- und Schreibzugriff auf jedes der Hardware-Stapelregister (64 32-Bit-Register) zu ermöglichen, als ob sie ein Direktzugriffsspeicher wären.
Hinsichtlich des zweiten Bereichs 54 des Speicherabbilds 50 steuern die Register in diesem Bereich die Operation des Programmiersprachen-Beschleunigungskerns 10. Diese Register haben Lese- und Schreibzugriff. Dieser Bereich beinhaltet auch vier spezielle Nur-Schreibe-Stellen ("write-only locations"). Zwei dieser Nur-Schreibe-Stellen werden für Variablen-Operationen verwendet, und zwei werden zur Kontextumschaltung verwen det. Irgendeines dieser Register wird über die niedrigen Adressbits der nativen CPU 16 adressiert. Die unten stehende Tabelle 2 ist eine Auflistung der anwendbaren Register innerhalb des zweiten Bereichs 54 des Speicherabbilds 50.
TABELLE 2
Hinsichtlich des dritten Bereichs 56 des Speicherabbilds wird dieser Bereich zum Einspeichern von Werten oder Konstanten in den Stapel oder zum Abheben von Werten vom Stapel verwendet. Die durchzuführende Operation wird durch die niedrigen Adressbits des Prozessors (das Auswahlbyte 62) bestimmt. D. h., die Adresse bestimmt die durchzuführende Operation. Diese Funktionen werden unten in einer Tabelle 3 aufgelistet. Ein Fachmann wird erkennen, dass in einigen Fällen der Datenwert, der von der nativen CPU 16 an den Programmiersprachen-Beschleunigungskern 10 geliefert wird, irrelevant sein wird, da die Operation unter Verwendung eines konstanten Werts durchgeführt wird.
TABELLE 3
Hinsichtlich des vierten Bereichs 58 des Speicherabbilds 50 wird dieser Bereich verwendet, um arithmetische Operationen auf den Wert an der Spitze des Stapels ("Top-Of-Stack") zu initiieren. Der Wert an der Spitze des Stapels wird durch das Ergebnis einer arithmetischen Operation zwischen einem Wert am Datenbus und dem aktuellen Wert an der Spitze des Stapels ersetzt. Die durchzuführende arithmetische Operation wird durch die niedrigen Adressbits des Prozessors (das Auswahlbyte 62) bestimmt. All diese Operationen werden an ganzzahligen Werten (32-Bit-ganze-Zahlen) durchgeführt. Diese Funktionen werden unten in einer Tabelle 4 aufgelistet.
TABELLE 4
Bezug nehmend auf die in der 6 gezeigte Wert-Einspeicherungsoperation 80, wenn die Programmiersprachen-Beschleunigungssoftware 34 den Java^TM-Code unter Berücksichtigung einer Wert-Einspeicherungsoperation übersetzt und optimiert hat und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird der Wert in einer Operation 80a an die Stelle "pushpop" geschrieben werden (vgl. Tabelle 3). Bei einer Operation 80b wird die Adresse decodiert (von dem Decodierer 46 – 3), der Wert wird so gerichtet. Dann wird bei einer Operation 80c der vom Datenbus (2) geschriebene Wert in den Hardware-Stapel (den Cache 38 – 3) an die Stelle geschrieben, auf die durch sein TOS-Register gezeigt wird, und die TOS wird inkrementiert. Falls der Hardware-Stapel (Cache 38) sich einem Überlauf nähert, wie in einer Entscheidungsoperation 80d bestimmt, dann wird der intelligente DMA-Controller 14 initialisiert, einen Teil des Inhalts des Caches 38 an den Speicher 30 (2) bei einer Operation 80e zu speichern.
Bezug nehmend auf die Wert-Einspeicherungsoperation 82, die in 7 gezeigt ist, wenn die Programmiersprachen-Beschleunigungssoftware 34 unter Berücksichtigung einer Wert-Einspeicherungsoperation den Java^TM-Code übersetzt und optimiert hat und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird der Lese-Befehl an die geeignete Stelle in einer Operation 82a gerichtet werden. Bei einer Operation 82b wird die Adresse decodiert (durch den Decodierer 46 – 3). Dann wird bei einer Operation 82c der Wert vom Cache 38 (3) gelesen (abgehoben), und der TOS-Zeiger wird dekrementiert. Der Wert wird in einer Operation 82d an den Datenbus (2) geschickt. Falls dies den Hardware-Stapel (Cache 38) in einer Unterlaufbedingung hinterlässt, wie in einer Entscheidungsoperation 82e bestimmt (d. h., falls der Cache 38 ein vorbestimmtes Niveau eines Nichtgebrauchs erreicht hat), dann wird der intelligente DMA-Controller 14 initialisiert, einen Teil des Inhalts des Cache 38 vom Speicher 30 (2) bei einer Operation 82f wiederherzustellen.
Bezug nehmend auf die konstante Einspeicherungsoperation 84, die in 8 gezeigt ist, wenn die Programmiersprachen- Beschleunigungssoftware 34 unter Berücksichtigung einer konstanten Einspeicherungsoperation den Java^TM-Code übersetzt und optimiert hat, und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird der Schreibbefehl an die geeignete Stelle in einer Operation 84a gerichtet werden. Bei einer Operation 84b wird die Adresse decodiert (durch den Decodierer 46 – 3). Dann wird bei einer Operation 84c der konstante Wert, der durch die bestimmte ausgewählte Adresse diktiert ist, in den Hardware-Stapel (den Cache 38 – 3) an der Stelle geschrieben (eingespeichert), auf die durch sein TOS-Register gezeigt wird, und die TOS wird inkrementiert. Falls der Hardware-Stapel (Cache 38) sich einem Überlauf nähert, wie in einer Entscheidungsoperation 84d bestimmt, dann wird der intelligente DMA-Controller initialisiert, einen Teil des Inhalts des Cache 38 an den Speicher 30 (2) in einer Operation 84e zu speichern.
Bezug nehmend auf die in 9 gezeigte arithmetische Operation 86, wenn die Programmiersprachen-Beschleunigungssoftware 34 unter Berücksichtigung einer bestimmten arithmetischen Operation den Java^TM-Code übersetzt und optimiert hat und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird der Schreibbefehl an die geeignete Stelle in einer Operation 86a gerichtet werden. Es ist festzustellen, dass genau das, was diese geeignete Stelle sein könnte, durch die bestimmte arithmetische Operation diktiert werden wird, die durchzuführen ist, wie zuvor in Tabelle 4 aufgelistet. Bei einer Operation 86b wird die Adresse decodiert (durch den Decodierer 46 – 3), und die entsprechenden Daten werden von diesem Datenbus 22 (2) geholt. Dann wird in einer Operation 86c die arithmetische Operation, die der ausgewählten Adresse ent spricht, auf den Wert an der Spitze des Stapels unter Verwendung des Werts angewendet, der vom Datenbus (2) geschrieben ist, und das Ergebnis wird in den Hardware-Stapel (den Cache 38 – 3) bei der Stelle geschrieben, auf die sein TOS-Register zeigt.
In einer Variablen-Speicheroperation 90 (11), wenn die Programmiersprachen-Beschleunigungssoftware 34 unter Berücksichtigung einer Variablen-Speicheroperation den Java^TM-Code übersetzt und optimiert hat und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird ein Schreibbefehl an die zweckgebundene Speicherstelle entsprechend der Speicheroperation im intelligenten Stapel 12 in einer Operation 90a gerichtet werden. Der an den Datenbus 22 geschriebene Wert sollte die absolute Speicheradresse der erforderlichen lokalen Variablen sein, die zu speichern ist. In einer Operation 90b wird die Adresse decodiert (durch den Decodierer 46 – 3). Dann wird, falls die erforderliche Variable sich im Stapel befindet (wie in einer Entscheidungsoperation 90c bestimmt), der Variablenwert von der TOS gelesen und an seine erforderliche Adresse gespeichert, und die Spitze des Stapels wird dekrementiert. Falls die erforderliche Variable sich nicht im Stapel befindet, wie in der Entscheidungsoperation 88c bestimmt, dann wird der intelligente DMA-Controller 14 initialisiert, den Variablenwert von der Spitze des Stapels zu speichern und die TOS in einer Operation 90e zu speichern. Falls der Hardware-Stapel (Cache 38) sich einem Unterlauf nähert, wie es in einer Entscheidungsoperation 90f bestimmt ist, dann wird der intelligente DMA-Controller 14 initialisiert, den Stapelinhalt aus dem Hauptspeicher 30 wiederherzustellen.
Bei einer Variablen-Ladeoperation 88 (10), wenn die Programmiersprachen-Beschleunigungssoftware 34 unter Berücksichtigung einer Variablen-Ladeoperation den Java^TM-Code übersetzt und optimiert hat und es für eine solche Operation Zeit ist, ausgeführt zu werden, wird ein Schreibbefehl an die zweckgebundene Speicherstelle im intelligenten Stapel 12 in einer Operation 88a gerichtet werden, die der Variablen-Speicheroperation zugewiesen ist. Der an den Datenbus 22 geschriebene Wert sollte die absolute Speicheradresse der erforderlichen lokalen Variablen sein, die zu speichern ist. In einer Operation 88b wird die Adresse decodiert (durch den Decodierer 46 – 3). Dann wird, falls die erforderliche Variable sich im Stapel befindet (wie in einer Entscheidungsoperation 88c bestimmt), der Variablenwert aus dem Cache 38 gelesen und oben auf dem Stapel in einer Operation 88d platziert; und die TOS wird inkrementiert. Falls die erforderliche Variable sich nicht im Stapel befindet, wie in der Entscheidungsoperation 88c bestimmt, dann wird der intelligente DMA-Controller 14 initialisiert, den Variablenwert an die Spitze des Stapels zu laden und die TOS in einer Operation 88e zu inkrementieren. Falls der Hardware-Stapel (Cache 38) sich einem Überlauf nähert, wie in einer Entscheidungsoperation 88f bestimmt, dann wird der intelligente DMA-Controller 14 initialisiert, den Stapelinhalt vom Hardware-Stapel (Cache 38) an den Hauptspeicher 30 zu transferieren.
Verschiedene Modifikationen könnten auf die Erfindung angewendet werden, ohne den Schutzbereich zu verlassen. Obwohl z. B. der erfinderische Programmiersprachen-Beschleunigungskern 10 und die zugehörige Programmiersprachen-Beschleunigungssoftware 34 hier als für eine Verwendung mit der Java^TM-Program miersprache optimiert beschrieben sind, sind die hier auftretenden Grundsätze auf gleiche Weise für eine Verwendung mit anderen Programmiersprachen anwendbar, insbesondere falls solche Sprachen primär für eine Verwendung mit Stapel-basierten Systemen entwickelt sein könnten.
Wie zuvor erläutert, wäre es noch eine sehr wahrscheinliche Modifikation, den Programmiersprachen-Beschleunigungskern als eine physisch vom CPU-Chip 18 getrennte Vorrichtung zu implementieren, so dass er einfacher zu existierenden Systemen oder existierenden Systementwürfen hinzugefügt werden könnte.
GEWERBLICHE ANWENDBARKEIT
Der erfinderische Programmiersprachen-Beschleunigungskern 10 und die damit in Bezug stehende Programmiersprachen-Beschleunigungssoftware 34 sind beabsichtigt, für die Echtzeit-Ausführung von Java^TM-Code in Verbindung mit Prozessoren verwendet zu werden, die sonst für eine Ausführung von Programmen optimiert sind, die in anderen Sprachen als Java^TM geschrieben sind. Wie angesichts der obigen Beschreibung zugestimmt werden wird, verwendet der Programmiersprachen-Beschleunigungskern 10 ein ganz neues Konzept, in dem die Programmiersprachen-Beschleunigungssoftware, wenn der Java^TM-Code für eine Ausführung im nativen Code der nativen CPU 16 interpretiert wird, gewisse Operationen veranlassen wird, an gewisse virtuelle Speicheradressen gerichtet zu werden, so dass die Operation automatisch durch den intelligenten Stapel 12 erzielt wird. Das bedeutet, der intelligente Stapel 12 wird wissen, welche Operation durchzuführen ist und wird sie basierend auf lediglich der Adresse durchführen, an die die Daten im Speicherabbild ge schrieben werden. Dies wird einen oder mehrere Taktzyklen pro Operation einsparen, wo dieses Merkmal aufgerufen wird. Dadurch wird die Ausführungsgeschwindigkeit von Java^TM-Code sehr verbessert, ohne den Computer 20 mit dem Laufen eines virtuellen Rechners oder ähnlichem im Hintergrund zu belasten.
Da der Programmiersprachen-Beschleunigungskern 10 der vorliegenden Erfindung leicht produziert und in existierende Entwürfe für Systeme und Vorrichtungen integriert werden könnte und da die Vorteile, wie hier beschrieben, ermöglicht werden, wird erwartet, dass er in der Industrie schnell akzeptiert werden wird. Aus diesen und anderen Gründen wird erwartet, dass die Nutzbarkeit und gewerbliche Anwendbarkeit der Erfindung sowohl in der Reichweite als auch bezüglich einer langen Dauerhaftigkeit bedeutend sein wird.
Alle der oben genannten Beispiele stellen nur einige der Beispiele erhältlicher Ausführungsformen der vorliegenden Erfindung dar. Ein Fachmann wird bereits beobachtet haben, dass vielzählige andere Modifizierungen und Veränderungen vorgenommen werden können, ohne den Schutzbereich der Erfindung zu verlassen. Dementsprechend ist die obige Offenbarung nicht als begrenzend beabsichtigt, und die angefügten Patentansprüche definieren den Schutzbereich der Erfindung.

Claims

Computersystem, das eine beschleunigte Verarbeitung von stapelorientierten interpretativen Sprachbefehlen bereitstellt, wobei das System (20) aufweist: eine native Verarbeitungseinheit (16) zum Ausführen von nativen Sprachbefehlen; einen Übersetzer (34) zum Übersetzen der interpretativen Sprachbefehle in native Sprachbefehle; gekennzeichnet durch die Tatsache, dass der Übersetzer (34) dazu in der Lage ist, ausgewählte Adresswerte (60, 62, 64) zu erzeugen, die ausgewählten Befehlen der nativen Sprachbefehle zugeordnet sind, wobei jeder der ausgewählten Befehle und der entsprechenden ausgewählten Adresswerte (60, 62, 64) einer entsprechenden Verarbeitungsbeschleunigungskern-Operation zugeordnet sind; einem Verarbeitungsbeschleunigungskern (10), der zur Kommunikation mit der nativen Verarbeitungseinheit (16) angeschlossen ist, wobei der Verarbeitungsbeschleunigungskern (10) aufweist eine Cache-Stapelspeichereinrichtung (38), die eine Vielzahl von Speicheradressorten aufweist, die durch entsprechende Werte der ausgewählten Adresswerte (60, 62, 64) indiziert sind, wobei die Speicheradressorte zum Speichern von Daten dienen, und zwar in Zuordnung zu entsprechenden Operationen der Verarbeitungsbeschleunigungskern-Operationen, eine Kernsteuerlogik (14, 40, 46), die auf die ausgewählten Adresswerte (60, 62, 64) anspricht und betriebsbereit ist, um das Schreiben und das Lesen der Daten, die den ausge wählten nativen Sprachbefehlen zugeordnet sind, in die Cache-Stapelspeichereinrichtung (38) hinein und aus dieser heraus zu steuern, und eine Arithmetiklogikeinheit (36) zum Empfangen der Daten von entsprechenden Orten der Speicheradressorte der Cache-Stapelspeichereinrichtung (38), wobei die Arithmetiklogikeinheit (36) betriebsbereit ist, die Verarbeitungsbeschleunigungskern-Operationen unter Verwendung der Daten durchzuführen, wobei jede der Verarbeitungsbeschleunigungskern-Operationen durch den entsprechenden Speicheradressort spezifiziert ist.
Computersystem nach Anspruch 1, dadurch gekennzeichnet, dass der Übersetzer (34) durch Übersetzungsbefehle implementiert ist, die von der nativen Verarbeitungseinheit (16) ausgeführt werden.
Computersystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Kernsteuerlogik (14, 40, 46) aufweist: eine Stapelsteuereinrichtung (40) zum Steuern des Schreibens und Lesens von Daten in die Cache-Stapelspeichereinrichtung (38) bzw. aus dieser heraus, und zwar gemäß einer Stapelmethodologie; und einen Decodierer (46) zum Decodieren von jedem der ausgewählten Adresswerte (60, 62, 64) zum Zwecke des Bestimmens der entsprechenden Verarbeitungsbeschleunigungskern-Operation.
Computersystem nach einem der Ansprüche 1 bis 3, gekennzeichnet durch eine Hauptspeichereinheit (30), und wobei die Kernsteuerlogik (14, 40, 46) ferner eine Direktspeicherzugriff-Steuereinrichtung (14) aufweist, die betriebsbereit ist, Daten von der Cache-Stapelspeichereinrichtung (38) in die Hauptspeichereinheit (30) zu verschieben, wenn die Cache-Stapelspeichereinrichtung (38) sich einem Stapelüberlaufzustand nähert, und die ferner betriebsbereit ist, Daten aus der Hauptspeichereinheit (30) in die Cache-Stapelspeichereinrichtung (38) zu laden, wenn die Cache-Stapelspeichereinrichtung (38) sich einem Stapelunterlaufzustand nähert.
Computersystem nach Anspruch 4, dadurch gekennzeichnet, dass die Direktspeicherzugriff-Steuereinrichtung (14) ferner betriebsbereit ist: eine lokale Variable aus der Hauptspeichereinheit (30) in die Cache-Stapelspeichereinrichtung (38) zu laden, und zwar für den Fall eines Variablen-Ladefehlschlages („Variable Load Miss"); eine lokale Variable in die Hauptspeichereinheit (30) zu speichern, und zwar für den Fall eines Variablen-Speicherfehlschlages („Variable Store Miss"); Daten von der Cache-Stapelspeichereinrichtung (38) in die Hauptspeichereinheit (30) zu übertragen, um Vorbereitungen für eine Kontext-Umschaltoperation zu treffen; und ein Verkettungskontext-Umschalten zu beschleunigen, indem nach Erfordernis Daten in die Cache-Stapelspeichereinrichtung (38) hinein bzw. aus dieser heraus verschoben werden.
Computersystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass jeder der ausgewählten Adresswerte (60, 62, 64) aufweist: eine Vielzahl von Bereichsauswahlbits (62) zum Auswählen aus einer Vielzahl von Speicherbereichen (52, 54, 56, 58) der Cache-Stapelspeichereinrichtung (38), wobei jeder der Speicher bereiche (52, 54, 56, 58) einen bestimmten Satz der Speicheradressorte beinhaltet; und eine Vielzahl von Auswahlbits (64) zum Auswählen von bestimmten Adressorten der Speicheradressorte von jedem der Speicherbereiche (52, 54, 56, 58), und zum Bestimmen der durchzuführenden Operation.
Computersystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die interpretative Sprache Java^TM ist.
Computersystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Verarbeitungsbeschleunigungskern-Operationen arithmetische Operationen aufweisen.
Computersystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Verarbeitungsbeschleunigungskern-Operationen Bool'sche Logikoperationen aufweisen.
Verfahren zum Bereitstellen einer beschleunigten Verarbeitung von stapelorientierten interpretativen Sprachbefehlen in einem Computersystem (20), das eine native Verarbeitungseinheit (16) zum Ausführen von nativen Sprachbefehlen aufweist, gekennzeichnet durch die Tatsache, dass das Computersystem (20) einen Verarbeitungsbeschleunigungskern (10) aufweist, der zur Kommunikation mit der nativen Verarbeitungseinheit (16) angeschlossen ist, wobei der Verarbeitungsbeschleunigungskern (10) eine Cache-Stapelspeichereinrichtung (38) aufweist, die eine Vielzahl von Speicheradressorten beinhaltet, eine Steuerlogik (14, 40, 46) aufweist, die betriebsbereit ist, das Schreiben in und das Lesen aus der Cache-Stapelspeichereinrichtung (38) zu steuern, und eine Arithmetiklogikeinheit (36) aufweist, zum Empfangen von Daten aus entsprechenden Orten der Speicheradressorte der Cache-Stapelspeichereinrichtung (38), und die betriebsbereit ist, unter Verwendung der Daten Verarbeitungsbeschleunigungskern-Operationen durchzuführen, und wobei das Verfahren die Schritte aufweist: Empfangen von interpretativen Sprachbefehlen; Übersetzen (76) der interpretativen Sprachbefehle in native Sprachbefehle; Erzeugen von ausgewählten Adresswerten (60, 62, 64), die ausgewählten Befehlen der nativen Sprachbefehle zugeordnet sind, wobei die ausgewählten Befehle und die entsprechenden ausgewählten Adresswerte (60, 62, 64) jeweils einer entsprechenden Verarbeitungsbeschleunigungskern-Operation zugeordnet sind; Schreiben und Lesen von Daten, die den ausgewählten nativen Sprachbefehlen zugeordnet sind, in Orte der Cache-Stapelspeichereinrichtung (38) bzw. aus dieser heraus, wobei die Speicheradressorte durch entsprechende Werte der ausgewählten Adresswerte (60, 62, 64) indiziert sind, wobei die Daten zugeordnet sind zu entsprechenden Operationen der Verarbeitungsbeschleunigungskern-Operationen; und Bereitstellen der Daten aus entsprechenden Orten der Speicheradressorte der Cache-Stapelspeichereinrichtung (38) an die Arithmetiklogikeinheit (36), und Verwenden der Arithmetiklogikeinheit (36) dazu, die Verarbeitungsbeschleunigungskern-Operationen unter Verwendung der Daten durchzuführen, wobei jede der Verarbeitungsbeschleunigungskern-Operationen durch den entsprechenden Speicheradressort spezifiziert ist.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der Schritt des Übersetzens (76) das Ausführen von Befehlen unter Verwendung der nativen Verarbeitungseinheit (16) beinhaltet.
Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass die Kernsteuerlogik (14, 40, 46) aufweist: eine Stapelsteuereinrichtung (40) zum Steuern des Schreibens und Lesens von Daten in die Cache-Stapelspeichereinrichtung (38) bzw. aus dieser heraus, und zwar gemäß einer Stapel-Methodologie; und einen Decodierer (46) zum Decodieren von jedem der ausgewählten Adresswerte (60, 62, 64) zum Zwecke des Bestimmens der entsprechenden Kern-Operation.
Verfahren nach einem der Ansprüche 10 bis 12, gekennzeichnet durch Direktspeicherzugriffs-Steuerschritte: Verschieben von Daten aus der Cache-Stapelspeichereinrichtung (38) in eine Hauptspeichereinheit (30) des Computersystems (20), wenn sich die Cache-Stapelspeichereinrichtung (38) einem Stapelüberlaufzustand nähert; und Laden von Daten aus der Hauptspeichereinheit (30) in die Cache-Stapelspeichereinrichtung (38), wenn sich die Cache-Stapelspeichereinrichtung (38) einem Stapelunterlaufzustand nähert.
Verfahren nach Anspruch 13, gekennzeichnet durch Direktspeicherzugriffs-Steuerschritte: Laden einer lokalen Variable aus der Hauptspeichereinheit (30) in die Cache-Stapelspeichereinrichtung (38) für den Fall eines Variablen-Ladefehlschlages; Speichern einer lokalen Variable in die Hauptspeichereinheit (30) für den Fall eines Variablen-Speicherfehlschlages; Übertragen von Daten aus der Cache-Stapelspeichereinrichtung (38) in die Hauptspeichereinheit (30), um Vorbereitungen für eine Kontext-Umschaltoperation zu treffen; und Durchführen von beschleunigtem Verkettungskontext-Umschalten durch Verschieben von Daten in die Cache-Stapelspeichereinrichtung (38) bzw. aus dieser heraus, je nach Anforderung.
Verfahren nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, dass jeder der ausgewählten Adresswerte (60, 62, 64) aufweist: eine Vielzahl von Bereichsauswahlbits (62) zum Auswählen aus einer Vielzahl von Speicherbereichen (52, 54, 56, 58) der Cache-Stapelspeichereinrichtung (38), wobei jeder der Speicherbereiche (52, 54, 56, 58) einen bestimmten Satz der Speicheradressorte beinhaltet; und eine Vielzahl von Auswahlbits (64) zum Auswählen von bestimmten Orten der Speicheradressorte von jedem der Speicherbereiche (52, 54, 56, 58), und zum Bestimmen der durchzuführenden Verarbeitungsbeschleunigungskern-Operation.
Verfahren nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, dass die interpretative Sprache Java^TM ist.
Verfahren nach einem der Ansprüche 10 bis 16, dadurch gekennzeichnet, dass die Verarbeitungsbeschleunigungskern-Operationen arithmetische Operationen beinhalten.
Verfahren nach einem der Ansprüche 10 bis 17, dadurch gekennzeichnet, dass die Verarbeitungsbeschleunigungskern-Operationen Bool'sche Logikoperationen beinhalten.