DE112005003343B4 - Mechanismus für eine befehlssatzbasierte Threadausführung an mehreren Befehlsablaufsteuerungen - Google Patents

Abstract

Chip-Multiprozessor (332) (CMP) mit zwei Befehlsablaufsteuerungen (338, 340)
a) mit jeweils einer eigenen fest zugeordneten Prozess-Befehlspipeline, die unterschiedliche Verarbeitungsbetriebsmittel aufweisen,
b) wobei an den Befehlsablaufsteuerungen (338, 340) Benutzerebenenbefehle von Benutzerebenenthreads ausführbar sind,
c) wobei einer der Benutzerebenenbefehle ein Befehl (352) zur Übertragung der Steuerung ist,
d) wobei bei Ausführung des Benutzerebenenbefehls (352) zur Übertragung der Steuerung an der ersten Befehlsablaufsteuerung (338) die erste Befehlsablaufsteuerung (338) ein Signal zur Übertragung der Steuerung erzeugt und die zweite Befehlsablaufsteuerung (340) das Signal empfängt,
d.1) wobei die zweite Befehlsablaufsteuerung (340) durch die Ablaufsteuerungskennung der Befehlsablaufsteuerung in dem Benutzerebenenbefehl (552) zur Übertragung der Steuerung identifiziert und veranlasst wird, Befehle beginnend an einem vorher bestimmten Befehlszeiger auszuführen,...

Description

• GEBIET DER ERFINDUNG
• Ausführungsformen der Erfindung betreffen Verfahren und Vorrichtungen zur Verarbeitung von Befehlen.
• ALLGEMEINER STAND DER TECHNIK
• Um die Leistungsfähigkeit von informationsverarbeitenden Systemen wie jenen, die Mikroprozessoren beinhalten, zu erhöhen, wurden sowohl Hardware- als auch Softwaretechniken eingesetzt. Auf der Hardwareseite haben Mikroprozessorgestaltungsansätze zur Verbesserung der Mikroprozessorleistungsfähigkeit erhöhte Taktgeschwindigkeiten, die Parallelverarbeitung, die Sprungvorhersage, die superskalare Ausführung, die Ausführung außerhalb der Reihenfolge, und Pufferspeicher beinhaltet. Viele derartige Ansätze haben zu einer erhöhten Transistoranzahl geführt und haben in manchen Fällen sogar zu einer Zunahme der Transistoranzahl in einem Ausmaß geführt, das größer als der Grad der verbesserten Leistungsfähigkeit ist.
• Anstatt zu versuchen, die Leistungsfähigkeit strikt durch zusätzliche Transistoren zu erhöhen, umfassen andere Leistungsfähigkeitsverbesserungen Softwaretechniken. Ein Softwareansatz, der eingesetzt wurde, um die Prozessorleistungsfähigkeit zu verbessern, ist als „Multithreading” bekannt. Bei dem Software-Multithreading kann ein Befehlsstrom in mehrere Befehlsströme geteilt werden, die parallel ausgeführt werden können:
• Bei einem Ansatz, der als „Zeitanteils-Multithreading” oder „Zeitmultiplex(TMUX)-Multithreading” bekannt ist, schaltet ein einzelner Prozessor nach einem festen Zeitraum zwischen Threads um. Bei noch einem anderen Ansatz schaltet ein einzelner Prozessor beim Auftreten eines Auslöseereignisses wie etwa eines Pufferfehlschusses mit langer Wartezeit zwischen Threads um. Bei diesem letzteren Ansatz, der als „Multithreading mit ereignisbasierter Umschaltung” („switch-on-event multithreading, SoEMT”) bekannt ist, ist zu einer gegebenen Zeit höchstens nur ein Thread aktiv.
• Das Multithreading wird zunehmend in Hardware unterstützt. Zum Beispiel können bei einem Ansatz Prozessoren in einem System mit mehreren Prozessoren, wie etwa Chipsystemen mit mehreren Prozessoren („chip multiprocessor, CMP”) (mehreren Prozessoren auf einer einzelnen Chippackung) und symmetrischen Systemen mit mehreren Prozessoren („symmetrical multi-prozessor, SMP”) (mehreren Prozessoren auf mehreren Chips) jeweils gleichzeitig auf einen der mehreren Softwarethreads wirken. Bei einem anderen Ansatz, der als „gleichzeitiges Multithreading” („simultaneous multithreading, SMT”) bezeichnet wird, wird ein einzelner physikalischer Prozessorkern dazu gebracht, für Betriebssysteme und Benutzerprogramme als mehrere logische Prozessoren zu erscheinen. Bei SMT können mehrere Softwarethreads aktiv sein und gleichzeitig an einem einzelnen Prozessorkern ausgeführt werden. Das heißt, jeder logische Prozessor unterhält einen vollständigen Satz des Architekturzustands, doch werden viele andere Betriebsmittel des physikalischen Prozessors, wie etwa Puffer, Ausführungseinheiten, Sprungvorhersagegeräte, Steuerlogik und Busse gemeinsam verwendet. Bei SMT werden daher die Befehle von mehreren Sofwarethreads gleichzeitig an jedem logischen Prozessor ausgeführt.
• Der Aufsatz „MISC”: a multiple instruction stream computer” von G. Tyson et al. erschienen in Procedings of the 25th Annual International Symposium an Microarchitecture, 1992, beschreibt eine Systemarchitektur mit vier Verarbeitungseinheiten, die durch Busse verbunden sind, über die Daten zwischen den Verarbeitungseinheiten bzw. einem Speicher übermittelt werden können. Den einzelnen Prozessoren können Code-Fragmente zugeordnet werden, die jeweils Ausgaben für die anderen Verarbeitungseinheiten erzeugen können oder Eingaben von den anderen Verarbeitungseinheiten erwarten. Hierdurch wird eine parallele Verarbeitung der Code-Fragmente ermöglicht.
• Bei einem System, das eine gleichzeitige Ausführung von Softwarethreads unterstützt, wie etwa SMT-, SMP-, und/oder CMP-Systemen, kann ein Betriebssystem die Planung und Ausführung der Softwarethreads steuern.
• Alternativ ist es möglich, daß einige Anwendungen mehrere Threads direkt zur Ausführung in einem Verarbeitungssystem verwalten und planen können. Derartige anwendungsgeplante Threads sind für das Betriebssystem (operating system, OS) im Allgemeinen unsichtbar und sind als Benutzerebenenthreads bekannt.
• Üblicherweise können Benutzerebenenthreads lediglich zur Ausführung durch eine Anwendung geplant werden, die an einem verarbeitenden Betriebsmittel läuft, das durch ein OS verwaltet wird. Demgemäß gibt es im typischen Verarbeitungssystem mit mehreren Prozessoren keinen Mechanismus, um einen Benutzerebenenthread zur Ausführung an einem Prozessor zu planen, der nicht direkt durch das OS verwaltet wird.
• Es ist die Aufgabe der vorliegenden Erfindung einen Chip-Multiprozessor bereitzustellen mit dem Benutzerebenenthreads besser gesteuert werden können sowie ein entsprechendes Verfahren.
• Diese Aufgabe wird gelöst durch einen Chip-Multiprozessor mit den Merkmalen gemäß Anspruch 1 sowie ein Verfahren mit den Merkmalen gemäß Anspruch 18.
• Bevorzugte Ausführungsformen der Erfindung sind in den Unteransprüchen angegeben.
• KURZE BESCHREIBUNG DER ZEICHNUNGEN
• 1A und 1B zeigen höhere Blockdiagramme eines Systems mit mehreren Ablaufsteuerungen nach einer Ausführungsform der Erfindung;
• 1C ist ein Blockdiagramm, das ausgewählte Merkmale von Ausführungsformen eines Systems mit mehreren Ablaufsteuerungen veranschaulicht, welches die Steuerung von Threads durch Benutzerebenenbefehle unterstützt;
• 2 zeigt eine logische Ansicht von Hardware mit mehreren Ablaufsteuerungen, die einen Teil des Systems mit mehreren Ablaufsteuerungen von 1A bis 1C bildet;
• 3a zeigt eine Ansicht einer Befehlssatzarchitektur für die Systeme von 1A bis 1C;
• 3b veranschaulicht ein logisches Diagramm eines Prozessors mit zwei oder mehr Befehlsablaufsteuerungen, die in ihren Befehlssätzen einen Benutzerebenenbefehl zur Übertragung der Steuerung und einen Benutzerebenenbefehl zur Überwachung beinhalten;
• 4A und 4B zeigen das Format des SXFR- bzw. des SEMONITOR-Befehls nach einer Ausführungsform der Erfindung;
• 5 veranschaulicht, wie der SXFR-Befehl zur Übertragung der Steuerung zwischen Ablaufsteuerungen verwendet werden kann, nach einer Ausführungsform der Erfindung;
• 6A und 6B veranschaulichen Tabellen nach einer Ausführungsform der Erfindung, die verwendet werden können, um einen Dienstkanal zu programmieren;
• 7 zeigt ein funktionelles Blockdiagramm der Komponenten, die die Threadverwaltungslogik der Systeme von 1A bis 1C aufbauen, nach einer Ausführungsform der Erfindung;
• 8 veranschaulicht den Betrieb eines Proxy-Ausführungsmechanismus nach einer Ausführungsform der Erfindung;
• 9 und 10 zeigen Beispiele für logische Prozessoren nach einer Ausführungsform der Erfindung;
• 11 zeigt, wie der SXFR- und der SEMONITOR-Befehl zur Unterstützung der Proxy-Ausführung bei einer Seitenfehlerbehandlung durch das OS verwendet werden können, nach einer Ausführungsform der Erfindung; und
• 12 zeigt ein Verarbeitungssystem nach einer Ausführungsform der Erfindung.
• 13 veranschaulicht ein Blockdiagramm eines beispielhaften Computersystems, das eine Ausführungsform einer Prozessorkomponente wie etwa eine zentrale Verarbeitungseinheit (ZVE) oder einen Chipsatz verwenden kann, die einen oder mehrere Befehlsablaufsteuerungen beinhaltet, die dazu konfiguriert sind, einen oder mehrere Benutzerebenenthreads auszuführen, die ablaufsteuerungsbewußte Benutzerebenenbefehle enthalten.
• AUSFÜHRLICHE BESCHREIBUNG
• In der folgenden Beschreibung werden zu Erklärungszwecken zahlreiche bestimmte Einzelheiten bekanntgemacht, um ein gründliches Verständnis der Erfindung bereitzustellen. Einem Fachmann wird jedoch offensichtlich sein, daß die Erfindung ohne diese bestimmten Einzelheiten ausgeführt werden kann. In anderen Fällen sind Aufbauten und Vorrichtungen in Blockdiagrammform gezeigt, um zu vermeiden, daß die Erfindung undeutlich gemacht wird.
• Eine Bezugnahme in dieser Beschreibung auf „eine Ausführungsform” bedeutet, daß ein besonderes Merkmal, ein besonderer Aufbau, oder eine besondere Eigenschaft, das, der bzw. die im Verbindung mit der Ausführungsform beschrieben wird, in zumindest einer Ausführungsform der Erfindung beinhaltet ist. Das Auftreten des Ausdrucks „in einer Ausführungsform” an verschiedenen Stellen in der Beschreibung bezieht sich nicht notwendigerweise immer auf die gleiche Ausführungsform, noch schließen gesonderte oder alternative Ausführungsformen gegenseitig andere Ausführungsformen aus. Überdies sind verschiedenste Merkmale beschrieben, die von einigen Ausführungsformen gezeigt werden können, und von anderen nicht. In der gleichen Weise sind verschiedenste Anforderungen beschrieben, die Anforderungen für einige Ausführungsformen, aber nicht für andere Ausführungsformen sein können.
• Die folgende Beschreibung beschreibt Ausführungsformen eines architektonischen Mechanismus, um Ausführungsthreads an mehreren Ablaufsteuerungen eines Systems mit mehreren Ablaufsteuerungen zu erzeugen und zu steuern, die von der OS-Steuerung abgesondert sind.
• Wie hierin verwendet beinhaltet der Ausdruck „Befehlsablaufsteuerung” oder einfach „Ablaufsteuerung” Zeigerlogik zum nächsten Befehl und zumindest irgendeinen Prozessorzustand. Zum Beispiel kann eine Befehlsablaufsteuerung einen logischen Prozessor oder einen physikalischen Prozessorkern umfassen.
• In einer Ausführungsform kann der architektonische Mechanismus gerade zwei Befehle umfassen, die zusammen einen Signalisierungsmechanismus definieren, um ein Signal zwischen zwei beliebigen Ablaufsteuerungen zu senden und zu empfangen, ohne eine OS-Anwendungsprogrammschnittstelle zu verwenden. Das Signal kann ein architektonisch definiertes Ereignis oder Szenario umfassen, das auf einen Handlercode abgebildet wird. Bei Empfang des Signals an einer Ablaufsteuerung wirkt das Szenario im Signal als Auslöser, um die Ablaufsteuerung zu veranlassen, zum Handlercode zu vektorieren. Unter Verwendung der beiden Befehle ist es möglich, Threaderzeugungs-, Threadsteuerungs- und Threadsynchronisationssoftwaregrundfunktionen, die durch bestehende Threadbibliotheken bereitgestellt werden, auszuführen.
• Ferner können die beiden Befehle verwendet werden, um einen Proxy-Ausführungsmechanismus zu erzeugen, um eine Dienstleisterablaufsteuerung zu veranlassen, einen Code im Auftrag einer Kundenablaufsteuerung auszuführen, wie nachstehend ausführlicher erklärt werden wird.
• Entsprechend werden beispielhafte Prozessorsysteme beschrieben, die zwei oder mehr Befehlsablaufsteuerungen beinhalten, um unterschiedliche Threads auszuführen. Zumindest einige der zwei oder mehr Befehlsablaufsteuerungen beinhalten in ihren Befehlssätzen ablaufsteuerungsbewußte Benutzerebenenbefehle, die eine Steuerung zwischen Ablaufsteuerungen durch eine Threadverwaltungstätigkeit an einer bestimmten Befehlsablaufsteuerung ohne Eingriff durch ein Betriebssystem gestatten. Die ablaufsteuerungsbewußten Benutzerebenenbefehle können einen Befehl zur Übertragung der Steuerung der Befehlsablaufsteuerung, einen Befehl zur Überwachung der Befehlsablaufsteuerung, einen Befehl zur Speicherung des Kontexts, und einen Befehl zur Wiederherstellung des Kontexts beinhalten. Das Prozessorsystem kann auch eine Threadverwaltungslogik aufweisen, um auf einen Benutzerebenenbefehl zu reagieren, um einer nicht abgesonderten Befehlsablaufsteuerung zu gestatten, ohne einen Betriebssystemplaner parallele Ausführungsthreads an zugehörigen abgesonderten Befehlsablaufsteuerungen zu erzeugen. Das Prozessorsystem kann auch einen Proxy-Ausfürungsmechanismus aufweisen, um einer Kundenbefehlsablaufsteuerung zu gestatten, als Reaktion auf bestimmte Auslösebedingungen, denen während der Befehlsausführung an der Kundenbefehlsablaufsteuerung begegnet wird, und ohne Eingriff durch das Betriebssystem einen Proxy-Thread zur Ausführung an der Dienstleisterbefehlsablaufsteuerung im Auftrag der Kundenbefehlsablaufsteuerung auszulösen.
• Unter Hinwendung zu 1A der Zeichnungen bezeichnet das Bezugszeichen 100A ein System mit mehreren Ablaufsteuerungen nach einer Ausführungsform der Erfindung. Das System mit mehreren Ablaufsteuerungen 100A beinhaltet einen Speicher 102 und Hardware 104 mit mehreren Ablaufsteuerungen. Der Speicher 102 umfaßt ein Benutzerebenenprogramm 106, das einen Planer 108 beinhaltet, um Befehle zur Ausführung an der Hardware 104 mit mehreren Ablaufsteuerungen zu planen. Um mehrere Ausführungsthreads auszudrücken, macht das Benutzerebenenprogramm 106 von einer Thread-Anwendungsprogrammierschnittstelle (application programming interface, API) 110 zu einer Threadbibliothek Gebrauch, die dem Benutzerebenenprogramm 106 Threaderzeugungs-, -steuerungs- und -synchronisationsgrundfunktionen bereitstellt. Im Speicher 102 befindet sich auch ein Betriebssystem 112. Die Hardware 104 mit mehreren Ablaufsteuerungen beinhaltet mehrere Ablaufsteuerungen, wovon in 1A nur vier gezeigt wurden. Die vier gezeigten Ablaufsteuerungen sind mit SID0, SID1, SID2 bzw. SID3 bezeichnet.
• Wie hierin verwendet kann eine „Ablaufsteuerung” ein einzelnes Threadausführungsbetriebsmittel sein und kann sie jede beliebige physikalische oder logische Einheit sein, die fähig ist, einen Thread auszuführen. Eine Befehlsablaufsteuerung kann eine Zeigerlogik zum nächsten Befehl beinhalten, um den nächsten Befehl, der für den gegebenen Thread ausgeführt werden soll, zu bestimmen. Eine Ablaufsteuerung kann eine logische Threadeinheit oder eine physikalische Threadeinheit sein. In einer Ausführungsform können sich mehrere Befehlsablaufsteuerungen in einem gleichen Prozessorkern befinden. In einer Ausführungsform kann sich jede Befehlsablaufsteuerung in einem unterschiedlichen Prozessorkern befinden.
• In einem gegebenen Prozessorkern ist eine Befehlssatzarchitektur beinhaltet. Die Befehlssatzarchitektur (instruction set architecture, ISA) kann ein abstraktes Modell des Prozessorkerns sein, das aus Zustandselementen (Registern) und Befehlen besteht, die an diesen Zustandselementen tätig sind. Die Befehlssatzarchitektur dient als eine Grenze zwischen Software und Hardware, indem sie sowohl dem Programmierer als auch dem Mikroprozessorgestalter eine abstrakte Beschreibung des Verhaltens des Prozessorkerns bereitstellt. Der Befehlssatz kann den Satz von Befehlen definieren, zu deren Decodierung und Ausführung der Prozessorkern fähig ist.
• Obwohl sich die hierin besprochenen Chipmehrfachverarbeitungs(CMP)-Ausführungsformen der Hardware 104 mit mehreren Ablaufsteuerungen nur auf einen einzelnen Thread pro Ablaufsteuerung SID0 bis SID3 beziehen, sollte nicht angenommen werden, daß die Offenbarungen hierin auf Prozessoren mit Einzelthreads beschränkt sind. Die hierin besprochenen Techniken können in jedem beliebigen System der Chipmehrfachverarbeitung (CMP) oder dem gleichzeitigen Multithreading (SMT) einschließlich einem Hybridsystem mit CMP-Prozessoren und SMT-Prozessoren, wobei jeder Kern eines CMP-Prozessors ein SMT-Prozessor oder ein Mehrfachprozessor mit ereignisbasierter Umschaltung (SoeMT) ist, eingesetzt werden. Zum Beispiel können die hierin offenbarten Techniken in einem System verwendet werden, das mehrere Prozessorkerne mit mehreren Threads in einem einzelnen Chippaket 104 enthält.
• Die Ablaufsteuerungen SID0 bis SID3 sind nicht notwendigerweise gleichförmig und können in Bezug auf jeden beliebigen Faktor, der die Rechenqualität beeinflußt, wie etwa die Verarbeitungsgeschwindigkeit, die Verarbeitungsfähigkeit, und den Leistungsverbrauch, asymmetrisch sein. Zum Beispiel kann der SID0 dahingehend „schwergewichtig” sein, daß er dazu gestaltet ist, alle Befehle einer gegebenen Befehlssatzarchitektur (z. B. die Befehlssatzarchitektur IA32) zu verarbeiten, während die Ablaufsteuerung SID1 dahingehend „leichtgewichtig” sein kann, daß sie nur einen ausgewählten Untersatz dieser Befehle verarbeiten kann. In einer anderen Ausführungsform kann ein schwergewichtiger Prozessor jener sein, der Befehle mit einer höheren Geschwindigkeit als ein leichtgewichtiger Prozessor verarbeitet. Die Ablaufsteuerung SID0 ist für das Betriebssystem (OS) sichtbar, während die Ablaufsteuerungen SID1 bis SID3 vom OS abgesondert sind. Doch dies bedeutet nicht, daß jede schwergewichtige Ablaufsteuerung für das OS sichtbar ist, oder daß alle leichtgewichtigen Ablaufsteuerungen abgesondert sind. Wie hierin verwendet bezeichnet der Ausdruck „von der OS abgesondert” eine Ablaufsteuerung, die zu einem abgesonderten Zustand oder einer abgesonderten Bedingung übergegangen ist. Eine Eigenschaft eines derartigen abgesonderten Zustands oder einer derartigen abgesonderten Bedingung ist, daß das OS für eine Ablaufsteuerung in einem derartigen Zustand keine Befehle plant.
• Wie ersichtlich werden wird, beinhaltet die Hardware oder Firmware (z. B. Mikrocode) mit mehreren Ablaufsteuerungen auch eine Threadverwaltungslogik 114. In einer Ausführungsform virtualisiert die Threadverwaltungslogik 114 die Ablaufsteuerungen SID0 bis SID3 derart, daß sie dem Benutzerebenenprogramm 106 als gleichförmig erscheinen. Mit anderen Worten maskiert die Threadverwaltungslogik 114 die Asymmetrie der Ablaufsteuerungen SID0 bis SID3 derart, daß die Ablaufsteuerungen SID0 bis SID3 von einem durch einen Assembliersprachenprogrammierer gesehenen logischen Blickpunkt her gleichförmig erscheinen, wie in der Ansicht 200, die in 2 der Zeichnungen gezeigt ist, dargestellt ist.
• Im System 100A, das in 1A der Zeichnungen gezeigt ist, ist das Benutzerebenenprogramm 106 eng mit der Hardware 104 mit mehreren Ablaufsteuerungen gekoppelt. In einer Ausführungsform kann das Benutzerebenenprogramm 106 durch Zwischentreiber lose mit der Hardware 104 mit mehreren Ablaufsteuerungen gekoppelt sein. Ein derartiges System ist in 1B der Zeichnungen durch das Bezugszeichen 100E dargestellt. Das System 100E ist im Grunde das gleiche wie das System 100A, außer daß das Benutzerebenenprogramm anstelle der Verwendung des Planers 108 von einer Kernelebenensoftware wie etwa einem Vorrichtungstreiber 116 wie etwa einem Treiber, einer Hardwareabstraktionsschicht usw. Gebrauch macht, um mit der Kernelebenen-API 118 zu kommunizieren, um Befehle zur Ausführung an der Hardware 104 mit mehreren Ablaufsteuerungen zu planen.
• 1C ist ein Blockdiagramm, das ausgewählte Merkmale von Ausführungsformen 109, 115, 150, 170 eines Systems mit mehreren Ablaufsteuerungen veranschaulicht, das die Steuerung von Threads durch Benutzerebenenbefehle unterstützt. 1C veranschaulicht ausgewählte Merkmale eines SMT-Multithreadingsystems 109 mit mehreren Ablaufsteuerungen, wobei jede Ablaufsteuerung ein logischer Prozessor ist, der einen Thread gleichzeitig mit der Ausführung anderer Threads an anderen logischen Prozessoren ausführen kann. 1C veranschaulicht auch zumindest eine Ausführungsform eines Systems 115 mit mehreren Ablaufsteuerungen, das mehrere logische Ablaufsteuerungen über einen Mechanismus mit ereignisbasierter Umschaltung (SoeMT) wie etwa einen Zeitmultiplex-Umschaltmechanismus unterstützt, so daß jeder der logischen Prozessoren seinen Thread abwechselnd ausführt – an einem derartigen System 115 wird zu einer Zeit lediglich ein Thread ausgeführt.
• 1C veranschaulicht auch ausgewählte Merkmale von Multithreadingsystemen 150, 170 mit mehreren Kernen. Die physikalischen Kerne für ein Multithreadingsystem mit mehreren Kernen können entweder Kerne mit einer einzelnen Ablaufsteuerung (siehe z. B. das System 150) oder Kerne mit mehreren Ablaufsteuerungen (siehe z. B. das System 170) sein. Derartige Ausführungsformen von Multithreading mit mehreren Kernen werden weiter unten besprochen, während die Systeme 109, 115 mit einem einzelnen Kern und mehreren Ablaufsteuerungen unmittelbar nachstehend besprochen werden.
• Im SMT-System 109 wird ein einzelner physikalischer Prozessor 103 dazu gebracht, als mehrere Threadkontexte zu erscheinen, die hierin als TC₁ bis TC_n (nicht gezeigt) bezeichnet sind. Jeder der n Threadkontexte ist tatsächlich eine Ablaufsteuerung. Wenn zumindest einige dieser Threadkontexte (z. B. m von n) dem Betriebssystem und/oder Benutzerprogrammen sichtbar gemacht sind, werden diese Threadkontexte manchmal als logische Prozessoren (nicht gezeigt) bezeichnet, und sind sie hierin als LP₁ bis LP_m bezeichnet. Jeder Threadkontext TC₁ bis TC_n unterhält jeweils einen Satz des Architekturzustands AS₁ bis AS_n. Der Architekturzustand beinhaltet, für zumindest eine Ausführungsform, Datenregister, Segmentregister, Steuerregister, Fehlersuchregister, und die meisten der modellspezifischen Register. Die Threadkontexte TC₁ bis TC_n verwenden die meisten anderen Betriebsmittel des physikalischen Prozessors 103, wie etwa Puffer, Ausführungseinheiten, Sprungvorhersagegeräte, Steuerlogik und Busse, gemeinsam.
• Obwohl derartige Merkmale gemeinsam verwendet werden können, kann jeder Threadkontext im Multithreadingsystem 109 die nächste Befehlsadresse unabhängig erzeugen (und zum Beispiel einen Abruf von einem Befehlspuffer, einem Ausführungsbefehlspuffer oder einem Ablaufverfolgungspuffer durchführen). Daher beinhaltet der Prozessor 103 eine logisch unabhängige Zeiger- zum nächsten Befehl und Abruflogik 120, um für jeden Threadkontext Befehle abzurufen, selbst wenn die mehreren logischen Ablaufsteuerungen in einer einzelnen physikalischen Abruf/Decodierungseinheit 122 ausgeführt sein können. Für eine SMT-Ausführungsform kann der Ausdruck „Ablaufsteuerung” zumindest die Zeiger- zum nächsten Befehl und Abruflogik 120 für einen Threadkontext zusammen mit zumindest etwas des zugehörigen Architekturzustands, AS, für diesen Threadkontext umfassen. Es sollte bemerkt werden, daß die Ablaufsteuerungen eines SMT-Systems 109 nicht symmetrisch zu sein brauchen. Zum Beispiel können sich zwei Ablaufsteuerungen des gleichen physikalischen Prozessors in der Menge der architektonischen Zustandsinformationen, die sie unterhalten, unterscheiden.
• Daher ist das System 209 mit mehreren Ablaufsteuerungen für zumindest eine Ausführungsform ein Einzelkernprozessor 103, der ein gleichzeitiges Multithreading unterstützt. Für eine derartige Ausführungsform ist jede Ablaufsteuerung ein logischer Prozessor, der seine eigene Befehlszeiger- zum nächsten Befehl und Abruflogik und seine eigenen architektonischen Zustandsinformationen aufweist, obwohl der gleiche physikalische Prozessorkern 103 alle Threadbefehle ausführt. Für eine derartige Ausführungsform unterhält der logische Prozessor seine eigene Version des architektonischen Zustands, obwohl die Ausführungsbetriebsmittel des einzelnen Prozessorkerns 103 unter gleichzeitig ausgeführten Threads gemeinsam verwendet werden können.
• 1C veranschaulicht auch eine alternative Ausführungsform eines Systems 115 mit mehreren Ablaufsteuerungen, das fähig ist, einen Code mit mehrfachen Threads auszuführen. Die Ausführungsform ist als Ausführungsform eines Multithreading mit ereignisbasierter Umschaltung (SOEMT) bezeichnet. Für eine derartige Ausführungsform 115 ist jede Ablaufsteuerung den Ablaufsteuerungen der vorhergehenden Ausführungsform 109 darin ähnlich, daß jede Ablaufsteuerung ein logischer Prozessor ist, der seine architektonischen Zustandsinformationen und seinen eigenen Zeiger zum nächsten Befehl aufweist. Doch das System 115 unterscheidet sich vom oben besprochenen System 109 darin, daß die Ablaufsteuerungen sich die gleiche physikalische Abruflogik 120 in einer einzelnen Abruf/Decodierungseinheit 122 im physikalischen Prozessorkern 103 teilen. Die Abruflogik 120 kann auf Basis einer Vielfalt von ereignisbasierten Umschaltpolitiken umgeschaltet werden, um für verschiedene Ablaufsteuerungen des Systems 115 abzurufen. Die ereignisbasierten Umschaltauslöser können der Verlauf eines bestimmten Zeitausmaßes oder von bestimmen Maschinenzyklen, wie etwa Zeitmultiplexieren (TMUX) sein. Für andere Ausführungsformen können die SOEMT-Auslöser andere Ereignisse wie etwa Pufferfehlschüsse, Seitenfehler, Befehle mit langer Wartezeit usw. sein.
• 1C veranschaulicht auch zumindest zwei Ausführungsformen von Multithreadingsystemen 150, 170 mit mehreren Kernen. Für zumindest einige Ausführungsformen des Systems 150, 170 mit mehreren Kernen, das in 1C veranschaulicht ist, kann das System einen Prozessor 103 als einen Aufbaublock verwenden. Jede der Ablaufsteuerungen kann ein Prozessorkern 103 sein, wobei die mehreren Kerne 1031 bis 103n, 1031 bis 103m in einer einzelnen Chippackung 160 bzw. 180 ansässig sind. Für das in 1C veranschaulichte System 150 kann jeder Kern 103i (i = 0 bis n) eine Ablaufsteuerung mit einzelnen Threads ein. Für das in 1C veranschaulichte System 170 kann jeder Kern 103j (j = 1 bis m) ein Prozessorkern mit mehreren Ablaufsteuerungen sein.
• Die Chippackungen 160, 180 sind in 1C gestrichelt angegeben, um anzuzeigen, daß die veranschaulichten Einzelchip-Ausführungsformen der Systeme 150, 170 mit mehreren Kernen lediglich erläuternd sind. Für andere Ausführungsformen können Prozessorkerne eines Systems mit mehreren Kernen auf gesonderten Chips ansässig sein oder können sie als ein SOEMT-System mit mehreren Ablaufsteuerungen organisiert sein.
• Ein erstes Multithreadingsystem 150 mit mehreren Kernen, das in 1C veranschaulicht ist, kann zwei oder mehr gesonderte physikalische Prozessoren 1031 bis 103n beinhalten, die jeweils fähig sind, einen unterschiedlichen Thread derart auszuführen, daß die Ausführung von zumindest Teilen der unterschiedlichen Threads zur gleichen Zeit vor sich gehen können. Jeder Prozessor 1031 bis 103n beinhaltet eine physikalisch unabhängig Abrufeinheit 122, um für ihren jeweiligen Thread Befehlsinformationen abzurufen. In einer Ausführungsform, in der jeder Prozessor 1031 bis 103n einen einzelnen Thread ausführt, führt die Abruf/Decodierungseinheit 122 eine einzelne Zeiger- zum nächsten Befehl und Abruflogik 120 aus.
• 1C veranschaulicht auch ein Multithreadingsystem 170 mit mehreren Kernen, das mehrere SMT-Systeme 109 beinhaltet. Für eine derartige Ausführungsform 170 unterstützt jeder Prozessor 1031 bis 103m mehrere Threadkontexte. Zum Beispiel ist jeder Prozessor 1031 bis 103m ein SMT-Prozessor, der k Ablaufsteuerungen derart unterstützt, daß das System 170 wirksam m·k Ablaufsteuerungen unterstützt. Zusätzlich führt die Abruf/Decodierungseinheit 122 für das System 170 für jeden unterstützten Threadkontext eine einzelne Zeiger- zum nächsten Befehl und Abruflogik 120 aus.
• Zur einfacheren Darstellung konzentriert sich die folgende Besprechung auf Ausführungsformen des Systems 150 mit mehreren Kernen. Diese Konzentration sollte jedoch nicht als beschränkend aufgefaßt werden, da die nachstehend beschriebenen Mechanismen entweder in einem Mehrfachkern- oder einem Einzelkern-System mit mehreren Ablaufsteuerungen durchgeführt werden können. Außerdem kann entweder das Einzelkern- oder das Mehrfachkern mit Kernen mit einer einzelnen Ablaufsteuerung oder mit Kernen mit mehreren Ablaufsteuerungen ausgeführt werden. Für jeden Kern mit mehreren Ablaufsteuerungen können eine oder mehrere Multithreadingtechniken einschließlich SMT und/oder SoeMT benutzt werden. Man wird verstehen, daß die in 1C gezeigten Systeme 109, 115, 150, 170 zusätzliche Merkmale wie etwa ein Speichersystem, Ausführungseinheiten und dergleichen beinhalten können, die in 1C nicht gezeigt sind.
• Jede Ablaufsteuerung 103 für die in 1C veranschaulichten Systemausführungsformen 109, 115, 150, 170 kann mit einer einzigartigen Kennung (nachstehend in Verbindung mit 3 besprochen) verbunden sein. Verschiedenste Ausführungsformen der Systeme 109, 150 können eine unterschiedliche Anzahl N an gesamten Ablaufsteuerungen beinhalten.
• Ausführungsformen der in 1C veranschaulichten Systeme 109, 115, 150, 170 können jeweils eine Signalisierung unter den Ablaufsteuerungen unterstützen. Wie hierin verwendet wird der Ausdruck „Ablaufsteuerungsarithmetik” verwendet, um auf eine Signalisierung zwischen Ablaufsteuerungen für einen Dienst zwischen zwei Ablaufsteuerungen zu verweisen. Die architektonische Unterstützung für die Ablaufsteuerungsarithmetik kann Erweiterungen auf eine Befehlssatzarchitektur beinhalten, so daß ein oder mehrere Befehle bereitgestellt werden, um einem Benutzer eine direkte Manipulation der Steuerung und der Zustandsübertragungen zwischen Ablaufsteuerungen zu gestatten. Ein Benutzerebenenbefehl gilt als „ablaufsteuerungsbewußt”, wenn er ein ablaufsteuerungsarithmetischer Befehl oder jede beliebige andere Art von Befehl ist, der eine logische Ablaufsteuerungsadresse als Parameter enthält, die als Befehlsoperand codiert sein kann und/oder auf die bei der Befehlsausführung implizit verwiesen wird. Derartige Befehle können ablaufsteuerungsarithmetische Befehle beinhalten, die entweder für das Signalisieren einer anderen Ablaufsteuerung sorgen (hierin als „Benutzerebenenbefehl zur Übertragung der Steuerung” bezeichnet), oder für das Einrichten einer Kundenablaufsteuerung zur Überwachung hinsichtlich eines solchen Signals sorgen (hierin als „Benutzerebenenbefehl zur Überwachung” bezeichnet).
• Ablaufsteuerungsbewußte Befehle können auch andere Befehle beinhalten, die eine logische Ablaufsteuerungsadresse als Parameter beinhalten, wie etwa einen ablaufsteuerungsbewußten Zustandsspeicher- bzw. Wiederherstellungsbefehl. Bei der Ausführung eines derartigen Zustandsspeicherbefehls kann eine erste Ablaufsteuerung eine Schnappschußkopie der architektonischen Zustände einer zweiten Ablaufsteuerung erzeugen. Der ablaufsteuerungsbewußte Wiederherstellungsbefehl kann bestimmen, daß die gespeicherten architektonischen Zustande zu einer bestimmten Ablaufsteuerung geladen werden.
• Jeder ablaufsteuerungsbewußte Befehl kann optional auch mehr als eine logische Ablaufsteuerungsadresse als Parameter beinhalten. Zum Beispiel kann ein ablaufsteuerungsbewußter Befehl eine Ansammlung von mehreren logischen Ablaufsteuerungsadressen als Parameter beinhalten. Ein derartiger Ansatz kann für das Gruppenrufen oder Senden von Signalen zwischen Ablaufsteuerungen von einer Ablaufsteuerung zu mehreren anderen Ablaufsteuerungen benutzt werden. Zur Vereinfachung der folgenden Besprechung können sich nachstehend bekannt gemachte Beispiele, sofern nicht anders angegeben, auf den Fall eines Einzelrufs beziehen: eine erste Ablaufsteuerung führt einen ablaufsteuerungsbewußten Befehl aus, der eine einzelne andere logische Ablaufsteuerungsadresse bestimmt. Ein derartiger Ansatz wird lediglich zur Bequemlichkeit der Beschreibung vorgenommen und zu Erläuterungszwecken vorgenommen und sollte nicht als beschränkend aufgefaßt werden. Ein Fachmann wird erkennen, daß Ausführungsformen der hierin besprochenen Mechanismen auch auf das Senden und Gruppenrufen von ablaufsteuerungsbewußten Befehlen angewendet werden können.
• 3a zeigt eine Ansicht einer Befehlssatzarchitektur für die Systeme von 1A bis 1C. Unter Bezugnahme auf 3a der Zeichnungen ist eine Ansicht einer Befehlssatzarchitektur (ISA) 300 der Systeme 100A und 100E gezeigt. Eine ISA definiert eine logische Ansicht eines Systems, wie sie durch einen Assembliersprachenprogrammierer, einen Binärübersetzer, einen Assemblierer, oder dergleichen gesehen wird. Hinsichtlich ihrer ISA beinhalten die Systeme 100A und 100E einen logischen Speicher 302 und einen Befehlssatz 304. Der logische Speicher 302 definiert eine sichtbare Speicherhierarchie, ein Adressierungsschema, einen Registersatz, usw. für die Systeme 100A und 100B, während der Befehlssatz 304 die Befehle und das Format der Befehle, das die Systeme 100A und 100E unterstützen, definiert. In einer Ausführungsform kann der Befehlssatz 304 den als IA32-Befehlssatz bekannten Befehlssatz und seine Erweiterungen umfassen, obwohl andere Befehlssätze möglich sind. Zusätzlich beinhaltet der Befehlssatz 304 in einer Ausführungsform zwei Befehle, die als Benutzerebenenbefehl zur Übertragung der Steuerung und als Benutzerebenenbefehl zur Überwachung bekannt sind. Ein Beispiel eines Benutzerebenenbefehls zur Übertragung der Steuerung kann ein SXFR-Befehl sein. Ein Beispiel eines Benutzerebenenbefehls zur Überwachung kann ein SEMONITOR-Befehl sein. Ein beispielhafter SXFR-Befehl und ein beispielhafter SEMONITOR-Befehl werden besprochen werden, um das Verständnis eines Benutzerebenenbefehls zur Übertragung der Steuerung und eines Benutzerebenenbefehls zur Überwachung zu unterstützen.
• Allgemein wird der SXFR-Befehl verwendet, um ein Signal von einer ersten Ablaufsteuerung zu einer zweiten Ablaufsteuerung zu senden, und wird der SEMONITOR-Befehl verwendet, um die zweite Ablaufsteuerung so zu konfigurieren, daß sie eine Überwachung hinsichtlich des Signals von der ersten Ablaufsteuerung vornimmt. Ferner sind diese Befehle zur Übertragung der Steuerung und zur Überwachung ablaufsteuerungsbewußt, wie nachstehend besprochen werden wird, und können sie mehr ablaufsteuerungsbewußte zusammengesetzte Befehle zusammensetzen.
• 3b veranschaulicht ein logisches Diagramm einer Ausführungsform eines Prozessors mit zwei oder mehr Befehlsablaufsteuerungen, die in ihren Befehlssätzen einen Benutzerebenenbefehl zur Übertragung der Steuerung und einen Benutzerebenenbefehl zur Überwachung beinhalten. Der Prozessor 332 kann einen oder mehrere Befehlsablaufsteuerungen 338 bis 342 beinhalten, um unterschiedliche Threads auszuführen. In einer Ausführungsform können mehrere Befehlsablaufsteuerungen gemeinsam eine Decodierereinheit und/oder eine Befehlsausführungseinheit verwenden. In der gleichen Weise kann jede Befehlsablaufsteuerung ihre eigene fest zugeordnete Prozeßbefehlspipeline aufweisen, die eine Decodierereinheit wie etwa eine erste Decodierereinheit 334, eine Befehlsausführungseinheit wie etwa eine erste Befehlsausführungseinheit 335, usw. beinhaltet. Zumindest einige der mehreren Befehlsablaufsteuerungen 338 bis 342 beinhalten Befehlssätze 344, die zumindest einen Benutzerebenenbefehl zur Überwachung (wie etwa einen SEMONITOR-Befehl), einen Benutzerebenenbefehl zur Übertragung der Steuerung (wie etwa einen SXFR-Befehl), einen ablaufsteuerungsbewußten Speicherbefehl (wie etwa einen SSAVE-Befehl), und einen ablaufsteuerungsbewußten Wiederherstellungsbefehl (wie etwa einen SRSTOR-Befehl) beinhalten. Alternativ können der ablaufsteuerungsbewußte Speicher- und der ablaufsteuerungsbewußte Wiederherstellungsbefehl nicht Teil des Befehlssatzes 334 sein. Vielmehr können die Benutzerebenenbefehle zur Übertragung der Steuerung und zur Überwachung Teil des Befehlssatzes sein und dann in Verbindung mit einem Szenario und einem Zeiger zum Handlercode verwendet werden, um den ablaufsteuerungsbewußten Speicher- bzw. Wiederherstellungsbefehl zusammenzusetzen. Arten von Szenarien, die architektonisch definierte zusammengesetzte Auslösebedingungen auf Basis von mikroarchitektonischen Ereignissen sein können, werden später beschrieben werden.
• Der Ablauf der Tätigkeit zur Übertragung der Steuerung kann wie folgt stattfinden.
• Eine erste Instanz des Benutzerebenenbefehls 346 zur Überwachung kann eine der Befehlsablaufsteuerungen, einen Zeiger zu einer Stelle des Handlercodes, und eines aus einer Anzahl von Szenarien zur Übertragung der Steuerung bestimmen. Der Befehl 346 zur Überwachung kann die ausführende Befehlsablaufsteuerung, wie etwa eine erste Befehlsablaufsteuerung 338, veranlassen, die bestimmte Befehlsablaufsteuerung dazu einzurichten, nach dem Beobachten oder Empfangen der Signalisierung des bestimmten Szenarios zur Übertragung der Steuerung den Handlercode an der bestimmten Speicherstelle aufzurufen. Die erste Speicherstelle 348, die den Handlercode speichert, kann ein Register, ein Puffer, oder eine andere ähnliche Speichervorrichtung sein. Der Benutzerebenenbefehl 346 zur Überwachung kann zuerst ausgeführt werden, um eine bestimmte Zielbefehlsablaufsteuerung dazu einzurichten, ein Signal zur Übertragung der Steuerung zu empfangen, bevor die Quellenablaufsteuerung dieses Signal zur Übertragung der Steuerung sendet.
• Die ausführende Befehlsablaufsteuerung, wie etwa die erste Befehlsablaufsteuerung 338, kann einen ablaufsteuerungsbewußten Speicherbefehl ausführen, um den Kontextzustand der Zielbefehlsablaufsteuerung zu speichern. Der Kontextzustand der Bestimmungsbefehlsablaufsteuerung kann an einer zweiten Speicherstelle 350 gespeichert werden. Die zweite Speicherstelle kann eine andere Stelle in einer geteilten Speicheranordnung oder in einem einzelnen Speicherbereich als die erste Speicherstelle sein.
• Eine erste Instanz des Befehls 352 zur Übertragung der Steuerung kann eine der Befehlsablaufsteuerungen und eines der vielen Szenarien zur Übertragung der Steuerung bestimmen. Das bestimmte Szenario zur Übertragung der Steuerung kann zum Beispiel in einer Tabelle 354 gespeichert werden. Der Befehl 352 zur Übertragung der Steuerung verursacht, daß die ausführende Befehlsablaufsteuerung ein Signal zur Übertragung der Steuerung erzeugt, das durch die bestimmte Zielbefehlsablaufsteuerung, wie etwa eine zweite Befehlsablaufsteuerung 340, empfangen werden soll.
• Die bestimmte Zielbefehlsablaufsteuerung 340 stellt das Signal zur Übertragung der Steuerung, das als Reaktion auf die Ausführung des Befehls 352 zur Übertragung der Steuerung, der diese Befehlsablaufsteuerung bestimmt, erzeugt wird, fest. Die bestimmte Zielbefehlsablaufsteuerung 340 führt dann den durch den Befehl 346 zur Überwachung, der diese Befehlsablaufsteuerung bestimmt hat, bestimmten Handlercode aus.
• Nachdem die Ausführung des Handlercodes abgeschlossen ist, kann die erste Befehlsablaufsteuerung 338 (d. h., die Quellenbefehlsablaufsteuerung) einen ablaufsteuerungsbewußten Wiederherstellungsbefehl ausführen, um den Kontextzustand der Zielbefehlsablaufsteuerung von seiner Stelle an der zweiten Speicherstelle 350 wiederherzustellen.
• In einer Ausführungsform kann ein Prozessor Hardware mit mehreren Ablaufsteuerungen beinhalten. Jede Befehlsablaufsteuerung ist fähig, unterschiedliche Threads auszuführen. Zumindest einige der mehreren Befehlsablaufsteuerungen sind fähig, Benutzerebenenbefehle auszuführen. Die Benutzerebenenbefehle können ablaufsteuerungsbewußt sein. Jeder der Benutzerebenenbefehle kann Informationen enthalten, die zumindest eine der mehreren Befehlsablaufsteuerungen bestimmen. Die Ausführung der Befehle an einer ausführenden Ablaufsteuerung veranlaßt die ausführende Befehlsablaufsteuerung, an der bestimmten einen der mehreren Befehlsablaufsteuerungen ohne Betriebssystemeingriff eine Threadverwaltungstätigkeit durchzuführen. Die Threadverwaltungstätigkeit kann eine Threaderzeugungs-, eine Threadsteuerungs- oder eine Threadsynchronisationstätigkeit sein. Beispiele der Benutzerebenenbefehle beinhalten die nachstehend ausführlicher beschriebenen ablaufsteuerungsbewußten Befehle SXFR, SEMONITOR, SSAVE und SRSTR.
• In einer Ausführungsform beinhaltet der SXFR-Befehl das in 4a der Zeichnungen gezeigte Befehlsformat. Unter Bezugnahme auf 4a wird ersichtlich werden, daß der SXFR-Befehl einen Opcode 400A und Operanden 402A bis 410A beinhaltet. Der Operand 402A entspricht einer Ablaufsteuerungskennung (sequencer ID, SID) für eine Bestimmungs/Zielablaufsteuerung, zu der das Signal gesendet wird. Der Operand 404A umfaßt ein Szenario oder eine Steuernachricht, das bzw. die ein architektonisch definierter Kennungscode sein kann, der eine Bedingung oder ein erwartetes Ereignis darstellt. Ein Szenario kann verwendet werden, um eine asynchrone Übertragung der Steuerung zu bewirken, wie beschrieben werden wird. Unter Bezugnahme auf 6A der Zeichnungen ist eine Tabelle von Szenarien nach einer Ausführungsform der Erfindung gezeigt. Allgemein können die Szenarien in Szenarien in Ablaufsteuerungen und Szenarien zwischen Ablaufsteuerungen unterteilt werden. In einer Ausführungsform fallen die Szenarien in Ablaufsteuerungen in die Kategorie „Betriebsmittel nicht verfügbar” (resource not available, RNA), die eine Kategorie für Ereignisse ist, die während der Ausführung an einer Ablaufsteuerung durch den Zugriff auf ein Betriebsmittel, das an der Ablaufsteuerung nicht verfügbar ist, erzeugt werden. In einer Ausführungsform beinhalten Szenarien, die in die Kategorie RNA fallen, einen Seitenfehler, einen Systemanruf an eine vom Betriebssystem abgesonderte Ablaufsteuerung, die unfähig ist, einen OS-Dienst direkt zu aktivieren, oder einen Fehler einer mißbilligten Tätigkeit. Ein Fehler einer mißbilligten Tätigkeit ist ein Fehler, der durch einen begrenzten oder mißbilligten Untersatz von ISA-Merkmalen, der an der Ablaufsteuerung ausgeführt ist, verursacht wird. Zum Beispiel kann ein Fehler einer mißbilligten Tätigkeit auftreten, wenn versucht wird, einen Befehl, der einen Gleitkommaaddierer benötigt, an einer Ablaufsteuerung auszuführen, die einen Gleitkommaaddierer physikalisch nicht ausführt. Was Personen, die mit der Technik vertraut sind, betrifft, kann der hier beschriebene Mechanismus an Abstraktionen unterschiedlicher Ebenen, in Anwendungssoftware, Systemebenensoftware, oder Firmware wie Mikrocode, oder in Hardware ausgeführt werden.
• Beispiele für Szenarien zwischen Ablaufsteuerungen beinhalten ein als „INIT”-Szenario bezeichnetes Initialisierungsszenario, ein „FORK/EXEC”-Szenario, und ein „PROXY”-Szenario. Das INIT-Szenario veranlaßt eine Ablaufsteuerung, deren Kennung in einem SXFR-Befehl bestimmt ist, zu veranlassen, daß ein Satz von ablaufsteuerungsspezifischen architektonischen Zuständen (wie etwa Allzweckregister oder maschinenspezifische Steuerregister) jeweils auf einen Satz von Anfangswerten initialisiert wird, während das FORK/EXEC-Szenario veranlaßt, daß ein Thread, der an einer Ablaufsteuerung ausgeführt wird, die einen SXFR-Befehl ausführt, einen parallelen Ausführungsthread an einer Ablaufsteuerung, die durch die Bestimmungs-SID in einem SXFR-Befehl identifiziert wird, abspaltet oder beginnt, indem bestimmte Werte auf die Bestimmungsablaufsteuerungszustände gesetzt werden, die zumindest einen Befehlszeiger (EIP) und/oder einen Stapelzeiger (ESP) beinhalten. Das PROXY-Szenario wird verwendet, um eine Ablaufsteuerung, die durch die SID in einem SXFR-Befehl identifiziert wird, zu veranlassen, in einem Proxy-Ausführungsmodus tätig zu werden, um zum Beispiel Befehle im Auftrag der Ablaufsteuerung, die den SXFR-Befehl ausgeführt hat, zu verarbeiten. Zum Beispiel kann die Ablaufsteuerung, die in einem Proxy-Ausführungsmodus tätig ist, in einer Ausführungsform verwendet werden, um Befehle zu verarbeiten, die an einer Ablaufsteuerung, die nur einen mißbilligten Satz von ISA-Merkmalen unterstützt, nicht verarbeitet werden können. In einer Ausführungsform kann das PROXY-Szenario in ein BEGIN_PROXY-Szenario und ein END_PROXY-Szenario unterteilt werden. Das BEGIN_PROXY-Szenario veranlaßt eine Befehlsablaufsteuerung, wie beschrieben im Proxy-Ausführungsmodus tätig zu werden, während das END_PROXY-Szenario die Tätigkeit des Proxy-Ausführungsmodus beendet.
• Unter erneuter Bezugnahme auf 4A der Zeichnungen umfaßt der Operand 406A in einer Ausführungsform einen Bedingungsparameter, der die Ausführung von Befehlen an einer Ablaufsteuerung, die einen SXFR-Befehl ausführt, regelt. Beispiele für Bedingungsparameter beinhalten einen „WARTE”- und einen „WARTENICHT”-Parameter. Zum Beispiel verursacht der WARTE-Bedingungsparameter bei einer Verwendung des SXFR mit einem PROXY-Szenario, daß die Ausführung von Befehlen an einer Ablaufsteuerung, die einen SXFR-Befehl ausführt, anhält, während auf den Abschluß der Proxy-Ausführung an einer anderen Ablaufsteuerung gewartet wird. Der WARTENICHT-Bedingungsparameter bestimmt, daß die Ausführung an einer Ablaufsteuerung, die einen SXFR-Befehl ausführt, parallel mit der Proxy-Ausführung an einer anderen Befehlsablaufsteuerung weitergehen kann.
• In einer Ausführungsform umfaßt der Operand 408A eine szenariospezifische Nutzlast oder Datennachricht. Zum Beispiel kann die Nutzlast im Fall des FORK/EXEC-Szenarios einen Befehlszeiger umfassen, an dem die Ausführung an der Ablaufsteuerung, die durch den Operanden 402A identifiziert wird, beginnen soll. Nach verschiedenen Ausführungsformen kann die Nutzlast einen Befehlszeiger, einen Stapelzeiger, usw. umfassen. Adressen, die in der Nutzlast enthalten sind, können auf eine Vielfalt von Adressierungsweisen ausgedrückt werden, wie etwa durch buchstäbliche, registerindirekte und Basis/Versatz-Adressierung.
• Der Operand 410A bestimmt eine Routingfunktion an der im Operanden 402A enthaltenen SID. Die Routingfunktion steuert, ob das als Ergebnis der Ausführung eines SXFR-Befehls erzeugte Signal als ein Sende-, ein Einzelruf- oder ein Gruppenrufsignal gesendet wird. Die Routingfunktion kann auch topologiespezifische Hinweisinformationen codieren, die verwendet werden können, um eine zugrundeliegende Verbindung zwischen Ablaufsteuerungen beim Routing zur Lieferung des Signals zu unterstützen.
• Unter Bezugnahme auf 4B der Zeichnungen ist nun das Format eines SEMONITOR-Befehls nach einer Ausführungsform der Erfindung gezeigt. Wie ersichtlich ist, beinhaltet der SEMONITOR-Befehl einen Opcode 400B und Operanden 402B bis 406B. Der Operand 402B bestimmt ein Szenario, das zum Beispiel in Form einer Szenariokennung ausgedrückt sein kann. Der Operand 404B bestimmt ein Tupel, das eine Ablaufsteuerungskennung (SID) und einen Befehlszeiger (EIP) umfaßt. Zur Bequemlichkeit der Beschreibung wird das Tupel als ein „SIDEIP” bezeichnet.
• Der SEMONITOR-Befehl bildet ein Szenario, das im Operanden 402B bestimmt ist, auf einen SIDEIP, der im Operanden 404B bestimmt ist, ab. Dadurch kann der SEMONITOR-Befehl verwendet werden, um eine Abbildungstabelle, wie sie in 6B der Zeichnungen gezeigt ist, zu erzeugen, die jedes Szenario auf einen bestimmten SIDEIP abbildet. Jede Abbildung eines Szenarios auf einen bestimmten SIDEIP ist als „Dienstkanal” bezeichnet. Der Operand 406B gestattet einem Programmierer, zu steuern, wie ein bestimmter Dienstkanal bedient wird, wie nachstehend ausführlicher erklärt werden wird. Ein Programmierer kann den SEMONITOR-Befehl verwenden, um die Dienstkanäle zu programmieren, die eine bestimmte Ablaufsteuerung verwendet, um hinsichtlich eines gegebenen Szenarios zu überwachen. In einer Ausführungsform erfährt die Ablaufsteuerung ein Aufgabeereignis, wenn die erwartete Bedingung, die einem Szenario entspricht, beobachtet wird, um beginnend mit der auf das Szenario abgebildeten SIDEIP eine asynchrone Steuerungsübertragung zu einem Aufgabeereignishandler zu verursachen. Zum Beispiel wird, falls die erwartete Bedingung einem Fehler entspricht, der gegenwärtige (Rückkehr)befehlszeiger auf den gegenwärtigen Stapel geschoben und die Steuerung zum SIDEIP, der auf das beobachtete Szenario abgebildet ist, übertragen, sobald ein Steuerungsaufgabeereignis erfahren wird. Falls die erwartete Bedingung einer Fangstelle entspricht, wird der Zeiger zum nächsten Befehl auf den gegenwärtigen Stapel geschoben und die Steuerung zum SIDEIP, der auf das beobachtete Szenario abgebildet ist, übertragen. Ein Fehler kann einen Befehl beseitigen, bevor dieser Befehl ausgeführt wird. Eine Fangstelle kann einen Befehl beseitigen, nachdem der Befehl ausgeführt wurde.
• In einer Ausführungsform kann ein architektonisch definiertes Blockierbit gesetzt werden, um ein rekursives Auslösen eines Aufgabeereignisses zu verhindern, bis das Blockierbit zurückgestellt wird. Ein besonderer Rückkehrbefehl kann das Blockierbit atomisch zurückstellen und die Steuerung vom Aufgabeereignishandler zum ursprünglichen Code, dessen Ausführung das Aufgabeereignis erzeugte, zurückführen.
• Auf Basis der obigen Beschreibung wird man verstehen, daß sowohl SXFR als auch SEMONITOR insofern „ablaufsteuerungsbewußt sind, als sie Operanden beinhalten, die bestimmte Ablaufsteuerungen identifizieren. Ferner sind auch die später beschriebenen Befehle SSAVE und SRSTOR insofern „ablaufsteuerungsbewußt”, als sie Operanden beinhalten, die bestimmte Ablaufsteuerungen identifizieren. Außerdem können diese Benutzerebenenbefehle insofern „ablaufsteuerungsbewußt” sein, als sie einen Zeiger zu Befehlen im Handlercode aufweisen. Wenn er durch eine Befehlsausführungseinheit ausgeführt wird, bezieht sich der Handlercode auf eine oder mehrere bestimmte Ablaufsteuerungen, wenn dieser Handlercode ausgeführt wird. Der Handlercode ist mit dem Benutzerebenenbefehl verbunden, da der Benutzerebenenbefehl den Befehlszeiger zum Beginn des Handlercodes lenkt und der Benutzerebenenbefehl die Tätigkeiten des Threads lenkt, nachdem die Ausführung des Handlercodes beendet ist. Daher können die Benutzerebenenbefehle ablaufsteuerungsbewußt sein, wenn die Benutzerbenenbefehle entweder 1) ein Feld aufweisen, das einen bestimmten Berg auf eine oder mehreren Befehlsablaufsteuerungen vornimmt, oder 2) mit einem Zeiger implizit auf einen Handlercode, der spezifisch eine oder mehrere Befehlsablaufsteuerungen anspricht, wenn der Handlercode ausgeführt wird, verweisen.
• In einer Ausführungsform können die Befehle SXFR und SEMONITOR verwendet werden, um Übertragungen der Steuerung zwischen Ablaufsteuerungen auszuführen, wie unter Bezugnahme auf 5 der Zeichnungen beschrieben werden wird.
• Unter Bezugnahme auf 5 überträgt eine Ablaufsteuerung 500, wenn sie an einem Befehlzeiger „I” einem SXFR-Befehl begegnet, die Steuerung zur Ablaufsteuerung 502, um die Ablaufsteuerung 502 zu veranlassen, beginnend an einem Befehlszeiger „J” Handerbefehle auszuführen. In einer Ausführungsform kann ein SXFR-Befehl im Format SXFR (SID, SCENARIO_ID, CONDITIONAL_PARAMETER), zum Beispiel SXFR (502, BEGIN_PROXY, WARTENICHT), verwendet werden, um die Übertragung der Steuerung zu bewirken. Wenn das Format des SXFR-Befehls näher betrachtet wird, ist die „SID”, die im Befehl erscheint, ein Bezug auf die Ablaufsteuerungskennung (SID) für die Ablaufsteuerung 502. Der Teil „SCENARIO_ID” des Befehls ist ein Bezug auf ein Szenario, das, wie oben beschrieben, in das System 100A und 100E programmiert werden kann, um eine asynchrone Übertragung der Steuerung zu veranlassen. Wie oben bemerkt unterstützt das System 100A und 100E in einer Ausführungsform die Szenarien, die in der Szenarientabelle in 6A der Zeichnungen gezeigt sind. Jedes Szenario ist auf eine Szenariokennung (ID) codiert. In einer Ausführungsform können Werte, die einer bestimmten Szenariokennung entsprechen, in ein Register programmiert werden, woraus sie gelesen werden können, wenn der SXFR-Befehl ausgeführt wird.
• In einer Ausführungsform wird die Abbildungstabelle von 6B, die jedes Szenario auf einen SIDEIP abbildet, verwendet, um den Befehlszeiger, der mit dem Teil „SCENA-RIO_ID” des SXFR-Befehl verbunden ist, aufzulösen.
• Wie oben beschrieben wird der SEMONITOR-Befehl verwendet, um die Tabelle von 6B mit den Dienstkanälen zu bestücken. Zum Beispiel bildet der Befehl SEMONITOR (1, (502, J)), der das Format SEMONITOR (SCENARIO_ID, SIDEIP) aufweist, den Befehlszeiger „J” an der Ablaufsteuerung 502 auf das durch SCENARIO_ID = 1, angegebene Szenario, d. h., das Szenario BEGIN_PROXY, ab. Die Ausführung des Befehls SXFR (502, 1) an der Ablaufsteuerung 500 verursacht, daß ein Signal, das eine SZENARIO_ID von 1 beinhaltet, zur Ablaufsteuerung 502 geliefert wird.
• Als Reaktion auf das Signal erfährt die Ablaufsteuerung 502 ein Aufgabeereignis, das eine Übertragung der Steuerung zum Befehlszeiger „J” veranlaßt, an dem der Handlercode, der mit dem Szenario BEGIN_PROXY verbunden ist, beginnt. In einer Ausführungsform kann die Ablaufsteuerung 502, anstatt den Handlercode als Reaktion auf den Empfang des Signals beginnend am Befehlszeiger „J” sofort auszuführen, eine Anzahl von Signalen reihen; und sobald die Anzahl der Signale eine Schwelle überschreitet, bedient die Ablaufsteuerung 502 die Signale durch Ausführen des Handlercodes, der mit den verschiedenen Signalen verbunden ist. In einer Ausführungsform werden die bestimmte Weise, in der die Ablaufsteuerung ein Signal verarbeiten soll, d. h., entweder durch sofortige Verarbeitung oder durch verzögerte Verarbeitung unter Verwendung einer Schlange, und der Wert der Schwelle durch den Steuerparameter 406B im Befehl SEMONITOR gesteuert oder konfiguriert. Diese Reihung der Anforderungen kann auch in Software vorgenommen werden.
• In einer Ausführungsform kann der Handlercode Befehle beinhalten, um einen Dienstthread zu veranlassen, eine Ausführung an der Befehlsablaufsteuerung 502 zu beginnen. Ein Dienstthread ist im Grunde jeder beliebige Thread, der bei der Ausführung eines ersten Threads, der an einer anderen Ablaufsteuerung, d. h., der Ablaufsteuerung 500 im Fall von 5, hilft oder diese unterstützt. Damit der Dienstthread an der Ablaufsteuerung 502 ausgeführt wird, sollte es irgendeine Form von Zustandsübertragung zwischen den Ablaufsteuerungen 500 und 502 geben. In einer Ausführungsform sind zusätzlich zu den Befehlen SXFR und SEMONITOR ein ablaufsteuerungsspezifischer Kontextspeicherbefehl und ein ablaufsteuerungsspezifischer Kontextwiederherstellungsbefehl bereitgestellt. Der ablaufsteuerungsspezifische Kontextspeicherbefehl ist als SSAVE bezeichnet, und die ablaufsteuerungsspezifische Kontextwiederherstellungstätigkeit ist als SRSTOR bezeichnet. Sowohl SSAVE als auch SRSTOR sind ablaufsteuerungsbewußte Befehle. Alternativ kann ein kanonischer Mindestbefehlssatz lediglich die Befehle SXFR und SEMONITOR beinhalten. Zum Beispiel sind in einer Ausführungsform Szenarien für eine Ablaufsteuerungskontextspeicherung und/oder -wiederherstellung definiert. Wenn die Befehle SXFR und SEMONITOR in Verbindung mit einem Szenario und einem Zeiger zu Handlercode verwendet werden, kann der entsprechende Handlercode an der Zielablaufsteuerung die entsprechende Ablaufsteuerungskontextspeicherungs- und/oder wiederherstellungstätigkeit durchführen, wodurch die gleichen Wirkungen wie durch die fest zugeordneten Befehle SRSTOR und SSAVE erzielt werden.
• In einer anderen Ausführungsform kann ein ablaufsteuerungsbewußter Kontextspeicherbefehl synthetisiert werden, indem man über ein Szenario verfügt, das auf einen Codeblock abbildet, um eine ablaufsteuerungsbewußte Kontextspeicherung durchzuführen. In der gleichen Weise ist es möglich, unter Verwendung eines Szenarios eine ablaufsteuerungsbewußte Kontextwiederherstellungstätigkeit zu synthetisieren.
• In einer Ausführungsform beinhaltet sowohl der SSAVE- als auch der SRSTOR-Befehl einen Operanden, der einer SID entspricht, und umfaßt der Operand eine Adresse für einen „Speicherbereich”, in dem der Zustand für die Ablaufsteuerung, die durch den SID-Operanden identifiziert wird, gespeichert werden soll. Im Beispiel von 5 ist es nötig, daß die Ablaufsteuerung 502 über einen Zugriff auf den Ausführungskontext für den ersten Thread verfügt, damit die Ablaufsteuerung 502 fähig ist, einen Dienstthread auszuführen, um die Ausführung eines ersten Threads, der an der Ablaufsteuerung 500 läuft, zu erleichtern oder dabei zu helfen. Um der Ablaufsteuerung 502 den Ausführungskontext für den ersten Thread verfügbar zu machen, wird zuerst der Befehl SSAVE an der Ablaufsteuerung 502 ausgeführt, um den Ausführungskontext für den ersten Thread, der an der Ablaufsteuerung 500 ausgeführt wird, an einer ersten Speicherstelle 512 zu speichern. Um die bestehende Arbeit, die an der Ablaufsteuerung 502 vor der Durchführung der Dienstthreadberechnung im Auftrag der Ablaufsteuerung 500 erledigt wird, zu bewahren, kann der gegenwärtig laufende Code (nachstehend „früherer Code”) an 502 SSAVE durchführen, um den Ausführungskontext des früheren Codes an einer zweiten Speicherstelle 514 zu speichern. Die Speicherbereiche, die erste Speicherstelle 512 und die zweite Speicherstelle 514 sind nicht überlappend.
• Sobald der Ausführungskontext des früheren Codes an der zweiten Speicherstelle 514 gespeichert ist, führt die Ablaufsteuerung 502 einen SRSTOR-Befehl aus, der der ersten Speicherstelle 512 anzeigt, die Ablaufsteuerungszustände der Ablaufsteuerung 502 zum Ausführungskontext/zustand, der mit der Verarbeitung des ersten Threads an der Ablaufsteuerung 500 verbunden ist, zu verändern. Danach kann die Ablaufsteuerung 502 die Ausführung des Dienstthreads beginnen. Während der Dienstthread ausgeführt wird, beinhalten die Optionen für die Ablaufsteuerung 500 das Warten auf den Abschluß der Ausführung des Diensthreads oder das Umschalten, um einen zweiten Thread auszuführen. Sobald die Ausführung des Dienstthreads an der Ablaufsteuerung 502 abgeschlossen ist, führt die Ablaufsteuerung 502 einen SXFR-Befehl aus, um ein Signal zur Ablaufsteuerung 500 zu senden, um anzuzeigen, daß die Ausführung des Dienstthreads abgeschlossen ist. Vor dem Senden des Signals zur Ablaufsteuerung 500, um anzuzeigen, daß die Ausführung des Dienstthreads abgeschlossen ist, führt die Ablaufsteuerung 502 einen SSAVE-Befehl aus, um einen aktualisierten Ausführungskontext für den ersten Thread nach dem Abschluß des Dienstthreads an einer dritten Speicherstelle 516 zu speichern.
• Falls die Ablaufsteuerung 500 auf den Abschluß der Ausführung des Dienstthreads wartet, kann der Dienstthread an der Ablaufsteuerung 502 dann SRSTOR durchführen, wodurch der dritten Speicherstelle 516 angezeigt wird, den Ausführungskontext für den ersten Thread an der Ablaufsteuerung 500 zu aktualisieren, bevor SXFR ausgeführt wird, um der Ablaufsteuerung 500 mitzuteilen, die Codeausführung fortzusetzen. Nach der Benachrichtigung der Ablaufsteuerung 500 vom Abschluß des Dienstthreads
• Alternativ führt die Ablaufsteuerung 500 bei Empfang des Signals, das den Abschluß des Dienstthreads anzeigt, von der Ablaufsteuerung 502 einen SRSTOR(500, POINTER_TO_SAVE_AREA_B)-Befehl aus, um den Ausführungskontext der Ablaufsteuerung 500 zu jenem des ersten Threads nach Abschluß des Dienstthreads zu verändern.
• In einer Ausführungsform kann die Speicherung und Wiederherstellung des Kontextzustands einer Befehlsablaufsteuerung entfernt an einer Zielablaufsteuerung durchgeführt werden. Die Quellenablaufsteuerung sendet eine Nachricht für die Zielablaufsteuerung, den Kontextzustand ihrer Ablaufsteuerung zu speichern und/oder wiederherzustellen. Dies könnte als ein SXFR-Befehl mit einem bestimmten Szenario ausgeführt werden.
• In einer Ausführungsform beinhaltet die Threadverwaltungslogik 114 einen Proxy-Ausführungsmechanismus 700 und einen Ablaufsteuerungsabsonderungsmechanismus 702, wie in 7 der Zeichnungen ersichtlich ist.
• Zur Erläuterung der Tätigkeit des Proxy-Ausführungsmechanismus 700 soll das in 8 der Zeichnungen gezeigte System 800 betrachtet werden, das zwei Ablaufsteuerungen beinhaltet, die als S1 bzw. S2 bezeichnet sind. Die Ablaufsteuerungen S1 und S2 können in Bezug zueinander symmetrisch oder asymmetrisch sein. In diesem Beispiel sind die Ablaufsteuerungen asymmetrisch, wobei die Ablaufsteuerung S1 nur Verarbeitungsbetriebsmittel A und B beinhaltet, wohingegen die Ablaufsteuerung S2 Verarbeitungsbetriebsmittel A, D und C beinhaltet. Die Verarbeitungsbetriebsmittel der Ablaufsteuerung S1 müssen fähig sein, die Ausführung der Befehlsblöcke 1 und 2 zu unterstützen.
• Die Zeit (T1) befindet sich am Endpfeil des Blocks von Befehlen 2. T1 zeigt, daß die Überwachung ein Ereignis feststellt, das die Übersiedlung des einzelnen Threads von der Kundenbefehlsablaufsteuerung S1 zur Dienstleisterbefehlsablaufsteuerung S2 veranlaßt. Zur Zeit T1 ist ein dritter Block von Befehlen zur Ausführung an der Ablaufsteuerung S1 geplant, doch benötigt der dritte Block von Befehlen die Verwendung eines Verarbeitungsbetriebsmittels, das an der Ablaufsteuerung S1 nicht verfügbar ist, sagen wir, des Verarbeitungsbetriebsmittels D, das an der Ablaufsteuerung S2 verfügbar ist. An diesem Punkt erfährt die Ablaufsteuerung S1 zumindest in einer Ausführungsform einen „Betriebsmittel nicht verfügbar”-Fehler, und ein „Betriebsmittel nicht verfügbar”-Handler, der in der Benutzerebenensoftware (oder in der Threadverwaltungshardware oder -firmware) definiert sein kann, ruft den Proxy-Ausführungsmechanismus 700 an, zu veranlassen, daß der dritte Block von Befehlen zur Ablaufsteuerung S2 übersiedelt wird, um daran ausgeführt zu werden.
• Die Zeit (T2) befindet sich am Beginn der Linie zum Pfeil des dritten Blocks von Befehlen. T2 zeigt den Beginn der Ausführung eines Blocks von Befehlen vom einzelnen Thread an der Dienstleisterbefehlsablaufsteuerung S2 im Auftrag der Kundenablaufsteuerung S1.
• Die Zeit (T3) befindet sich am Endpfeil des dritten Blocks von Befehlen. T3 zeigt den Abschluß der Ausführung eines Blocks von Befehlen vom einzelnen Thread an der Dienstleisterbefehlsablaufsteuerung S2. Zur Zeit T3, nach der Ausführung des dritten Blocks von Befehlen an der Ablaufsteuerung S2 unter Verwendung des Verarbeitungsbetriebsmittels D, verwendet die Ablaufsteuerung S2 den Proxy-Ausführungsmechanismus 700, um der Ablaufsteuerung S1 zu signalisieren, daß die Ausführung des dritten Blocks von Befehlen abgeschlossen ist.
• Die Zeit (T4) befindet sich am Beginn der Linie zum Pfeil eines vierten Blocks von Befehlen. T4 zeigt den Abschluß der Proxy-Ausführung eines Blocks von Befehlen vom einzelnen Thread an der Dienstleisterbefehlsablaufsteuerung S2 und die Rückübertragung zur Kundenbefehlsablaufsteuerung S1. Die Ablaufsteuerung S1 kann dann damit fortfahren, einen vierten Block von Befehlen zu verarbeiten, was lediglich Verarbeitungsbetriebsmittel benötigt, die an der Ablaufsteuerung S1 verfügbar sind.
• Da die Ablaufsteuerung S1 im obigen Beispiel die Ablaufsteuerung S2 verwendet, um in ihrem Aufrag einen Befehlsblock auszuführen, wird die Ablaufsteuerung S1 als „Kunden” ablaufsteuerung bezeichnet. Die Ablaufsteuerung S2, die in einem Proxy-Ausführungsmodus tätig ist, um einen Befehlsblock im Auftrag einer Kundenablaufsteuerung zu verarbeiten, ist als „Dienstleister” ablaufsteuerung bekannt. Das Betriebsmittel D kann eine höchst spezialisierte funktionelle Einheit für einen begrenzten Satz von Anwendungen umfassen. Die funktionelle Einheit kann verhältnismäßig leistungshungrig, teuer und komplex sein. Daher ist das Betriebsmittel D in einer bestimmten Ausführungsform nur an der Ablaufsteuerung S2, und nicht an der Ablaufsteuerung S1 ausgeführt, um Kosten zu sparen. Doch wie oben bemerkt maskiert der Proxy-Ausführungsmechanismus 700 die Asymmetrie zwischen den Ablaufsteuerungen in einem System mit mehreren Ablaufsteuerungen, indem er die Verarbeitungsbetriebsmittel, die an den verschiedenen Ablaufsteuerungen in einem System mit mehreren Ablaufsteuerungen verfügbar sind, so abbildet, daß eine Kundenablaufsteuerung den Proxy-Ausführungsmechanismus verwenden kann, um einen Thread zur Ausführung an einer Ablaufsteuerung, die ein benötigtes Verarbeitungsbetriebsmittel aufweist oder zur Ausführung des Threads optimiert ist, zu übersiedeln. Der Proxy-Ausführungsmechanismus 700 kann auch verwendet werden, um einen Befehlsblock, der an einer vom Betriebssystem OS abgesonderten Ablaufsteuerung ausgeführt wird, zu einer OS-sichtbaren Ablaufsteuerung zu übersiedeln, z. B., um einen OS-Dienst wie etwa die Handhabung eines Seitenfehlers oder eines Systemanrufs durchzuführen, wie nachstehend unter Bezugnahme auf 11 der Zeichnungen ausführlicher erklärt werden wird.
• Für eine gegebene physikalische Ausführung des Systems mit mehreren Ablaufsteuerungen mit asymmetrischer Betriebsmittelorganisation kann der Proxy-Ausführungsmechanismus 700 wie oben beschrieben unter Verwendung der Befehle SEMONITOR und SXFR aufgebaut sein und einen Abbildungsmechanismus beinhalten. Im Allgemeinen kann der Proxy-Ausführungsmechanismus 700 in Hardware, in Firmware (z. B. Mikrocode) oder an einer Systemsoftwareschicht oder einer Anwendungssoftwareschicht ansässig sein. In einer Ausführungsform kann der Proxy-Ausführungsmechanismus 700 die Befehle SEMONITOR und SXFR verwenden, um zwei Kategorien von Proxy-Diensten zu behandeln. Die erste Kategorie ist als Ausstiegsdienstszenario bekannt, während die zweite Kategorie als Einstiegsdienstszenario bekannt ist. An einer Kundenablaufsteuerung sind für einen Satz von Betriebsmitteln und die zugehörigen Tätigkeiten, die in der Kundenablaufsteuerung nicht verfügbar sind oder physikalisch nicht unterstützt werden, Ausstiegsdienstszenarien definiert, um diese Tätigkeiten abzufangen oder als Fehler darzustellen. Jedes Ausstiegsszenario wird auf eine Ablaufsteuerungskennung (und einen Befehlszeiger (SIDEIP)) abgebildet, die zu einer Dienstleisterablaufsteuerung zeigt. Die Abbildung kann in Hardware, Firmware oder sogar Software erzielt werden. Der Proxy-Zugriff auf die Dienstleisterablaufsteuerung kann dann wie oben beschrieben unter Verwendung einer Signalisierung zwischen Ablaufsteuerungen erzielt werden.
• Eine Dienstleisterablaufsteuerung ist dafür verantwortlich, den Proxy-Zugriff auf die Betriebsmittel, die in einer Kundenablaufsteuerung nicht verfügbar sind, aber in der Dienstleisterablaufsteuerung verfügbar sind, zu unterstützen. Die Einstiegsdienstszenarien sind in den Dienstkanal definiert und konfiguriert und auf die lokalen Diensthandler (Handlercode), die die Proxy-Ausführung im Auftrag der Kundenablaufsteuerungen durchführen, abgebildet. Eine Liste von Musterausstiegs- und -einstiegsdienstszenarien ist in der Tabelle von 6A bereitgestellt.
• In einem Sinn entspricht ein Ausstiegsdienstszenario einer Fangstellen- oder Fehlertätigkeit, die aufgrund des benötigten Zugriffs auf ein Verarbeitungsbetriebsmittel, das an der Kundenablaufsteuerung nicht verfügbar ist, doch an einer Dienstleisterablaufsteuerung verfügbar ist, einen „Fehlschuß” auf eine Kundenablaufsteuerung erfährt. Umgekehrt entspricht ein Einstiegsdienstszenario einer asynchronen Unterbrechungsbedingung, die das Eintreffen einer Anforderung eines Zugriffs auf ein lokales Verarbeitungsbetriebsmittel, das an der Dienstleisterablaufsteuerung verfügbar ist, im Auftrag einer Kundenablaufsteuerung, die das lokale Verarbeitungsbetriebsmittel nicht besitzt, angibt. Der Proxy-Ausführungsmechanismus definiert ein Furnier oder eine Schicht der Abstraktion, das bzw. die derart mit jeder Ablaufsteuerung unter mehreren Ablaufsteuerungen verbunden ist, daß die Kunden- und Dienstleisterablaufsteuerungen zusammenarbeiten, um einen Proxy-Betriebsmittelzugriff durchzuführen. In zumindest einer Ausführungsform, in der die Proxy-Ausführung in Firmware oder direkt in Hardware ausgeführt ist, ist das Proxy-Betriebsmittel für die Benutzerebenensoftware und für ein Betriebssystem transparent.
• Jedes Dienstszenario spielt eine ähnliche Rolle wie die eines Opcodes in einer herkömmlichen ISA, außer daß ein Dienstszenario einen besonderen Handlercodeablauf auslöst. Daher ist es möglich, unter Verwendung des SXFR-Befehls als Metabefehl und eines Ausstiegsdienstszenarios, das auf einen Handlercode für den synthetisierten Befehl abgebildet ist, neue zusammengesetzte Befehle zu synthetisieren. In einer Ausführungsform ist die Beziehung zwischen einer Dienstszenariokennung und ihres Handlercodeablaufs der Beziehung zwischen einem Computer mit komplexem Befehlssatz (Complex Instruction Set Computer, CISC) und seinem entsprechenden Mikrocodeablauf ähnlich. Der CISC kann zusammengesetzt werden, indem die ablaufsteuerungsbewußten Benutzerebenenbefehle zur Überwachung und zur Übertragung als die kanonische Befehlsbasis zum Aufbau des Mikrocodeablaufs verwendet werden. Wie oben beschrieben wird die Abbildung zwischen einem Dienstszenario und ihrem Handlercode über SEMONITOR erzielt, während SXFR einen Mechanismus zum Senden von Steuernachrichten zwischen Ablaufsteuerungen bereitstellt. Die Kommunikation der Steuernachrichten wirkt als ein Auslöser für die Ausführung des Handlercodes, der auf die Dienstszenarien abgebildet ist.
• In einer Ausführungsform kann der Ablaufsteuerungsabsonderungsmechanismus 702 verwendet werden, um eine bestimmte Kombination von OS-sichtbaren Ablaufsteuerungen und OS-abgesonderten Ablaufsteuerungen abzubilden oder zu gruppieren, um einen logischen Prozessor zu bilden. Die Abbildung kann eine Abbildung von Eins-auf-Viele sein, die eine Abbildung einer einzelnen OS-sichtbaren Ablaufsteuerung auf viele OS-abgesonderte Ablaufsteuerungen umfaßt, oder eine Abbildung von Viele-auf-Viele sein, die eine Abbildung vieler OS-sichtbarer Ablaufsteuerungen auf viele OS-abgesonderte Ablaufsteuerungen umfaßt. Zum Beispiel zeigt 9 ein System mit mehreren Ablaufsteuerungen, das zwei logische Prozessoren 900 bzw. 902 umfaßt. Jeder der logischen Prozessoren 900 und 902 umfaßt eine Abbildung von Eins-auf-Viele, bei der eine einzelne OS-sichtbare Ablaufsteuerung auf viele OS-abgesonderte Ablaufsteuerungen abgebildet wird.
• Unter Hinwendung zu 10 kann ein beispielhaftes System 1000 mit mehreren Ablaufsteuerungen eine Besetzung von 18 Ablaufsteuerungen beinhalten, wobei zwei OS-sichtbare Ablaufsteuerungen auf 16 OS-abgesonderte Ablaufsteuerungen abgebildet sind, um eine Abbildung von Viele-auf-Viele zu definieren. Im logischen Prozessor des Systems 1000 kann jede der OS-sichtbaren Ablaufsteuerungen als Proxy für jede beliebige der OS-abgesonderten Ablaufsteuerungen dienen.
• In einer Ausführungsform kann der Ablaufsteuerungsabsonderungsmechanismus 702 Ablaufsteuerungen selektiv von der OS-Steuerung absondern. Nach verschiedenen Ausführungsformen der Erfindung können die Ablaufsteuerungen nach dem Hochfahren oder in einigen Fällen sogar während der Zeit des Hochfahrens abgesondert werden. Um eine Ablaufsteuerung unter OS-Steuerung abzusondern, kann der Ablaufsteuerungsabsonderungsmechanismus 702 einen Indikator für das OS setzen, um anzugeben, daß sich die Ablaufsteuerung in einem nicht verfügbaren Zustand befindet. Zum Beispiel kann der Ablaufsteuerungsabsonderungsmechanismus 702 den Leistungs- oder Leistungs/Leistungsfähigkeitszustand einer Ablaufsteuerung verkörpern, um dem OS anzuzeigen, daß die Ablaufsteuerung in einen besonderen nicht verfügbaren Zustand eingetreten ist, so daß das OS die Ablaufsteuerung als zu überlastet oder zu heiß ansehen wird, um Berechnungen zu entsenden oder Befehle für die Ablaufsteuerung zu planen. In einer Ausführungsform kann der Ablaufsteuerungsabsonderungsmechanismus 702 für eine Ablaufsteuerung, die einen Leistungssparmechanismus wie etwa die Intel SpeedStep^©-Technologie ausführt, einen bestimmten Untersatz der OS-sichtbaren Ablaufsteuerungen auf die bestimmten Leistungszustände stellen, um anzuzeigen, daß sich der Untersatz von Ablaufsteuerungen im nicht verfügbaren Zustand befindet, so daß das OS diesen Untersatz von Ablaufsteuerungen als überlastet ansehen wird und daher keine Berechnungen zum Untersatz von Ablaufsteuerungen entsenden wird. Die Befehle SXFR und SEMONITOR können auf eine Weise, die für das OS transparent ist, verwendet werden, um Berechnungen oder Threads für die abgesonderte Ablaufsteuerung zu planen.
• In einer Ausführungsform kann die Steuerung einer abgesonderten Ablaufsteuerung zum OS zurück übergeben werden, sobald die abgesonderte Ablaufsteuerung die Ausführung eines Threads abgeschlossen hat. Dies kann durch einen Mechanismus erzielt werden, der einen Indikator setzt, um dem OS anzuzeigen, daß sich die abgesonderte Befehlsablaufsteuerung nicht länger im nicht verfügbaren Zustand befindet.
• In einer Ausführungsform wird ein privilegierter Zustand einer abgesonderten Befehlsablaufsteuerung mit einem privilegierten Gegenzustand von nicht abgesonderten Befehlsablaufsteuerungen, die sich nach wie vor unter OS-Steuerung befinden, synchronisiert.
• Um ein Allzweck-M:N-Multithreadingpaket, d. h., ein Paket, das M Threads auf N Ablaufsteuerungen abbildet, wobei M >> N ist, kanonisch zu unterstützen, sind die Mindestaufbaublocksynchronisationsobjekte, die benötigt werden, im Allgemeinen der kritische Abschnitt und das Ereignis. Mit diesen Synchronisationsobjekten können Synchronisationsobjekte höherer Ebene wie etwa Mutexe, Bedingungsvariable, und Semaphore aufgebaut werden. Ein kritischer Abschnitt kann über Hardwaresperrgrundfunktionen ausgeführt werden. Die abgesonderten Ablaufsteuerungen können den Zustand von den nicht abgesonderten Ablaufsteuerungen erben, so daß die Ansicht des virtuellen Speichers sowohl für die abgesonderten Ablaufsteuerungen als auch die nicht abgesonderten Ablaufsteuerungen gleich ist. Ein Ereignis kann durch einen ereignisbasierten Planer (zentralisiert oder verteilt) für mehrere Ablaufsteuerungen, der mit den Befehlen SXFR und SEMONITOR synchronisiert ist, unterstützt werden. Zum Beispiel kann ein einfacher POSIX-fähiger oder -kompatibler verteilter Planer, der eine globale Aufgabenschlange aufweist, die durch einen kritischen Abschnitt geschützt wird, geschaffen werden. Jede Ablaufsteuerung führt wirksam eine Kopie des Planers aus und versucht, den Zugriff auf den Kopf der Aufgabenschlange zu erstreiten, um den nächsten bereiten Aufgabenthread, der an der Ablaufsteuerung ausgeführt werden soll, zu ergreifen. Sollte eine Aufgabe an einer Ablaufsteuerung auf eine Synchronisationsvariable wie etwa Mutex, eine Bedingungsvariable oder einen Semaphor warten, wird die Aufgabe durch Aufgeben ausgeplant und nach dem Eintritt in den entsprechenden kritischen Abschnitt ans Ende der globalen Aufgabenschlange gestellt.
• Durch den weit verbreiteten Einsatz von Threadgrundfunktionen in den Threadbibliotheken der meisten modernen Betriebssysteme ist es möglich, daß eine riesige Anzahl von bestehenden Codes mit Threads, die auf diesen POSIX-fähigen oder -kompatiblen Threadbibliotheken aufgebaut sind, in die Umgebung mit mehreren Ablaufsteuerungen portiert werden kann. Natürlich kann es sein, daß die Kopfdateien in den Threads neugeplant werden müssen und der Altcode mit Threads neukompiliert werden muß.
• Durch das Verwenden der Befehle SXFR und SEMONITOR und des INIT-Szenarios ist es möglich, Ausführungsthreads an OS-abgesonderten Ablaufsteuerungen zu planen, ohne ein Betriebssystem zu verwenden. Daher ist es aufgrund der hierin offenbarten Techniken möglich, ein System mit mehreren Ablaufsteuerungen aufzubauen, das mehr Ablaufsteuerungen aufweist, als ein Betriebssystem zu unterstützen fähig ist, und eine Benutzerebenenplanung von Threads an Ablaufsteuerungen des Systems mit mehreren Ablaufsteuerungen, die nicht durch das Betriebssystem unterstützt werden, zu gestatten.
• Demgemäß können die mehreren Befehlsablaufsteuerungen mit dem erweiterten Befehlssatz in einer Ausführungsform auch ein Einzelbildbetriebssystem an einer größeren Anzahl von Prozessoren unterstützen, als ursprünglich durch das Betriebssystem unterstützt wurde. Zum Beispiel könnte ein Betriebssystem, das fähig ist, eine Vier-Wege-Befehlsablaufsteuerung zu unterstützen, als das Betriebssystem für eine Hardwareausführung ausgeführt werden, die tatsächlich ein 32-Wege-Befehlablaufsteuerungssystem aufweist. Dies gestattet Anwendungen, mehr Prozessoren als die Grenzanzahl von Ablaufsteuerungen, die durch das Betriebssystem unterstützt wird, zu verwenden. Die Befehlsablaufsteuerungen können asymmetrische Ablaufsteuerungen oder symmetrische Ablaufsteuerungen sein.
• Nun beschreiben wir eine Ausführungsform für die Proxy-Ausführung in einem System mit mehreren Ablaufsteuerungen, wobei einige Ablaufsteuerungen OS-sichtbar sind, während andere OS-unsichtbar sind. Im Allgemeinen stellt die Proxy-Ausführung eine richtige Handhabung sicher, wenn ein Code, der auf den OS-unsichtbaren Ablaufsteuerungen läuft, einen Seitenfehler oder einen Systemanruf, der OS-Dienste erfordert, erfährt. Unter Bezugnahme auf 11 der Zeichnungen wird nun ein Ablaufdiagramm von Tätigkeiten gezeigt, die durchgeführt werden, um als Reaktion auf ein Auslöseereignis für eine Proxy-Ausführung einen OS-Dienst an einer OS-abgesonderten Ablaufsteuerung mit der Ablaufsteuerungskennung SID1 zu bewirken. Wenn dem Auslöseereignis begegnet wird, führt die OS-abgesonderte Ablaufsteuerung SID1 bei 1100 den Befehl SSAVE (1,ST_1_0) aus. Das Auslöseereignis kann eine vordefinierte Ausführungsbedingung im architektonischen Zustand, die einen OS-Dienst benötigt, wie etwa eine Fangstelle, ein Seitenfehler, oder ein Systemanruf, sein. Dieser Befehl speichert den Ausführungskontext eines Threads, dessen Ausführung das Auslöseereignis erzeugte. Zur Bequemlichkeit der Beschreibung ist der Speicherbereich für den Ausführungskontext des Threads mit (ST_1_0) bezeichnet, worauf ein Zugriff in zumindest einer Ausführungsform keinen Seitenfehler verursachen wird. Bei 1102 wird ein SXFR-Befehl ausgeführt, um das Ausstiegsdienstszenario „BEGIN_PROXY” zu einer OS-sichtbaren Ablaufsteuerung weiterzugeben. Es ist zu beachten, daß die Verarbeitung von Befehlen an der Ablaufsteuerung SID1 bis zum Abschluß des Proxy-Ausführungsthreads an der Ablaufsteuerung SID0 blockiert werden muß, da der SXFR-Befehl, der bei 1102 ausgeführt wurde, den Bedingungsparameter „WARTE” beinhaltete. Bei 1104 stellt die Ablaufsteuerung SID0 das Signal von der Ablaufsteuerung SID1 fest und gibt die Ausführung des gegenwärtigen Threads auf oder „stellt sie zeitweilig ein”. Bei 1106 wird ein SSAVE-Befehl ausgeführt, um den Ausführungskontext oder den Zustand, der mit der Ablaufsteuerung SID0 verbunden ist, zu speichern. Der Ausführungskontextspeicherbereich ist mit „ST_0_0” bezeichnet, was nicht mit ST_1_0 überlappt. Bei 1108 wird ein Proxy-Bit auf „1” gesetzt, um anzuzeigen, daß die Ablaufsteuerung SID0 im Proxy-Ausführungsmodus tätig ist. Bei 1110 wird eine Kontextwiederherstellungs(SRSTOR)-Tätigkeit ausgeführt, um den Zustand „ST_1_0”, bei dem es sich um den Ausführungskontext handelt, der mit dem Seitenfehler an SID1 verbunden ist, zu kopieren. Bei 1112 wird der Seitenfehler an der Ausführungssteuerung SID0 nachgebildet oder verkörpert. Bei 1114 wird ein Ringübergang durchgeführt, um die Steuerung zum Betriebssystem umzuschalten. Das Betriebssystem bedient den Seitenfehler. Wenn der Betriebssystemdienst abgeschlossen ist, wird bei der Privilegebenenumschaltung (d. h., einem Ringübergang) vom Betriebssystem zur Benutzerebene und im Fall des Proxy-Bits auf „EIN” das END_PROXY-Szenario als ein Aufgabeereignis innerhalb einer Ablaufsteuerung erfahren. Im Aufgabeereignishandler wird aufgrund des END_PROXY-Szenarios bei 1116 eine Kontextspeicherung durchgeführt, um einen Ausführungskontext „ST_1_1” zu speichern. Bei 1118 wird das Proxy-Bit auf „0” gesetzt. Bei 1120 wird ein SXFR-Befehl ausgeführt, um das Dienstszenario „END_PROXY” zur Ablaufsteuerung SID1 weiterzugeben. Bei 1122 stellt die Ablaufsteuerung SID0 den Zustand ST_0_0 wieder her. Bei 1124 tritt die Ablaufsteuerung SID1 bei Empfang des „END_PROXY”-Szenarios zurück, um bei 1126 den Kontext „ST_1_1” wiederherzustellen, damit die Ausführung des Threads, der dem Auslöseereignis begegnete, wieder beginnen kann.
• In einer Ausführungsform kann die Proxy-Ausführung die Übersiedlung eines Benutzerebenenthreads als Reaktion auf das Feststellen einer asymmetrischen Bedingung zwischen einer OS-sichtbaren Befehlsablaufsteuerung und einer Befehlsablaufsteuerung unter der Steuerung eines Anwendungsebenenprogramms, wenn der Benutzerebenenthread ausgeführt wird, sein.
• Eine asymmetrische Bedingung zwischen den Befehlsablaufsteuerungen kann zumindest die folgenden Bedingungen wie etwa die Notwendigkeit für einen Ring/Privilegebenenübergang beinhalten; was einen Seitenfehler oder einen Systemanruf, einen Mangel an Befehlsfähigkeit durch die Befehlsablaufsteuerung, die den Benutzerebenenthread ausführt (z. B. eine Mißbilligung eines bestimmten Befehls an einer Ablaufsteuerung und ein sich daraus ergebener Opcodefehler), einen Unterschied in der Befehlsausführungsleistungsfähigkeit zwischen den beiden Befehlsablaufsteuerungen beinhaltet.
• Die Zustandsübersiedlung während der Proxy-Ausführung kann schwergewichtig oder leichtgewichtig sein. Eine schwergewichtige Übersiedlung ist ein vollständiger Registerzustand, der von einer übertragenden Ablaufsteuerung gespeichert wird und auf der empfangenden Ablaufsteuerung wiederhergestellt wird. Eine schwergewichtige Übersiedlung weist zumindest einen Befehl vom Benutzerebenenthread auf, der zum Nutzen der übertragenden Ablaufsteuerung an der empfangenden Ablaufsteuerung ausgeführt wird. Die schwergewichtige Übersiedlung gestattet, daß ein Benutzerebenenthread, der ausgeführt wird, an der empfangenden Ablaufsteuerung verbleibt oder nach der Ausführung eines oder mehrerer Befehle im Auftrag der übertragenden Befehlsablaufsteuerung zur übertragenden Ablaufsteuerung zurückkehrt.
• Die leichtgewichtige Übesiedlung weist viele Abarten auf, wobei die Idee eine Rationalisierung für bestimmte Situationen ist. Die leichtgewichtige Übesiedlung kann das Übertragen irgendeines geringen Ausmaßes an Zustand, damit irgendeine geringe Aufgabe behandelt werden kann, beinhalten. In einigen leichtgewichtigen Übersiedlungsszenarien wird ein Befehl vom Benutzerebenenthread nicht tatsächlich ausgeführt – z. B. in der Seitenfehlersituation. Die Befehlsablaufsteuerung unter der Steuerung eines Anwendungsebenenprogramms überträgt lediglich die Adresse, die den Seitenfehler verursacht. Die empfangende Ablaufsteuerung führt lediglich eine Sondierungsbelastung durch, um zu verursachen, daß die Seite geladen wird, und teilt dann der Befehlsablaufsteuerung unter der Steuerung des Anwendungsebenenprogramms mit, daß die gewünschte Aufgabe erfüllt wurde. Daher muß „Übersiedlung” nicht bedeuten, daß ein Befehl vom übersiedlenden Benutzerebenenthread tatsächlich ausgeführt wird.
• Daher findet eine Proxy-Ausführung im wesentlichen zu jeder Zeit statt, zu der eine zweite Befehlsablaufsteuerung eine Tätigkeit „im Auftrag” einer ersten Befehlsablaufsteuerung, die einen Benutzerebenenthread ausführt, oder eine „von dieser Ablaufsteuerung stammende” Tätigkeit durchführt.
• In einer Ausführungsform für die leichtgewichtige Behandlung eines Seitenfehlers beinhaltet ein Gesichtspunkt der Proxy-Ausführung das Einstellen der Ausführung von Befehlen in einem Benutzerebenenthread in einer ersten Befehlsablaufsteuerung, die sich unter der Steuerung des Anwendungsebenenprogramms befindet, das Übertragen eines Adressenzeigers von der ersten Befehlsablaufsteuerung, die sich unter der Steuerung des Anwendungsebenenprogramms befindet, zu einer OS-sichtbaren Befehlsablaufsteuerung, das Laden der Inhalte am Adressenzeiger mit der OS-sichtbaren Befehlsablaufsteuerung, und schließlich das Wiederaufnehmen der Ausführung des ersten Benutzerebenenthreads in der Befehlsablaufsteuerung, die sich unter der Steuerung des Anwendungsebenenprogramms befindet, nachdem die Inhalte am Adressenzeiger geladen wurden.
• Ein anderer Gesichtspunkt der Proxy-Ausführung beinhaltet das Übertragen der Steuerung und von Zustandsinformationen von einer OS-abgesonderten Befehlsablaufsteuerung zu einer OS-sichtbaren Befehlsablaufsteuerung, und außerdem das Übersiedeln der Ausführung zumindest eines Befehls vom ersten Benutzerebenenthread an der OS-abgesonderten Befehlablaufsteuerung zur OS-sichtbaren Befehlsablaufsteuerung, so daß die OS-sichtbare Befehlsablaufsteuerung auslösen kann, daß ein Betriebssystem eine OS-Tätigkeit im Auftrag der OS-abgesonderten Befehlsablaufsteuerung durchführt.
• 12 der Zeichnungen zeigt ein Verarbeitungssystem 1200 nach einer Ausführungsform der Erfindung. Wie ersichtlich werden wird, beinhaltet das System 1200 eine Verarbeitungskomponente 1202, die mit einer Speichervorrichtung 1204 gekoppelt ist. In einer Ausführungsform beinhaltet die Verarbeitungskomponente 1202 mehrere Befehlsablaufsteuerungen, wovon in 12 der Zeichnungen nur zwei gezeigt sind, die als 1206A bzw. 1206B bezeichnet sind. Die Verarbeitungskomponente 1202 beinhaltet auch einen Steuerungsübertragungsmechanismus 1208, der einen Signalisierungsmechanismus 1210 und einen Überwachungsmechanismus 1212 beinhaltet. Der Signalisierungsmechanismus 1210 kann verwendet werden, um Szenarien/Steuerungsübertragungsnachrichten zwischen den Ablaufsteuerungen der Verarbeitungskomponente 1202 zu senden. Als solches beinhaltet der Signalisierungsmechanismus 1210 in einer Ausführungsform Logik, um den oben beschriebenen SXFR-Befehl auszuführen. Der Überwachungsmechanismus 1212 kann verwendet werden, um eine beliebige der Befehlsablaufsteuerungen der Verarbeitungskomponente 1202 derart einzurichten, daß sie eine Überwachung hinsichtlich eines Signals vornimmt, das eine besondere Steuernachricht/ein besonderes Szenario beinhaltet. In einer Ausführungsform beinhaltet der Überwachungsmechanismus Logik, um den oben beschriebenen SEMONITOR-Befehl zu decodieren.
• Die Verarbeitungskomponente 1202 beinhaltet auch einen wie oben beschriebenen Ablaufsteuerungsabsonderungsmechanismus 1214.
• Die Speichervorrichtung 1204 kann ein Betriebssystem beinhalten. In einer Ausführungsform kann das Betriebssystem durch Speichern des gesamten Registerzustands einer vorherigen Aufgabe und Wiederherstellen des gesamten Registerzustands einer nächsten Aufgabe eine Kontextumschaltung durchführen.
• In der Verarbeitungskomponente 1202 können verschiedenste Techniken verwendet werden, um zum Beispiel die Ablaufsteuerung 1206B dazu einzurichten, hinsichtlich besonderer Signale von der Ablaufsteuerung 1206A zu überwachen. In einer Ausführungsform kann die Ablaufsteuerung 1206B dazu vorkonfiguriert sein (d. h., ohne irgendeinen Benutzerkonfigurationsschritt zu benötigen), hinsichtlich von Signalen zu überwachen, die bestimmte Steuernachrichten/Szenarien tragen. Daher kann die Ablaufsteuerung 1206B in einer Ausführungsform dazu vorkonfiguriert sein, hinsichtlich eines Signals zu überwachen, das das INIT-Szenario trägt. Man wird verstehen, daß ein Benutzerebenenbefehl wie etwa SXFR verwendet werden kann, um die Ausführung eines Initialisierungscodes an der Ablaufsteuerung 1206B auszulösen. Der Initialisierungscode selbst kann einen SEMONITOR-Befehl umfassen, der verwendet werden kann, um die Ablaufsteuerung 1206B dazu einzurichten, hinsichtlich besonderer Signale (Szenarien) von der Ablaufsteuerung 1206A zu überwachen.
• In einer anderen Ausführungsform kann der ablaufsteuerungsbewußte SEMONITOR-Befehl an der Ablaufsteuerung 1206A ausgeführt werden, um die Ablaufsteuerung 1206B zu veranlassen, hinsichtlich besonderer Signale/Szenarien von der Ablaufsteuerung 1206A zu überwachen. In einer anderen Ausführungsform kann ein Zeiger zu einer Speicherstelle, die einen Lade/Initialisierungscode speichert, unter Verwendung des oben beschriebenen SSAVE-Befehls als Teil eines Kontexts für die Ablaufsteuerung 1206A gespeichert werden. Für diese Ausführungsform ist es möglich, einen SRSTOR-Befehl an der Ablaufsteuerung 1206B auszuführen, um den Kontext/Zustand für die Ablaufsteuerung 1206A derart wiederherzustellen, daß der Lade/Initialisierungscode ausgeführt werden kann. Der Lade/Initialisierungscode selbst enthält zumindest einen SEMONITOR-Befehl, um die Ablaufsteuerung 1206B dazu einzurichten, hinsichtlich besonderer Signale/Szenarien von der Ablaufsteuerung 1206A zu überwachen.
• 13 veranschaulicht ein Blockdiagramm eines beispielhaften Computersystems, das eine Ausführungsform einer Prozessorkomponente, wie etwa eine ZVE oder einen Chipsatz, verwenden kann, die eine oder mehrere Befehlsablaufsteuerungen beinhaltet, welche dazu konfiguriert sind, einen oder mehrere Benutzerebenenthreads auszuführen, die ablaufsteuerungsbewußte Benutzerebenenbefehle enthalten. In einer Ausführungsform umfaßt das Computersystem 1300 einen Kommunikationsmechanismus oder Bus 1311, um Informationen zu kommunizieren, und eine integrierten Schaltungskomponente wie etwa eine Hauptverarbeitungseinheit 1312, die mit dem Bus 1311 gekoppelt ist, um Informationen zu verarbeiten. Eine oder mehrere der Komponenten oder Vorrichtungen im Computersystem 1300 wie etwa die Hauptverarbeitungseinheit 1312 oder ein Chipsatz 1336 können eine Ausführungsform der Befehlsablaufsteuerungen verwenden, die konfiguriert sind, um einen oder mehrere Benutzerebenenthreads auszuführen. Die Hauptverarbeitungseinheit 1312 kann aus einem oder mehreren Prozessorkernen, die zusammen als eine Einheit arbeiten, bestehen.
• Das Computersystem 1300 umfaßt ferner einen Direktzugriffsspeicher (RAM) oder eine andere dynamische Speichervorrichtung 1304 (als Hauptspeicher bezeichnet), der bzw. die mit dem Bus 1311 gekoppelt ist, um Informationen und Befehle, die durch die Hauptverarbeitungseinheit 1312 ausgeführt werden sollen, zu speichern. Der Hauptspeicher 1304 kann auch verwendet werden, um während der Ausführung von Befehlen durch die Hauptverarbeitungseinheit 1312 zeitweilige Variable oder andere Zwischeninformationen zu speichern.
• Firmware 1303 kann eine Kombination aus Software und Hardware wie etwa ein elektronisch programmierbarer Nurlesespeicher (EPROM) sein, die die Tätigkeiten für das Programm im EPROM aufgezeichnet aufweist. Die Firmware 1303 kann einen Basiscode, einen Ein-/Ausgabegrundsystemcode (BIOS) oder einen anderen ähnlichen Code einbetten. Die Firmware 1303 kann es dem Computersystem 1300 möglich machen, sich selbst zu starten.
• Das Computersystem 1300 umfaßt auch einen Nurlesespeicher (ROM) und/oder eine andere statische Speichervorrichtung 1306, der bzw. die mit dem Bus 1311 gekoppelt ist, um statische Informationen und Befehle für die Hauptverarbeitungseinheit 1312 zu speichern. Die statische Speichervorrichtung 1306 kann OS-Ebenen- und Anwendungsebenensoftware speichern.
• Das Computersystem 1300 kann ferner mit einer Anzeigevorrichtung 1321 wie etwa einer Kathodenstrahlröhre (cathode ray tube, CRT) oder einer Flüssigkristallanzeige (liquid crystal display, LCD) gekoppelt sein, die mit dem Bus 1311 gekoppelt ist, um einem Computerbenutzer Informationen anzuzeigen. Ein Chipsatz kann mit der Anzeigevorrichtung 1321 gekoppelt sein.
• Eine alphanumerische Eingabevorrichtung (Tastatur) 1322, die alphanumerische und andere Tasten beinhaltet, kann ebenfalls mit dem Bus 1311 gekoppelt sein, um Informationen und Befehlsauswahlen zur Hauptverarbeitungseinheit 1312 zu kommunizieren. Eine zusätzliche Benutzereingabevorrichtung ist eine Cursorsteuervorrichtung 1323, wie etwa eine Maus, eine Rollkugel, ein Steuerfeld, ein Stift oder Cursorrichtungstasten, die mit dem Bus 1311 gekoppelt ist, um Richtungsinformationen und Befehlsauswahlen zur Hauptverarbeitungseinheit 1312 zu kommunizieren, und um die Cursorbewegung an einer Anzeigevorrichtung 1321 zu steuern. Ein Chipsatz kann mit der Ein-/Ausgabevorrichtungen gekoppelt sein.
• Eine andere Vorrichtung, die mit dem Bus 1311 gekoppelt sein kann, ist eine Ausdruckvorrichtung 1324, die verwendet werden kann, um Befehle, Daten oder andere Informationen auf ein Medium wie etwa Papier, Film, oder ähnliche Arten von Medien zu drucken. Darüber hinaus kann optional eine Tonaufzeichnungs- und -wiedergabevorrichtung wie etwa ein Lautsprecher und/oder ein Mikrophon (nicht gezeigt) für eine Audiokopplung mit dem Computersystem 1300 mit dem Bus 1311 gekoppelt sein. Eine andere Vorrichtung, die mit dem Bus 1311 gekoppelt sein kann ist, eine verdrahtete/drahtlose Kommunikationsfähigkeit 1325.
• In einer Ausführungsform kann die Software, die verwendet wird, um das Programm zu erleichtern, in ein maschinenlesbares Medium eingebettet sein. Ein maschinenlesbares Medium beinhaltet jeden beliebigen Mechanismus, der Informationen in einer Form bereitstellt (d. h., speichert und/oder sendet), auf die durch eine Maschine (z. B. einen Computer, eine Netzwerkvorrichtung, einen Minicomputer, ein Fertigungswerkzeug, jede beliebige Vorrichtung mit einem Satz von einem oder mehreren Prozessoren, usw.) zugegriffen werden kann. Zum Beispiel beinhaltet ein maschinenlesbares Medium beschreibbare/nicht beschreibbare Medien (z. B. einen Nurlesespeicher (ROM), der Firmware beinhaltet; einen Direktzugriffsspeicher (RAM); Magnetplattenspeichermedien; optische Speichermedien; Flash-Speichervorrichtungen; usw.) wie auch elektrische, optische, akustische oder andere Formen von ausgebreiteten Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale, usw.); usw.
• Während der Entwicklung kann eine Gestaltung von der Schaffung über die Simulation bis zur Herstellung mehrere Stufen durchlaufen. Daten, die eine Gestaltung darstellen, können die Gestaltung auf eine Vielfalt von Weisen darstellen. Erstens, wie in Simulationen nützlich, kann die Hardware unter Verwendung einer Hardwarebeschreibungssprache oder einer funktionellen Beschreibungssprache dargestellt werden. Zusätzlich kann in einigen Stufen des Gestaltungsprozesses ein Schaltkreisebenenmodell mit logischen oder Transistortoren erzeugt werden. Darüber hinaus erreichen die meisten Gestaltungen in irgendeiner Stufe eine Ebene von Daten, die die physikalische Anordnung von verschiedenen Vorrichtungen im Hardwaremodell darstellen. Falls herkömmliche Halbleiterherstellungstechniken verwendet werden, können die Daten, die das Hardwaremodell darstellen, jene Daten sein, die das Vorhandensein oder Fehlen von verschiedenen Merkmalen auf verschiedenen Maskenschichten für Masken, die zur Herstellung der integrierten Schaltung verwendet werden, bestimmen. In jeder beliebigen Darstellung der Gestaltung können die Daten in jeder beliebigen Form eines maschinenlesbaren Mediums gespeichert werden. Das maschinenlesbare Medium kann jede beliebige optische oder elektrische Welle, die moduliert oder auf eine andere Weise erzeugt ist, um derartige Informationen umzusetzen, ein Speicher, oder ein magnetischer oder optischer Speicher wie etwa eine Platte sein. Jedes dieser Medien kann die Gestaltung oder Softwareinformation „tragen” oder „angeben”. Wenn eine elektrische Trägerwelle, die den Code oder die Gestaltung angibt oder trägt, gesendet wird, wird in dem Ausmaß, in dem ein Kopieren, Puffer oder eine Neuübertragung des elektrischen Signals durchgeführt wird, eine neue Kopie angefertigt. Daher kann ein Kommunikationsprovider oder ein Netzwerkprovider Kopien eines Gegenstands (einer Trägerwelle) anfertigen, der Techniken der vorliegenden Erfindung verkörpert.
• Obwohl bestimmte beispielhafte Ausführungsformen beschrieben und in den beiliegenden Zeichnungen gezeigt wurden, versteht sich, daß diese Ausführungsformen lediglich erläuternd sind und die breite Erfindung nicht beschränken, und daß diese Erfindung nicht auf die gezeigten und beschriebenen bestimmten Auftauten und Anordnungen beschränkt ist, da Durchschnittsfachleuten beim Studium dieser Offenbarung verschiedenste andere Abwandlungen einfallen können. Auf einem technologischen Gebiet wie diesem, auf dem das Wachstum rasch ist und weitere Entwicklungen nicht leicht vorhersehbar sind, können die offenbarten Ausführungsformen durch technische Fortschritte, die dies ermöglichen, unterstützt leicht im Hinblick auf die Gestaltung und die Einzelheiten abwandelbar sein, ohne von den Grundsätzen der vorliegenden Offenbarung oder vom Umfang der beiliegenden Ansprüche abzuweichen.

Claims (27)

1. Chip-Multiprozessor (332) (CMP) mit zwei Befehlsablaufsteuerungen (338, 340) a) mit jeweils einer eigenen fest zugeordneten Prozess-Befehlspipeline, die unterschiedliche Verarbeitungsbetriebsmittel aufweisen, b) wobei an den Befehlsablaufsteuerungen (338, 340) Benutzerebenenbefehle von Benutzerebenenthreads ausführbar sind, c) wobei einer der Benutzerebenenbefehle ein Befehl (352) zur Übertragung der Steuerung ist, d) wobei bei Ausführung des Benutzerebenenbefehls (352) zur Übertragung der Steuerung an der ersten Befehlsablaufsteuerung (338) die erste Befehlsablaufsteuerung (338) ein Signal zur Übertragung der Steuerung erzeugt und die zweite Befehlsablaufsteuerung (340) das Signal empfängt, d.1) wobei die zweite Befehlsablaufsteuerung (340) durch die Ablaufsteuerungskennung der Befehlsablaufsteuerung in dem Benutzerebenenbefehl (552) zur Übertragung der Steuerung identifiziert und veranlasst wird, Befehle beginnend an einem vorher bestimmten Befehlszeiger auszuführen, d.2) wobei die erste Befehlsablaufsteuerung (338) die Ausführung von Befehlen anhält und auf den Abschluss der Ausführung an der zweiten Befehlsablaufsteuerung (340) wartet.
2. Prozessor nach Anspruch 1, wobei die erste Befehlsablaufsteuerung (338) einen ersten Decodierer aufweist, um den ersten ablaufsteuerungsbewussten Benutzerebenenbefehl (346, 352), der die zweite Befehlsablaufsteuerung (340) bestimmt, zu decodieren.
3. Prozessor nach Anspruch 1, wobei die erste Befehlsablaufsteuerung (338) eine Befehlsausführungseinheit aufweist, um den ersten ablaufsteuerungsbewussten Benutzerebenenbefehl (346, 352) auszuführen, der, wenn er ausgeführt wird, bei der Ausführung eines zugehörigen Codes implizit auf die zweite Befehlsablaufsteuerung (340) verweist.
4. Prozessor nach Anspruch 1, ferner umfassend: einen ersten Decodierer, um den Inhalt in Feldern des ersten ablaufsteuerungsbewussten Benutzerebenenbefehls (352) in einen decodierten Befehlscode zu übersetzen, wobei der erste ablaufsteuerungsbewusste Benutzerebenenbefehl (352) den Befehl zur Übertragung der Steuerung umfasst, der ein oder mehrere Felder aufweist, die eine Steuernachricht und eine Zielbefehlsablaufsteuerung spezifizieren.
5. Prozessor nach Anspruch 1, ferner umfassend: eine erste Befehlsausführungseinheit, um den ersten ablaufsteuerungsbewussten Benutzerebenenbefehl (352) auszuführen, wobei der erste ablaufsteuerungsbewusste Benutzerebenenbefehl (352) den Befehl zur Übertragung der Steuerung umfasst, der einen Datennutzlastanteil enthält, um bei der Ausführung durch die erste Befehlsausführungseinheit semantisch auf eine Zielbefehlsablaufsteuerung zu verweisen.
6. Prozessor nach Anspruch 1, ferner umfassend: einen ersten Decodierer, um den Inhalt in Feldern des ersten ablaufsteuerungsbewussten Benutzerebenenbefehls (346) in einen decodierten Befehlscode zu übersetzen, wobei der erste ablaufsteuerungsbewusste Benutzerebenenbefehl (346) den Befehl zur Überwachung umfasst, der ein oder mehrere Felder aufweist, die eine Zielbefehlsablaufsteuerung, eine Steuernachricht, und eine Stelle eines Handlercodes, der mit einer Steuernachricht verbunden ist, um eine Benutzerebenenthreadverwaltungstätigkeit durchzuführen, spezifizieren.
7. Prozessor nach Anspruch 1, ferner umfassend: einen ersten Decodierer, um den Inhalt in Feldern eines ersten ablaufsteuerungsbewussten Benutzerebenenbefehls in einen decodierten Befehlscode zu übersetzen, wobei der erste ablaufsteuerungsbewusste Benutzerebenenbefehl einen Speicherbefehl umfasst, der ein oder mehrere Felder aufweist, die zumindest eine der Befehlsablaufsteuerungen spezifizieren, deren Kontextzustand als Reaktion auf das Ausführen des Speicherbefehls gespeichert werden soll.
8. Prozessor nach Anspruch 1, ferner umfassend: einen ersten Decodierer, um den Inhalt in Feldern eines ersten ablaufsteuerungsbewussten Benutzerebenenbefehls in einen decodierten Befehlscode zu übersetzen, wobei der erste ablaufsteuerungsbewusste Benutzerebenenbefehl einen Wiederherstellungsbefehl umfasst, der ein oder mehrere Felder aufweist, die zumindest eine der Befehlsablaufsteuerungen spezifizieren, deren Ausführungsinhalt wiederhergestellt werden soll.
9. Prozessor nach Anspruch 6, wobei die Benutzerebenenthreadverwaltungstätigkeit aus einer Gruppe gewählt wird, die aus einer Benutzerebenenthreaderzeugungstätigkeit, einer Benutzerebenenthreadsteuerungstätigkeit, und einer Benutzerebenenthreadsynchronisationstätigkeit besteht.
10. Prozessor nach Anspruch 1, ferner umfassend: eine Kundenbefehlsablaufsteuerung, die einen Satz von Kundenbetriebsmitteln aufweist, um Befehle zu verarbeiten; eine Dienstleisterbefehlsablaufsteuerung, die einen Satz von Dienstleisterbetriebsmitteln aufweist, um Befehle zu verarbeiten; und einen Proxy-Ausführungsmechanismus, um der Kundenbefehlsablaufsteuerung zu gestatten, als Reaktion auf eine vordefinierte Bedingung, die während der Ausführung eines ersten Benutzerebenenthreads an der Kundenablaufsteuerung festgestellt wird, und ohne Eingriff eines Betriebssystems, die Ausführung eines Proxy-Benutzerebenenthreads im Auftrag der Kundenbefehlsablaufsteuerung an der Dienstleisterbefehlsablaufsteuerung auszulösen.
11. Prozessor nach Anspruch 10, wobei die Kundenbetriebsmittel in Bezug auf die Dienstleisterbetriebsmittel asymmetrisch sind, und der vordefinierte Zustand angibt, daß der erste Benutzerebenenthread versucht, ein Betriebsmittel zu verwenden, das an der Kundenablaufsteuerung nicht verfügbar ist, aber an der Dienstleisterablaufsteuerung verfügbar ist.
12. Prozessor nach Anspruch 11, wobei der Proxy-Ausführungsmechanismus die Asymmetrie zwischen den Kunden- und den Dienstleisterbetriebsmitteln vor einem Benutzerebenenprogramm maskiert.
13. Prozessor nach Anspruch 10, wobei der Proxy-Ausführungsmechanismus einen Satz von Ausstiegsszenarien umfasst, die mit der Kundenbefehlsablaufsteuerung verbunden sind, wobei jedes Ausstiegsszenario eine Auslösebedingung definiert, um die Proxy-Ausführung an der Dienstleisterbefehlsablaufsteuerung zu beginnen.
14. Prozessor nach Anspruch 1, ferner umfassend: eine Kundenbefehlsablaufsteuerung, die einen Satz von Kundenbetriebsmitteln aufweist, um Befehle zu verarbeiten; eine Dienstleisterbefehlsablaufsteuerung, die einen Satz von Dienstleisterbetriebsmitteln aufweist, um Befehle zu verarbeiten; und einen Proxy-Ausführungsmechanismus, um der Kundenbefehlsablaufsteuerung zu gestatten, als Reaktion auf eine vordefinierte Bedingung, die während der Ausführung eines ersten Benutzerebenenthreads festgestellt wird, eine Übertragung der Steuerung und von Zustandsinformationen von der Kundenbefehlsablaufsteuerung zur Dienstleisterbefehlsablaufsteuerung auszulösen, wobei die Kundenbefehlsablaufsteuerung eine Ausführung zumindest eines Befehls vom ersten Benutzerebenenthread zur Dienstleisterbefehlsablaufsteuerung migrieren soll, so daß die Dienstleisterbefehlsablaufsteuerung auslösen kann, daß ein Betriebssystem eine OS-Tätigkeit im Auftrag der Kundenbefehlsablaufsteuerung durchführt.
15. Prozessor nach Anspruch 1, ferner umfassend: eine Kundenbefehlsablaufsteuerung, die einen Satz von Kundenbetriebsmitteln aufweist, um Befehle zu verarbeiten.
16. Prozessor nach Anspruch 15, ferner umfassend: eine Dienstleisterbefehlsablaufsteuerung, die einen Satz von Dienstleisterbetriebsmitteln aufweist, um Befehle zu verarbeiten.
17. Prozessor nach Anspruch 16, ferner umfassend: einen Proxy-Ausführungsmechanismus, um der Kundenbefehlsablaufsteuerung zu gestatten, als Reaktion auf eine asymmetrische Bedingung, die während der Ausführung eines ersten Benutzerebenenthreads festgestellt wird, die Übertragung eines Adressenzeigers von der Kundenbefehlsablaufsteuerung zur Dienstleisterbefehlsablaufsteuerung auszulösen, wobei die Dienstleisterbefehlsablaufsteuerung den Inhalt am Adressenzeiger laden soll, und die Kundenbefehlsablaufsteuerung Befehle vom ersten Benutzerebenenthread ausführen soll, nachdem die Inhalte am Adressenzeiger geladen wurden.
18. Verfahren zur Steuerung von Benutzerebenenthreads in einem Chip-Multiprozessor (CMP) (332) gemäß Anspruch 1, umfassend: a) Erzeugen eines Signals zur Übertragung der Steuerung durch die erste Befehlsablaufsteuerung (338) und Empfangen des Signal durch die zweite Befehlsablaufsteuerung (340), umfassend: a.1) Identifizieren der zweiten Befehlsablaufsteuerung (340) durch die Ablaufsteuerungskennung der Befehlsablaufsteuerung in dem Benutzerebenenbefehl (352) zur Übertragung der Steuerung und Veranlassen der zweiten Befehlsablaufsteuerung dazu, Befehle beginnend an einem vorher bestimmten Befehlszeiger auszuführen, und a.2) in der ersten Befehlsablaufsteuerung (338) Anhalten der Ausführung von Befehlen und Warten auf den Abschluss der Ausführung der Befehle in der zweiten Befehlsablaufsteuerung (340)
19. Verfahren nach Anspruch 18, ferner umfassend: Ausführen eines Benutzerebenenbefehls (352) zur Übertragung der Steuerung an der ersten Befehlsablaufsteuerung, wobei der Benutzerebenenbefehl (352) zur Übertragung der Steuerung eine Steuernachricht und die zweite Befehlsablaufsteuerung bestimmt; und Senden, als Reaktion auf das Ausführen des Benutzerebenenbefehls (352) zur Übertragung der Steuerung, eines Signals, das die Steuernachricht beinhaltet, durch die erste Befehlsablaufsteuerung zur zweiten Befehlsablaufsteuerung.
20. Verfahren nach Anspruch 18, ferner umfassend: Ausführen eines Benutzerebenenbefehls (346) zur Überwachung an der ersten Befehlsablaufsteuerung, wobei der Benutzerebenenbefehl zur Überwachung die zweite Befehlsablaufsteuerung, eine Steuernachricht, und eine Stelle eines mit der Steuernachricht verbundenen Handlercodes zur Durchführung einer Benutzerebenenthreadverwaltungstätigkeit bestimmt; und Erzeugen, als Reaktion auf das Ausführen des Benutzerebenenbefehls (346) zur Überwachung, einer Abbildung zwischen der zweiten Befehlsablaufsteuerung, der Steuernachricht, und der Stelle des Handlercodes.
21. Verfahren nach Anspruch 18, ferner umfassend: Ausführen eines Benutzerebenenspeicherbefehls an der ersten Befehlsablaufsteuerung (340), der eine oder mehrere andere Befehlsablaufsteuerungen einschließlich der zweiten Befehlsablaufsteuerung (340) spezifiziert und veranlasst, dass Ausführungskontexte der einen oder der mehreren Befehlsablaufsteuerungen als Reaktion auf das Ausführen des Benutzerebenenspeicherbefehls gespeichert werden.
22. Verfahren nach Anspruch 18, ferner umfassend: Ausführen eines Benutzerebenenwiederherstellungsbefehls an der ersten Befehlsablaufsteuerung (340), die eine oder mehrere andere Befehlsablaufsteuerungen einschließlich der zweiten Befehlsablaufsteuerung (340) spezifiziert, deren Ausführungskontexte wiederhergestellt werden sollen, wenn der Benutzerebenenbefehl ausgeführt wird.
23. Verfahren nach Anspruch 18, ferner umfassend: Migrieren einer Ausführung von Befehlen von der ersten Befehlsablaufsteuerung (338), um einen Teil dieser Befehle an der zweiten Befehlsablaufsteuerung (340) auszuführen, wenn bei der Ausführung des ersten Benutzerebenenthreads einer vordefinierten Bedingung begegnet wird.
24. Verfahren nach Anspruch 23, wobei die vordefinierte Bedingung eine Feststellung einer asymmetrischen Bedingung zwischen der ersten Befehlsablaufsteuerung (338), die unter der Steuerung des Anwendungsebenenprogramms steht, und der zweiten Befehlsablaufsteuerung (340) ist.
25. Verfahren nach Anspruch 24, wobei die asymmetrische Bedingung aus einer Gruppe gewählt wird, bestehend aus einem begegneten Fehler, der es erfordert, dass eine Betriebssystemtätigkeit durch ein Betriebssystem (OS) durchgeführt wird, um den Fehler zu lösen, einem begegneten Trap, der es erfordert, dass eine Betriebssystemtätigkeit durch ein Betriebssystem (OS) durchgeführt wird, um den Trap aufzulösen, einem Systemaufruf zur Befehlsablaufsteuerung, die unter der Steuerung des Anwendungsebenenprogramms steht, aber unfähig ist, direkt einen OS-Dienst zu aktivieren, oder einem Fehler einer mißbilligten Tätigkeit, wobei es der Befehlsablaufsteuerung (338), die unter der Steuerung des Anwendungsebenenprogramms steht, an eingebauten Betriebsmitteln zur Unterstützung der Ausführung eines ersten Befehls vom ersten Benutzerebenenthread mangelt.
26. Verfahren nach Anspruch 18, ferner umfassend: Übertragen der Steuerung und von Zustandsinformationen von einer OS-abgesonderten Befehlsablaufsteuerung zu einer OS-sichtbaren Befehlsablaufsteuerung; und Migrieren einer Ausführung zumindest eines Befehls vom ersten Benutzerebenenthread an der OS-abgesonderten Befehlsablaufsteuerung zur OS-sichtbaren Befehlsablaufsteuerung, so daß die OS-sichtbare Befehlsablaufsteuerung ein Betriebssystem auslösen kann, einen OS-Dienst im Auftrag der OS-abgesonderten Befehlsablaufsteuerung durchzuführen.
27. Verfahren nach Anspruch 18, ferner umfassend: Einstellen der Ausführung des ersten Benutzerebenenthreads in der ersten Befehlsablaufsteuerung (338), die unter der Steuerung des Anwendungsebenenprogramms steht; Übertragen eines Adressenzeigers von der ersten Befehlsablaufsteuerung (338) zu einer OS-sichtbaren Befehlsablaufsteuerung, wobei der Adressenzeiger auf einen Inhalt, der in einem Speicher gespeichert ist, zeigt; Laden des Inhalts am Adressenzeiger mit der OS-sichtbaren Befehlsablaufsteuerung; und Wiederaufnehmen der Ausführung des ersten Benutzerebenenthreads in der ersten Befehlsablaufsteuerung (338), nachdem die Inhalte am Adressenzeiger geladen wurden.

Images