DE69326705T2

DE69326705T2 - Verfahren und Anordnung zur Feststellung der Befehlsablauffolge in einem Datenverarbeitungssystem

Info

Publication number: DE69326705T2
Application number: DE69326705T
Authority: DE
Inventors: James B. Gullette; William C. Moyer; Kara B. Pepe
Original assignee: Motorola Inc
Current assignee: NXP USA Inc
Priority date: 1992-02-14
Filing date: 1993-01-25
Publication date: 2000-04-27
Anticipated expiration: 2013-01-26
Also published as: EP0555680A1; JPH06119297A; DE69326705D1; EP0555680B1; KR930018389A; US5594880A; KR100315880B1; JP3431941B2

Description

Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf Datenverarbeitungssysteme und im Besonderen darauf, Reihenfolgen in einem Datenverarbeitungssystem zu erreichen.

Hintergrund der Erfindung

Da Mikroprozessorsysteme immer komplexer werden, sind neue Techniken erforderlich, um die effiziente Verwendung der Systemressourcen sicherzustellen. Zum Beispiel gibt es in vielen Multi-Prozessorsystemen einige Mikroprozessoren, die versuchen, sich einige der selben Systemressourcen zu teilen, wie etwa Speicher, einen Drucker oder einen Anschluß für eine Bildschirmanzeige. In diesen Multi-Prozessorsystemen ist entscheidend, dass die Kommunikationspfade oder Busse, die Informationen zwischen den Mikroprozessoren und den Systemressourcen austauschen, so effizient wie möglich verwendet werden.
Meldungen, die über Kommunikationspfade von Mikroprozessoren zu Systemressourcen gelangen, sind vergleichbar mit Autos, die über Straßen aus einem Teil der Stadt in einen anderen fahren. Falls der Verkehr auf den Kommunikationspfaden nicht so effizient wie möglich gehandhabt wird, wird der Verkehr beginnen, sich zu stauen und verstopft die Pfade. Im Ergebnis wird die Kommunikation zwischen den Mikroprozessoren und den Systemressourcen langsamer. Dies bewirkt, dass das ganze System langsamer arbeitet. Falls die Stauung auf den Kommunikationspfaden schlimm genug ist, wie im "Rush hour"-Verkehr, kann das ganze Mikroprozessorsystem langsam vor sich hin schleichen.
Aber im Gegensatz zu Autos kann nur eine Meldung gleichzeitig über den Mikroprozessor-Bus aus herkömmlichen elektrischen Leitern übertragen werden. Daher kann zu einer Zeit nur ein Mikroprozessor den Bus steuern und Informationen zu einem anderen Mikroprozessor oder einer Systemressource senden.
Mikroprozessoren müssen sich miteinander bewerben und untereinander festlegen, welcher der Prozessoren beim Bewerben erfolgreich war und für die Steuerung des Busses zuständig ist. Nur wenn sich ein Mikroprozessor erfolgreich beworben hat und so zum "Bus Master" geworden ist, kann dieser Mikroprozessor Informationen über den Bus senden oder empfangen. Die anderen Mikroprozessoren müssen solange warten, bis sie "Bus Master" sind, um Informationen über den Bus zu senden oder zu empfangen.
Abgesehen von der Notwendigkeit, die Busse effizient zu verwenden, besteht die Notwendigkeit, die Systemressourcen effizient zu teilen, wie zum Beispiel einen Drucker. Falls sich mehrere Mikroprozessoren einen Drucker teilen, muss es einen Weg geben, anzuzeigen, welcher Mikroprozessor derzeit die Ressource benutzt und ob der Prozessor gerade eine Funktion ausführt, die nicht gestört werden darf. Für diese Funktion werden in vielen Multi-Prozessorsystemen Semaphore eingesetzt.
Semaphore sind eine Art von Markierung oder Zustandsanzeige, die den gegenwärtigen Zustand einer Systemressource widerspiegeln. Gewöhnlich zeigt die Zustandsinformation in einem Semaphor an, ob die Systemressource derzeit benutzt wird oder nicht. In einigen Multi-Prozessorsystemen kann das Semaphor auch Informationen darüber enthalten, welcher Mikroprozessor die Ressource benutzt, und möglicherweise sogar die Art der Funktion, die mit der Ressource durchgeführt wird.
Zum Beispiel kann eine spezielle Stelle im Speicher für die Stelle des Semaphors einer Druckerressource fest zugewiesen werden. Falls ein beliebiger Mikroprozessor die Benutzung des Druckers wünscht, muss dieser Mikroprozessor das Drucker- Semaphor durch Lesen der speziellen Stelle im Speicher lesen. Das Drucker-Semaphor enthält Informationen über den Status des Druckers wie etwa, ob der Drucker momentan benutzt wird. Falls das Drucker-Semaphor anzeigt, dass der Drucker momentan benutzt wird und somit beschäftigt ist, muss der Mikroprozessor warten. Der Mikroprozessor kann das Abfragen des Drucker- Semaphors fortsetzen, indem er periodisch das Drucker-Semaphor ließt, um nachzusehen, ob der Drucker immer noch benutzt wird oder ob er verfügbar geworden ist.
Sobald das Drucker-Semaphor anzeigt, dass der Drucker verfügbar ist, schreibt der wartende Mikroprozessor in das Drucker- Semaphor, um seinen Status auf "beschäftigt" zu ändern. Dadurch hat der wartende Mikroprozessor die Drucker-Ressource effektiv für seine eigenen Zwecke verriegelt. Solange das Drucker-Semaphor anzeigt, dass der Drucker beschäftigt ist, kann kein anderer Mikroprozessor den Drucker benutzen. Sobald der Mikroprozessor die Benutzung des Druckers abgeschlossen hat, schreibt er einen neuen Wert in die Stelle des Drucker- Semaphors, um das Drucker-Semaphor zu verändern, um anzuzeigen, dass der Drucker wieder verfügbar ist.
Es gibt ein entscheidendes Problem, das in Systemen auftritt, die Semaphore zur Zuweisung zu teilender Systemressourcen verwenden. Das Problem tritt dann auf, wenn mehr als ein Mikroprozessor das Semaphor der zu teilenden Ressource abfragt, um nachzusehen, ob die Ressource inzwischen verfügbar geworden ist. Zum Beispiel sei angenommen, dass sowohl Mikroprozessor Nr. 1 als auch Mikroprozessor Nr. 2 beide das Drucker-Semaphor abfragen. Mikroprozessor Nr. 1 ist der erste, der das Drucker-Semaphor ließt, nachdem es geändert wurde um anzuzeigen, dass der Drucker verfügbar ist. Dann ließt Mikroprozessor Nr. 2 das Drucker-Semaphor und stellt ebenfalls fest, dass der Drucker verfügbar ist. Weder Mikroprozessor Nr. 1 noch Mikroprozessor Nr. 2 erlangen Kenntnis davon, dass sich ein anderer Mikroprozessor um die Benutzung des Druckers bewirbt.
Falls Mikroprozessor Nr. 1 einen Interrupt (Unterbrechungsanforderung) empfängt, muss Mikroprozessor Nr. 1 eine Software-Interrupt-Routine ausführen, bevor er da weiterarbeiten kann, wo er aufgehört hatte. Zwischenzeitlich schreibt Mikroprozessor Nr. 2 einen Wert ins Drucker-Semaphor um anzuzeigen, dass der Drucker jetzt beschäftigt ist. Mikroprozessor Nr. 2 fährt dann mit der Benutzung des Druckers fort.
Mikroprozessor Nr. 1 beendet seine Interrupt-Routine und arbeitet da weiter, wo er in seinem Software-Programm aufgehört hatte. Mikroprozessor Nr. 1 hatte in dem Wissen aufgehört, dass der Drucker verfügbar ist. Daher schreibt Mikroprozessor Nr. 1 einen Wert ins Drucker-Semaphor um anzuzeigen, dass der Drucker jetzt beschäftigt ist und setzt dann den Versuch fort, den Drucker zu benutzen. Der Drucker wird aber schon von Mikroprozessor Nr. 2 benutzt. Das führt zu einer Kollision auf dem Bus zum Drucker. Im Ergebnis ist der Drukker nicht in der Lage, die Informationen von keinem der Mikroprozessoren richtig auszudrucken.
Ein Weg zur Lösung dieses Problems besteht darin, den Bus für die gesamte Zeit zu verriegeln, die vom Mikroprozessor benötigt wird, um sowohl einen Lesezugriff als auch den nachfolgenden Schreibzugriff auf das Semaphor im Speicher durchzuführen. "Verriegeln" des Busses bedeutet, dass der momentane Bus-Master der einzige Prozessor ist, dem erlaubt ist, den Bus für mehrere Bus-Zyklen zu verwenden. Normalerweise kommt das Bewerben um den Bus so häufig vor, dass alle Prozessoren die Chance haben, den Bus in regelmäßigen Intervallen zu benutzen. Die Verriegelung des Busses wird so durchgeführt, dass kein anderer Prozessor die Chance bekommt, Bus-Master zu werden und den Bus zu benutzen.
Ein Prozessor, der die Bewerbung um den Bus gewonnen hat und zum Bus-Master wurde, verriegelt den Bus, bevor er ein Semaphor ließt. Da der Bus verriegelt ist, können keine anderen Prozessoren den Bus benutzen. Dann ließt der Bus-Master-Prozessor das Semaphor aus dem Speicher und bestimmt, ob die Systemressource verfügbar ist. Falls die Ressource beschäftigt ist, entriegelt der Bus-Master-Prozessor den Bus und es kann eine Bewerbung um den neuen Bus-Master stattfinden. Wenn aber die Ressource verfügbar ist, hält der Bus-Master-Prozessor den Bus solange verriegelt, bis der Bus-Master-Prozessor in der Lage ist, einen neuen Wert in das Semaphor zu schreiben, das anzeigt, dass die Systemressource jetzt beschäftigt ist.
Durch Verriegelung des Busses ist zu einer Zeit nur ein Prozessor in der Lage, ein Semaphor zu lesen und nachzusehen, ob die Systemressource verfügbar ist, und einen Wert in das Semaphor zurückzuschreiben, der anzeigt, dass die Ressource jetzt beschäftigt ist. Daher gewährleistet die Verriegelung des Busses, dass tatsächlich nur ein Prozessor zur Zeit eine Systemressource benutzt. Damit werden Kollisionen auf dem Bus vermieden.
Die Verriegelung des Busses hat aber einen sehr entscheidenden Nachteil. Sie kann bewirken, dass die Kommunikation zwischen anderen Mikroprozessoren und Systemressourcen beachtlich langsamer wird. Und im Ergebnis kann das ganze System deutlich langsamer arbeiten.
Zum Beispiel kann ein Problem auftreten, wenn eine hierarchische Bus-Struktur eingesetzt wird, die mehrere Busse verwendet. Falls sich der Bus-Master-Prozessor und der Speicher, der das Semaphor enthält, an Bussen befinden, die voneinander sehr entfernt sind, muss der Bus-Master fortwährend alle Busse zwischen ihm und dem entfernt liegenden Speicher sowohl während des Lesezugriffs als auch während des nachfolgenden Schreibzugriffs auf das Semaphor verriegeln. Dies ist keine sehr effektive Verwendung der Bus-Zeit, insbesondere wenn man bedenkt, dass es sich beim Zugriff auf ein Semaphor in aller Regel um einen sehr häufigen Zugriff in einem Multi-Prozessorsystem handelt. Daher ist die Verriegelung des Busses keine sehr zufriedenstellende Lösung.
"Operating Systems: Design and Implementation" von Andrew S. Tannenbaum, 1987, Prentice-Hall International Inc. offenbart auf Seite 57 eine TEST AND SET LOCK (TSL) Computer-Anweisung, die in einer Subroutine aus vier Anweisungen zum Setzen und Löschen eines Markers (Flag) verwendet werden kann, um den Zugriff auf verteilten Speicher durch zwei Prozessoren zu koordinieren.

Zusammenfassung der Erfindung

Durch die vorliegende Erfindung werden die zuvor erwähnten Notwendigkeiten erfüllt und andere Vorteile erreicht. In einer Form weist die vorliegende Erfindung ein Verfahren zur Bestimmung einer Reihenfolge einer Vielzahl von Tasks (Aufgaben) auf, die zur Ausführung einer Anweisung in einer Datenverarbeitungseinheit nach Anspruch 1 erforderlich sind. Die vorliegende Erfindung umfasst auch ein Datenverarbeitungssystem nach Anspruch 7 zur Ausführung einer Anweisung, die eine Vielzahl von Tasks enthält.
Die vorliegende Erfindung wird von Personen, die mit der Technik vertraut sind, anhand der unten folgenden ausführlichen Beschreibung in Zusammenhang mit den sie begleitenden Abbildungen zu verstehen sein.

Kurzbeschreibung der Abbildungen

Abb. 1 veranschaulicht in Form eines Blockdiagramms ein Datenverarbeitungssystem und einen Bus in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung;
Abb. 2 veranschaulicht in Form eines Blockdiagramms einen Steuerregisterstapel der Abb. 1 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung; und
Abb. 3 veranschaulicht in Form eines Blockdiagramms ein hierarchisches Bus-System in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.

Beschreibung der bevorzugten Ausführungsform

Anstelle der Verriegelung des Busses verwendet die vorliegende Erfindung eine davon verschiedene Herangehensweise, um zu gewährleisten, dass nur ein Prozessor zur Zeit einen Semaphor-Wert empfängt, der anzeigt, dass eine Ressource verfügbar ist. Die vorliegende Erfindung stellt dadurch sicher, dass nur ein Prozessor zur Zeit versucht, eine Ressource zu benutzen. Und weil die vorliegende Erfindung nicht die Verriegelung irgendeines Busses erforderlich macht, kann der mögliche Durchsatz auf den Bussen in einigen Multi-Prozessorsystemen entscheidend erhöht werden.
Abb. 1 veranschaulicht eine Datenverarbeitungseinheit 10, die an einen externen Bus 12 angeschlossen ist. Obwohl es sich bei der in Abb. 1 gezeigten speziellen Datenverar beitungseinheit 10 um eine mit RISC-Architektur (Reduced Instruction Set Computer) handelt, kann jede beliebige Architektur oder Art von Datenverarbeitungseinheit 10 verwendet werden. Datenverarbeitungseinheit 10 ist in der Lage, Anweisungen auszuführen, die von einem Anwender oder einem Software-Programm vorgesehen sind.
Eine Ganzzahleinheit 14, eine Gleitkommaeinheit 16, eine Grafikeinheit 18, eine Lade-/Speicher-Ausführungseinheit 20, ein Registerstapel 22 und eine Superskalar-Anweisungseinheit 24 sind alle bidirektional an einen internen Bus 26 angeschlossen. Die Lade-/Speicher-Ausführungseinheit 20 wird zur Steuerung der Ausführung von Anweisungen innerhalb der Datenverarbeitungseinheit 10 verwendet. In einigen Ausführungsformen der vorliegenden Erfindung kann die Lade-/Speicher-Ausführungseinheit 20 eine Eingabe von Steueranschluss 27 empfangen. Der Registerstapel 22 enthält Informationsregister, die verwendet werden können, um verschiedene Datentypen zu speichern, wie zum Beispiel numerische Werte und Adressen. Ein Ziel-Anweisungs-Cache 28 ist an die Superskalar-Anweisungseinheit 24 zur Übertragung von Informationen an die Superskalar-Anweisungseinheit 24 angeschlossen.
"Memory management unit" (Speicherverwaltungseinheit) kann als "MMU" abgekürzt werden. Eine Daten-Cache-MMU 30 hat eine Speicherverwaltungseinheit 32, Marker 34 und einen Daten- Cache 36. Alle Blöcke innerhalb der Daten-Cache-MMU 30 können Informationen zu jedem beliebigen anderen Block innerhalb der Daten-Cache-MMU 30 übertragen. Die Marker 34 empfangen Informationen von der Lade-/Speicher-Ausführungseinheit 20. Der Daten-Cache 36 ist bidirektional an die Lade-/Speicher-Ausführungseinheit 20 angeschlossen. Eine Anweisungs-Cache-MMU 38 hat eine Speicherverwaltungseinheit 40, Marker 42 und einen Anweisungs-Cache 44. Alle Blöcke innerhalb der Anweisungs-Cache-MMU 38 können Informationen zu jedem beliebigen anderen Block innerhalb der Anweisungs-Cache-MMU 38 übertragen.
Die Marker 42 und die Speicherverwaltungseinheit 40 empfangen Informationen von der Superskalar-Anweisungseinheit 24. Der Anweisungs-Cache 44 sendet Informationen an die Superskalar- Anweisungseinheit 24. Speicherverwaltungseinheit 32 enthält einen Steuerregisterstapel 46. Der Steuerregisterstapel 46 kann von einem Anwender unter Verwendung des internen Busses 26 gelesen, beschrieben und programmiert werden. Der Datenpfad zum Lesen und Schreiben des Steuerregisterstapels 46, unter Verwendung des internen Busses 26, verläuft über die Lade-/Speicher-Ausführungseinheit 20 und den Daten-Cache 36. Auch der Steuerregisterstapel 46 überträgt Steuerinformationen an die Lade-/Speicher-Ausführungseinheit 20.
Ein Bus-Interface 48 ist bidirektional mit dem Daten-Cache 36 verbunden. Das Bus-Interface 48 empfängt Informationen von der Speicherverwaltungseinheit 32 und der Speicherverwaltungseinheit 40. Zusätzlich sendet das Bus-Interface 48 Informationen an die Marker 34 und den Anweisungs-Cache 44. Das Bus-Interface 48 ist ebenfalls bidirektional mit dem externen Bus 12 verbunden.
Abb. 2 veranschaulicht eine Implementierung des Steuerregisterstapels 46 der Abb. 1. Obwohl der Steuerregisterstapel 46 mit einer Breite von 32 Bit gezeigt wird, können andere Breiten verwendet werden. Und obwohl diese Ausführungsform den Steuerregisterstapel 46 als Teil der Speicherverwaltungseinheit 32 zeigt, kann sich der Steuerregisterstapel 46 tatsächlich irgendwo in der Datenverarbeitungseinheit 10 mit Zugriff auf die Lade-/Speicher-Anweisungseinheit 20 befinden. Der Steuerregisterstapel 46 enthält verschiedene Steuerregister, von denen nur eines, nämlich das Daten- MMU/Cache-Steuerregister 50 veranschaulicht wird.
Das Daten-MMU/Cache-Steuerregister 50 wird in dieser Spezifikation als Steuerregister 50 bezeichnet. Steuerregister 50 könnte sich irgendwo im Steuerregisterstapel 46 befinden. Tatsächlich muss das Steuerregister 50 nicht einmal Bestandteil des Steuerregisterstapels 46 sein, sondern es könnte sich irgendwo anders in der Datenverarbeitungseinheit 10 befinden.
Das Steuerregister 50 enthält ein XMEM-Steuerbit 52 (exchange register with memory) (nicht maßstabsgerecht gezeichnet). In anderen Ausführungsformen könnte sich das XMEM-Steuerbit 52 praktisch irgendwo in einer Speichereinrichtung in der Datenverarbeitungseinheit 10 befinden. Das XMEM-Steuerbit 52 müsste sich nicht in einem Steuerregister befinden, obwohl dies gewöhnlich eine praktische Stelle ist. Obwohl sich das XMEM-Steuerbit 52 in dieser Ausführungsform an Bit-Position 13 im Steuerregister 50 befindet, könnte sich das XMEM-Steuerbit 52 irgendwo im Steuerregister 50 befinden. Die anderen Steuerbits, die sich im Steuerregister 50 befinden, werden nicht gezeigt.
Die Vorteile der vorliegenden Erfindung werden vorrangig durch das XMEM-Steuerbit 52 und die Lade-/Speicher-Ausführungseinheit 20 erreicht, zusammen mit der zugehörigen Logik, die in jedem beliebigen Datenverarbeitungssystem verwendet werden könnte. Die Arbeitsweise des XMEM-Steuerbits 52 und der zugehörigen Logik wird unten erörtert.
Abb. 3 veranschaulicht ein Multi-Prozessorsystem mit einer hierarchischen Bus-Struktur. Bei den Datenverarbeitungseinheiten 54, 60 und 66 kann es sich jeweils um beliebige Arten von Datenverarbeitungseinheiten handeln, die das XMEM-Steuerbit 52 und die dazugehörige Logik haben. Aus Gründen der Einfachheit wird angenommen, dass es sich bei den Datenverarbeitungseinheiten 54, 60 und 66 um jeweils die gleiche Datenverarbeitungseinheit 10 aus Abb. 1 handelt.
Die Datenverarbeitungseinheit 54 und der Speicher 56 sind bidirektional an den Bus 58 angeschlossen. Die Datenverarbeitungseinheit 60 und der Speicher 62 sind bidirektional an den Bus 64 angeschlossen. Die Datenverarbeitungseinheit 66 und der Speicher 68 sind bidirektional an den Bus 70 angeschlossen. Der Bus 58 ist über den Bus-Schalter 72 bidirektional mit dem Bus 64 verbunden. Der Bus 64 ist über den Bus-Schalter 74 bidirektional mit dem Bus 70 verbunden. Der Bus 64 ist über den Bus-Schalter 76 bidirektional mit dem Bus 78 verbunden.
Eine wie in Abb. 3 veranschaulichte hierarchische Bus- Struktur ist eine Anordnung von mehreren lokalen Bussen, die mit anderen Bussen über Bus-Schalter kommunizieren können. Die Prozessoren und andere Einrichtungen am selben lokalen Bus können unter Verwendung nur ihres eigenen Busses miteinander kommunizieren. Falls aber ein Prozessor mit einer Einrichtung kommunizieren möchte, die sich an einem anderen lokalen Bus befindet, müssen die Informationen zwischen den beiden lokalen Bussen mit Hilfe eines oder mehrerer Bus- Schalter und möglicherweise anderer dazwischen liegender Busse übertragen werden.
Falls zum Beispiel die Datenverarbeitungseinheit 54 eine Stelle im Speicher 56 lesen möchte, ist nur der lokale Bus, Bus 58, erforderlich, um die Übertragung zu bewerkstelligen. Zunächst bewirbt sich die Datenverarbeitungseinheit 54 als Bus-Master für den Bus 58. Es ist anzumerken, dass das Sein des momentanen Bus-Masters eines Busses bedeutet, dass man "Besitzrechte" an diesen Bus hat. Sobald die Datenverarbeitungseinheit 54 Besitzrechte am Bus 58 hat, sendet die Datenverarbeitungseinheit 54 lediglich eine Adresse über den Bus 58 an den Speicher 56, zusammen mit einem Signal, das anzeigt, dass ein Lesezugriff stattfinden soll. Nach Zugriff auf die entsprechende Speicherstelle sendet Speicher 56 die in der Speicherstelle enthaltenen Daten über den Bus 58 zurück. In diese Übertragung von Informationen ist nur der Bus 58 einbezogen.
Falls aber die Datenverarbeitungseinheit 54 eine Stelle in einem entfernter liegenden Speicher lesen möchte, etwa in Speicher 68, sind alle Busse 58, 64 und 70 erforderlich, um die Übertragung zu bewerkstelligen. Zunächst bewirbt sich die Datenverarbeitungseinheit 54 als Bus-Master von Bus 58. Dann bewirbt sich die Datenverarbeitungseinheit 54 über den Bus- Schalter 72 als Bus-Master von Bus 64, Abschließend bewirbt sich die Datenverarbeitungseinheit 54 über den Bus-Schalter 74 als Bus-Master von Bus 70. Es ist anzumerken, dass die Datenverarbeitungseinheit 54 die Busse an sich bindet, an denen sie Besitzrechte hat, während sie fortgesetzt versucht, die Besitzrechte an den verbleibenden Bussen zu erlangen.
Die Datenverarbeitungseinheit 54 muss Besitzrechte an allen drei Bussen 58, 64 und 66 gewinnen, bevor sie eine Adresse und ein Lese-Signal an Speicher 68 über die drei Busse senden kann. Sobald dieser eine Adresse und ein Lese-Signal empfängt, greift Speicher 68 intern auf die Speicherstelle zu, auf welche die Adresse zeigt. Es sind wieder Besitzrechte an allen drei Bussen erforderlich, damit Speicher 68 die Daten zurücksenden kann, die in der Speicherstelle enthalten waren, auf die zugegriffen wurde. Alle drei Busse, 58, 64 und 70, sind in die Übertragung sowohl der Adressinformationen als auch in die nachfolgende Übertragung der Dateninformationen einbezogen.
Die Vorteile der vorliegenden Erfindung werden anhand des in Abb. 3 veranschaulichten Multi-Prozessorsystems beschrieben. Der Vorteil, dass keine Busse verriegelt werden, ist am deutlichsten in einem Multi-Prozessorsystem, das aufgeteilte Bus-Transaktionen und/oder "Pipelining" verwendet. Die Busse 56, 64 und 70 werden daher in der vorliegenden Erfindung als Busse betrachtet, die sowohl aufgeteilte Transaktionen als auch "Pipelining" unterstützen.
Ein System, dass aufgeteilte Bus-Transaktionen verwendet, ist eines, das verschiedenen Prozessoren gleichzeitig Besitzrechte am Adress-Bus und am Daten-Bus zubilligt. Diese Art von Bus wird als aufgeteilter Transaktions-Bus bezeichnet. Wenn ein aufgeteilter Transaktions-Bus verwendet wird, kann zum Beispiel Mikroprozessor Nr. 1 den Adress-Bus zu der selben Zeit benutzen, in welcher Mikroprozessor Nr. 2 den Daten-Bus benutzt. Bei ungeteilten Transaktions-Bussen ist der selbe Prozessor Bus-Master sowohl des Adress- als auch des Daten- Busses. Daher können die Besitzrechte am Adress-Bus und am Daten-Bus nicht aufgeteilt werden, wenn ungeteilte Busse verwendet werden. Aufgeteilte Transaktions-Busse werden häufig in Multi-Prozessorsystemen eingesetzt, um die Bandbreite der Busse zu erhöhen.
Ein Bus mit "Pipeline" ist ein Bus, der eine Überlappung der Adress-Phase einer Transaktion mit der Daten-Phase einer anderen Aktion gestattet. Viele Multi-Prozessorsysteme kombinieren aufgeteilte Transaktionen und "Pipelining", um die Übertragung von Informationen sowohl auf dem Adress-Bus als auch auf dem Daten-Bus zu maximieren.
Das in Abb. 2 veranschaulichte XMEM-Steuerbit 52 wird nur während einer besonderen Anweisung verwendet, einer XMEM- Anweisung (exchange register with memory, vertausche Register mit Speicher). Die XMEM-Anweisung tauscht den Inhalt eines Speichers mit dem Inhalt eines Registers aus, das im Registerstapel 22 in Abb. 1 angeordnet ist. In anderen Worten vertauscht die XMEM-Anweisung den Inhalt einer Speicherstelle mit dem Inhalt eines Registers. Wenn die Speicherstelle ursprünglich den Wert "X" enthält und das Register ursprünglich den Wert "Y" enthält, wird die XMEM-Anweisung deren Inhalte vertauschen. Nach der Ausführung der XMEM-Anweisung wird die Speicherstelle den Wert "Y" enthalten und das Register wird den Wert "X" enthalten. Die XMEM-Anweisung wird auf herkömmliche Weise von Teilen der in Abb. 1 veranschaulichten Schaltkreise empfangen und ausgeführt.
Die XMEM-Anweisung ist insbesondere nützlich in Multi-Prozessorsystemen, die Semaphore verwenden. Ein Prozessor, der die Verwendung einer speziellen Systemressource wünscht, liest das Semaphor der Ressource, um zu sehen, ob die Ressource verfügbar ist. Falls die Ressource nicht verfügbar ist, setzt der Prozessor die Abfrage des Semaphors durch periodisches Lesen des Semaphors fort. Sobald der Semaphor-Wert anzeigt, dass die Ressource verfügbar ist, führt der Prozessor eine XMEM-Anweisung aus, die zunächst den momentanen Wert des Semaphors in ein Register lädt und danach einen neuen Wert in das Semaphor schreibt, um anzuzeigen, dass die Ressource jetzt beschäftigt ist.
Dann schaut der Prozessor auf den Wert des Semaphors, das in das Register geladen wurde, um festzustellen, ob die Ressource beschäftigt oder verfügbar ist. Falls das Semaphor anzeigt, dass die Ressource verfügbar ist, weiß der Prozessor, dass die Ressource verfügbar war, als er seine XMEM- Anweisung begonnen hat. Und da bisherige Geräte es erforderlich machten, dass der Bus während einer XMEM-Anweisung verriegelt war, weiß der Prozessor, dass kein anderer Prozessor in der Lage war, zwischen den Lese- und Schreibabschnitten der XMEM-Anweisung auf das Semaphor zuzugreifen. Daher steht es dem Prozessor frei, die Ressource zu verwenden, mit dem Wissen, dass sich keine Kollisionen ergeben.
Wenn aber das während der XMEM-Anweisung in das Register geladene Semaphor anzeigt, dass die Ressource beschäftigt ist, weiß der Prozessor, dass die Ressource zwischen der letzten Lese-Abfrage des Semaphors und der Ausführung der XMEM-Anweisung von einem anderen Prozessor übernommen wurde. Daher weiß der Prozessor, dass er die Ressource nicht verwenden kann und statt dessen die Abfrage des Semaphors solange fortsetzen muß, bis es wieder anzeigt, dass die Ressource verfügbar ist.
In bisherigen Datenverarbeitungseinheiten wurde eine XMEM- Anweisung zum Austausch der Inhalte von Speicher und Register von einem Signal auf dem Bus zur Verriegelung des Busses begleitet, das anzeigte, dass eine XMEM-Operation stattfand. Der Speicher und die Bus-Zuteilungs-Logik verwendeten dieses Bus-Verriegelungs-Signal um sicherzustellen, dass das Lesen und das nachfolgende Schreiben der XMEM-Anweisung niemals von einem anderen Prozessor unterbrochen wurde, der Besitzrechte am Bus erlangt hatte. Der Bus mußte für die Dauer der XMEM- Anweisung verriegelt bleiben, damit einem Prozessor gewährleistet werden konnte, dass das Lesen und das nachfolgende Schreiben der XMEM-Anweisung als ein unteilbares Paar durchgeführt werden konnte. Falls es irgendeinem anderen Prozessor gestattet werden würde, Besitzrechte am Bus zwischen den Lese- und Schreibabschnitten der XMEM-Anweisung zu erlangen, würde XMEM zur Übertragung von Semaphoren nicht nützlich sein.
Die vorliegende Erfindung macht es aber nicht erforderlich, dass Busse zwischen dem XMEM-Lese-Bus-Zyklus und dem XMEM- Schreib-Bus-Zyklus verriegelt werden. Daher wird der mögliche Durchsatz auf den Bussen in einigen Bus-Umgebungen deutlich erhöht. Die XMEM-Anweisung in bisherigen Datenverarbeitungseinheiten nutzten ein Lesen (auch als "Laden" bezeichnet), gefolgt von einem Schreiben (auch als "Speichern" bezeich net). Die vorliegende Erfindung gestattet die Ausführung des Schreibabschnitts der XMEM-Anweisung vor dem Leseabschnitt. Als Ergebnis davon muss der Bus nicht verriegelt werden.
Zum Beispiel wird unter Bezugnahme auf Abb. 3 angenommen, dass die Datenverarbeitungseinheit 54 wünscht, auf das im Speicher 68 vorliegende Semaphor zuzugreifen. In bisherigen Systemen mussten alle drei Busse, 58, 64 und 70, sowohl für die Dauer des Lese- als auch des nachfolgenden Schreibabschnitts der XMEM-Anweisung verriegelt werden. Die vorliegende Erfindung aber gestattet die Ausführung der gleichen XMEM-Anweisung ohne die Notwendigkeit, alle drei Busse sowohl für die Lese- als auch die Schreibabschnitte der XMEM-Anweisung dauerhaft zu verriegeln.
Durch vorherige Ausführung des Schreibabschnitts der XMEM- Anweisung müssen die Busse zwischen den Schreib- und Lese- Abschnitten der XMEM-Anweisung nicht verriegelt werden. Das Bus-Signal, das in bisherigen Systemen verwendet wurde, um den Bus zu verriegeln, kann statt dessen nur eingesetzt werden, um anzuzeigen, dass derzeit eine XMEM-Anweisung ausgeführt wird.
Die neue Weise der Ausführung der XMEM-Anweisung, bei der das Schreiben vor dem Lesen durchführt wird, wird als die modifizierte XMEM-Anweisung bezeichnet. Der Einsatz der modifizierten XMEM-Anweisung in Semaphor-Anwendungen wird nun beschrieben.
Wenn der Prozessor eine modifizierte XMEM-Anweisung ausführt, ist der erste auftretende Bus-Zyklus ein Schreiben in die Speicherstelle, die das Semaphor enthält. Der Prozessor schreibt immer einen Wert, der anzeigt, dass die Ressource beschäftigt ist. Während des selben Schreib-Bus-Zyklusses sendet der Prozessor auch einen Wert für eine Prozessor-Ken nung, damit der Speicher weiß, welcher Prozessor die XMEM- Anweisung begonnen hat. Es kann ein Bus-Signal verwendet werden, um anzuzeigen, dass derzeit eine XMEM-Anweisung ausgeführt wird. Wenn der Speicher das Schreibsignal vom Prozessor empfängt, lädt der Speicher zunächst den vorliegenden Wert des Semaphors in einen Puffer und schreibt danach den neuen Wert in die selbe Speicherstelle. Im Speicher wird auch der Wert der Prozessor-Kennung mit dem gepufferten Wert des Semaphors gespeichert, damit der Speicher den richtigen Wert des Semaphors an den richtigen Prozessor zurückliefern kann.
Zu diesem Zeitpunkt wird jeder Prozessor, der das Semaphor ließt, einen Wert lesen, der anzeigt, dass die Ressource beschäftigt ist. Und jeder Prozessor, der versucht, eine XMEM-Anweisung auszuführen, wird nur erneut den gleichen Wert in das Semaphor schreiben, der anzeigt, dass die Ressource beschäftigt ist.
Der wichtige anzumerkende Punkt ist, dass der vom zweiten Prozessor empfangene Wert des Semaphors der Wert ist, den der erste Prozessor zuvor geschrieben hat: Ein Wert, der anzeigt, dass die Ressource beschäftigt ist. Falls also der Leseabschnitt der XMEM-Anweisung des zweiten Prozessors vor dem des ersten Prozessors ausgeführt wird, wird der Speicher den Wert der Prozessor-Kennung des zweiten Prozessors empfangen und wird den Wert des Semaphors an den zweiten Prozessor zurückliefern, der anzeigt, dass die Ressource beschäftigt ist. Und wenn schließlich der Leseabschnitt der XMEM-Anweisung des ersten Prozessors ausgeführt wird, wird der Speicher den Wert der Prozessor-Kennung des ersten Prozessors empfangen, und wird den gepufferten Wert des Semaphors zurückliefern, der anzeigt, dass die Ressource verfügbar ist. Daher wird zu einer Zeit immer nur ein Prozessor einen Semaphor-Wert empfangen, der anzeigt, dass die Ressource verfügbar ist.
Wieder unter Bezugnahme auf Abb. 3 wird angenommen, dass Datenverarbeitungseinheit 54 wünscht, auf ein in Speicher 68 vorliegendes Semaphor zuzugreifen. Prozessor 54 führt eine modifizierte XMEM-Anweisung aus. Der erste Bus-Zyklus ist ein Schreiben von Datenverarbeitungseinheit 54 nach Speicher 68. Obwohl Datenverarbeitungseinheit 54 zum Schreiben alle drei Busse, 58, 64 und 70, verwenden muss, ist keine Bus-Verriegelung erforderlich. Nach dem einzigen Schreib-Bus-Zyklus gibt die Datenverarbeitungseinheit 54 die Besitzrechte am Bus ab und anderen Prozessoren steht es frei, den Bus zu verwenden. Wenn sich Datenverarbeitungseinheit 54 für die drei Busse bewirbt und erneut Besitzrechte daran erlangt, kann der Leseabschnitt der XMEM-Anweisung ausgeführt werden und die Datenverarbeitungseinheit empfängt den richtigen Wert des Semaphors zurück.
Wieder wird die kritische Kohärenz aufrecht erhalten, da zu einer Zeit immer nur ein Prozessor einen Semaphor-Wert empfangen kann, der anzeigt, dass die Ressource verfügbar ist. Und diese Kohärenz wird bereitgestellt ohne die Notwendigkeit, den Bus zwischen den Lese- und Schreibabschnitten der XMEM-Anweisung zu verriegeln, die bei bisherigen Systemen erforderlich war.
Es ist anzumerken, dass die modifizierte XMEM-Anweisung es ebenfalls erforderlich macht, dass die Schreib- und Lesezyklen auf irgendeine Weise markiert werden, um anzuzeigen, welcher Prozessor die modifizierte XMEM-Anweisung ausführt. Falls diese Markierung nicht erfolgt, muss das System Kohärenz dadurch sicherstellen, dass es gewährleistet, dass der erste Prozessor, der während einer XMEM-Übertragung in den Speicher schreibt, der einzige Prozessor ist, der den ursprüngliche Semaphor-Wert ließt und empfängt, der anzeigt, dass die Ressource verfügbar war. Eine XMEM-Übertragung bezieht die Schritte ein, die während einer XMEM-Anweisung auftreten, nämlich einen Lese-Bus-Zyklus und einen Schreib- Bus-Zyklus in beliebiger Reihenfolge.
Zusätzlich erlaubt die vorliegende Erfindung dem Anwender, festzulegen, ob die Ausführung der XMEM-Anweisung als eine normale XMEM-Anweisung oder als eine modifizierte XMEM-Anweisung durchgeführt wird. Bei der normalen XMEM-Anweisung, die nach wie vor für viele existierende Bus-Umgebungen erforderlich ist, wird ein Lesezyklus durchgeführt, gefolgt von einem Schreibzyklus. Bei der modifizierten XMEM-Anweisung, die notwendig ist, um die Bandbreite von Systemen mit aufgeteilten Transaktions-Bussen zu erhöhen, wird ein gepufferter Schreibzyklus ausgeführt, gefolgt von einem Lesezyklus.
In der vorliegenden Ausführungsform verwendet der Anwender ein Steuerregister-Bit um festzulegen, ob die XMEM-Anweisung als normale XMEM-Anweisung oder aber als modifizierte XMEM- Anweisung ausgeführt wird. Das verwendete Steuerbit ist das XMEM-Steuerbit 52, das in Abb. 2 veranschaulicht wird. In der vorliegenden Ausführungsform wird eine normale XMEM- Anweisung ausgeführt, falls es sich bei dem XMEM-Steuerbit 52 um einen binären Wert von Null handelt, der einem digitalen logischen Zustand "Null" entspricht. Eine modifizierte XMEM- Anweisung wird ausgeführt, falls es sich bei dem XMEM-Steuerbit 52 um einen binären Wert von Eins handelt, der einem digitalen logischen Zustand "Eins" entspricht.
Alternativ kann in anderen Ausführungsformen der vorliegenden Erfindung der Steueranschluss 27 als alternative Weise anstelle des XMEM-Steuerbits 52 verwendet werden, um es dem Anwender zu gestatten, auszuwählen, welche Art der XMEM- Anweisung auszuführen ist. Durch Anlegen einer Spannung an Steueranschluss 27, die entweder einem digitalen logischen Zustand "Eins" oder einem digitalen logischen Zustand "Null" entspricht, kann der Anwender die Art der auszuführenden XMEM-Anweisung auswählen. Wie in Abb. 1 gezeigt wird, kann der Steueranschluss 27 direkt mit der Lade/Speicher-Ausführungseinheit 20 verbunden werden. Der Anschluss kann an den externen Bus 12 angeschlossen werden oder nicht. Alternativ kann der Anschluss mit dem externen Bus 12 und an das Bus-Interface 48 angeschlossen werden. Bei dieser Alternative kann die Lade/Speicher-Ausführungseinheit 20 die Steuerinformationen vom Anschluss über Anweisungs-Cache 44, die Superskalar-Ausführungseinheit 24 und den internen Bus 26 empfangen.
Alternativ kann in weiteren Ausführungsformen der vorliegenden Erfindung ein Bitfeld aus einem oder mehreren Bits innerhalb der binären Kodierung der Anweisung selbst anstelle eines Steuerregister-Bits als alternative Weise verwendet werden, um dem Anwender zu gestatten, die Art der auszuführenden XMEM-Anweisung auszuwählen. Die Anweisung in einer Ausführungsform der vorliegenden Erfindung besteht aus 32 Bits, die in einer Vielzahl von Bitfeldern angeordnet sind. In anderen Ausführungsformen können mehr oder weniger als 32 Bits verwendet werden. Durch Einfügen des richtigen binären Werts in das richtige Bitfeld der XMEM-Anweisung kann der Anwender die Art der auszuführenden XMEM-Anweisung auswählen. Zum Beispiel könnte ein Bitfeld aus einem Bit mit einem binären Wert von Null verwendet werden, um eine normale XMEM- Anweisung darzustellen, und einem binären Wert von Eins, um eine modifizierte XMEM-Anweisung darzustellen.
Falls unter Bezugnahme auf Abb. 1 ein Bitfeld innerhalb der XMEM-Anweisung verwendet wird, um die Reihenfolge der Schritte oder Tasks der XMEM-Anweisung auszuwählen, wird die XMEM-Anweisung von der Datenverarbeitungseinheit 10 auf die gleiche Weise empfangen wie andere Anweisungen. Genau wie andere Anweisungen wird die XMEM-Anweisung über das Bus- Interface 48 vom externen Bus 12 empfangen. Die verschiedenen Bitfelder der XMEM-Anweisung werden auf die gleiche Weise verwendet wie die Bitfelder anderer Anweisungen, mit Ausnahme des Bitfeldes, das zur Auswahl der Reihenfolge der Schritte oder Tasks der XMEM-Anweisung dient. Das Bitfeld für die Task-Reihenfolge wird zur Lade/Speicher-Ausführungseinheit 20 übertragen, die zur Steuerung der Ausführung von Anweisungen verwendet wird. In der vorliegenden Ausführungsform wird das Bitfeld für die Task-Reihenfolge über den Anweisungs-Cache 44, die Superskalar-Ausführungseinheit 24 und den internen Bus 26 an die Lade/Speicher-Ausführungseinheit 20 übertragen.
Zusammenfassend gestattet die modifizierte XMEM-Anweisung eine mögliche Erhöhung der Bandbreite von aufgeteilten Transaktions-Bussen durch Wegfall der Forderung nach Verriegelung der Busse während einer XMEM-Übertragung. Das XMEM-Steuerbit 52 gestattet Anwendern, die XMEM-Anweisung auszuwählen, die für Ihr System optimal ist. Anwender, die Systeme mit normalen Bus-Umgebungen haben, können die normale XMEM-Anweisung auswählen. Und Anwender mit aufgeteilten Transaktions-Bussen und komplexeren Bus-Umgebungen können die modifizierte XMEM- Anweisung auswählen. Diese Steuerung durch Software erlaubt der selben Datenverarbeitungseinheit 10 die Unterstützung des Bedarfs von Anwendern, die sehr unterschiedliche Bus-Umgebungen einsetzen. Diese Steuerung durch Software erlaubt Anwendern auch, die Datenverarbeitungseinheit 10 für Ihr spezielles System zu optimieren.
Es ist wichtig, anzumerken, dass das XMEM-Steuerbit 52 nur die Reihenfolge der Schritte oder Tasks verändert, die erforderlich sind, um eine XMEM-Anweisung durchzuführen. Es werden immer die selben Schritte oder Tasks abgearbeitet, wenn eine XMEM-Anweisung ausgeführt wird, unabhängig vom logischen Zustand des XMEM-Steuerbits 52. Es wird nur die Reihenfolge der Schritte verändert. Daher ist das Ergebnis oder die Ausgabe der Anweisung für den Anwender identisch. Die Ausgabe oder das Ergebnis sowohl der normalen XMEM-Anweisung als auch der modifizierten XMEM-Anweisung ist der Austausch oder das Wechseln der Werte in einem Register und einer Speicherstelle. Aber die Tatsache, dass der Anwender die Reihenfolge der verwendeten Schritte zur Ausführung dieser Anweisung wählen kann, kann zu einer deutlichen Verbesserung der Bandbreite bei gewissen Bus-Umgebungen führen.
Obwohl die vorliegende Erfindung im Zusammenhang mit einer speziellen Anweisung, der XMEM-Anweisung, beschrieben wurde, könnte die vorliegende Erfindung mit jeder beliebigen Anweisung verwendet werden, die mehr als einen Schritt oder einen Task aufweist. Die vorliegende Erfindung gestattet dem Anwender, die Reihenfolge der Schritte oder der Tasks einer Anweisung zu verändern. Obwohl die hier erläuterte XMEM-Anweisung nur zwei mögliche Reihenfolgen hat, können andere Ausführungsformen der vorliegenden Erfindung mehrere Steuerbits verwenden, um zwischen den mehreren möglichen Reihenfolgen der Schritte oder Tasks der gewählten Anweisung auszuwählen.
Während die vorliegende Erfindung mit Bezugnahme auf spezielle Ausführungsformen veranschaulicht und beschrieben wurde, werden Personen, die mit der Technik vertraut sind, weitere Abwandlungen und Verbesserungen einfallen.

Claims

1. Verfahren zur Festlegung einer Reihenfolge einer Vielzahl von Tasks, die zur Ausführung einer Anweisung in einer Datenverarbeitungseinheit (10) erforderlich sind, das Verfahren die Schritte aufweist:

Erlauben dem Anwender der Datenverarbeitungseinheit (10), einen logischen Zustand eines Steuermittels (52 oder 27) festzulegen;

Verwendung des Steuermittels (52 oder 27) zur Auswahl einer ersten Reihenfolge einer Vielzahl von Tasks einer Anweisung als ausgewählte Reihenfolge und einer zweiten Reihenfolge der selben Vielzahl von Tasks der selben Anweisung; und

Ausführung der Anweisung unter Verwendung der ausgewählten Reihenfolge.

2. Verfahren nach Anspruch 1, im weiteren den Schritt aufweisend:

Verwendung der Anweisung um einen ersten Wert in einem Register (22) mit einem zweiten Wert in einer Speicherstelle (56) auszutauschen.

3. Verfahren nach Anspruch 1, wobei die Vielzahl der Tasks einen Lese-Task und einen Schreib-Task enthält.

4. Verfahren nach Anspruch 1, 2, oder 3, bei dem ein erstes Ergebnis, das über eine erste Reihenfolge der Vielzahl von Tasks der Anweisung erzeugt wurde, das Selbe ist wie ein zweites Ergebnis, das über eine zweite Reihenfolge der Vielzahl von Tasks der selben Anweisung erzeugt wurde.

5. Verfahren nach Anspruch 1, 2, 3 oder 4, wobei das Steuermittel wenigstens einen Abschnitt (52) eines durch den Anwender programmierbaren Registers (50) aufweist.

6. Verfahren nach Anspruch 1, 2, 3 oder 4, wobei das Steuermittel einen Anschluss (27) zum Empfang eines Signals von außerhalb der Datenverarbeitungseinheit aufweist.

7. Verfahren nach Anspruch 1, 2, 3 oder 4, wobei das Steuermittel einen Abschnitt einer Multi-Bit-Darstellung der Anweisung aufweist.

8. Datenverarbeitungseinheit (10) zur Ausführung einer Software-Anweisung, bei der die Software-Anweisung einen Abschnitt einer binären Multi-Bit-Darstellung hat, die Software-Anweisung eine Vielzahl an Tasks enthält, und die Datenverarbeitungseinheit aufweist:

Steuermechanismus (27, 52) zur Bereitstellung eines vom Anwender programmierbaren Steuerwerts; und

Ausführungsschaltkreise (20) zur Steuerung der Ausführung der Software-Anweisung, die Ausführungsschaltkreise während der Ausführung der Software-Anweisung die binäre Multi-Bit-Darstellung der Software-Anweisung empfangen und den vom Anwender programmierbaren Steuerwert empfangen, und als Reaktion darauf die Vielzahl der Tasks der Software-Anweisung in einer ersten Reihenfolge ausgeführt werden, falls der vom Anwender programmierbare Wert einen ersten Wert hat, und die Vielzahl der Tasks der Software-Anweisung in einer zweiten Reihenfolge ausgeführt werden, falls der vom Anwender programmierbare Wert einen zweiten Wert hat.

9. Datenverarbeitungseinheit nach Anspruch 8, wobei die Vielzahl der Tasks einen Lese-Task und einen Schreib-Task enthält.

10. Datenverarbeitungseinheit nach Anspruch 8 oder 9, wobei der Lese-Task und der Schreib-Task jeweils auf die selbe Speicherstelle zugreifen.