-
Diese
Erfindung bezieht sich auf Multiprozessor- oder Computersysteme
und insbesondere auf Techniken, die einer Host-CPU ermöglichen,
Aufgaben, die nicht kompatibel mit dem aktuellen Operationsmodus
der Host-CPU sind, einer oder mehreren Slave-CPUs, die die Betriebsmittel und die
notwendigen Betriebskonfiguration zur Ausführung derselben hat oder haben,
zuzuladen.
-
Viele
beliebte Personalcomputer basieren auf der Intel Corporation (Intel).
Die 8086-Rechnertamilie
umfasst den 8088, den 8086, den 80186, den 80286, den 80386, den
80486 und in letzter Zeit die Pentium-Prozessoren und Pentium-Pro-Prozessoren.
Diese komplexen Befehlssatz-Mikroprozessoren sind für Aufwärts-Kompatibilität ausgelegt,
d. h. Programme, die für
den 16-Bit-8088/8086 geschrieben wurden, können auf dem 80286, dem 80386,
dem 80486 und den Pentium- oder Pentium-Pro-Prozessoren betrieben
werden. Für
den Zweck dieser Offenlegung wird die aufwärts kompatible Baureihe der
Intel-Prozessoren und anderer Prozessoren, die einen Befehlssatz
dieser Prozessoren enthalten, im Folgenden als die Intel-x86-Rechnerfamilie
von Mikroprozessoren bezeichnet. Ebenso können für den Zweck dieser Offenlegung
der 8088 und der 8086 als funktionsgemäß äquivalent betrachtet werden
und werden im Folgenden als „der
8086" bezeichnet.
Zusätzlich
werden der 80386, der 80486, der Pentium und der Pentium Pro als
funktionsgemäß äquivalent betrachtet
und im Folgenden als „der
80386" bezeichnet.
-
Die
erste Generation der x86-Intel-Mikroprozessor-Rechnerfamilie, der
8086 und der 8088 erschien 1981 mit der Einführung des IBM-PC der International
Business Machines Corporation. Sie wurde sofort ein kommerzieller
Erfolg, der ein Durcheinander von vergleichbaren Einheiten auslöste, die
Mikroprozessoren 8086 oder 8088 enthielten. Mit der Zeit wurde die
PC-Bauweise allgemeine Norm für den
Multimilliarden-PC-Markt. Gleichermaßen wurde das erste Betriebssystem
des PCs, MS-DOS, sofort und weltweit zur Anwendung gebracht. Dies
lief auf eine enorme Menge an Software hinaus, die zum Betreiben
auf Geräten
der 8086-Klasse, die MS-DOS betrieben, entwickelt wurde.
-
Jedoch
wurden die Beschränkungen
des 8086 bald erkannt, als der Systemspeicher billiger wurde und
die Benutzer anspruchsvoller wurden. Der 8086 konnte nur 1 MB Speicher
direkt adressieren, der in einer Ansammlung von statischen 64 KB-Segmenten
organisiert war und bot keine wirklichen mehrpfadigen, mehraufgabenfähigen Fähigkeiten oder
hierarchische Tasking-Programme. Um den Mängeln ihrer Rechner zu begegnen,
führte
Intel deshalb 1983 den 80286 ein. Der Intel 80286 bot mehrere neue
Leistungen, von denen die hervorragendste die Fähigkeit umfasste, in verschiedenen
Betriebsarten – real
und geschützt – zu arbeiten.
Im Realbetrieb arbeitete der 80286 wie ein schneller 8086 und konnte
MS-DOS und Anwendungen, die ursprünglich für den 8086 entwickelt wurden,
ohne Modifizierung betreiben. Dies bedeutete jedoch auch, dass der
80286, wenn er im Realbetrieb betrieben wurde, die gleichen Beschränkungen
wie der 8086 aufwies. Der geschützte
Betrieb erlaubte die volle Anwendung der weiterentwickelten Adressierung
und der Multitasking-Fähigkeiten
des 80286, jedoch wurden die Rückwärts-Kompatibilität mit dem
8086 und mit MS-DOS geopfert. Weiterhin konnte der 80286, wenn er
sich im geschützten
Betrieb befand, nur durch einen Reset des Rechners auf den Realbetrieb zurückgeschaltet
werden. Infolgedessen wurden die Vorteile des geschützten Betriebs
des 80286 von PC-Software-Entwicklern wenig genutzt.
-
Mit
der Baureihe der 80386-Mikroprozessoren überwand Intel schließlich diese
Beschränkungen.
Wie auch der 80286, bot der 80386 sowohl einen Realbetrieb als auch
einen geschützten
Betrieb an, bot jedoch höher
entwickelte Adressierung und Datenübertragung an. Ebenso konnten
dem Betriebssystem Privilegstufen (als Ringe bekannt, wobei Ring
0 der höchste
und Ring 3 der niedrigste ist) zugewiesen werden und Anwendungen,
um den Schutz vor Speicherfehlern zu verbessern und den Zugriff
auf Systemdienste während
der Ausführung von
Multitasking-Operationen zu verbessern. Vor allem konnte der 80386
einen 8086 emulieren, während
er im geschützten
Betrieb war und zwar durch virtuelle 8086- (V86-) Emulation. MS-DOS
selbst, oder andere Realbetriebanwendungen, konnten als ein V86-Task,
dem Kern im geschützten
Betrieb untergeordnet, aufgerufen werden. Mit derartigen geschützten Programmen
und einem 4-Gigabyte
dynamisch zuordbaren Speicherplatz konnte der 80386 mehrere V86-Thread-Arbeitsgänge mit
Leichtigkeit gleichzeitig ausführen
und konnte diese gleichzeitig mit Aufgaben im geschützten Betrieb
ausführen.
Eine ausführlichere
Beschreibung der Intel-x86-Entwicklung
und ein Vergleich der Leistungsfähigkeit
jedes Mikroprozessors ist in U. S. Pat. Nr. 5,303,378, mit dem
Titel „Reentrant
Protected Mode Kernel Using Virtual 8086 Mode Interrupt Service
Routines" zu finden.
-
Der
geschützte
Betrieb des 80386 ermöglicht
fortgeschrittenen Betriebssystemen und Anwendungsprogrammen, das
volle Potential des 80386 und seiner Nachfolger zu entfalten. Jedoch
unterstützt
der geschützte
Betrieb, hauptsächlich
wegen inkompatibler Adressierungsverfahren, noch immer nicht das
vorherrschende PC-Betriebssystem MS-DOS als eine Systemanwendung. Deshalb
kann die Codeausführung
im geschützten
Betrieb die meisten Bios-Level-Dienstprogramme nicht ausführen und
die MS-DOS-Software
unterbricht und muss sich stattdessen auf eine langsame Software-Emulation
stützen,
wenn derartige Dienste oder verwendete überlange Reflexionstechniken
erforderlich sind.
-
Die
V86-Task-Ausführung
auf dem 80386 wurde sogar noch weitergehender aus dem Dienstprogramm
und der Hardware entfernt. Programme, die auf MS-DOS basieren, von
denen viele vor der Einführung
des 80386 geschrieben wurden, setzten typischerweise ausschließlich Zugriff
auf BIOS und die System-Eingabe/Ausgabe voraus und rufen häufig Realbetriebsdienste
auf, um ihre Funktionen auszuführen.
Um diese Programme in die hierarchische Multitasking-Umgebung des
geschützten
Betriebs zu integrieren, verweigern Systementwickler den V86-Tasks
den direkten Zugriff auf die meisten BIOS-Level-Aufrufe und die
DOS-Software unterbricht. Andernfalls könnten sie vordrängen, ohne
die Privileg-Hierarchien des geschützten Betriebs zu respektieren.
Alle Aufrufe werden durch eine virtuelle DOS-Überwachung (VDM) gefangen,
entschieden und emuliert, ohne mit dem MS-DOS selbst durch eine
Schnittstelle verbunden zu sein. Die VDM ist ebenso für die Unterbrechung
von Reflexionsaktivitäten,
die isolierte V86-Tasks über
Systemänderungen benachrichtigen,
verantwortlich. Die VDM ist bei der Emulation dieser Aufrufe erfolgreich,
jedoch verlangen die zusätzlichen
Verarbeitungsschritte im Vergleich zu dem echten Realbetrieb einen
schweren Leistungsverlust ab. Außerdem muss die VDM, bevor
beliebige V86-Threads beginnen können,
durch den geschützten
Modellkern vorinstalliert werden, typischerweise von einer Disk
und derartiges Emulieren legt eine zusätzliche Codeverwaltungslast
auf, die von Kompatibilitätsfaktoren,
die unabhängig
von der Anwendung sind, bei der Emulation gebraucht wird, abhängt.
-
Alternativ
kann der 80386 niedrige BIOS-Level und MS-DOS-Dienste durch Zurückfallen
in den Realbetrieb unterstützen.
Wie oben und in dem U. S. Pat. Nr. 5,303,378 erörtert, deaktiviert jedoch der Übergang
zurück
in den Realbetrieb alle Funktionen des geschützten Betriebs und hinterlässt den
Mikroprozessor lediglich so schnell wie den 8086 arbeitend. Selbst
ein kurzzeitiger Übergang
stört den
Zugriff auf den Speicher über
1 MB hinaus und deaktiviert die meisten Multitasking-Schutzmechanismen, was
zu unerwünschter
Suspendierung von Threads oder zur Beendigung oder zu Datenkorruption
führt, selbst
wenn bei erweitertem Betrieb Kellerspeicher-Ablageoperationen verwendet
werden. Ebenso muss das Speicherabbild des geschützten Betriebs bei erneutem
Eintritt in den geschützten
Betrieb neu initialisiert werden, was bei der Dienstabwicklung jeder
Realbetriebsabfrage neue kritische Programmschritte und Taktzyklen
hinzufügt.
Deshalb wäre
es erwünscht,
die Funktionen und Systembetriebsmittel, die für eine bestimmte Betriebsart
zugreifbar sind, zu verwenden, ohne auf langsame Software-Emulation zurückzugreifen
oder die aktuelle Betriebsart des 80386-System-Mikroprozessors zu ändern.
-
EP-A-0623875
legt ein Computersystem mit einer Vielzahl von unabhängigen Prozessoren
offen, die entweder einen getrennten Prozess für jeden Prozessor ausführen können, oder
parallele Prozessoperationen über
mehrere Prozessoren für
einen Prozess ausführen
können.
-
EP-A-0442041
legt einen Mehrzweckrechner offen, der einen Digitalsignalrechner
zur Ausführung
von bestimmten Befehlen zur Signalverarbeitung aufruft.
-
EP-A-0668560
legt ein Verfahren offen, bei dem das Errechnen intensiver Funktionen,
wie zum Beispiel der Datensortierung, einem zweiten Rechner zugeladen
wird.
-
US 4943915 legt ein Datenverarbeitungssystem
zum Synchronisieren des Betriebs einer Co-Rechnereinheit mit dem
Rest einer CPU offen, das zur Fließbandverarbeitung von Befehlen
implementiert wird.
-
EP-A-0358136
legt einen Mikroprozessor offen, der einen Befehl durch einen extern
mit dem Mikroprozessor verbundenen Co-Rechner erweitern kann.
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zum Betreiben eines Multiprozessorsystems
bereitgestellt. Das Multiprozessor-Computersystem umfasst einen
ersten Multimodusprozessor, der geeignet für den Betrieb in einem ersten
Verarbeitungsmodus und für
den Betrieb in einem zweiten, mit dem ersten Verarbeitungsmodus
inkompatiblen Verarbeitungsmodus, und zum Wechseln zwischen dem
ersten und dem zweiten Verarbeitungsmodus, konfiguriert ist und
einen zweiten Prozessor, konfigurierbar für den Betrieb in einem zweiten,
mit dem ersten Verarbeitungsmodus inkompatiblen Verarbeitungsmodus,
Einrichtungen zum Speichern eines Codevektors und Einrichtungen
zum Speichern von Daten und Befehlsparametern, die sowohl für den ersten
als auch für
den zweiten Prozessor zugreifbar sind, wobei das Verfahren die folgenden
Schritte umfasst:
Treffen des ersten Prozessors, während er
im ersten Verarbeitungsmodus ist, auf einen Befehl, der nicht durch
den ersten Prozessor ausgeführt
werden kann, sondern nur Software emuliert, während er im ersten Verarbeitungsmodus
ist, und der durch den ersten Prozessor ausgeführt werden kann, während er
im zweiten Verarbeitungsmodus ist,
Ermitteln durch den ersten
Prozessor, ob der zweite Prozessor für die Verarbeitung des Befehls
verfügbar ist
und
Offloading des Befehls durch den ersten Prozessor auf den
zweiten Prozessor, wenn der zweite Prozessor für die Verarbeitung des Befehls
verfügbar
ist, wobei die Offloading-Schritte umfassen:
Zuladen der zur
erfolgreichen Verarbeitung des Befehls erforderlichen Daten und
Befehlsparameter in die Speichereinrichtung durch den ersten Prozessor,
Bereitstellen
eines auf den zur vollständigen
Verarbeitung des Befehls notwendigen Quellcode hinweisenden Codevektors
in der Codevektor-Speichereinrichtung durch den ersten Prozessor,
Aktivieren des zweiten Prozessors durch den ersten Prozessor,
Verwenden
der gespeicherten Daten, der Befehlsparameter und des gespeicherten
Codevektors durch den zweiten Prozessor, um die Verarbeitung des
Befehls aufzunehmen,
Speichern der durch die Verarbeitung des
Befehls beschafften Resultate in der Daten und Befehlsparameterspeichereinrichtung
durch den zweiten Prozessor,
Melden des zweiten Prozessors
an den ersten Prozessor, wenn die Verarbeitung des Befehls abgeschlossen
ist,
Laden der gespeicherten Resultate durch den ersten Prozessor
zur Verwendung bei einem nachfolgenden Prozess, wenn die Meldung
des zweiten Prozessors empfangen wurde.
-
Die
vorliegende Erfindung involviert das Hinzufügen wenigstens eines Mikroprozessors,
der im Folgenden als der Slave-Mikroprozessor oder Slave bezeichnet
wird, der mit dem 80386-Mikroprozessor, der als System-CPU dient,
der im Folgenden als der Host-Mikroprozessor
oder als Host bezeichnet wird, so verbunden ist, dass Datenübertragung
zwischen den Rechnern möglich
ist. Vorzugsweise wird eine zugeordnete Leitung oder werden mehrere
zugeordnete Leitungen, die von dem Host-Prozessor ausgeht oder ausgehen,
elektrisch mit der Schaltung der Hardware-Interrupt-Leitung oder
mit den Eingängen für die Datenübertragung
zwischen den Rechnern des Slave-Mikroprozessors
verbunden, um Task-Kontrolle durch den Host zu ermöglichen.
Weitere durch die Slave-Mikroprozessoren unterhaltene Verbindungen
sollten jene zwischen dem Host und dem Rest des Computersystems
imitieren und die Slave-Mikroprozessoren
werden in einer bekannten Art und Weise in das Computersystem integriert,
so dass sie auf den gleichen Speicher zugreifen können oder
an den gleichen Adressen eingeben/ausgeben können, wie jene, die für den Host-Mikroprozessor spezifiziert
sind.
-
Der
Slave-Mikroprozessor bzw. die Slave-Mikroprozessoren wird bzw. werden
für den
Offload von Software-Unterbrechungsbearbeitung und von anderen betriebsartspezifischen
Befehlen, auf die der Host-Mikroprozessor trifft, wenn der Host nicht
in der richtigen Betriebsart ist, um den Befehl auszuführen, verwendet.
Genauer gesagt, wenn der Host-Mikroprozessor auf einen Befehl trifft,
der wegen des aktuellen Betriebszustands des Hosts nicht bedient
werden kann, wird der Host versuchen, einen „verfügbaren" Slave-Mikroprozessor zu finden, der zur
Ausführung
des Befehls geeignet ist. Dies kann das Abfragen des aktuellen Zustands
des Slave-Mikroprozessors über
Zustand und Betriebsartzustand umfassen. Wenn keine Slave-Mikroprozessoren
verfügbar
sind, belegt der Host das Kommando zur Weiterverarbeitung auf eine
konventionelle Art und Weise durch Software-Emulation oder zeitweilige
Transition des Betriebszustandes vor. Wenn jedoch ein geeigneter
Slave zugeordnet wird, nimmt ihn der Host für die Ausführung des Befehls in Anspruch.
Der Host füllt
das Register des Slaves mit den zur Ausführung des Befehls erforderlichen
Informationen einschließlich
der Startadresse des Codes der benötigt wird, um den erwünschten
Befehl durchzuführen,
aller notwendigen Eingabeparameter (weitergegeben durch Verweis
oder durch Wert) und Speicherplätze,
an denen die Resultate gespeichert werden können. Bei Bedarf wird der Host
den ausgewählten
Multimodus-Slave für
den adäquaten
Betriebsmodus neu konfigurieren.
-
Nachdem
alle notwendigen Informationen geladen wurden und die Slave-Betriebsart
bedingt konfiguriert ist, weist der Host den ausgewählten Slave
an, die Ausführung
an der adäquaten
Codeadresse zu beginnen, während
er seine eigene Ausführung des
Tasks vorläufig
einstellt. Der Slave fährt
damit fort, das Programm auf eine konventionelle Art und Weise auszuführen und
lädt bei
Vollzug die Resultate auf die zugewiesenen Speicherstellen und signalisiert
an den Host. Danach stellt der Slave-Mikroprozessor die Ausführung ein
und wartet auf das Erfolgen des nächsten für den Host modusungeeigneten Befehls.
Zwischenzeitlich führt
der Host, bei Empfang des durch den Slave ausgelösten Vollzugsignals, ein Upload
der Ergebnisse in sein eigenes internes Register durch und nimmt
die konventionelle Ausführung
des zeitweilig eingestellten Threads wieder auf.
-
Die
vorliegende Erfindung bietet eindeutige Vorteile gegenüber dem
Stand der Technik, weil ein Wechsel der Host-Betriebsart oder eine
komplizierte Emulation nicht erforderlich ist, um den modusungeeigneten
Befehl oder die modusungeeignete Anweisung zu verarbeiten. Weiterhin
ermöglicht
es die Technik der bevorzugten Ausführung dem Host, die Ausführung des
Tasks, bei dem der modusungeeignete Befehl entdeckt wurde, zeitweilig
einzustellen, was dem Host ermöglicht,
sich anderen Tasks in der Warteschlange zuzuwenden, während ein
untergeordneter Mikroprozessor den Befehl durchführt. Ebenso müssen die
Slave-Mikroprozessoren nicht multimodusfähig sein, solange sie anderweitig
Registerlevel-Kompatibilität
mit dem Host-Mikroprozessor bereitstellen können. Schließlich veranschaulicht
die bevorzugte Ausführung,
dass die vorliegende Erfin dung nicht implementierungsspezifisch
ist und angewendet werden kann, wann immer der Host mit einer in
dem Computersystem ebenso vorhandener Slave-Einheit oder mehreren
in dem Computersystem ebenso vorhandener Slave-Einheiten Daten austauschen
kann und diese Slave-Einheiten) steuern kann.
-
Ein
besseres Verständnis
der vorliegenden Erfindung ergibt sich, wenn die folgende ausführliche Beschreibung
der bevorzugten Ausführung
in Verbindung mit den begleitenden Zeichnungen betrachtet wird,
in denen
-
1 ein Blockdiagramm des
Computersystems gemäß der bevorzugten
Ausführung
ist,
-
2 ein ausführlicheres
Blockdiagramm der CPU der 1 ist,
-
3A und 3B Fließdiagramme der von dem Host-Mikroprozessor
der bevorzugten Ausführung
vorgenommenen Prozessschritte zum Offload eines modusungeeigneten
Befehls auf den Slave-Mikroprozessor der bevorzugten Ausführung sind
und
-
4A und 4B Fließdiagramme der von dem Slave-Mikroprozessor
der bevorzugten Ausführung
vorgenommenen Prozessschritte bei der durch den Host der bevorzugten
Ausführung
angeforderten Ausführung
des modusungeeigneten Befehls sind.
-
Bezug
nehmend auf 1 wird ein
Computersystem C gezeigt, das ein Computersystem ist, das in der
bevorzugten Ausführung
vorzugsweise vier zentrale Recheneinheiten (CPUs) umfasst, obwohl
die vorliegende Erfindung in ein System aufgenommen werden kann,
das nur zwei CPUs aufweist. Die Elemente des Computersystems C,
die für
die vorliegende Erfindung nicht wesentlich sind, es sei denn, um
ein Beispiel eines vollständig
konfigurierten Computersystems darzustellen, werden nicht detailliert
erörtert.
Die Mehrzahl der in 1 gezeigten Funktions-
und Einrichtungsblöcke
wird vorzugsweise auf einer Systemkarte (nicht gezeigt) angebracht. Das
Computersystem C enthält
vorzugsweise vier CPUs, die als CPU 20, 21, 22 und 23 bezeichnet
werden, die an einen Hostbus 24 gekoppelt sind. Die CPUs 20–23 werden
jeweils als CPU0, CPU1, CPU2 und CPU3 bezeichnet, womit die Zuweisungen
der bevorzugten logischen Eingänge
angegeben werden. In der bevorzugten Ausführung werden wenigstens vier
CPU-Steckverbinder auf dem Hostbus 24 zur Aufnahme von
auswechselbaren CPU-Karten bereitgestellt, wobei die CPUs 20–23 im
Wesentlichen identisch in Konfiguration und Funktion sind. Es sei angemerkt,
dass das Computersystem C zur Unterstützung einer Höchstanzahl
von 8 CPUs geeignet ist. Die Eingangszuweisungen werden anfänglich durch
den physikalischen Einschub, in den die CPU-Karte eingesteckt wird,
bestimmt, obwohl die Zuweisung des logischen Eingangs vorzugsweise programmierbar
ist.
-
Ein
Speichercontroller 30 wird mit dem Hostbus 24 und
ebenso mit einem Hauptspeicher-Array 32 gekoppelt, das
vorzugsweise mehrere DRAM-Bänke
enthält.
Die Speicher-Mapper-Logik 34 wird mit dem Hostbus 24,
dem Speichercontroller 30 und dem Speicher-Array 32 gekoppelt
und stellt Speicher-Mapping-Funktionen zur Erleichterung des Speicherzugriffs
an das Speicher-Array 32 bereit. Das Computersystem C enthält einen
Erweiterungs-Bus 42, der vorzugsweise der EISA-(Extended Industry
Standard Architecture-)Bus ist, obwohl andere Arten von Erweiterungs-Bussen
in Erwägung gezogen
werden können.
Eine entsprechende EISA-Bus-Steuerung (EBC) 40 wird zwischen
den Hostbus 24 und den EISA-Bus 42 gekoppelt.
Der EBC 40 stellt verschiedene Bus-Zyklus-Translationen
und Konvertierungsfunktionen bereit, um die Übertragung zwischen dem Hostbus 24 und
dem EISA-Bus 42 zu erleichtern. Ein Systemdatenpuffer (SDP) 44 ist
an den Hostbus 24, den EISA-Bus 42 und das Speicher-Array 32 gekoppelt.
Der SDB 44 arbeitet, um die Daten zwischen dem Hostbus 24 und dem
Speicher-Array 32,
zwischen dem Hostbus 24 und dem EISA-Bus 42 und
zwischen dem EISA-Bus 42 und
dem Speicher-Array 32 zu puffern und zu übertragen.
-
Ein
Logikblock, der als eine Zentralsystemperipherie (CSP) 46 bezeichnet
wird, ist an den Hostbus 24, den EISA-Bus 42 und
ebenso an eine Tastaturcontroller 62 gekoppelt. Die CSP 46 ist
vorzugsweise durch einen MUX-Bus 50 an einen logischen Block
gekoppelt, der als die verteilte Systemperipherie (DSP) 88A in
der CPU 20 an eine in der CPU 21 angeordnete DSP 88B,
an eine in der CPU 22 angeordnete DSP 88C und
an eine in der CPU 23 angeordnete DSP 88D gekoppelt
ist. Der MUX-Bus 50 umfasst eine Vielzahl von Leitungen
zur Übertragung von
Signalen zwischen der CSP 46 und den DSPs 88A–D.
Der EISA-Bus 42 enthält
eine Vielzahl von EISA-Einschubrahmen 52 und 54 zur
Aufnahme von auswechselbaren EISA-Erweiterungskarten, wie zum Beispiel
Netzwerkkarten und Festplattenkarten. Der EISA-Bus 42 ist
durch Puffer 56 an einen Bus, der als ein X-Bus 60 bezeichnet
wird, gekoppelt. Eine Anzahl von Peripherieeinrichtungen ist an
den X-Bus 60 gekoppelt: der Tastatur-Controller 62,
eine Echtzeituhr (RCT) 64, ein elektronisch löschbarer
programmierbarer Festwertspeicher (EEPROM) 66, ein Disketten-Controller 68 und
einen Peripherie-Controller-Chip 70, der zahlreiche Eingänge und UARTs (universelle
Asynchron-Empfänger/Sender)
enthält. Der
EEPROM 66 enthält
bestimmte Grundbetriebsprogramme, die als BIOS bezeichnet werden,
um die Hochfahrfunktionen in dem Computersystem C durchzuführen. Die
Hochfahrfunktionen schließen die
Initialisierung von Einrichtungstreibern für die peripheren Einrichtungen
und die I/O-Einrichtungen ein. Der X-Bus 60 ist ebenso
an einen Festplatten-Controller 69 gekoppelt, der einem
Festplattenlaufwerk 71 Steuerungs- und Datensignale bereitstellt.
-
Die
CPS 46 enthält
verschiedene Systemfunktionen, einschließlich eines Auftrischungs-Controllers 90,
einer MUX-Bus Schnittstelle 92, die an den MUX-Bus 50 gekoppelt
ist, eines Direkt-Speicherzugriff-(DMA-)Controllers 94,
eines EISA- oder zentralen Arbitrations-Controllers (CAC) 96 und
diverser anderer logischer Funktionen der Systemkarte, die generell
als die SGC 98 bezeichnet werden. Der Auffrischungs-Controller 90 steuert
die Auffrischung der DRAMs in dem Speicher-Array 32 und
der DMA-Controller 94 steuert den Direkt-Speicherzugriff
auf den Speicher 32 durch die Peripherie- und I/O-Einrichtungen. Die
MUX-Bus-Schnittstelle 92 empfängt verschiedene Interrupt-Anforderungssignale IRQ3-IRQ12,
IRQ14 und IRQ15 von den verschiedenen Peripherie- und I/O-Einrichtungen.
Die MUX-Bus-Schnittstelle 92 überträgt dann die Interrupt-Anforderungssignale
an die DSPs 88A–D über den
MUX-Bus 50. Die SGC 98 in der CSP 46 enthält die CPU-Restart-Logik
und die Force-A20-Logik und aktiviert entsprechende RSTAR- und LOW-A20-Signale,
die dem MUX-Bus 50 bereitgestellt werden.
-
Diverse
weitere Übertragungen
sind erforderlich, um die DSPs 88A–D über das
Eintreten diverser Ereignisse innerhalb der CSP 46 zu informieren,
u. a. sowohl die Bestätigung
als auch die Nicht-Bestätigung,
dass diese Ereignisse auf den MUX-Bus 50 übertragen
werden. Beim Hochfahren ermittelt der Computer C automatisch, welche
CPUs in den verfügbaren
physikalischen CPU-Einschüben installiert
sind und weist logische Eingangsnummern zu. Ein Hochfahrzeitabschaltungssignal
wird aktiviert, das angibt, dass die CPU nicht installiert ist, wenn
eine CPU nicht vor der Zeitabschaltung eines Timers reagiert.
-
Im
Folgenden Bezug nehmend auf die 2 wird
ein Blockdiagramm der CPU 20 gezeigt. Die CPUs 20–23 arbeiten
vorzugsweise auf eine sehr gleiche Art und Weise, ausgenommen, dass
nur die CPU 20 in der bevorzugten Ausführung eine Speicher- Auffrischung generiert,
da sie vorzugsweise die Host-CPU ist, d. h., sie ist logisch der
CPU0 zugewiesen. Die CPU 20 wird im Folgenden beschrieben.
Es versteht sich, dass die folgende Beschreibung ebenso für die CPUs 21–23 gilt.
Die CPU 20 enthält
einen Rechner 72, der vorzugsweise entweder der Pentium oder
der 80486-Mikroprozessor von Intel ist. Der Rechner 72 ist
an einen Rechnerbus 76 gekoppelt, der Steuerungs-, Daten-
und Adressbereiche, wie gezeigt, enthält. Ein 2 Level Cache-Controller 78 ist an
die Adressen- und Steuerungsbereiche des Rechnerbusses 76 gekoppelt.
Ein Cache-Speicher 80 ist an
die Adressen- und Datenbereiche des Rechnerbusses 76 gekoppelt.
Der Cache-Controller 78 ist über verschiedene Kontrollleitungen
mit dem Cache-Speicher 80 verbunden,
um einen vereinheitlichten Rückschreib-
und Anweisungscache, der für
die Systemsoftware erkennbar ist, bereitzustellen.
-
Die
Cache-Schnittstellenlogik 82 ist durch Kontrollleitungen
an den Cache-Controller 78 gekoppelt und ist an den Steuerungsbereich
des Rechnerbusses 76 und des Hostbusses 24 gekoppelt.
Die Adress-Pins des Cache-Controllers 78 sind mit einem
Transceiver verbunden, der wiederum mit dem Hostbus 24 verbunden
ist. Die durch den Transceiver 84 bereitgestellten Adressensignale
werden ebenso mit der Cache-Schnittstellenlogik 82 verbunden.
Die Daten-Pins des Cache-Speichers 80 werden mit einem
Cache-Datenpuffer 86 verbunden,
der mit dem Hostbus 24 verbunden ist. Der Cache-Datenpuffer 86 ist
mit der DSP 88A über
einen lokalen I/O-Bus 90, der die lokalen I/O-Adressdaten und Kontrollleitungen
umfasst, verbunden.
-
Die
DSP 88A enthält
einen programmierbaren Interrupt-Controller (PIC), eine NMI-Logik, verschiedene
Timer und eine Multiprozessor-Interrupt-Logik (MPINT). Der PIC umfasst
vorzugsweise zwei kaskadierte 8-Bit-Interrupt-Controller INT-1 und INT-2,
jeder ähnlich
dem Intel 8259, um 15 Interrupt-Level bereitzustellen. Der INT-1
hat die Eingaben IRQ0–IRQ7,
wovon IRQ2 die kaskadierte Interrupt IRQ2 von 1NT-2 ist. INT-2 empfängt die
Eingaben IRQ8–IRQ15.
Die CSP 46 stellt die Interrupts IRQ1, IRQ3–12 und
IRQ14 und IRQ15, wie zuvor beschrieben, über den MUX-Bus 50 an
den PIC bereit. Das IRQ0-Signal wird von den verschiedenen Timern bereitgestellt
und stellt ein System-Timer-Interrupt für eine Uhrzeit, das Disketten-Timeout
und andere System-Timing-Funktionen
bereit. Das IRQ13-Interrupt wird zusammen mit einem DMA-Interrupt,
einem korrigierbaren Speicherfehler-Interrupt, einem Coprozessor-Fehler-Interrupt
und mehreren CPU-IRQ13 programmierbaren Interrupts benutzt.
-
Steuerungs-,
Masken- und Flanken-/Level-Kontrollregister werden in der DSP 88A für jeden der
Interrupt-Controller INT-1 und INT-2 bereitgestellt. Ebenso ist
ein Interrupt-Anerkennungsregister, das
als das INTA-Register bezeichnet wird, für die lokale CPU über einen
Interrupt-Anerkennungszyklus für
den lokalen I/O-Bus 90 zugreifbar. Der PIC aktiviert ein
Signal INT an die CPU 20, wenn beliebige dieser Interrupts
auftreten und nicht maskiert sind.
-
Die
NMI-Logik in der DSP 88A erzeugt ein NMI-Interrupt über ein
Signal NMI, um den lokalen Rechner 72 über die Bedingungen in dem
System, die sofortige Aufmerksamkeit benötigen, bevor der Rechner 72 mit
seinem aktuellen Task fortsetzen kann, zu benachrichtigen.
-
Die
MPINT ermöglicht,
CPU-Interprozessor-Interrupts (IPIs) und andere Interrupt-Quellen gemeinsam
auf jedem Interrupt-Level zu benutzen und ermöglicht auf diese Art und Weise
eine höhere
Softwareflexibilität
in einer Multiprozessorumgebung. Die MPINT generiert die Interrupt-Level-MPIRQ0–15, die als
Reaktion auf Interprozessor-Interrupts generiert werden. Jedes programmierbare
PCU-Interrupt kann bei jedem Interrupt-Level durch Multiprozessor-Interrupt-Steuerungs-/Status-Eingänge einzeln
aktiviert werden, deaktiviert werden, eingestellt oder gelöscht werden.
Die MP-Interrupt-Eingänge
werden im Allgemeinen als Steuerungseingänge bezeichnet, wenn sie angeschrieben
werden und als Statuseingänge, wenn
sie gelesen werden. Jedes Level des Interrupts, im Allgemeinen durch
den Buchstaben X dargestellt, ist eine ganze Zahl von 0 bis 15,
die Level 2 ausschließt,
bei dem jedes der Interrupt-Level MPIRQ0–15 seinen eigenen MP-Interrupt-Steuerungs-/Status-Eingang
hat. Vorbestimmte, in die Steuerungseingänge geschriebene Werte, können folglich
ein Interrupt-Level-MPIRQX freigeben oder einstellen, um auf eine
IPI zu reagieren. Der Status für
jedes der Interrupt-Levels X kann durch Lesen des entsprechenden
MP-Interrupt-Status-Eingangs beschafft werden. Der Rechner 72 kann
auf seine eigenen MP-Interrupt-Eingänge über den lokalen Buszugriff
zugreifen und kann auf die MP-Interrupt-Eingänge anderer Rechner durch den
Hostbus 24 zugreifen.
-
Das
Mapping der Interprozessor-Interrupts auf Interrupt-Level-MPIRQX
erfolgt über
einen CPU-Interrupt-Maskeneingang und einen durch die CPU programmierbaren
Inter rupt-Eingang. Die MP-Interrupt-Anforderungsausgaben (MPIRQX) werden
mit den IRQX-Eingaben innerhalb des PIC0 gelesen und ermöglichen
somit das Benutzen der Interprozessor-Interrupt-Levels zusammen
mit normalen System-Interrupts.
-
In
der folgenden Beschreibung wird vorausgesetzt, dass die CPU 20 die
Host-CPU ist, obwohl jede der anderen CPUs 21–23 Host
sein kann. Da per Definition nur eine CPU als Host bestimmt werden
kann, werden in der folgenden Beschreibung die CPUs 21–23 kollektiv
als die Slave-CPUs bezeichnet.
-
Es
versteht sich, dass andere Anordnungen des Multiprozessor-Computersystems
verwendet werden könnten,
wobei die einzelnen Rechner auf andere Art und Weise angeordnet
werden und auf andere Art und Weise miteinander Daten austauschen.
-
Die 3A und 3B sind Fließdiagramme der von der Host-CPU
vorgenommenen Prozessschritte zum Offload eines modusungeeigneten
Befehls gemäß der bevorzugten
Ausführung.
Als ein besonderes Beispiel zeigen die 3A und 3B,
wie die Host-CPU 30 ein BIOS-Level-INT-13h-Diskettentreiber-Software-Interrupt
initialisiert, während
sie im geschützten
Betrieb verbleibt.
-
Während der
Ausführung
eines Threads, kann die Host-CPU 20 auf eine Anweisung,
einen Befehl oder ein Interrupt (im Folgenden zusammengefasst als
Befehl bezeichnet) treffen, die bzw. den sie in ihrem aktuellen
Betriebsmodus nicht verarbeiten kann. Gemäß der bevorzugten Ausführung beginnt, wenn
sich eine derartige Situation entwickelt, die Ausführung durch
die Host-CPU bei Schritt 1000. In dem Schritt 1010 wird
ein vorzugsweise softwarebasierter slave_available Wachhund-Timer
neu eingestellt, um die Höchstwartezeit
anzugeben, die der Host, um auf eine verfügbare Slave-CPU 21, 22 oder 23 zu
warten, einzukalkulieren hat, bevor er auf die Verarbeitung des
modusungeeigneten Befehls zurückfällt (d.
h. durch die oben erörterten
Ring- und Modustransitionen oder durch Befehls-Emulation). Ebenso
stellt der Softwaretimer sicher, dass die Rückwärtskompatibilität für Systeme,
die zu diesem Zweck keine Slave-CPUs eingesetzt haben, aufrechterhalten
bleibt. Danach geht die Steuerung zu dem Schritt 1011 über. In
dem Schritt 1011 wird ermittelt, ob eine Slave-CPU 21–23 zum
Offload der Ausführung
des modusungeeigneten Befehls verfügbar ist. Vorzugsweise wird
dies durch das Abfragen des aktuellen Status und des Aktivitätszustands,
die in den 1 und 2 oben beschrieben wurden,
der Multiprozessor-Interrupt-Eingänge jeder der Slave- CPUs erreicht. Alternativ
könnte
die Host-CPU 20 den aktuellen Status aller in dem System
vorhandenen Slave-CPUs 21–23 mittels einer
Suchtabelle, die in einem Rechnerstatusspeicherblock, der vorzugsweise innerhalb
des Hauptspeicher-Arrays 32 enthalten ist, suchen, wobei
dieser Rechnerstatusspeicherblock sowohl für den Host als auch für alle Slave-CPUs
zugreifbar ist. Jede Slave-CPU ist für die Aufrechterhaltung ihrer
eigenen Statuseinträge
verantwortlich, einschließlich
des Konfigurationsmodus (z. B. geschützt, V86 oder real). Andere
Informationen, wie zum Beispiel Task-Prioritätszuweisungen, Anruf der CPU
usw., könnten
auf eine in der Technik bekannte Art und Weise implementiert werden.
Ein Aktivitätszustands-Flag,
das als das slave_finished Flag bezeichnet wird, wird verwendet,
um Arbeits- bzw. Freizustandsanzeigen bereitzustellen, wobei die Host-CPU 20 das
Flag für
den Arbeitszustand setzt und die Slave-CPU das Flag zurück auf den
Freizustand bringt.
-
Wenn
in dem Schritt 1010 wird ermittelt wurde, dass keine Slave-CPU 21, 22 oder 23 verfügbar ist,
um den Befehl zu bedienen, geht die Steuerung zu dem Schritt 1015 über. In
dem Schritt 1015 wird ermittelt, ob der slave_available
Software-Timer abgelaufen ist. Wenn er tatsächlich abgelaufen ist, geht die
Steuerung zu dem Schritt 1016. In dem Schritt 1016 wird
der modusungeeignete Befehl konventionell, entweder durch Software-Emulation, die eine Codeableitung
der VDM verwendet, oder durch Ringmodus-Transition, wie zuvor beschrieben, behandelt.
-
Wenn
in dem Schritt 1015 jedoch ermittelt wird, das der slave_available
Timer noch nicht abgelaufen ist, geht die Steuerung innerhalb dieses Thread
zu dem Schritt 1011 zurück.
Es sollte anerkannt werden, dass die Host-PCU vorzugsweise ein 80386
oder ein höherer
Mikroprozessor ist, der innerhalb eines interrupt-betriebenen Computersystems vollständige Multitasking-Fähigkeiten
anbietet, so dass der Host die Ausführung des aktuellen Threads ordnungsgemäß an jedem
hier beschriebenen Punkt zeitweilig aussetzen kann, um einem Ereignis
oder einem Thread höherer
Priorität
dienen zu können, wie
in der Technik bekannt. Danach werden die Schritte 1011 und 1015 ständig wiederholt,
bis entweder eine Slave-CPU 21–23 mit den notwendigen
Modusfähigkeiten
verfügbar
wird oder der slave_available Softwaretimer abläuft.
-
Wenn
eine Slave-CPU 21, 22 oder 23 vor dem
Ablaufen des slave_vailable Timers verfügbar wird, geht die Steuerung
zu dem Schritt 1020 über.
In dem Schritt 1020 wird ein vorzugsweise angrenzender
Block des Hauptspeicher-Arrays 32, der sowohl für den Host
als auch für
alle in dem Computersystem vorhandenen Slave-CPUs zugreifbar ist,
mit den Parametern, die notwendig sind, um den modusungeeigneten
Befehl erfolgreich auf der ausgewählten Slave-CPU 21, 22 oder 23 durchzuführen, geladen. Speziell
bei dem Fall eines INT-13h-Software-Interrupts gemäß der bevorzugten
Ausführung
wird dieser gemeinsame Speicherblock wenigstens das bestimmte BIOS-Diskettendienstprogramm
zum Ausführen
enthalten, das eventuell in das EAX-Allzweckregister der CPU des ausgewählten Slaves
und in die physikalische Geräte-ID
für die
Zieldiskette oder das Datenfeld der Diskette geladen werden, die
in das EDX-Allzweckregister
des Slaves geladen werden. Andere Speicherorte innerhalb des Blocks,
die weiteren Daten entsprechen, die eventuell in die Register der
CPUs 21, 22 oder 23 zu laden sind, werden
bedingt, basierend auf dem bestimmten Diskettendienstprogramm, das
der Host ausgeführt
haben möchte,
aufgefüllt.
Wenn das Laden abgeschlossen ist, geht die Steuerung zu dem Schritt 1030 weiter.
-
In
dem Schritt 1030 wird, wie in 3A gezeigt, die adäquate Startadresse für den Code,
der notwendig ist, um den ungeeigneten Befehl auf der ausgewählten Slave-CPU 21, 22 oder 23 auszuführen, auf
eine bekannte Art und Weise auf die CS : IP (40 : 67) „warne" Reset-Vektorspeicherstelle
geschrieben. Vorzugsweise wird die Host-CPU 20 die adäquate Startadresse
aus einer Suchtabelle oder einem Array beschaffen, die durch den
erwünschten Slave-Modus
und den eingetroffenen ungeeigneten Befehl verschlüsselt sind.
Dies ermöglicht,
wenn erforderlich, eine automatische Neukonfiguration des ausgewählten Slaves
vor der Ausführung
des Befehls. Jedoch können
Abwicklungstabellen oder Datenbasisalternativen, die den Fachleuten
auf diesem Gebiet bekannt sind, ebenso verwendet werden, um die
richtige Startadresse mit dem zur Ausführung erwünschten Befehl und dem erwünschten
Modus, in dem auszuführen
ist, übereinzustimmen.
Sobald der „warme" Reset-Vektor mit
der adäquaten
Startcodeadresse geladen ist, geht die Steuerung zu dem Schritt 1040 über.
-
In
dem Schritt 1040 löscht
die Host-CPU 20 das in dem oben beschriebenen Status- oder gemeinsamen
Speicherblöcken
enthaltene slave_finished Flag für
die ausgewählte
Slave-CPU. Wenn dieses Flag gelöscht
ist, zeigt dies dem Computersystem und allen CPUs an, dass der ausgewählte Slave
mit der Ausführung
eines modusungeeigneten Befehls beschäftigt ist. Danach geht die Steuerung
zu dem Schritt 1050 über
(3B), in dem die Host-CPU 20 die
ausgewählte
Slave-CPU 21, 22 oder 23 durch Aktivieren
eines Interprozessor-Interrupts an dem Multiprozessor-Interrupt-Eingang
des Slaves rücksetzt,
wie unter Bezugnahme auf die 1 und 2 oben beschrieben wurde.
Alternative Formen des Interprozessor-Datenaustauschs können benutzt
werden, einschließlich
des Weckens des ausgewählten
Slaves aus dem Schlafmodus durch Schreiben eines adäquaten Befehls
an den MP-Interrupt-Eingang des ausgewählten Slaves (s. 2) und ihn dann anzuweisen,
auf den adäquaten,
in dem „warmen" Reset-Vektor platzierten,
Codeabschnitt zu springen, ohne den Rechner tatsächlich zurückzusetzen. Wegen der geringen
Anzahl von Befehlsschritten, die den echten RESET-Vektor und den „warmen" Reset-Vektor zwischenschalten,
und wegen der Geschwindigkeit, mit der eine Slave-CPU asynchron
zurückgesetzt
werden kann, stellt jedoch der Reset der ausgewählten Slave-CPU die beste Leistung
für die
angegebene Konfiguration bereit. Nachdem die ausgewählte Slave-CPU 21, 22 oder 23 rückgesetzt
wurde, geht die Steuerung zu dem Schritt 1060 über.
-
In
dem Schritt 1060 wird ermittelt, ob die ausgewählte Slave-CPU
die Ausführung
des modusungeeigneten Befehls beendet hat. Vorzugsweise wird diese
Ermittlung durch Untersuchen der Inhalte des slave_finished Flags
vorgenommen. Die Ausführung innerhalb
des aktuellen Threads wird zeitweilig ausgesetzt, bis die ausgewählte Slave-CPU 21, 22 oder 23 mit
der Ausführung
des erwünschten
Befehls fertig ist. Die Host-CPU kann dann andere Threads ausführen, die
eventuell vorhanden sind. Der Host wird periodisch das adäquate slave_finished
Flag Abfragen, um zu ermitteln, ob der aktuelle Thread wieder aufgenommen
werden kann. Sobald dieser wieder aufgenommen wird (d. h. das slave_finished
Flag ist durch die ausgewählte
Slave-CPU umgeschaltet gesetzt und die Host-CPU wurde benachrichtigt)
geht die Steuerung zu dem Schritt 1070 über.
-
In
dem Schritt 1070 beschafft die Host-CPU die durch die Slave-CPU 21, 22 oder 23 errechneten Resultate.
Vorzugsweise sind diese Resultate, um Speicherplatz zu sparen, in
Speicherstellen enthalten, die vorhergehend verwendet wurden, um
Eingabeparameter in speziellen Registern des ausgewählten Slaves
zu speichern (weitergegeben durch Referenz), wie oben beschrieben,
obwohl andere Speicherstellen verwendet werden können, um die Eingabeparameter
noch zu erhalten. Danach geht die Steuerung zu dem Schritt 1080 über, in
dem die konventionelle Ausführung
unter Verwendung der be schafften Resultate folgt. Dies kennzeichnet
ebenso den Vollzug des modusungeeigneten Befehls innerhalb der Host-CPU
gemäß der bevorzugten
Ausführung.
-
Die 4A und 4B sind Fließdiagramme der von der ausgewählten Slave-CPU 21, 22 oder 23 vorgenommenen
Prozessschritte bei der Erledigung des durch den Host angetroffenen
modusungeeigneten Befehls. Die Ausführung beginnt bei dem Schritt 2000,
wobei die ausgewählte
Slave-CPU 21, 22 oder 23 aus dem Reset
kommt, beziehungsweise durch den Host aus dem Schlafmodus geweckt
wird. Die Steuerung geht dann zu dem Schritt 2010 über, in dem
die Slave-CPU-Vektoren an den Startadressen des Codeprogramms benutzt
werden, um den erwünschten
Befehl zu behandeln. Vorzugsweise wird die Startadresse auf der „warmen" Reset-Vektorstelle platziert,
um den Interprozessor-Datenaustausch durch Mindestwartezeiten zu
vereinfachen. Andere Verfahren und Speicherstellen können für Rechner, die
kein X-86 sind, verwendet werden oder wenn der Rechner anders als
durch Reset erwacht. Danach, in dem Schritt 2020, schaltet
die ausgewählte
Slave-CPU 21, 22 oder 23 in den Betriebsmodus,
der notwendig ist, um den erwünschten
Befehl, wie in der Technik bekannt, auszuführen. Es sollte hier angemerkt
werden, dass in der bevorzugten Ausführung alle Slave-CPUs Mitglieder
der Intel-x86-Mikroprozessorfamilie sind und deshalb bereits im
echten Realbetrieb konfiguriert aus dem Reset-Modus kommen, so dass,
wenn die Host-CPU in dem geschützten
Betrieb auf einen Realbetriebsbefehl trifft, es diesen nicht in
dem geschützten
Betrieb verarbeiten kann (in diesem Fall unterbricht eine BIOS-Level-INT-13h-Diskettentreibersoftware),
sie kann einfach die ausgewählte
Slave-CPU rücksetzen,
ohne die Betriebsart des Slaves neu zu bedingen. Sobald die ausgewählte Slave-CPU
bedingt modus-neukonfiguriert ist, geht die Steuerung zu dem Schritt 2030 über.
-
In
dem Schritt 2030 lädt
die ausgewählte
Slave-CPU 21, 22 oder 23 durch die Host-CPU 20 in dem
gemeinsamen Speicherblock platzierte Eingabeparameter herunter und
kopiert diese in das adäquate
Mehrzweckregister. Danach geht die Steuerung zu dem Schritt 2040 über, bei
dem der ausgewählte
Slave den adäquaten
Befehl, die Anweisung oder das Interrupt aufruft, das bzw. die zur
Verarbeitung durch die Host-CPU auf eine konventionelle Art der
Ausführung
ungeeignet ist bzw. sind und geht dann zu dem Schritt 2050 über.
-
In
dem Schritt 2050 platziert die ausgewählte CPU 21, 22 oder 23 die
Resultate der in dem Schritt 2040 ausgeführten Operation
vorzugsweise in dem gemeinsamen Speicherblock. Danach setzt der
ausgewählte
Slave das slave_finished Flag, das dem Host anzeigt, dass der Slave
fertig oder frei ist und der gemeinsame Speicherblock jetzt die
gültigen
Resultatdaten enthält.
Dann geht die Steuerung zu dem Schritt 2070 über ( 4B). In dem Schritt 2070 geht
die ausgewählt
Slave-CPU 21, 22 oder 23 in einen Inaktiv- oder Schlafzustand über, um
auf den nächsten
modusungeeigneten Befehl zu warten, auf den die Host-CPU 20 trifft.
Dies zeigt den erfolgreichen Vollzug der Behandlung eines modusungeeigneten
Befehls durch eine Slave-CPU 21, 22 oder 23 gemäß der bevorzugten
Ausführung
an.
-
Somit
können
nach der Beschreibung der bevorzugten Ausführung oben rechnermodusungeeignete
Befehle, die in einem Multiprozessorsystem eintreffen, ohne aufwendige
Emulationen oder Betriebsartwechsel durch Offloading des Tasks auf
einen stellvertretenden Rechner, der die erforderliche Betriebsart
und die erforderlichen Betriebsmittel besitzt, erledigt werden.
Wenn eine Multimodus-Host-CPU während
der Ausführung
eines Threads auf einen Befehl oder eine Anweisung trifft, die sie
normalerweise nicht ausführen
kann, ohne die Betriebsart zu wechseln oder eine Betriebsartemulation
durchzuführen,
wird sie nach einer anderen in dem System vorhandenen CPU suchen,
die dies an ihrer Stelle erledigen kann.
-
Wenn
ein geeigneter Stellvertreter gefunden wird, werden die notwendigen
Eingabeparameter einschließlich
der Betriebsartumgestaltungsinformationen auf einen für alle CPUs
in dem System zugreifbaren gemeinsamen Speicherblock heruntergeladen und
die stellvertretende CPU wird mit der Startadresse des Codes, der
den ungeeigneten Befehl bzw. die ungeeignete Anweisung behandeln
wird geladen. Danach suspendiert die Host-CPU, die ursprünglich den
Befehl bzw. die Anweisung angetroffen hat, zeitweilig die Ausführung des
Threads, bis die stellvertretende CPU die Ausführung abgeschlossen hat. Wenn die
Ausführung
abgeschlossen ist, führt
die stellvertretende CPU ein Upload der Resultate auf einen gemeinsamen
Speicher durch und signalisiert der Host-CPU ihren Status. Die Verarbeitung
des ungeeigneten Befehls ist vollendet, wenn die Host-CPU die Resultate
aus einem gemeinsamen Speicher beschafft und die Ausführung des
zeitweilig suspendierten Threads wieder aufnimmt.
-
Die
vorhergehende Offenlegung und die Beschreibung der bevorzugten Ausführungen
sind lediglich darstellend und diese erklärend und verschiedene Änderungen
in den Arbeitsschritten, Bauteilen und Schaltelementen, wie auch
in den Einzelheiten des dargestellten Schaltschemas und Betriebsverfahrens,
können
innerhalb des Gültigkeitsbereichs der
Erfindung, wie in den Patentansprüchen definiert, vorgenommen
werden.