DE69803304T2

DE69803304T2 - Hardwareunterstütztes verfahren zum kontextwechsel

Info

Publication number: DE69803304T2
Application number: DE69803304T
Authority: DE
Inventors: D. Arnold; Eric Chesters; G. Fleck; Bruce Holmer; Vojin Oklobdzija
Original assignee: Infineon Technologies North America Corp
Current assignee: Infineon Technologies AG
Priority date: 1997-09-12
Filing date: 1998-09-04
Publication date: 2002-05-02
Anticipated expiration: 2018-09-05
Also published as: EP1012715A1; IL134236A0; KR20010030592A; WO1999014671A1; JP2001516922A; US6128641A; EP1012715B1; DE69803304D1

Description

Die vorliegende Erfindung betrifft eine Datenverarbeitungseinheit mit hardwareunterstützten Kontextwechselfähigkeiten. Die meisten eingebetteten und Echtzeit-Steuersysteme werden gemäß einem Modell entworfen, in dem Interrupt-Handler und durch Software verwaltete Tasks jeweils als auf ihrer eigenen virtuellen Mikrosteuerung ablaufend betrachtet werden. Dieses Modell wird im allgemeinen durch die Dienste eines Echtzeit-Ausführungs- oder -Betriebssystems unterstützt, die über den Merkmalen und Fähigkeiten der zu Grunde liegenden Maschinenarchitektur geschichtet werden. Eine virtuelle Mikrosteuerung kann als eine Task mit ihren eigenen Vielzweckregistern und zugeordneten Spezialfunktionsregistern, wie zum Beispiel Programmzähler, Programmstatuswort usw., angesehen werden, die den Kontext der Task darstellen. Die Abwicklung dieser virtuellen Mikrosteuerungen in den meisten bekannten Systemen erfolgt durch Software, die den jeweiligen Kontext sichert und wiederherstellt. Deshalb benötigt Software für eine solche Datenverarbeitungseinheit mehr Speicher, und das Ausführungsoverhead für die Kontextwechseloperation vermindert die für Anwendungstasks verfügbare Verarbeitungsbandbreite.
Aus US-A-4 074 353 sind mehrere Trap-Sicherungsbereiche bekannt, die verbunden sind, um einen Pool zu bilden, aus dem ein Bereich als Reaktion auf einen Trap- Zustand, wie zum Beispiel die Adressierung von unbenutzbarem Speicher, mit Kontext von verschiedenen Quellen geladen werden kann. Der geladene Bereich wird von dem Pool abgebunden, und verschiedene Zeiger werden so geändert, daß sie diese Abbindung wiedergeben. Der abgebundene Bereich wird dem Prozeß zugeordnet, der zum Zeitpunkt des Auftretens der Trap-Bedingung ablief, indem er effektiv an den Interrupt-Level eines solchen Prozesses angekoppelt wird. Unabhängig von dem Interrupt-Level wird eine Trap-Handler-Routine ausgeführt, die für die Beschaffenheit des Trap- Zustands spezifisch ist, und der abgebundene Bereich wird danach an den Pool zurückgegeben, und die verschiedenen Zeiger werden so geändert, daß sie diese Rückgabe wiedergeben.
Aus US-A-4 025 904 ist ein Kontextwechsel bekannt, bei dem die Speicheradresse eines Arbeitsraums eines Problemprogramms in dem Speicherarbeitsraum eines Interrupt-Programms gespeichert wird. Der Speicherarbeitsraum speichert einen Problemprogrammarbeitsraumzeiger, Programmzählerinhalte und die Inhalte eines Statusregisters beim Auftreten eines Interrupt. Der Bezug auf die Speicherstelle des Arbeitsraums erfolgt durch die Inhalte eines Arbeitsraum-Zeigerregisters. Beim Auftreten eines Interrupt werden die Inhalte des Registers in einem Element eines neuen Arbeitsraums gespeichert, indem neue Inhalte in das Arbeitsraum-Zeigerregister geladen werden.
Aus dem Artikel "Mechanism for High Speed Context Switch", IBM Technical Disclosure Bulletin, Band 36, Nr. 11, 1.11.1993, Seite 135, ist ein Kontextwechsel bekannt, bei dem der aktuelle Kontext eines aktuellen Prozesses in einem Kontextsicherungsbereich gesichert wird, indem Inhalte von Hardwareregistern in dem Sicherungsbereich gespeichert werden, der in dem Hauptspeicher angeordnet wird. Der Kontext des Prozesses, der wieder aufgenommen werden soll, wird durch Laden von Werten von Hardwareregistern aus dem Sicherungsbereich wiederhergestellt, wobei diese Werte von dem vorausgehenden Kontextwechsel gesichert werden.
Eine Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren und eine Datenverarbeitungseinheit mit der Möglichkeit eines schnellen hardwareunterstützten Kontextwechsels bereitzustellen, mit dem Ergebnis, daß weniger Speicherplatz benötigt wird und daß Ausführungsoverhead für Kontextwechseloperationen vermindert wird. Diese Aufgabe wird gelöst, indem ein Verbundlistenmechanismus verwendet wird, um Sicherungsbereiche in einem Speicher zu verbinden, wobei jeder Sicherungsbereich mindestens einen Teil eines Kontexts einer jeweiligen Task speichert.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, einen hardwareunterstützten Kontextwechsel bereitzustellen. Diese Aufgabe wird gelöst, indem die Hardware so entworfen wird, daß sie sowohl für den vollen Kontextwechsel, der beim Wechseln zwischen Tasks auftritt, als auch den begrenzten Kontextwechsel, der beim Aufruf einer Softwarefunktion oder bei der Rückkehr von einer Funktion zu ihrem Aufrufer auftritt, verwendbar ist. Sie dient daher zur Verminderung des Speicherplatz- und Ausführungsoverhead sowohl für Task- Wechsel als auch für Funktionsaufrufe und die Rückkehr.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Kontextwechsel von einer ersten Task zu einer zweiten Task in einer Datenverarbeitungseinheit bereitgestellt, die folgendes umfaßt: einen Speicher mit mindestens einem vorherigen Kontextsicherungsbereich und mindestens einem unbenutzten Kontextsicherungsbereich, wobei jeder Kontextsicherungsbereich einen ersten Teil zum Speichern des Kontexts und einen zweiten Teil zum Speichern eines Verbindungsworts aufweist; ein Registerfile mit mehreren Vielzweckregistern und einem Kontextwechselregister zum Speichern der Adresse des vorherigen Kontextsicherungsbereichs; eine Befehlssteuereinheit mit einem Programmzählerregister, einem Programmstatuswortregister und einer Kontextwechselsteuereinheit; und ein Mittel zum Koppeln des Speichers mit dem Registerfile und der Befehlssteuereinheit und zum Koppeln der Befehlssteuereinheit mit dem Registerfile; wobei das Verfahren die folgenden Schritte umfaßt: a) Durchführen des Kontextwechsels von der ersten Task zu der zweiten Task bei einem Befehl oder einer Ausnahme, wobei der Kontext den Inhalt einer vordefinierten Anzahl von Vielzweckregistern, den Inhalt des Programmzählerregisters und den Inhalt des Programmstatuswortregisters umfaßt; b) Beschaffen eines neuen Sicherungsbereichs von dem unbenutzten Sicherungsbereich; c) Speichern des Kontexts der ersten Task in dem ersten Teil des neuen Sicherungsbereichs; d) Speichern des Inhalts des Kontextwechselregisters in dem zweiten Teil des unbenutzten Kontextsicherungsbereichs, um tatsächliche Kontextsicherungsbereiche und unbenutzte Kontextsicherungsbereiche als jeweilige erste und zweite Kontextsicherungsbereiche zu verbinden; e) Speichern der Adresse des unbenutzten Kontextsicherungsbereichs in dem Kontextwechselregister; und f) Verbinden des neuen Sicherungsbereichs mit einem vorherigen Kontextsicherungsbereich; dadurch gekennzeichnet, daß Schritt c) das parallele Speichern des Inhalts mehrerer Register in dem Kontextsicherungsbereich umfaßt.
Eine Datenverarbeitungseinheit umfaßt ein Registerfile mit mehreren Vielzweckregistern und Spezialregistern, durch die die Hardware Kontextwechseloperationen verwalten kann. Die Datenverarbeitungseinheit umfaßt einen Speicher mit einem tatsächlichen Kontextsicherungsbereich und einem unbenutzten Kontextsicherungsbereich, der mit dem Registerfile gekoppelt ist. Ferner ist eine Befehlssteuereinheit mit einem Programmzählerregister und einem Programmstatusregister mit dem Speicher und dem Registerfile gekoppelt. Jeder Kontextsicherungsbereich enthält ein Wort mit Informationen, die zur Verbindung dieses Sicherungsbereichs mit dem nächsten Sicherungsbereich in einer Kette verbundener Sicherungsbereiche dienen. Freie Sicherungsbereiche (die gerade keine Kontextinformationen für "aktive" Tasks oder Funktionen enthalten) werden zu einer Kette verbunden. Gesicherte Kontexte, die sich aus einer Folge von Aufruf-Traps oder Interrupts ergeben, werden zu einer weiteren Kette verbunden, die als die vorherige Kontextliste bezeichnet wird. Der aktuelle Kontext ist in den Vielzweck- und Programmzustandsregistern des Prozessors verankert. Um den aktuellen Kontext zu sichern und einen neuen zu erzeugen, können von der Prozessorhardware die folgenden Schritte durchgeführt werden:
- ein Kontextsicherungsbereich wird der Frei- Liste entnommen,
- der aktuelle Kontext wird in dem
Sicherungsbereich gespeichert,
- der Sicherungsbereich wird am Kopf der vorherigen Kontextliste hinzugefügt.
Die obigen Schritte werden in Verbindung mit einem Funktionsaufruf oder bei Traps oder Interrupts durchgeführt. Sie lassen die aufgerufene Funktion bzw. den aufgerufenen Interrupt- oder Trap-Handler frei, um die allgemeinen Register und den weiteren Prozessorzustand zu modifizieren, ohne den Kontext der aufrufenden Funktion oder der unterbrochenen Task zu zerstören.
Zum Austritt aus einer aufgerufenen Funktion oder einem aufgerufenem Trap- oder Interrupt-Handler und zum Zurückkehren zum vorherigen Kontext werden von der Prozessorhardware die folgenden Schritte durchgeführt:
- der Sicherungsbereich am Kopf der vorherigen Kontextliste wird aus dieser Liste entfernt,
- der aktuelle Kontext wird aus dem gerade aus der vorherigen Kontextliste entfernten Sicherungsbereich geladen,
- der Sicherungsbereich wird zu der Frei- Kontextsicherungsbereichsliste hinzugefügt.
Die obigen Schritte werden automatisch als Teil des Funktionsrückkehrbefehls oder des Befehls zur Rückkehr aus einem Interrupt- oder Trap-Handler durchgeführt.
Um den Kontext einer aktuellen Task zu sichern und zu einer anderen Task zu wechseln, werden die obigen Kontextsicherungs- und Wiederherstellungsoperationen folgendermaßen gemeinsam verwendet:
- es wird ein Systemaufrufbefehl ausgegeben, der einen Task-Wechsel anfordert,
- das Systemaufruf-Trap bewirkt, daß der aktuelle Kontext wie bereits beschrieben gesichert wird,
- der Trap-Handler für das Systemaufruf-Trap ändert den Wert des Prozessorregisters, das auf den Kopf der vorherigen Kontextliste zeigt, so daß er auf den Sicherungsbereich für die Task zeigt, zu der die Ausführung gewechselt werden soll,
- der Trap-Handler endet, wodurch der Kontext für die neue Task geladen und diese Task weiter ausgeführt wird.
Bei einer Verfeinerung des Verfahrens, die die grundlegende Erfindung nicht ändert, wird der Prozessorkontext in zwei Teile, den oberen Kontext und den unteren Kontext, aufgeteilt. Die beiden Teile können separat gesichert und wiederhergestellt werden. Die erste Kontextsicherungsoperation, die bei einem Funktionsaufruf, Interrupt oder Trap durchgeführt wird, sichert nur den oberen Kontext. Durch Softwarekonvention erwartet eine Funktion, die einen Aufruf ausgibt, daß ihr oberer Kontext über den Aufruf hinweg bewahrt wird, erwartet aber nicht, daß ihr unterer Kontext bewahrt wird. Die aufgerufene Funktion muß deshalb niemals die Kosten des Sicherns des unteren Kontexts tragen. Ein Trap- oder Interrupt-Handler, der keine Registerwerte in dem unteren Kontext modifiziert, kann ebenfalls die Kosten des Sicherns des unteren Kontexts vermeiden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 zeigt die relevanten Teile einer Datenverarbeitungseinheit zum Wegwechsel gemäß der vorliegenden Erfindung,
Fig. 2 zeigt ein Diagramm der Organisation der Kontextsicherungsbereiche in dem Speicher und den zugeordneten Systemregistern,
Fig. 3 zeigt ein Schema zum Verändern der Inhalte der Kontextwechselregister bei einem Task-Wechsel,
Fig. 4 zeigt die Organisation der Kontextsicherungsbereiche in einem Speicher nach einem Kontextwechsel gemäß Fig. 2,
Fig. 5 zeigt den oberen und unteren Kontext einer Datenverarbeitungseinheit gemäß der vorliegenden Erfindung, und
Fig. 6 zeigt ein Flußdiagramm eines sequenziellen Ausführungsmodells.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

Die Datenverarbeitungseinheit gemäß der vorliegenden Erfindung liefert die Möglichkeit, ein Echtzeit- Ausführungs- oder -Betriebssystem zu erzeugen, das sehr "dünn" sein kann. Ein großer Teil der Aufgabe des Wechselns zwischen einer Task und einer anderen wird durch die Hardware selbst effizient abgewickelt. Im Verlauf der vorliegenden Beschreibung wird der Begriff Task in einem allgemeinen Sinne verwendet und soll einen unabhängigen Steuerablauf mit seinem eigenen Kontext bedeuten, der den Zustand des virtuellen Prozessors definiert, auf dem er abläuft. Es ist nützlich, zwei Arten von Tasks zu unterscheiden: von Software verwaltete Tasks (SMT) und Interrupt- Serviceroutinen (ISR). Von Software verwaltete Tasks werden durch die Dienste eines Echtzeit-Kernels oder -Betriebssystems erzeugt und durch Ablaufsteuerungssoftware gesteuert abgeschickt. Interrupt-Serviceroutinen werden von der Hardware als Reaktion auf ein Interrupt abgeschickt. In bestimmten Systemen besteht die Hauptaufgabe einer ISR einfach darin, eine von Software verwaltete Task in eine Warteschlange einzureihen und zu der Task-Ablaufsteuerung zu springen. In diesen Sytemen ist es tatsächlich eine von Software verwaltete Task, die vom Funktionsstandpunkt aus gesehen auf das Interrupt-Ereignis reagiert. Von Software verwaltete Tasks werden manchmal an anderer Stelle Benutzertasks bezeichnet. Dies bedeutet eine Annahme, daß sie im Benutzermodus ausgeführt werden, während ISR erwartungsgemäß im Supervisor-Modus ausgeführt werden. Bei eingebetteten Systemen laufen SMTs häufig jedoch aus Gründen des effizienten Zugangs zu Systembetriebsmitteln im Supervisor-Modus ab.
Fig. 1 zeigt ein Blockschaltbild relevanter Teile für den Task-Wechsel in einer Datenverarbeitungseinheit. Ein Speicher 1 ist durch D-Busse 4a und 4b mit einem Registerfile 2 gekoppelt. Das Registerfile 2 enthält eine erste Gruppe von Datenregistern 2a und eine zweite Gruppe von Adreßregistern 2b, die die Vielzweckregister bilden. Eine zweite Menge von Registern 2c bilden Systemregister, wobei Fig. 1 nur drei dieser Register zeigt, die für den Kontextwechsel notwendig sind. Die drei Register sind das FCX-Register 2d, das PCXI, das PCX-Register 2e und das FCXLMT-Register 2f. Die Systemregister können Teil des Registerfiles sein oder sich an anderer Stelle im Kern eines Mikroprozessors befinden. Außerdem zeigt Fig. 1 eine Befehlssteuereinheit 3, die über einen Bus 5 mit dem Speicher 1 und über einen Bus 6 mit dem Registerfile 2 verbunden ist. Die Befehlssteuereinheit ist für die Ausführung von Befehlen zuständig, die in einer Programmsequenz im Speicher 1 gespeichert sind. Deshalb umfaßt die Befehlssteuereinheit ein Programmzählerregister 3a und ein Programmstatuswortregister 3b. Zur Verwaltung des Task- Wechsels umfaßt die Befehlssteuereinheit 3 eine Kontextwechselsteuereinheit 3c.
Die Kontextwechselsteuereinheit 3c ist für das Sichern der Inhalte aller einer Task zugeordneten notwendigen Register zuständig, die den Kontext einer Task aufbauen. Eine Datenverarbeitungseinheit gemäß der Erfindung sichert den Kontext einer Task automatisch ohne jegliche zusätzliche Befehle, die durch jeweiliges Softwareprogramm bereitgestellt werden. Da die Kontextwechselsteuereinheit 3c Teil der Befehlssteuereinheit 3 ist, werden die jeweiligen Befehle oder Ereignisse von der Kontextsteuereinheit 3c geprüft. Im Fall eines Aufrufbefehls, einer Ausnahme, wie zum Beispiel bei externen Interrupts oder Traps, oder einem Systemaufrufbefehl speichert die Kontextwechselsteuereinheit 3c automatisch den Kontext in einem Speicherfeld, den sogenannten Kontextsicherungsbereichen. Die Verwaltung mehrerer Kontextsicherungsbereiche wird durch die spezifischen Task- Wechselregister 2d, 2e und 2f abgewickelt, die in dem Systemregisterfile 2 bereitgestellt werden.
Wie bereits erwähnt, ist jeder Task eine Menge von Zustandselementen zugeordnet, die zusammen als der Task-Kontext bekannt sind. Der Kontext ist alles vom Prozessor Benötigte, um den Zustand der zugeordneten Task zu definieren und ihre fortgesetzte Ausführung zu ermöglichen. Er enthält die allgemeinen Register der zentralen Verarbeitungseinheit, die die Task verwendet, den aktuellen Programmzähler der Task und ihr Programmstatuswort. Technisch gesehen enthält der Kontext außerdem die Inhalte des Task-Speicherraums und der verschiedenen Spezialfunktionsregister, die sich auf ihre Ausführung auswirken können, wie zum Beispiel die Speicherschutzregister usw. Bei dieser Ausführungsform wird der Begriff jedoch in einem engeren Sinne nur für den Zustand verwendet, der unmittelbar gesichert werden muß, wenn eine Task unterbrochen oder suspendiert wird, und unmittelbar wiederhergestellt werden muß, bevor ihre Ausführung wieder aufgenommen wird. Der Task-Speicherraum muß gewöhnlich nicht gesichert werden, da er in der Regel unverändert gelassen wird, während die Task suspendiert ist, und keiner anderen Task zugewiesen wird.
Bei einem Interrupt suspendiert der Prozessor die Ausführung der aktuellen Task durch Sichern ihres Kontexts im Speicher, bevor die Ausführung des Interrupt-Handlers begonnen wird. Später kann der gesicherte Kontext wieder geladen werden, um die Ausführung der unterbrochenen Task wieder aufzunehmen.
Bei einem Funktionsaufruf weist die aufrufende Routine ebenfalls einen Kontext auf, der gesichert und dann wiederhergestellt werden muß, um die Ausführung des Aufrufers nach der Rückkehr von der Funktion wieder aufzunehmen. Der Hauptunterschied besteht darin, daß Interrupts asynchron auftreten, so daß der gesicherte Kontext alle Register enthalten muß, die die unterbrochene Task möglicherweise verwendet, während Aufrufe synchron sind. Die aufrufende Funktion weiß, wann sie einen Aufruf einleiten wird, so daß aufrufende und aufgerufene Funktionen zusammenwirken können, um die Menge von Kontext, die gesichert und wiederhergestellt werden muß, möglichst gering zu halten. Dies geschieht durch Aufteilen der allgemeinen Register in Teilmengen: Register, deren Inhalte über den Aufruf hinweg bewahrt werden, nämlich nichtflüchtige Register, und Register, deren Inhalte nicht bewahrt werden, nämlich Scratch-Register. Der Aufrufer ist dafür zuständig, vor dem Aufruf jedweden Kontext, der in Scratch-Registern verankert ist, zu bewahren, während die aufgerufene Funktion dafür zuständig ist, die Werte des Aufrufers in etwaigen nichtflüchtigen Registern, die die aufgerufene Funktion benutzt, zu bewahren. Die aufrufende Funktion bewahrt ihren Scratch-Register-Kontext gegebenenfalls entweder durch Sichern der Register im Speicher oder durch Kopieren dieser in nichtflüchtige Register. Aber die Compiler-Register-Zuteilungsvorrichtung versucht, jede dieser Aktionen möglichst gering zu halten, indem mitverfolgt wird, welche Datenelemente über einen Aufruf hinweg aktiv sind, vor dem Aufruf definiert und nach diesem verwendet werden, und teilt diese Elemente nichtflüchtigen Registern zu. Ähnlich versucht der Compiler, die Menge von Kontextsicherung und - wiederherstellung in der aufgerufenen Funktion möglichst gering zu halten, indem die Anzahl von ihr benutzter nichtflüchtiger Register möglichst klein gehalten wird.
Eine Datenverarbeitungseinheit gemäß der vorliegenden Erfindung fügt zu diesem Bild die Möglichkeit hinzu, Kontext schneller als herkömmliche Mikroprozessoren und Mikrosteuerungen zu sichern und wiederherzustellen. Dabei verwendet sie einen breiten Bus, um Blöcke von On-Chip-Speicher zu synchronisieren. Bus 4a und Bus 4b sind jeweils mindestens etwa zwei oder mehr Register breit. Wie in Fig. 1 gezeigt, sind deshalb zum Beispiel vier Register, ein Gerade- und ein Ungerade- Datenregister und ein Gerade- und ein Ungerade- Adreßregister parallel zugänglich. Dies geschieht durch Gruppieren von Datenregistern und Adreßregistern jeweils zu einer Gruppe von Ungerade- und Gerade- Registern. Das Hauptmerkmal besteht darin, daß das Sichern der nichtflüchtigen Register mit dem Aufrufbefehl integriert ist, so daß es parallel zu dem Aufrufsprung erfolgt. Ähnlich ist die Wiederherstellung der Register mit dem Rückkehrbefehl integriert und erfolgt parallel zum Rückkehrsprung. Die aufgerufene Funktion muß sich selbst nicht um das Sichern und Wiederherstellen des Kontexts des Aufrufers kümmern und wird von der Anforderung befreit, die Anzahl von ihr verwendeter nichtflüchtiger Register möglichst gering zu halten.
Bei einem Interrupt wird dieser genauso wie ein Aufrufbefehl abgewickelt. Ein weiteres Merkmal der vorliegenden Erfindung besteht darin, daß jeder Kontext in zwei Kontextteile aufgeteilt wird, die als der obere Kontext und der untere Kontext bezeichnet werden. Der obere und der untere Kontext können vorzugsweise dieselbe Größe aufweisen, gegebenenfalls aber auch verschieden groß sein. Der Verbundlistenmechanismus ist insofern zweckmäßig, als jeder Kontextsicherungsbereich gegebenenfalls verschieden groß sein kann. Der Inhalt des oberen Kontexts ist in Fig. 5 mit der Zahl 8 gezeigt, und der Inhalt des unteren Kontexts ist in Fig. 5 mit der Zahl 9 gezeigt. Der obere Kontext 8 besteht aus den oberen Adreßregistern A10-A15 und den oberen Datenregistern D8-D15. Dabei handelt es sich um die Register, die für den Zweck des Funktionsaufrufs als nichtflüchtig gekennzeichnet sind. Der obere Kontext enthält außerdem das Prozessorstatuswort PSW. Der untere Kontext 9 besteht aus den unteren Adreßregistern A2-A7 und den unteren Datenregistern DO-D7, plus dem Interrupt-Programmzählerwert. Der obere und der untere Kontext 8, 9 enthalten beide ein Verbindungswort. In dem oberen Kontext ist die Verbindung jedoch in dem PCXI eingebettet. Die Register A0-A1 in den unteren Adreßregistern und A8-A9 in den oberen Adreßregistern werden als globale Register des Systems definiert. Sie sind in keiner Kontextaufteilung enthalten und werden nicht über Aufrufe und Interrupts hinweggesichert und wiederhergestellt - Sie werden normalerweise vom Betriebssystem verwendet, um das Systemoverhead zu vermindern und können wahlweise vor unbeabsichtigter Modifikation durch Anwendungstasks schreibgeschützt werden. Wenn ein Aufruf oder ein Interrupt ausgeführt wird, wird nur der obere Kontext automatisch im Speicher 1 gespeichert. Der untere Kontext kann jedoch durch einen speziellen Befehl gespeichert werden, der bewirkt, daß jeweiliger Speicher zugeteilt wird und die Inhalte des unteren Kontexts auf unten ausführlicher erläuterte Weise gespeichert wird. Für kleine Interrupt-Handler oder Aufruf-Befehls-Handler, die vollständig in der beim Interrupt gesicherten Menge von Registern ausgeführt werden können, ist keine weitere Kontextsicherung notwendig. Der jeweilige Handler kann sofort ausgeführt werden und zurückkehren, wobei die ungesicherten Teile des Kontexts der unterbrochenen Task unberührt bleiben. Wenn ein Interrupt-Handler Aufrufe durchführt, ist nur ein zusätzlicher Befehl notwendig, um die Register zu sichern, die nicht als Teil der Interruptfolge gesichert wurden.
Da der untere Kontext bei einem Auf ruf oder einer Ausnahme normalerweise nicht gespeichert wird, können die zugeordneten Register des unteren Kontexts verwendet werden, um Argumente an eine aufgerufene Funktion weiterzuleiten. Da sie nicht automatisch als Teil einer Rückkehrfolge wiederhergestellt werden, können sie gleichermaßen verwendet werden, um Rückgabewerte von den aufgerufenen Funktionen zu ihren Aufrufern zurückzuleiten.
Fig. 6 zeigt ein sequenzielles Ausführungsmodell zum Verständnis der Ausnahme- und Interrupt-Abwicklung einer Datenverarbeitungseinheit gemäß der vorliegenden Erfindung. Das grundlegende Ausführungsmodell ist ein grundlegendes Ausführungsmodell eines sequenziellen Ausführungsflusses. Jeder Befehl wird einzeln im Schritt 60 abgerufen, im Schritt 62 decodiert und im Schritt 64 ausgeführt. Wenn ein Befehl eine Ausnahme verursacht, wird dies in den Schritten 61, 63 und 65 geprüft. Danach sind keine Nebeneffekte oder Aktualisierungen von einem folgenden Befehl in der Maschine sichtbar. Dies ist sehr wichtig, da dadurch das Ausnahmeabwicklungsmodell sehr vereinfacht wird. Im Schritt 66 wird der Zustand der Programmzählerregister, Vielzweckregister und des Speichers aktualisiert, und im Schritt 68 wird geprüft, ob ein Interrupt ansteht. Die Schritte 67 und 69 setzen die jeweiligen Trap- oder Interrupt-Randler.
Eine Datenverarbeitungseinheit gemäß der vorliegenden Erfindung verwendet Verbundlisten von Kontextsicherungsbereichen (CSA5) fester Größe. Fig. 2 zeigt, wie diese CSA5 im Speicher 1 organisiert werden. Die Inhalte des PCX-Registers 2e zeigen auf eine Adresse, an der ein Kontextsicherungsbereich CSA2 beginnt. Ein Kontextsicherungsbereich kann zwei Teile aufweisen, wobei der erste Teil den tatsächlichen Kontext und ein zweiter Teil 1b einen Zeiger auf einen anderen Kontextsicherungsbereich, den Kontextsicherungsbereich CSA 1 in Fig. 2, enthält. Das FCX-Register 2d zeigt auf den ersten einer Liste unbenutzter Kontextsicherungsbereiche CSA3, CSA4 und CSA5. Jeder Kontextsicherungsbereich CSA3, CSA4 und CSA5 umfaßt ein Verbindungswort 1c, 1d und 1e, das die Adresse des folgenden CSA enthält. Deshalb enthält das FCX-Register die Startadresse von CSA3, das Verbindungswort 1c enthält die Adresse von CSA4 und das Verbindungswort 1d enthält die Startadresse von CSA5. Das Systemregisterfile enthält außerdem einen Komparator 2g, der die Inhalte des FCX-Registers 2d und des FCXLMT-Registers 2f vergleicht. Wenn die Inhalte beider Register 2d und 2f gleich sind, wird ein Signal zu dem Endgerät 7 gesendet.
Bei einem CSA handelt es sich zum Beispiel um 16 Wörter eines On-Chip-Speichers mit einer Ausrichtung auf einer 16-Wort-Grenze. Ein einzelner CSA kann genau einen oberen oder einen unteren Kontext 8, 9 halten (siehe Fig. 5). Wie in Fig. 8 und 9 gezeigt, beginnt das Startwort des oberen bzw. unteren Kontextsicherungsbereichs 8, 9 mit dem Verbindungswort oder PCXI. Dadurch wird der Datenteil 1a, 1b, 1c, 1d und 1e von Fig. 2 dargestellt. In Fig. 2 werden unbenutzte Kontextsicherungsbereiche CSA3, CSA4, CSA5 auf einer Frei-Liste miteinander verbunden. Das Kontextwechselregister 2d zeigt auf die ersten Kontextsicherungsbereiche CSA3 der Verbundliste. Sie werden je nach Bedarf aus der Frei-Liste beschafft und an diese zurückgegeben, wenn sie nicht mehr benötigt werden. Die Zuteilung und Freigabe erfolgt durch die Prozessorhardware und ist für Anwendungscode transparent. Nur der System-Startup-Code und bestimmte Ausnahme-Abwicklungsroutinen des Betriebssystems müssen explizit auf die CSA-Listen in der Speicherung zugreifen.
Die Kontextsicherungsbereiche CSA2 und CSA1 sind als eine Liste benutzter Kontextsicherungsbereiche miteinander verbunden. Das Kontextwechselregister 2e zeigt immer auf den tatsächlichen Kontextwechselbereich, bei dem es sich im Fall von Fig. 2 um den Kontextsicherungsbereich CSA2 handelt.
Wie bereits erwähnt, zeigt das FCX-Register 2d immer auf einen verfügbaren CSA, wobei der obere Kontext automatisch im Fall eines Aufrufs oder Interrupts gesichert werden kann oder der untere Kontext im Fall eines Spezialbefehls gesichert werden kann. Kurz bevor ein Kontext in diesem Bereich gesichert wird, wird jedoch das Verbindungswort aus diesem gelesen, das einen neuen Wert für FCX liefert. Für das Speicherteilsystem ist der Kontextwechsel deshalb eine Lese-Änderungs-Schreib-Operation. Der neue Wert von FCX ist unmittelbar für nachfolgende Aufrufe oder Interrupts oder zum expliziten Sichern des unteren Kontexts verfügbar.
Das FCXLMT-Register 2f wird verwendet, um einen bevorstehenden CSA-Listenunterlauf zu erkennen. Wenn der Wert von FCX, der bei einem Interrupt oder Aufruf verwendet wird, mit dem Grenzwert übereinstimmt, wird die Kontextsicherungsoperation abgeschlossen, aber der Komparator 2g erzeugt das Trap-Signal, das erzwingt, daß die Zieladresse zu der Trap-Vektoradresse für die CSA-Listenerschöpfung wird. Die von dem Trap-Handler unternommene Aktion hängt vom Systementwurf ab; er könnte eine System-Rücksetzung ausgeben, falls bestimmt wird, daß die CSA-Listenerschöpfung durch einen nichtbehebbaren Softwarefehler verursacht wurde. Normalerweise erweitert er jedoch die Frei-Liste entweder durch Zuteilen zusätzlichen Speichers oder durch Beenden einer oder mehrerer Tasks und Wiedereinnahme ihrer CSA-Aufrufketten. In diesen Fällen endet der Trap-Handler mit einer Rückkehr aus dem Ausnahmebefehl und das ursprüngliche Interrupt wird eingeleitet, oder der Aufrufbefehl Lese-ausgeführt.
Das PCX-Feld in dem PCXLPCX-Register zeigt auf den CSA für den vorherigen Kontext, zum Beispiel den Kontext, der wiederhergestellt wird, wenn ein jeweiliger Rückkehrbefehl ausgeführt wird. Es handelt sich um den Listenkopfzeiger für eine Verbundliste gesicherter Kontexte. Der gesicherte Kontext, auf den er zeigt, könnte ein oberer oder unterer Kontext sein, abhängig davon, ob die vorhergehende Kontextsicherungsoperation für einen Aufruf-, Interrupt- oder Trap-Vorgang oder für die Kontextsicherungsbefehlsoperation erfolgte.
Das folgende Beispiel zeigt eine Kontextsicherungsoperation. In diesem einfachen Beispiel enthält die Frei-Kontextliste drei freie CSAs, nämlich CSA3, CSA4 und CSA5, und die vorherige Kontextliste enthält zwei CSAs, nämlich CSA2 und CSA1 (siehe Fig. 2). Wenn die Kontextsicherungsoperation durchgeführt wird, wird der erste Kontextsicherungsbereich in der Frei-Kontextliste CSA3 herausgezogen und an erster Stelle der vorherigen Kontextliste angeordnet. Diese Verschiebung von der Frei- zu der vorherigen Kontextliste umfaßt die Aktualisierung des PCX-Registers 2e und des FCX- Registers 2d und des Verbindungsworts für die transferierten Kontextsicherungsbereiche auf die folgende Weise (siehe Fig. 3). Möglicherweise könnte ein zusätzliches Hilfsregister verwendet werden, um diese Prozedur abzuschließen. Das Hilfsregister wird mit dem Inhalt des Verbindungsworts 1c von CSA3 geladen, das Verbindungswort von CSA3 1c wird mit dem Inhalt des PCX-Registers 2e geladen; das PCX-Register 2e wird mit dem Inhalt des FCX-Registers 2d geladen; und das FCX-Register wird mit dem Inhalt des Hilfsregisters geladen.
Die Kontext- und Kontextwechselregister sehen nun wie in dem in Fig. 4 gezeigten Diagramm aus. Der zu sichernde Prozessorkontext kann nun in den Rest von CSA3 geschrieben werden, der an die erste Stelle der vorherigen Kontextliste transferiert wurde.
Um einen Kontextsicherungsbereich wiederherzustellen, wird der wiederherzustellende Prozessorkontext aus dem CSA an der ersten Stelle der vorherigen Kontextliste gelesen, d. h. in diesem Fall aus CSA3. Der CSA wird nun aus der vorherigen Kontextliste an die erste Stelle der Frei-Kontextliste transferiert. Diese Verschiebung von der vorherigen zu der Frei-Kontextliste umfaßt das Aktualisieren des PCX-Registers 2e und des FCX- Registers 2d und des Verbindungsworts für den transferierten Kontextsicherungsbereich auf die folgende Weise. Das Hilfsregister wird mit dem Verbindungswort 1c von CSA3 geladen; das Verbindungswort 1c von CSA3 wird mit dem Inhalt des FCX-Registers 2d geladen; das FCX-Register 2d wird mit dem Inhalt des PCX-Registers 2e geladen; und das PCX-Register 2e wird mit dem Inhalt des Hilfsregisters geladen. Die Kontext- und Kontextwechselregister sehen nun wie in dem in Fig. 2 gezeigten Diagramm aus.
Zusätzlich zu der automatischen Sicherungs- und Wiederherstellungsfunktion, die durch die Kontextwechselsteuereinheit 3c ausgeführt wird, kann eine Datenverarbeitungseinheit gemäß der vorliegenden Erfindung dieselbe Prozedur zum Sichern eines oberen oder unteren Kontexts durch einen Spezialbefehl einleiten. Zum Beispiel kann ein Befehl zum Sichern des unteren Kontexts dieselbe Prozedur wie ein Aufrufbefehl oder eine Ausnahme einleiten. Zusätzlich kann ein sogenannter Kontextspeicherbefehl entweder den unteren oder den oberen Kontext speichern, ohne die Liste benutzter Kontextsicherungsbereiche oder unbenutzter Kontextsicherungsbereiche zu verändern. Eine Wiederherstellung des unteren Kontexts bewirkt dasselbe wie ein Rückkehrbefehl, während ein Kontextladebefehl entweder den unteren oder oberen Kontext aus dem tatsächlichen Kontextsicherungsbereich lädt, ohne die Liste benutzter und unbenutzter Kontextsicherungsbereiche zu ändern.

Claims

1. Verfahren zum Kontextwechsel von einer ersten Task zu einer zweiten Task in einer Datenverarbeitungseinheit, umfassend:

einen Speicher (1) mit mindestens einem vorherigen Kontextsicherungsbereich (CSA3, 1c, CSA4, 1d, CSA5, 1e) und mindestens einem unbenutzten Kontextsicherungsbereich (CSA2, 1b, CSA1, 1a), wobei jeder Kontextsicherungsbereich (CSA1, 1a, CSA2, 1b, CSA3, 1c, CSA4, 1d, CSA5, 1e) einen ersten Teil (CSA1, CSA2, CSA3, CSA4, CSA5) zum Speichern des Kontexts und einem zweiten Teil (1a, 1b, 1c, 1d, 1e) zum Speichern eines Verbindungsworts aufweist;

ein Registerfile (2) mit mehreren Vielzweckregistern (2a, 2b) und einem Kontextwechselregister (2c, 2d, 2e, 2f, 2g) zum Speichern der Adresse des vorherigen Kontextsicherungsbereichs (CSA3, 1c);

eine Befehlssteuereinheit (3) mit einem Programmzählerregister (3a), einem Programmstatuswortregister (3b) und einer Kontextwechselsteuereinheit (3c); und

ein Mittel (4a, 4b, 5, 6) zum Koppeln des Speichers (1) mit dem Registerfile (2) und der Befehlssteuereinheit (3) und zum Koppeln der Befehlssteuereinheit (3) mit dem Registerfile (2);

wobei das Verfahren die folgenden Schritte umfaßt:

a) Durchführen des Kontextwechsels von der ersten Task zu der zweiten Task bei einem Befehl oder einer Ausnahme, wobei der Kontext den Inhalt einer vordefinierten Anzahl von Vielzweckregistern (2a, 2b), den Inhalt des Programmzählerregisters (3a) und den Inhalt des Programmstatuswortregisters (3b) umfaßt;

b) Beschaffen eines neuen Sicherungsbereichs (CSA2, 1b) von dem unbenutzten Sicherungsbereich (CSA2, 1b, CSA1, 1a);

c) Speichern des Kontexts der ersten Task in dem ersten Teil (CSA2) des neuen Sicherungsbereichs (CSA2, 1b);

d) Speichern des Inhalts des Kontextwechselregisters (2c, 2d, 2e, 2f, 2g) in dem zweiten Teil (1b) des unbenutzten Kontextsicherungsbereichs (CSA2, 1b), um tatsächliche Kontextsicherungsbereiche (CSA3, CSA4, CSA5) und unbenutzte Kontextsicherungsbereiche (CSA2, CSA1) als jeweilige erste und zweite Kontextsicherungsbereiche zu verbinden;

e) Speichern der Adresse des unbenutzten Kontextsicherungsbereichs (CSA1, 1a) in dem Kontextwechselregister (2c, 2d, 2e, 2f, 2g); und

f) Verbinden des neuen Sicherungsbereichs (CSA2, 1b) mit einem vorherigen Kontextsicherungsbereich (CSA3, 1c);

dadurch gekennzeichnet, daß Schritt cl das parallele Speichern des Inhalts mehrerer Register (2a, 2b, 8, 9) in dem Kontextsicherungsbereich (CSA2) umfaßt.

2. Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten zum Wechseln zurück zu der ersten Task: Speichern des Inhalts des zweiten Teils (1b) des zweiten Kontextsicherungsbereichs (CSA2, 1b) in dem Kontextwechselregister (2c, 2d, 2e, 2f, 2g) und Wiederherstellen des in dem ersten Teil (CSA2) des ersten Kontextsicherungsbereichs (CSA2, 1b) gespeicherten Kontexts.

3. Verfahren nach Anspruch 1, wobei Schritt b) folgendes umfaßt: Zuweisen eines neuen Kontextsicherungsbereichs (CSA2, 1b) aus der Liste unbenutzter Kontextbereiche durch Speichern des Inhalts des zweiten Teils (1b) des ersten unbenutzten Kontextsicherungsbereichs (CSA2, 2b) der Verbundliste in einem ersten Kontextwechselregister (2e), Speichern des Inhalts eines zweiten Kontextwechselregisters (2d) in dem ersten Kontextwechselregister (2e), Speichern des Inhalts des ersten Kontextwechselregisters (2e) in dem zweiten Teil (1b) des neu zugewiesenen Kontextsicherungsbereichs (CSA2, 1b) und Speichern des Kontexts in dem ersten Teil (CSA2) des neu zugewiesenen Kontextsicherungsbereichs (CSA2, 1b)

4. Verfahren nach Anspruch 3, weiterhin mit den folgenden Schritten zum Wechseln zurück zu der ersten Task: Speichern des Inhalts des zweiten Teils (1b) des tatsächlichen Kontextsicherungsbereichs (CSA2, 1b) in dem ersten Kontextwechselregister (2e), Speichern des Inhalts des ersten Kontextwechselregisters (2e) in dem zweiten Kontextwechselregister (2d), Speichern des Inhalts des zweiten Kontextwechselregisters (2d) in dem zweiten Teil (1c) des tatsächlichen Kontextsicherungsbereichs (CSA3, 1c) und Wiederherstellen des Kontexts, der in dem ersten Teil (CSA2) des. Kontextsicherungsbereichs (CSA2, 1b) gespeichert ist, der durch das erste Kontextwechselregister (2e) angegeben wird.

5. Verfahren nach Anspruch 4, weiterhin mit einem dritten Kontextwechselregister (2f) zum Speichern der Adresse eines definierbaren unbenutzten Kontextsicherungsbereichs in der Verbundliste und einem Komparator (2g), der mit dem zweiten und dritten Kontextwechselregister (2d, 2f) gekoppelt ist und eine Ausnahme erzeugt, wenn die Inhalte beider Register gleich sind.

6. Verfahren nach Anspruch 1, wobei jeder Kontext in mindestens einen oberen und einen unteren Kontext (8, 9) aufgeteilt wird, wobei der obere Kontext (8) durch die Kontextsteuerwechselsteuereinheit (3c) gespeichert wird und der untere Kontext durch einen Befehl speicherbar ist, der einen zusätzlichen Taskwechsel auslöst.

7. Verfahren nach Anspruch 6, wobei der obere und untere Kontext (8, 9) dieselbe Größe aufweisen.

8. Verfahren nach Anspruch 1, wobei die Vielzweckregister (2a, 2b) in dem Registerfile (2) in mehreren Gruppen organisiert sind, die parallel zugänglich sind.

9. Verfahren nach Anspruch 8, wobei die mehreren Gruppen eine erste Gruppe von Adressregistern (2b) und eine zweite Gruppe von Datenregistern (2a) umfassen.

10. Verfahren nach Anspruch 9, wobei die erste und zweite Gruppe (2a, 2b) jeweils in Gruppen von Ungerade- und Gerade-Registern aufgeteilt werden, die parallel zugänglich sind.