DE69901176T2

DE69901176T2 - Rechnersystem mit einem emulationscoprozessor und verfahren zur emulation eines anwendungsprogramms

Info

Publication number: DE69901176T2
Application number: DE69901176T
Authority: DE
Inventors: Charles R. Boswell Jr.; J. Gorishek
Original assignee: Advanced Micro Devices Inc
Current assignee: Advanced Micro Devices Inc
Priority date: 1998-05-26
Filing date: 1999-01-25
Publication date: 2002-11-14
Anticipated expiration: 2019-01-26
Also published as: EP1080407A1; JP2002517034A; US6480952B2; WO1999061981A1; KR100537813B1; US20020013892A1; DE69901176D1; KR20010043807A; EP1080407B1

Description

Hintergrund der Erfindung

1. Technisches Gebiet

Diese Erfindung bezieht sich auf das Gebiet von Prozessoren für Computersysteme und insbesondere auf das Unterstützen von Mehrfach-Befehlssatzarchitekturen innerhalb eines Computersystems.

2. Hintergrund der Technik

Die EP-A-0 455 345 offenbart einen programmierbaren Kontroller mit einem Hauptprozessor und einem Koprozessor. Der Hauptprozessor ist einem Systemspeicher zugeordnet, der ein Betriebssystem für den Hauptprozessor speichert. Ein Source-Befehlsspeicher ist vorgesehen, um ein Ursprungs-Programm zur Steuerung von E/A- und Peripherie-Geräten zu steuern. Das Ursprungs-Programm wird von dem Hauptprozessor in ein Programm kompiliert, das entsprechend verringerte Befehle umfasst, und in einem Koprozessor- Befehlsspeicher gespeichert. Der Koprozessor stellt die Befehle von dem Koprozessor-Befehlsspeicher wieder her, um die Befehle parallel mit der Ausführung des Hauptprozessors auszuführen. Das Thema dieser Offenbarung bildet die Präambel der begleitenden Ansprüche 1 und 8.
Die US-A-4 799 150 offenbart eine Schnittstellen-Schaltung, die das Entladen eines Host-Computersystems auf eine Peripherie-Prozessoreinheit steuert. Der Peripherie-Prozessor arbeitet unabhängig von und gleichzeitig mit dem Host- Computer.
Die EP-A-0 230 353 offenbart ein Datenverarbeitungssystem mit einem Hauptprozessor, der mit einem Systemspeicher durch eine Speicher-Manager- Einheit und einen Koprozessor verbunden ist. Das System legt eine Umgebung von virtuellen Maschinentyp fest, in dem eine Anzahl unterschiedlicher Betriebssysteme verfügbar sind, um auf virtuellen Maschinen ausgeführt zu werden. Die virtuellen Maschinen teilen sich die System-Ressourcen.
Die EP-A-0 817 096 offenbart ein verbessertes PC-System mit einem Haupt- CPU-Mikroprozessor, einem datei-basierten Betriebssystem und einem DSP- Mikroprozessor, der derart angeordnet ist, so dass die DSP Haupt-CPU-Operationen während Zeitintervallen ausführen kann, in denen die Haupt-CPU anderweitig belegt ist, wodurch die Bandbreite des Systems erhöht wird. Das System kann mehrfache CPUs und/oder mehrfache DSPs umfassen.
Computersysteme sind ein bedeutendes Produktivitäts-Werkzeug bei vielen Umgebungen geworden. Fast alle Arbeitszweige ziehen Nutzen aus einem Computersystem, um viele Aufgaben durchzuführen, die für diese Arbeit zentral sind. Beispielsweise verwenden Führungskräfte Computersysteme zum Verwalten von Datenbanken von unternehmenskritischen Daten, Erzeugen und Verwalten von Dokumenten etc. Technische Angestellte verwenden Computersysteme für Forschung, Ausgestaltung und Verifizierung von Produkten. Herstellung- und Verteilungs-Zentren verwenden Computersysteme, um Herstellungsmaschinen zu steuern, Produkte durch den Herstellungsprozess zu verfolgen, und um die Verteilung von Produkten an Großhandel/Einzelhandel zu verwalten. Alle der obigen können Computersysteme zu Kommunikationen sowie auch über E-Mail, Internet, Intranet etc. verwenden. Heimanwendungen für Computersysteme, einschließlich Finanzverwaltung, Kommunikation und Entertainment, sind ebenfalls reichlich vorhanden. Viele weitere Anwendungen für Computersysteme existieren.
Wie das obige veranschaulicht, wurde ein großer vielfältiger Satz von Anwendungen für Computersysteme entwickelt. Im allgemeinen werden diese Anwendungen von einer Vielfalt von Anwendungsprogrammen unterstützt, die ausgestaltet sind, um unter einem Betriebssystem ausgeführt zu werden, das für das Computersystem bereitgestellt wird. Das Betriebssystem stellt eine Schnittstelle zwischen den Anwendungsprogrammen und der Computersystem-Hardware bereit. Jede Computersystem kann einen Vielfalt von Unterschieden in der Hardware-Konfiguration aufweisen (z. B. Menge an Speicher, Anzahl und Art von Eingangs-/Ausgangs (E/A)-Vorrichtungen etc.). Das Betriebssystem isoliert das Anwendungsprogramm von den Hardware- Unterschieden. Demgemäss kann das Anwendungsprogramm häufig ohne Rücksicht auf die genaue Hardware-Konfiguration ausgestaltet werden, auf dem das Anwendungsprogramm auszuführen ist. Außerdem liefert das Betriebssystem eine Vielfalt von Diensten auf unterer Ebene, die viele unterschiedliche Arten von Anwendungsprogrammen benötigen können, was es den Anwendungsprogrammen ermöglicht, sich auf die Betriebssystem-Dienste anstatt auf das Programmieren dieser Dienste intern zu dem Anwendungsprogramm zu stützen. Im allgemeinen sieht das Betriebssystem eine Planung der Aufgaben (z. B. unterschiedliche Anwendungsprogramme, die gleichzeitig arbeiten können). Verwaltung und Zuordnung von System-Ressourcen, wie beispielsweise E/A-Vorrichtungen und Speicher, Fehlerhandhabung (z. B. ein fehlerhaft arbeitendes Anwendungsprogramm), etc. Beispiele von Betriebssystemen sind das Windows-Betriebssystem (einschließlich Windows 95 und Windows NT), UNIX, DOS und MAC-OS unter anderen. Umgekehrt liefert ein Anwendungsprogramm eine spezifische Anwender-Funktionalität, um eine spezifische Anwenderaufgabe zu erfüllen. Text-Prozessoren, Spreadsheets, Graphik-Design-Programme, Inventur-Verwaltungs-Programme etc. sind Beispiele von Anwendungsprogrammen.
Daher sind Anwendungsprogramme typischerweise ausgestaltet, um auf einem bestimmten Betriebssystem zu arbeiten. Die von dem Betriebssystem verfügbaren Dienste ("Betriebssystem-Routine") werden optional von dem Anwendungsprogramm verwendet. Außerdem entspricht das Anwendungsprogramm den Anforderungen des Betriebssystems.
Ein Hardware-Merkmal, von dem das Anwendungsprogramm durch das Betriebssystem nicht typischerweise isoliert ist, ist die Befehlssatzarchitektur des Prozessors innerhalb des Computersystems. Im allgemeinen legt eine Befehlssatzarchitektur die Befehle fest, die auf den Prozessoren ausgeführt werden, sowie auch Prozessor-Ressourcen, die von den Befehlen direkt verwendet werden (wie beispielsweise Register, etc.). Das Anwendungsprogramm wird im allgemeinen in ein Satz von Befehlen kompiliert, der von der Befehlssatzarchitektur festgelegt wird, und somit isoliert das Betriebssystem das Anwendungsprogramm nicht von diesem Merkmal der Computersystem-Hardware.
Wie es oben beschrieben ist, muss eine Computersystem eine große Anzahl von unterschiedlichen Arten von Anwendungsprogrammen unterstützen, um für eine große Basis von Kunden nützlich zu sein. Prozessoren, die neu entwickelte Befehlssatzarchitekturen verwenden, sehen sich einer beängstigenden Aufgabe gegenüber, Anwendungsentwickler dazu zu verleiten, Anwendungen zu entwickeln, die für die neue Befehlssatzarchitektur ausgestaltet sind. Ohne die Anwendungsprogramme werden jedoch die Befehlssatzarchitektur und die dafür ausgestalteten Prozessoren häufig bestenfalls nur eine begrenzte Marktakzeptanz erreichen.
Es ist schwierig und zeitintensiv, Anwendungsprogramme unter Verwendung der neuen Befehlssatzarchitektur infolge der großen Anzahl von Anwendungsprogrammen und die Zeit und Mühe, die benötigt werden, um jedes Anwendungsprogramm auf die neue Befehlssatzarchitektur zu "portieren", neu zu erzeugen. Ferner kann der Source-Code für viele Anwendungsprogramme für diejenigen nicht verfügbar sein, die wünschen, die Portierung durchzuführen. Andererseits sind Betriebssysteme in der Anzahl geringer (insbesondere diejenigen mit weit verbreiteter Akzeptanz) und können auf eine Vielfalt von Befehlssatzarchitekturen portiert werden. Beispielsweise hat Windows NT die von Digital Equipment Cooperation entwickelte Alpha-Architektur, die von IBM und Motorola entwickelte Power-PC-Architektur und die MIPS-Architektur zusätzliche zu der x86-Architektur unterstützt.
Um eine große Anwendungsbasis bereitzustellen, um dadurch Marktakzeptanz zu erzeugen, die dazu führt, dass mehr Anwendungsprogramme entwickelt werden, kann ein Computersystem, das auf Prozessoren basiert, die die neu entwickelte Befehlssatzarchitektur verwenden, versuchen, Anwendungen zu unterstützen, die in einer unterschiedlichen Befehlssatzarchitektur codiert sind. Hier wird ein Code, der von der von Prozessoren in einem Computersystem verwendeten Befehlssatzarchitektur definiert wird, als ein "systemeigen" oder "Host" bezeichnet, während ein Code, der von einer unterschiedlichen Befehlssatzarchitektur festgelegte Befehle verwendet, als ein "nicht systemeigen" oder "fremd" bezeichnet wird.
Die x86-Architektur (auch als IA-32 oder APX bezeichnet) weist eine der größten Anwendungsprogramm-Basen in der Geschichte des Rechenwesens auf. Ein großer Prozentsatz dieser Programme wurde entwickelt, um unter dem Betriebssystem Windows zu laufen. Während Windows- und x86- Anwendungsprogramme periodisch hier als Beispiel verwendet werden, sind die hier offenbarten Techniken und die Hardware nicht auf diese Befehlssatzarchitektur und dieses Betriebssystem begrenzt. Jedes Betriebssystem und jede Befehlssatzarchitektur kann verwendet werden.
Neue Computersysteme, deren Host-Prozessor nicht-x86 ist, können Unterstützung für x86-(d. h. Fremd-)Anwendungsprogramme liefern, die unter dem Windows-Betriebssystem laufen, während Anwendungsprogramme für den Nicht-x86-Host-Prozessor entwickelt werden. Zwei Verfahren, die verwendet wurden, um Fremd-Anwendungen in einem Computersystem zu unterstützen, sind Software-Emulation und Binär-Übersetzung. Die Software-Emulation umfasst im allgemeinen ein Lesen jedes Befehls in dem Anwendungsprogramm, wenn der Befehl zur Ausführung ausgewählt wird, und Durchführen einer äquivalenten Befehlssequenz in der Host-Architektur. Die Binär-Übersetzung beinhaltet im allgemeinen ein Übersetzen jedes Befehls in dem Anwendungsprogramm in eine äquivalente Befehlssequenz vor dem Ausführen des Programms, und dann das Ausführen der übersetzten Programmsequenz.
Da jeder Fremd-Befehl während der Ausführung des Programms geprüft wird, liefert unglücklicherweise die Software-Emulation eine bedeutend verringerte Leistung des Anwendungsprogramms, als diejenige, die auf einem Computersystem erreichbar ist, das die Fremd-Befehlssatzarchitektur verwendet. Ferner ist mehr Speicher erforderlich, um das Anwendungsprogramm auszuführen, um das Emulationsprogramm zu speichern und Datenstrukturen zu unterstützen. Wenn das Anwendungsprogramm Echtzeit-Merkmale (z. B. Audio und Video) aufweist, können diese Merkmale aufgrund der übermäßigen Ausführungszeit schlecht arbeiten. Außerdem umfassen Prozessor- Implementierungen einer Befehlssatzarchitektur häufig eine Vielfalt von nichtdokumentierten Merkmalen (sowohl bekannt als auch unbekannt), die von dem Software-Emulator modelliert werden müssen. Ferner ist es schwierig, komplexe Hardware-Merkmale (wie beispielsweise der x86 Gleitkomma- Register-Keller) genau in dem Software-Emulator zu modellieren.
Die Binär-Übersetzung leidet ebenfalls unter verschiedenen Nachteilen. Die Binär-Übersetzung ist dem Anwender nicht transparent. Die Binär-Übersetzung erfordert häufig mehrfachen Durchläufe durch den Anwendungsprogramm-Code, um das Programm erfolgreich zu übersetzen. In der Zwischenzeit kann die Software-Emulation verwendet werden, um die Anwendung auszuführen (mit vielen der oben erwähnten Nachteilen). Manchmal wird eine vollständige Übersetzung nicht erreicht, und somit ist Software-Emulation noch erforderlich.
Verschiedene Kombinationen der obigen Vorgehensweisen wurden von Computersystem-Firmen und Betriebssystem-Firmen verwendet. Beispielsweise bietet die Digital Equipment Cooperation ihr FX!32-System und Microsoft ihre Wx86-Erweiterung zu Windows NT an. Obgleich diese Vorgehensweisen Funktionalität bereitgestellt haben, wurde im allgemeinen die für die Fremdanwendungen gewünschte hohe Leistung nicht eingehalten.

Offenbarung der Erfindung

Die oben umrissenen Probleme werden größtenteils von einem Computersystem gelöst, das einen Host-Prozessor und einen Emulations-Koprozessor in Übereinstimmung mit der vorliegenden Erfindung verwendet. Der Host-Prozessor umfasst Hardware, die konfiguriert ist, um Befehle auszuführen, die von einer Host-Befehlssatzarchitektur festgelegt sind, während der Emulations-Koprozessor Hardware umfasst, die ausgestaltet ist, um Befehle auszuführen, die von einer von der Host-Befehlssatzarchitektur unterschiedlichen Befehlssatzarchitektur festgelegt sind ("die Fremd-Befehlssatzarchitektur"). Der Host-Prozessor führt Betriebssystem-Code sowie auch Anwendungsprogramme aus, die in der Host-Befehlssatzarchitektur codiert sind. Beim Einleiten eines Fremd-Anwendungsprogramms kommuniziert der Host-Prozessor mit dem Emulations-Koprozessor, um den Emulations-Koprozessor-Kern zu veranlassen, das Fremd-Anwendungsprogramm auszuführen.
Vorteilhafterweise können Anwendungsprogramme, die gemäß der Fremd- Befehlssatzarchitektur codiert sind, direkt in der Hardware aufgeführt werden. Die Ausführungsleistung des Anwendungsprogramms kann wesentlich größer als diejenige einer Software-Emulation oder eines Binär-Übersetzungs-Verfahrens sein. Außerdem kann die Ausführungsleistung im wesentlichen der Ausführungsleistung des Anwendungsprogramms innerhalb eines Computersystems ähnlich sein, das auf einem Prozessor basiert, der die Fremd-Befehlssatzarchitektur verwendet, wodurch viel des Echtzeit-Verhaltens des Fremd- Anwendungsprogramms erhalten bleibt. Software-Emulations/Binär-Übersetzungs-Verfahren und Kombinationen derselben können zugunsten der Hardware-Ausführung der Fremd-Anwendungsprogramme eliminiert werden. Da der Emulations-Koprozessor die Hardware-Funktionalität zum Ausführen der Fremd-Befehlssatzarchitektur aufweist, können die Schwierigkeiten einer genauen Architektur-Modellierung eliminiert werden. Die Kombination dieser verschiedenen Vorteile kann eine Leistung auf hoher Ebene bereitstellen, was ermöglicht, dass die Ausführungsleistung der Fremd-Anwendung für einen Anwender äußerst annehmbar ist. Demgemäss kann die Markt-Akzeptanz des auf der Host-Befehlssatzarchitektur basierenden Computersystems erhöht werden. Wenn die Markt-Akzeptanz ansteigt, kann die Anzahl von Anwendungsprogrammen, die für die Host-Befehlssatzarchitektur codiert sind, ebenfalls ansteigen. Langzeit-Erfolg und Lebensfähigkeit der Host-Befehlssatzarchitektur sind daher wahrscheinlicher.
Das Bereitstellen von Hardware-Funktionalität für die Fremd-Befehlssatzarchitektur innerhalb des Computersystems erzeugt zusätzliche Vorteile. Insbesondere kann das Computersystem als ein heterogenes Multi-Prozessorsystem gekennzeichnet werden. Während der Emulations-Koprozessor, das Fremd- Anwendungsprogramme ausführt, kann der Host-Prozessor Betriebssystem- Routinen, die sich nicht mit dem Fremd-Anwendungsprogramm verwandt sind, oder ein Host-Anwendungsprogramm ausführen. Vorteilhafterweise kann das Computersystem einen wesentlich höher Durchsatz an sowohl dem Host- als auch dem Fremd-Code erreichen, als mittels eines Computersystems erreichbar wäre" das nur den Host-Prozessor und die Software-Emulation/Binär-Übersetzung für die Fremd-Befehlssatzarchitektur verwendet.
Die vorliegende Erfindung liefert eine Vorrichtung für ein Computersystem, das einen ersten Prozessor und einen zweiten Prozessor umfasst, wie es in dem beigefügten Anspruch 1 festgelegt ist. Der erste Prozessor ist ausgestaltet, um erste Befehle auszuführen, die von einer ersten Befehlssatzarchitektur festgelegt sind. Ein von dem Computersystem verwendetes Betriebssystem ist mittels der ersten Befehle codiert. Der mit dem ersten Prozessor gekoppelte zweite Prozessor ist ausgestaltet, um zweite Befehle auszuführen, die von einer zweiten Befehlssatzarchitektur festgelegt sind, die sich von der ersten Befehlssatzarchitektur unterscheidet. Ein Anwendungsprogramm, das ausgestattet ist, um innerhalb des Betriebssystems ausgeführt zu werden, ist unter Verwendung der zweiten Befehle codiert. Der zweite Prozessor ist ausgestaltet, um das Anwendungsprogramm auszuführen, während der erste Prozessor ausgestaltet ist, um das Betriebssystem auszuführen. Das Betriebssystem weist eine Routine auf, die ausgeführt wird in Reaktion auf einen Anwenderbefehl zum Starten eines innerhalb des Betriebssystems auszuführenden Anwendungsprogramm, wobei die Routine das Dateiformat des Anwendungsprogramms analysiert, um zu bestimmen, auf welcher Befehlssatzarchitektur dieses Anwendungsprogramm codiert ist. Der zweite Prozessor ist konfiguriert, um das Anwendungsprogramm auszuführen, wenn das Anwendungsprogramm auf der zweiten Befehlssatzarchitektur codiert ist. Der zweite Prozessor ist konfiguriert, um mit dem ersten Prozessor beim Detektieren einer Verwendung einer Betriebssystem-Routine für das Anwendungsprogramm zu kommunizieren.
Außerdem liefert die vorliegende Erfindung ein Verfahren zum Ausführen eines Anwendungsprogramms, das unter Verwendung von Befehlen einer ersten Befehlssatzarchitektur codiert ist, und ausgestaltet ist, um innerhalb eines Betriebssystems ausgeführt zu werden, das unter Verwendung von Befehlen von einer zweiten Befehlssatzarchitektur codiert ist, die sich von der ersten Befehlssatzarchitektur unterscheidet, wie es in dem beigefügten Anspruch 8 definiert ist. Die Einleitung des Anwendungsprogramms wird von dem Betriebssystem erfasst, das auf einem ersten Prozessor ausgeführt wird, der konfiguriert ist, um Befehle von der zweiten Befehlssatzarchitektur auszuführen. Das Detektieren umfasst eine Analysieren eines Dateiformats des Anwendungsprogramms, um zu bestimmen, auf welcher Befehlssatzarchitektur das Anwendungsprogramm codiert ist. Ein Kontext für das Anwendungsprogramm wird in einem zweiten Prozessor festgelegt, der konfiguriert ist, um Befehle von der ersten Befehlssatzarchitektur auszuführen. Das Festlegen des Kontextes für das Anwendungsprogramm wird in Reaktion auf das Detektieren, das das Anwendungsprogramm auf der ersten Befehlssatzarchitektur codiert ist, durchgeführt. Das Anwendungsprogramm wird auf dem zweiten Prozessor ausgeführt.
Die vorliegende Erfindung betrachtet ferner ein heterogenes Multi- Prozessorsystem mit einem ersten Prozessor, einem zweiten Prozessor, einem Betriebssystem und einem Anwendungsprogramm. Der erste Prozessor ist konfiguriert, die ersten Befehle auszuführen, die von einer ersten Befehlssatzarchitektur festgelegt sind. Der zweite Prozessor ist mit dem ersten Prozessor gekoppelt und ist ausgestaltet, um von einer zweite Befehlssatzarchitektur, die sich von der ersten Befehlssatzarchitektur unterscheidet, festgelegte zweite Befehle auszuführen. Das Betriebssystem ist mit den ersten Befehlen codiert, während das Anwendungsprogramm unter Verwendung der zweiten Befehle codiert und ausgestaltet ist, um innerhalb des Betriebssystems ausgeführt zu werden. Der zweite Prozessor ist konfiguriert, um das Anwendungsprogramm auszuführen, und der erste Prozessor ist konfiguriert, um gleichzeitig einen Prozess auszuführen, der nicht mit dem Anwendungsprogramm verwandt ist.

Figurenkurzbeschreibung

Weitere Aufgaben und Vorteile der Erfindung werden beim Lesen der folgenden ausführlichen Beschreibung und mit Bezug auf die beigefügten Zeichnungen offensichtlich werden. Es zeigen:
Fig. 1 ein Blockdiagramm einer Ausführungsform eines Computersystems;
Fig. 2 ein Blockdiagramm einer Ausführungsform eines in Fig. 1 gezeigten Prozessors, der einen Host-Prozessor-Kern und einen Emulations-Koprozessor-Kern aufweist;
Fig. 3 ein Blockdiagramm eines Prozessors, der eine Fremd-Anwendung emuliert;
Fig. 4 ein Ablaufdiagramm, das eine Ausführungsform der Initialisierung eines Anwendungsprogramms in dem in Fig. 12 gezeigten Computersystems darstellt;
Fig. 5 ein Ablaufdiagramm, das eine Ausführungsform eines Ausrufens einer in Fig. 3 gezeigten Emulations-Schnittstelle darstellt;
Fig. 6 eine Tabelle, die Kommunikationsbefehle gemäß einer Ausführungsform des in Fig. 1 gezeigten Prozessors darstellt;
Fig. 7 ein Blockdiagramm einer zweiten Ausführungsform des in Fig. 1 gezeigten Prozessors;
Fig. 8 ein Ablaufdiagramm, das die Arbeitsweise einer Ausführungsform eines in Fig. 7 gezeigten Schnittstellen-Logikblocks darstellt;
Fig. 9 ein Blockdiagramm einer dritten Ausführungsform des in Fig. 1 gezeigten Prozessors;
Fig. 10 ein Blockdiagramm einer zweiten Ausführungsform eines Computersystems;
Fig. 11 ein Blockdiagramm einer dritten Ausführungsform eines Computersystems;
Fig. 12 ein Blockdiagramm einer vierten Ausführungsform eines Computersystems;
Fig. 13 ein Blockdiagramm einer Ausführungsform einer in Fig. 12 gezeigten Emulations-Koprozessor-Karte;
Fig. 14 ein Diagramm, das eine Steuerstruktur darstellt, die von einer Ausführungsform eines in Fig. 13 gezeigten Ausführungsprogramms unterhalten wird; und
Fig. 15 ein Satz von Ablaufdiagrammen, die eine Ausführungsform des in Fig. 13 gezeigten Exekutive-Programms darstellt.
Obwohl die Erfindung auf verschiedene Modifikationen und alternative Formen empfänglich ist, werden spezifische Ausführungsformen derselben mittels Beispiel in den Zeichnungen gezeigt und hier ausführlich beschrieben, Es sollte jedoch offensichtlich sein, dass die Zeichnungen und die ausführliche Beschreibung dazu nicht bestimmt sind, die Erfindung auf die bestimmte offenbarte Form zu begrenzen, sondern es besteht im Gegenteil die Absicht, alle Modifikationen, Äquivalente und Alternative abzudecken, die innerhalb des Geistes und Schutzumfang der vorliegenden Erfindung fallen, wie es von den beigefügten Ansprüchen festgelegt ist.

Betriebsart(en) zum Ausführen der Erfindung

In Fig. 1 ist ein Blockdiagramm einer Ausführungsform eines Computersystems 5 mit einem mit einer Vielfalt von Systemkomponenten durch eine Busbrücke 12 gekoppelter Prozessor 10 gezeigt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei dem dargestellten System ist ein Hauptspeicher 14 mit der Busbrücke 12 durch einen Speicher-Bus 12 gekoppelt, und ein Graphik-Kontroller ist mit der Busbrücke 12 durch einen AGP-Bus 20 gekoppelt. Schließlich ist eine Mehrzahl von PCI-Vorrichtungen 22A bis 22B mit der Bus-Brücke 12 durch einen PCI-Bus 24 gekoppelt. Eine sekundäre Busbrücke 26 kann ferner bereitgestellt werden, um eine elektrische Schnittstelle zu einer oder mehrerer EISA- oder ISA-Vorrichtungen 29 durch einen EISA/ISA-Bus 30 aufzunehmen. Der Prozessor 10 ist mit der Busbrücke 12 durch einen CPU-Bus 34 gekoppelt.
Allgemein gesagt umfasst der Prozessor 10 einen Host-Prozessor-Kern und einen Emulations-Koprozessor-Kern. Der Host-Prozessor-Kern umfasst Hardware, die ausgestaltet ist, um von einer Host-Befehlssatzarchitektur festgelegte Befehle auszuführen, während der Emulations-Koprozessor-Kern Hardware umfasst, die ausgestaltet ist, um durch eine von der Host-Befehlssatzarchitektur unterschiedliche Befehlssatzarchitektur ("die Fremd-Befehlssatzarchitektur") festgelegte Befehle auszuführen. Der Host-Prozessor-Kern führt einen Betriebssystem-Code sowie auch Anwendungsprogramme aus, die in der Host-Befehlssatzarchitektur codiert sind. Bei Einleitung eines Fremd- Anwendungsprogramms kommuniziert der Host-Prozessor-Kern mit dem Emulations-Koprozessor-Kern, um den Emulations-Koprozessor-Kern zu veranlassen, das Fremd-Anwendungsprogramm auszuführen.
Vorteilhafterweise können Anwendungsprogramme, die gemäß der Fremd-Befehlssatzarchitektur codiert sind, direkt in Hardware mittels des Prozessors 10 ausgeführt werden. Die Ausführungsleistung des Anwendungsprogramms kann wesentlich größer als diejenige einer Software-Emulation oder eines Binär-Übersetzungsverfahren sein. Außerdem kann die Ausführungsleistung im wesentlichen der Ausführungsleistung des Anwendungsprogramm innerhalb des Computersystems ähnlich sein, das auf einem Prozessor basiert, der die Fremd-Befehlssatzarchitektur verwendet. Software-Emulations/Binär-Übersetzungsverfahren und Kombinationen derselben können zugunsten der Hardware-Ausführung des Fremd-Anwendungsprogramms eliminiert werden. Da der Prozessor 10 Hardware-Funktionalität zum Ausführen der Fremd-Befehlssatzarchitektur aufweist, können die Schwierigkeiten einer genauen Architektur-Modellierung eliminiert werden. Da ferner das Fremd-Anwendungsprogramm in einer Zeitspanne ausgeführt wird, die der Ausführung in einem eigenen Computersystem ähnlich ist, kann viel von dem Echtzeit-Verhaltens des Fremd-Anwendungsprogramms erhalten bleiben. Die Kombination dieser verschiedenen Vorteile kann eine Leistung auf hohem Niveau bereitstellen, was ermöglicht, dass die Ausführungsleistung der Fremd-Anwendung für einen Anwender äußerst annehmbar ist. Außerdem kann die Markt-Akzeptanz des auf der Host-Befehlssatzarchitektur basierenden Computersystems erhöht werden. Wenn die Markt-Akzeptanz ansteigt, kann die Anzahl der für die Host-Befehlssatzarchitektur codierten Anwendungsprogramme ebenfalls ansteigen. Langzeit-Erfolg und Lebensfähigkeit der Host-Befehlssatzarchitektur kann daher ebenfalls wahrscheinlicher sein.
Das Bereitstellen von Hardware-Funktionalität für die Fremd-Befehlssatzarchitektur innerhalb des Computersystems 5 erzeugt zusätzliche Vorteile. Insbesondere kann das Computersystem 5 als ein heterogenes Multi-Prozessorsystem gekennzeichnet werden. Während der Emulations-Koprozessor das Fremd-Anwendungsprogramm ausführt, kann der Host-Prozessor die Betriebssystem-Routinen, die mit dem Fremd-Anwendungsprogramm nicht verwandt sind, oder ein Host-Anwendungsprogramm ausführen. Vorteilhafterweise kann das Computersystem 5 einen wesentlichen höheren Durchsatz auf sowohl dem Host als auch dem Fremd-Code erreichen, als diejenige, die mittels eines Computersystems erreichbar wäre, das nur den Host-Prozessor und Software-Emulation/Binär-Übersetzung für die Fremd-Befehlssatzarchitektur verwendet.
Bei einer bestimmten Ausführungsform ist die Host-Befehlssatzarchitektur die von Digital Equipment Cooperation entwickelte Alpha-Befehlssatzarchitektur und die Fremd-Befehlssatzarchitektur ist die x86-Befehlssatzarchitektur. Es könnte jedoch jede Befehlssatzarchitektur als die Host-Befehlssatzarchitektur gewählt werden. Beispielsweise kann die Host-Befehlssatzarchitektur die PowerPC-Architektur, die von Intel entwickelte IA-64-Architektur, die MIPS- Architektur, die SPARC-Architektur etc. sein. Ebenso kann die Fremd-Befehlssatzarchitektur gewählt werden, um jede Befehlssatzarchitektur verschieden von der Host-Befehlssatzarchitektur, einschließlich irgendeines der oben aufgeführten Beispiele, sein.
Es sei bemerkt, dass einige unterschiedliche Ausführungsformen des Computersystems 5 und des Prozessors 10 hier gezeigt sind. Obwohl die in Fig. 1 und 2 gezeigten Ausführungsformen gegenwärtig als bevorzugte Ausführungsformen betrachtet werden, kann jede der hier gezeigten Ausführungsformen abhängig von einer Vielfalt von Ausgestaltungsfaktoren, die Kosten, Entwicklungsplan, Komplexität, etc. umfassen, geeignet sein. Zusätzliche Ausführungsformen werden innerhalb des Geistes und Schutzumfangs der beigefügten Ansprüche in Erwägung gezogen.
In Fig. 1 ist der Prozessor 10 mit einem optionalen L2-Cache-Speicher 38 gekoppelt gezeigt. Der L2-Cache-Speicher 38 wird als ein "Backside L2" bezeichnet, wenn der Cache-Speicher mit dem Prozessor 10 über eine private Schnittstelle getrennt von dem CPU-Bus 34 gekoppelt ist. Der L2-Cache- Speicher 38 kann größer als irgendeiner der innerhalb des Prozessor 10 verwendeten internen Cache-Speicher sein und kann verwendet werden, um Daten für einen schnelleren Zugriff, als derjenige, der von dem Hauptspeicher erreichbar ist, zu speichern.
Wie es hier verwendet wird, bezieht sich der Begriff "Prozessor" auf mindestens die Hardware zum Ausführen von einer bestimmten Befehlssatzarchitektur festgelegten Befehlen. Demgemäss qualifizieren sich die in Fig. 2 gezeigten Prozessor-Kerne als Prozessor gemäß der vorliegenden Definition. Prozessoren können zusätzliche Hardware aufweisen, wie es gewünscht ist.
Die Bus-Brücke 12 liefert eine Schnittstelle zwischen dem Prozessor 10, dem Hauptspeicher 14, und einem Graphik-Kontroller 18 und den an den PCI-Bus 24 verbundene Vorrichtungen. Wenn eine Operation von einer der mit der Bus-Brücke 12 verbundenen Vorrichtungen empfangen wird, identifiziert die Bus-Brücke 12 das Ziel der Operation (z. B. eine bestimmte Vorrichtung oder in dem Fall des PCI-Bus 24, dass das Ziel auf dem PCI-Bus 24 ist). Die Bus- Brücke 12 leitet die Operation zu der als Ziel ausgewiesenen Vorrichtung. Die Bus-Brücke 12 übersetzt im allgemeinen eine Operation von dem von der Source-Vorrichtung oder von dem Bus verwendeten Protokoll in das Protokoll, das von der Ziel-Vorrichtung oder dem Bus verwendet wird. Bei einer Ausführungsform umfasst der CPU-Bus 34 einen von Digital Equipment entwickelten EV6-Bus, und die Bus Brücke 12 umfasst einen Alpha-21171- oder 21172- Kern-Logik-Chipsatz. Es kann jedoch jeder CPU-Bus und jede geeignete Bus- Brücke verwendet werden.
Zusätzlich zum Bereitstellen einer Schnittstelle an einem ISA/EISA-Bus für den PCI-Bus 24, kann eine sekundäre Bus-Brücke 26 ferner zusätzliche Funktionalität aufnehmen, wie es gewünscht ist. Beispielsweise umfasst bei einer Ausführungsform die sekundäre Bus-Brücke 26 einen Master-PCI-Arbiter (nicht gezeigt) zum Arbitrieren der Inhaberschaft des PCI-Bus 24. Ein Eingangs/Ausgangs-Kontroller (nicht gezeigt), der entweder extern von der sekundären Bus-Brücke 26 oder in diese integriert ist, kann ebenfalls in dem Computersystem 5 enthalten sein, um zusätzliche Betriebsunterstützung für eine Tastatur und eine Maus 32 und für verschiedene serielle und parallele Ports bereitzustellen, wie es gewünscht ist. Eine externe Cache-Einheit (nicht gezeigt) kann ferner mit dem CPU-Bus 34 zwischen dem Prozessor 10 und der Bus-Brücke 12 bei anderen Ausführungsformen gekoppelt sein. Alternativ kann der externe Cache-Speicher mit der Bus-Brücke 12 gekoppelt sein, und die Cache-Speicher-Steuerlogik für den externen Cache-Speicher kann in die Bus-Brücke 12 integriert sein.
Der Hauptspeicher 14 ist ein Speicher, in dem Anwendungsprogramme gespeichert werden und von dem der Prozessor 10 primär ausführt. Ein geeigneter Hauptspeicher 14 umfasst DRAM (Dynamic Random Access Memory) und vorzugsweise eine Mehrzahl von Banken von SDRAM (Synchronous DRAM).
PCI-Vorrichtungen 22A bis 22B veranschaulichen eine Vielfalt von Peripherie- Vorrichtungen, wie beispielsweise Netzwerk-Schnittstellen-Karten, Video-Beschleuniger, Audio-Karten, Festplatten- oder Floppy-Disk-Laufwerke oder Laufwerk-Kontroller, SCSI(Small Computer Systems Interface)-Adapter und Telephonie-Karten. Ebenso ist die ISA-Vorrichtung 28 beispielhaft für verschiedene Arten von Peripherie-Vorrichtungen, wie beispielsweise ein Modem, ein Soundkarte und eine Vielfalt von Datenerfassungskarten, wie beispielsweise GPIB- oder Feld-Bus-Schnittstellen-Karten.
Der Graphik-Kontroller 18 ist vorgesehen, um die Wiedergabe von Text und Bildern auf einer Anzeige 36 zu steuern. Der Graphik-Kontroller 18 kann einen typischen Graphik-Beschleuniger aufnehmen, der allgemein in der Technik bekannt ist, um dreidimensionale Datenstrukturen wiederzugeben, die wirksam in und aus dem Hauptspeicher 14 verschoben werden können. Der Graphik-Kontroller 18 kann daher ein Master des AGP-Bus 20 dadurch sein, dass er Zugriff auf eine Ziel-Schnittstelle innerhalb der Bus-Brücke 12 anfordern und empfangen kann, um dadurch Zugriff auf dem Hauptspeicher 14 zu erhalten. Ein dedizierter Graphik-Bus bringt schnelle Wiederherstellung von Daten von dem Hauptspeicher 14 unter. Für bestimmte Operationen kann der Graphik-Kontroller 18 ferner konfiguriert sein, um PCI-Protokoll-Transaktionen auf dem AGP-Bus 20 zu erzeugen. Die AGP-Schnittstelle der Bus-Brücke 12 kann somit Funktionalität aufweisen, um sowohl die AGP-Protokoll-Transaktionen als auch die PCI-Protokoll-Ziel- und Initiator-Transaktionen zu unterstützen. Eine Anzeige 36 ist eine beliebige elektronische Anzeige, auf der ein Bild oder ein Text dargestellt werden kann. Eine geeignete Anzeige 36 umfasst eine Kathoden-Strahlröhre ("CRT"), eine Flüssigkristall-Anzeige ("LCD"), etc.
Es sei bemerkt, dass, obwohl die AGP-, PCI- und ISA- oder EISA-Busse als Beispiele bei der obigen Beschreibung verwendet wurden, beliebige Bus-Architekturen substituiert werden können, wie es gewünscht ist. Es sei ferner bemerkt, dass das Computersystem 5 eine Multi-Prozessor-Computersystem mit zusätzlichen Prozessoren sein kann (z. B. Prozessor 10a gezeigt als eine optionale Komponente des Computersystems 5 zusammen mit einem optionalen L2-Cache-Speicher 38a). Der Prozessor 10a kann den Prozessor 10 ähnlich sein. Genauer gesagt kann der Prozessor 10a eine identische Kopie des Prozessors 10 sein. Wie es in Fig. 1 gezeigt ist, ist der Prozessor 10a mit der Bus- Brücke 12 über einen, dem CPU-Bus 34 ähnlichen getrennten CPU-Bus 34a gekoppelt. Alternativ kann der Prozessor 10a den CPU-Bus 34 mit dem Prozessor 10 teilen.
In Fig. 2 ist ein Blockdiagramm einer ersten Ausführungsform des Prozessors 10 gezeigt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei der Ausführungsform von Fig. 2 umfasst der Prozessor 10 eine Bus-Schnittstellen-Einheit 40, eine Speicher-Verwaltungs-Einheit (MMU) 42, einen Befehls-Cache-Speicher (ICache) 44, einen Daten-Cache-Speicher (DCache) 46, einen Host-Prozessor-Kern 48 und einen Emulations- Koprozessor-Kern 50. Die Bus-Schnittstellen-Einheit 40 ist mit dem CPU-Bus 34 und einer Backside-L2-Schnittstelle 52 mit dem L2-Cache-Speicher 38 gekoppelt. Die Bus-Schnittstellen-Einheit 40 ist ferner mit der MMU 42 gekoppelt, die ferner mit dem Befehls-Cache-Speicher 44 und dem Daten-Cache- Speicher 46 gekoppelt ist. Sowohl der Befehls-Cache-Speicher 44 als auch der Daten-Cache-Speicher 46 sind mit dem Host-Prozessor-Kern 48 gekoppelt, und der Daten-Cache-Speicher 46 ist mit dem Emulations-Koprozessor-Kern 50 gekoppelt. Der Befehls-Cache-Speicher 44 ist optional mit dem Emulations-Prozessor-Kern 50 gekoppelt, wie es weiter ausführlich nachstehend beschrieben ist. Bei der Ausführungsform von Fig. 2 sind die Elemente des Prozessors 10 auf einem Halbleitersubstrat integriert. Eine Befehlsschnittstelle 54 ist zwischen dem Host-Prozessor-Kern 48 und dem Emulations-Koprozessor- Kern 50 gekoppelt.
Der Host-Prozessor-Kern 48 ist ausgestaltet, um Befehle von dem Befehls- Cache-Speicher 44 abzurufen und diese Befehle auszuführen. Die Befehle können einen Teil eines Host-Anwendungsprogramm oder einen Teil des von dem Computersystem 5 verwendeten Betriebssystems umfassen. Ein bestimmter Teil des Betriebssystems wird verwendet, um Prozesse zu erzeugen, einschließlich des Einleitens eines Fremd-Anwendungsprogramms. Falls während der Ausführung des Erzeugungsprozess-Teils das Betriebssystem ein Fremd-Anwendungsprogramm erfasst wird, wenn es eingeleitet wird, kommuniziert der Host-Prozessor-Kern 48 über die Befehlsschnittstelle 54 mit dem Emulations-Koprozessor-Kern 50. Der Host-Prozessor-Kern 48 legt einen Kontext innerhalb des Emulations-Koprozessor-Kern 50 fest, der dem eingeleiteten Fremd-Anwendungsprogramm entspricht. In dem Kontext ist eine Anfangs-Programm-Zähler-Adresse enthalten, von der der erste Befehl in dem Fremd-Anwendungsprogramm abzurufen ist. Sobald der Kontext festgelegt ist, liefert der Host-Prozessor-Kern 48 einen Befehl an den Emulations-Koprozessor-Kern 50, um die Ausführung zu beginnen. Der Emulations-Koprozessor-Kern 50 beginnt das Abrufen von Befehlen an der Programm-Zähler-Adresse und führt die Befehle gemäß der Fremd-Befehlssatzarchitektur aus. Wie er hier verwendet wird, bezieht sich der Begriff "Kontext" auf Werte, die einem Prozess eigen sind. Der Kontext umfasst im allgemeinen die dem Prozess zugeteilten Speicherseiten sowie auch Registerwerte.
Der Emulations-Koprozessor-Kern 50 ist konfiguriert, um zu bestimmen, ob ein Übergang in des Fremd-Anwendungsprogramm-Prozesses an Befehlen auftritt, die in der Host-Befehlssatzarchitektur codiert sind. Wenn beispielsweise das Fremd-Anwendungsprogramm eine Betriebssystem-Routine aufruft, wird ein Übergang erfasst, da das Betriebssystem gemäß der Host-Befehlssatzarchitektur codiert ist. Außerdem sind Ausnahmen und weitere Prozessor- Ereignisse, die dazu führen, dass der Betriebssystem-Code oder ein anderer Code die Host-Befehlssatzarchitektur verwenden, Übergänge. Beim Bestimmen, dass ein Übergang stattfindet, kommuniziert der Emulations-Koprozessor 50 über eine Befehlsschnittstelle 54 an den Host-Prozessor-Kern 48, dass der Emulations-Koprozessor-Kern 50 angehalten hat. Der Host-Prozessor- Kern 48 fordert Kontext-Information an, um den Grund für das Anhalten zu bestimmen, und trifft eine entsprechende Maßnahme (z. B. Ausführen der aufgerufenen Routine oder Bereitstellen des Betriebssystem-Dienstes). Sobald der Host-Prozessor-Kern 48 bestimmt, dass das Fremd-Anwendungsprogramm wieder aufgenommen werden kann, liefert der Host-Prozessor-Kern 48 Kontext-Information (falls benötigt) und liefert den Befehl für den Emulations- Koprozessor-Kern 50 zu starten.
Die Befehlsschnittstelle 54 kann in einer Vielfalt von Arten implementiert sein. Beispielsweise kann die Befehlsschnittstelle 54 einen Satz von festverdrahteten Signale zwischen dem Host-Prozessor-Kern 48 und dem Koprozessor-Kern 50 umfassen. Befehlssignale können jeden Befehl zugewiesen werden, der für die Befehlsschnittstelle 54 festgelegt ist, sowie auch einen Bus zum Weiterleiten von Kontext-Werten. Alternativ kann die Befehlsschnittstelle 54 FIFOs zum Kommunizieren zwischen den Prozessor-Kernen (d. h. ein oder mehrere FIFOs für Mitteilungen von dem Host-Prozessor-Kern 48 an den Emulations- Koprozessor-Kern 50 und eine oder mehrere FIFOs für Mitteilungen von dem Emulations-Koprozessor-Kern 50 an den Host-Prozessor-Kern 48). Es sei bemerkt, dass die Befehlsschnittstelle 54 ein Beispiel eines "Kommunikationskanals" sein kann. Im allgemeinen ist ein Kommunikationskanal eine Verbindung zwischen einem Sender und einem Empfänger, über die Mitteilungen gesendet werden können. Ein vordefiniertes Protokoll kann verwendet werden, um die über den Kanal übertragenen Mitteilungen festzulegen. Beispielsweise bilden festverdrahtete Signale einen Kommunikationskanal, und Kombinationen der Signale werden verwendet, um Mitteilungen zu übertragen. Ferner können FIFOs einen Kommunikationskanal bilden, und die N Mitteilungen werden als FIFO-Einträge codiert. Die FIFOs können ebenfalls einfach als Warteschlangen im Speicher unterhalten werden.
Der Host-Prozessor-Kern 48 und der Emulations-Koprozessor-Kern 50 teilen sich ebenfalls den Befehls-Cache-Speicher 44 und den Daten-Cache-Speicher 46 bei der vorliegenden Ausführungsform. Der Host-Prozessor-Kern 48 ruft Befehle von dem Befehls-Cache-Speicher 44 ab, und ruft Daten, an denen zu arbeiten ist, in Reaktion auf die Befehle von dem Daten-Cache-Speicher 46 ab. Der Emulations-Koprozessor-Kern 50 ruft ebenfalls Daten von dem Daten- Cache-Speicher 46 ab. Verschiedene Ausführungsformen werden für eine Befehls-Source für den Emulations-Koprozessor-Kern 50 in Erwägung gezogen. Bei einer ersten Ausführungsform ruft der Emulations-Koprozessor-Kern 50 Befehle aus dem Befehls-Cache-Speicher 44 ab, während bei einer zweiten Ausführungsform der Emulations-Koprozessor-Kern 50 Befehle aus dem Daten-Cache-Speicher 46 abruft. Verschiedene Faktoren können die Entscheidung beeinflussen, ob der Emulations-Prozessor-Kern 50 Befehle von dem Befehls-Cache-Speicher 44 oder von dem Daten-Cache-Speicher 46 abruft. Beispielsweise werden bei einer Ausführungsform, in dem der Emulations-Koprozessor-Kern 50 die x86-Befehlssatzarchitektur ausführt, Merkmale wie beispielsweise selbstmodifizierender Code unterstützt. Daher kann der Befehls- Cache-Speicher 44 bei Aktualisierungen am den Daten-Cache-Speicher 46 mitlauschen (Snoop), um derartige Situationen zu erfassen. Die Host-Befehlssatzarchitektur kann jedoch derartige Merkmale nicht unterstützen, und Mitlauschen (snooping) durch den Befehls-Cache-Speicher 44 des Daten-Cache- Speichers 46 kann unnötig sein. Ferner kann der Host-Prozessor-Kern 48 auf Befehle zugreifen, die durch den Emulations-Koprozessor-Kern-50 als Daten auszuführen sind. Beispielsweise kann, um Ausnahmedienste für Fremd-Anwendungsprogramme bereitzustellen, die von dem Emulations-Prozessor-Kern 50 ausgeführt werden, es für den Host-Prozessor-Kern 48 erforderlich sein, den Befehl zu prüfen, für den die Ausnahme stattfand. Demgemäss können Befehle für den Emulations-Koprozessor-Kern 50 bereits in dem Daten-Cache- Speicher 46 gespeichert sein. Bei einer noch weiteren in Erwägung gezogenen Ausführungsform umfasst der Emulations-Koprozessor-Kern 50 einen Befehls- Cache-Speicher, und Befehls-Cache-Fehltreffer werden aus dem Daten-Cache- Speicher 46 abgerufen.
Der Host-Prozessor-Kern 48 und der Emulations-Koprozessor-Kern 50 teilen sich bei dieser Ausführungsform ebenfalls die MMU 42. Die MMU 42 ist ausgestaltet, um Übersetzungen von den über die Ausführung von Befehlen in dem Host-Prozessor-Kern 48 und im Emulations-Koprozessor-Kern 50 erzeugten virtuellen Adressen in physikalische Adressen bereitzustellen, die die Bus- Schnittstellen-Einheit 40 verwenden kann, um den Hauptspeicher 14 oder den L2-Cache-Speicher 38 zu lesen. Der Befehls-Cache-Speicher 44 und der Daten-Cache-Speicher 46 können ebenfalls Befehle und Daten gemäß den physikalischen Adressen speichern, wobei in diesem Fall auf die MMU 42 parallel mit dem Befehls-Cache-Speicher 44 und dem Daten-Cache-Speicher 46 zugegriffen werden kann.
Im allgemeinen legen die Host-Befehlssatzarchitektur und die Fremd-Befehlssatzarchitektur unterschiedliche Adressen-Übersetzungs-Mechanismen fest. Die MMU 42 kann den von der Host-Befehlssatzarchitektur festgelegten Adressen-Übersetzungs-Mechanismus unterstützen, und Übersetzungen für sowohl den Host-Prozessor-Kern 48 als auch den Emulations-Koprozessor-Kern 50 können von dem Host-Adressen-Übersetzungs-Mechanismus bereitgestellt werden. Wenn unterschiedliche Seitengrößen für den Host und die Fremd-Befehlssatzarchitektur festgelegt sind, kann der Schutzteil des Übersetzungs- Mechanismus mit zusätzlichen Kopien der Schutzinformation vergrößert werden, um einen unabhängigen Schutz an der Granularität der kleinere Seitengröße bereitzustellen, falls erwünscht. Alternativ kann die MMU 42 ausgestaltet sein, um den von der Host-Befehlssatzarchitektur festgelegten Adressen- Übersetzungs-Mechanismus sowie auch den von der Fremd- Befehlssatzarchitektur festgelegten Adressen-Übersetzungs-Mechanismus zu unterstützen. Das Betriebssystem kann Speicherseiten für virtuelle Adressen gemäß dem von der Host-Befehlssatzarchitektur festgelegten Adressen-Übersetzungs-Mechanismus zuteilen. Zusätzliche Software oder Hardware innerhalb der MMU 42 können entsprechende Übersetzungen unter Verwendung des von der Fremd-Befehlssatzarchitektur festgelegten Adressen-Übersetzungs-Mechanismus erzeugen. Alternativ kann das Betriebssystem Adressen- Übersetzungen innerhalb der Adressen-Übersetzungs-Mechanismen der Fremd-Befehlssatzarchitektur ebenfalls erzeugen, wenn die Seite von einem Fremd-Anwendungsprogramm angefordert wird.
Wie es in Fig. 2 gezeigt ist, umfasst der Host-Prozessor-Kern 48 eine Abruf/Decodier-Einheit 60, eine Mehrzahl von Funktionseinheiten 62A bis 62C, einen Reihenfolgen- und Abhängigkeits-Steuerblock 64 und eine Mehrzahl von Registern 66. Ebenso ist der Koprozessor-Kern 50 mit einer Abruf/Decodier- Einheit 70, einer Mehrzahl von Funktionseinheiten 72A bis 72 C, einen Reihenfolge- und Abhängigkeits-Steuerblock 74 und einer Mehrzahl von Registern 76 gezeigt. Im allgemeinen sind die Abruf/Decodier-Einheiten 60 und 70 konfiguriert, um Befehle abzurufen, wie sie durch die entsprechende Befehlssatzarchitektur festgelegt sind, und diese Befehle zu decodieren, um zu bestimmen, welche der entsprechenden Funktionseinheiten 62A bis 62C und 72A bis 72C konfiguriert sind, um die Befehle auszuführen. Abruf/Decodier-Einheiten 60 und 70 können die Befehle an die Funktionseinheiten 62A bis 62C und 72A bis 72C sowie auch an die Reihenfolge- und Abhängigkeits-Steuerblöcke 64 bzw. 74 liefern. Die Reihenfolge- und Abhängigkeits-Steuerblöcke 64 und 74 gewährleisten, dass Befehlsabhängigkeiten erfasst werden und geeignete Quellen für Operanten-Werte für jeden Befehl bereitgestellt werden, sowie auch gewährleisten, dass die Befehls-Ausführungs-Reihenfolge ordnungsgemäß beibehalten wird. Die Reihenfolge- und Abhängigkeits-Steuerblöcke von 64 und 74 können beispielsweise einen Neuordnungs-Puffer und verwandte Schaltungsanordnungen umfassen. Alternativ können die Reihenfolge- und Abhängigkeits-Steuerblöcke 64 und 74 jede geeignete Schaltungsanordnung zum Durchführen von Reihenfolge- und Abhängigkeits-Steuerfunktionen umfassen. Bei einer noch weiteren Alternative können Reihenfolge- und Abhängigkeits-Operationen durch Abruf/Decodier-Einheiten 60 und 70 durchgeführt werden. Die Register 66 und 76 sind die Register, die von der entsprechenden Befehlssatzarchitektur festgelegt werden.
Die Funktionseinheiten 62A und 72A sind mit dem Daten-Cache-Speicher 46 bei der Ausführungsform von Fig. 2 verbunden gezeigt. Diese Funktionseinheiten können die Speicher-Operations- (d. h. Laden und Speicher-) Funktionalität aufweisen. Weitere Funktionseinheiten können Speicher-Operations- Funktionalität bei alternativen Ausführungsformen ebenfalls umfassen. Die Kombination der Funktionseinheiten 62A bis 62C liefert die Hardware, die verwendet wird, um die von der Host-Befehlssatzarchitektur festgelegten Befehle auszuführen. Auf ähnliche Weise liefert die Kombination der Funktionseinheiten 72A bis 72 C die Hardware, die verwendet wird, um die von dem Fremd-Befehlssatz festgelegten Befehle auszuführen. Mikrocode-Techniken können ebenfalls verwendet werden, falls gewünscht, um die Ausgestaltung von Funktionseinheiten zu vereinfachen. Es sei bemerkt, dass, obwohl mehrere Funktionseinheiten in jedem der Kerne 48 und 50 in Fig. 2 gezeigt sind, Ausführungsformen mit mehr oder weniger Funktionseinheiten, einschließlich Ausführungsformen, die eine Funktionseinheit in einem oder beiden der Kerne 48 und 50 aufweisen, in Erwägung gezogen werden können. Ferner kann einer der Kerne 48 oder 50 mehr Funktionseinheiten als der andere aufweisen.
Es sei bemerkt, dass, obwohl ein Emulations-Koprozessor-Kern in Fig. 2 gezeigt ist (und ein Emulations-Koprozessor in Fig. 7, 9, 10, 11 und 13 nachstehend gezeigt ist), es in Erwägung gezogen wird, dass mehrere Emulations- Koprozessoren verwendet werden können. Ferner wird in Erwägung gezogen, dass mehrere Fremd-Befehlssatzarchitekturen unter Verwendung von mehreren Emulations-Koprozessoren unterstützt werden können.
In Fig. 3 ist eine Blockdiagramm eines von einer Ausführungsform des Computersystems 5 verwendeten Software-Modells gezeigt. Fig. 3 veranschaulicht einen Host-Prozess 80 mit einem Fremd-Anwendungsprogramm 82. Die gezeigte Ausführungsform kann beispielsweise den Betrieb des Betriebssystems Windows NT mit der Alpha-Befehlssatzarchitektur als die Host-Befehlssatzarchitektur und die x86-Befehlssatzarchitektur als die Fremd-Befehlssatzarchitektur darstellen. Fig. 3 kann ferner weitere Betriebsysteme, Host-Befehlssatzarchitekturen und Fremd-Befehlssatzarchitekturen darstellen. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen.
Die Fremd-Anwendung 82 umfasst eine oder mehrere Module, die in der Fremd-Befehlssatzarchitektur codiert sind. Die Fremd-Anwendung kann Aufrufe an Betriebssystem-Routinen umfassen. Anstatt eines direkten Aufrufens der Betriebssystem-Routinen wird jede Routine durch ein "thunk" ersetzt. Der Thunk ist eine Routine mit dem gleichen Namen wie die Routine, die er ersetzt (und daher mit der gleichen Adresse innerhalb des Adressenraums des Prozesses 80), Bei der vorliegenden Ausführungsform umfasst der Thunk einen bestimmten vordefinierten illegalen Operations-Code, der den Emulations- Koprozessor veranlasst, eine illegale Operations-Code-Trap (oder "Ausnahme") zu nehmen. Beim Nehmen einer illegalen Operations-Code-Trap kommuniziert der Emulations-Koprozessor mit dem Host-Prozessor, um anzugeben, dass die Fremd-Anwendung angehalten hat. Beispielsweise kann der Emulations-Koprozessor Hardware umfassen, die die Stopp-Mitteilung beim Nehmen der illegalen Operations-Code-Trap erzeugt. Alternativ kann der illegale Operations-Trap-Hantierer (bei einer vorbestimmten Adresse gespeicherter Code, der festgelegt ist, bei dem Auftreten der illegalen Operations-Code- Trap abgerufen zu werden) codiert werden, um die Halte-Mitteilung zu liefern. Zwei Sätze von Thunks sind in Fig. 3 gezeigt, Betriebssystem-Thunks 86 und Prozess-Thunks 88. Betriebssystem-Thunks 86 werden verwendet, um Betriebsystem-Aufrufe abzufangen, d. h. sowohl direkte Betriebssystem-Aufrufe, die in dem Fremd-Anwendungsprogramm 82 codiert sind, und indirekte Betriebssystem-Aufrufe, die in Reaktion auf Ausnahmen während der Ausführung des Fremd-Anwendungsprogramms 82 auftreten. Außerdem können Prozess-Thunks 88 zum Kommunizieren mit einem in dem Prozess enthaltenen Block des Host-Code 90 enthalten sein. Die Prozess-Thunks 86 und der Host- Code 90 sind jedoch optional. Der oben erwähnte Prozess kann verwendet werden, um die Übergänge zwischen dem Fremd-Anwendungs-Code und dem Host-Code zu erfassen. Andere Ausführungsformen können andere Verfahren zum Detektieren des Übergangs verwenden.
Der Host-Prozess 80 umfasst ferner einen Emulations-Schnittstellen-Code 92, der verwendet werden kann, um zwischen dem Host-Prozessor und dem Emulations-Koprozessor zu kommunizieren. Demgemäss können Betriebssystem- Thunks 86 zu dem Aufrufen des Emulations-Schnittstellen-Codes 92 führen, um Mitteilungen zwischen dem Host-Prozessor und dem Emulations- Koprozessor weiterzuleiten. Ferner kann der Host-Prozessor konfiguriert sein, um Kontext-Information von dem Emulations-Koprozessor unter Verwendung des Emulations-Schnittstellen-Codes 92 anzufordern. Während die Betriebssystem-Routinen von dem Fremd-Anwendungsprogramm 82 aufgerufen werden, und entsprechende Betriebssystem-Routinen von dem Betriebssystem 84 die gleiche Funktion bereitstellen, sind die Aufruf-Konventionen (d. h. die Art und Weise, mit der Parameter zwischen der Anwendungs- und der Betriebssystem-Routine weitergeleitet werden) unterschiedlich, da die Befehlssatzarchitekturen unterschiedlich sind. Beispielsweise unterscheiden sich die Anzahl und die Art der Register, und daher unterscheidet sich die Fähigkeit, Parameter innerhalb der Register weiterzuleiten (im Gegensatz zu Speicherstellen). Demgemäss kann der Emulations-Schnittstellen-Code 92 die Kontext-Werte anfordern, die die Parameter für den Aufruf sind, und kann die Parameter in die entsprechenden Register auf dem Host-Koprozessor platzieren. Der Betriebssystem-Aufruf kann dann von dem Host-Prozessor durchgeführt werden. Im Anschluss daran können die Ergebnisse der Betriebssystem-Routine in den Emulations-Koprozessor durch Umkehren der Konversion des Aufrufens von Konventionen platziert werden.
Ferner kann der Betriebssystem-Bibliothek-Code 94 in dem Host-Prozess 80 aufgenommen sein. Beispielsweise können in dem Betriebssystem Windows NT festgelegte, dynamische Last-Bibliotheken über die Betriebssystem-Bibliotheken 94 aufgelöst werden.
In Fig. 4 ist als nächstes ein Ablaufdiagramm gezeigt, das die Initialisierung eines Anwendungsprogramms gemäß einer Ausführungsform des in Fig. 1 gezeigten Computersystems darstellt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Obwohl verschiedene Schritte in Fig. 4 in einer seriellen Reihenfolge zum leichteren Verständnis gezeigt sind, kann jede geeignete Reihenfolge verwendet werden. Außerdem können Schritte parallel durchgeführt werden, wie es gewünscht ist.
Bei Empfangen eines Befehls von einem Anwender, um ein Anwendungsprogramm einzuleiten, erzeugt das Betriebssystem ein Prozess, in dem das Anwendungsprogramm ausgeführt wird. Das Betriebssystem prüft das Dateiformat des Anwendungsprogramms, um zu bestimmen, welche Art von Code in dem Anwendungsprogramm enthalten ist (Schritt 100). Für eine Ausführungsform, die das Betriebssystem Windows NT verwendet, umfasst beispielsweise das portierbare Ausführungsformat eine Angabe, für welche Befehlssatzarchitektur das Anwendungsprogramm codiert ist. Das portierbare Ausführungsformat wird als Teil des von Windows NT festgelegten Anwendungs-Programmierungs-Schnittstelle festgelegt.
Wenn bestimmt wird, dass das Anwendungsprogramm der Host- Befehlssatzarchitektur codiert ist (Entscheidungsblock 102), legt das Betriebsystem den Prozess als einen normalen Host-Prozess fest, und das Anwendungsprogramm wird von dem Host-Prozessor ausgeführt (Schritt 104). Wenn andererseits bestimmt wird, dass das Anwendungsprogramm nicht gemäß der Host-Befehlssatzarchitektur codiert ist, bestimmt das Betriebssystem, ob das Anwendungsprogramm gemäß einer Fremd-Befehlssatzarchitektur codiert ist, die von einem Emulations-Koprozessor innerhalb des Computer ausführbar ist (Entscheidungsblock 106). Wenn die Fremd-Befehlssatzarchitektur von dem Emulations-Koprozessor ausführbar ist, ruft das Betriebssystem den Emulations-Koprozessor-Schnittstellen-Code auf, um das Fremd-Anwendungsprogramm auf dem Emulations-Koprozessor einzuleiten (Schritt 108). Wenn die Fremd-Befehlssatzarchitektur nicht von dem Emulations-Koprozessor ausführbar ist, zeigt das Betriebssystem dem Anwender eine Mitteilung an, die angibt, dass die Anwendung nicht unterstützt wird (Schritt 110). In diesem Fall wird das Anwendungsprogramm nicht gestartet. Alternativ kann die Software- Emulation oder die Binär-Übersetzung der Anwendung bei Schritt 110 bereitgestellt werden, falls erwünscht. Beispielsweise kann ein Schema ähnlich dem FX132-Produkt von Digital Equipment Cooperation oder dem Wx86-Prödukt von Microsoft verwendet werden.
In Fig. 5 ist als nächstes ein Ablaufdiagramm gezeigt, das eine Ausführungsform des Aufrufens einer in Fig. 3 gezeigten Emulations-Schnittstelle zeigt (z. B. in Figur gezeigter Schritt 108). Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Der Prozess-Kontext wird von dem Host- Prozessor festgelegt (mit mittels der Befehlsschnittstelle zwischen dem Host- Prozessor und dem Emulations-Coprozessor übertragener Befehle). Anfangswerte für die Register, einschließlich eines Wert für das Programmzähler- Register, der die virtuelle Adresse des ersten Befehls in dem Anwendungsprogramm ist, werden bereitgestellt. Nach Festlegen des Kontexts wird der "Go" (d. h. Start-Ausführungs-) Befehl an den Emulations-Koprozessor übergeben (Schritt 120).
Der Emulations-Schnittstellen-Code, der von dem Host-Prozessor ausgeführt wird, überwacht die Befehlsschnittstelle 54, um eine Mitteilung von dem Emulations-Koprozessor zu empfangen, dass ein Übergang zu dem Host-Code erfasst wurde (d. h. eine Stopp-Mitteilung wird von dem Emulations-Koprozessor empfangen). Wenn ein Übergang zu dem Host-Code erfasst wird (Entscheidungsblock 122), bestimmt der Host-Prozessor, ob der Übergang aufgrund einer Prozess-Ausstiegsbedingungen stattfindet (Entscheidungsblock 128). Wie es nachstehend in Fig. 6 dargestellt ist, kann der Stopp-Befehl eines Angabe des Grundes zum Anhalten umfassen. Wenn ein Prozess-Ausstieg erfasst wird, wird eine Zerstöre-Prozess-Mitteilung an das Betriebssystem gesendet und der Emulations-Schnittstellen-Code springt aus (Schritt 130).
Wenn andererseits ein Prozess-Ausstieg nicht erfasst wird, sammelt der Host- Prozessor Kontext-Information über die Befehlsschnittstelle 54, um zu bestimmen, welche Betriebsystem-Routine auszuführen ist und was die Aufrufparameter sind (Schritt 124). Der Host-Code wird dann auf dem Host-Prozessor ausgeführt. Die Kontext-Information wird über die Befehlsschnittstelle 54 an den Emulations-Koprozessor bereitgestellt. Die mittels der Ausführung der Betriebssystem-Routine 54 bereitgestellten Ergebnisse können, falls anwendbar, an den Emulations-Koprozessor auf diese Art und Weise geleitet werden. Der Go-Befehl wird dann bereitgestellt, um den Emulations-Koprozessor zu veranlassen, fortzufahren (Schritt 126), und der Host-Prozessor fährt fort, Mitteilungen von dem Emulations-Koprozessor zu überwachen.
Es sei bemerkt, dass es mindestens zwei Arten von Betriebssystem-Routinen gibt, die von dem Fremd-Anwendungsprogramm aufgerufen werden können. Die erste Art ist ein Betriebssystem-Bibliotheks-Routinen-Aufruf, der absichtlich in dem Fremd-Anwendungsprogramm codiert ist. Bibliotheks-Routinen liefern Dienste niedriger Ebene, die von vielen Anwendungsprogrammen verwendet werden können, und werden von dem Anwendungsprogramm verwendet, anstatt dass sie den Dienst selber codieren. Typischerweise werden die Bibliotheks-Routinen und Parameter, die von den Routinen verwendet werden, für die Benutzung des Anwendungsentwicklers dokumentiert. Außerdem können Betriebssystem-Routinen, die Ausnahme-Handhabung bereitstellen, aufgerufen werden. Wie es in dem Namen impliziert ist, werden diese Routinen "aufgerufen", wenn der Emulations-Koprozessor eine Ausnahme erfasst. Beispielsweise rufen Seitenfehler, die auftreten, wenn eine Befehls-Abruf-Adresse oder Daten-Adresse versagt zu übersetzen, eine Ausnahme-Routine auf, um eine Seite zuzuteilen.
Seitenfehler können bei dem anfänglichen Zugriff auf eine bestimmte Seite auftreten. Wenn beispielsweise der Emulations-Koprozessor versucht, den ersten Befehl eines Anwendungsprogramms abzurufen, kann die Seite mit dem ersten Befehl noch nicht dem Anwendungsprogramm zugeteilt sein. Demgemäss übersetzt die Abruf-Adresse nicht und ein Seitenfehler tritt auf. Ebenso kann jedes Mal, wenn auf Daten von einer neuen Seite zugegriffen wird, ein Seitenfehler auftreten. Seitenfehler können ebenfalls auftreten, wenn die Seite an die Platte "ausgelagert" ist, um zu ermöglichen, das eine unterschiedliche Seite zugeteilt wird.
Es sei bemerkt, dass das Ablaufdiagramm von Fig. 5 gemäß einem präemptiven Multitasking-Betriebssystem, wie beispielsweise Windows NT, unterbrochen werden kann, um dem Host-Prozessor zu ermöglichen, weitere Tasks auszuführen (z. B. ein Host-Anwendungsprogramm oder Betriebssystem- Routine, die sich nicht auf die ausgeführte Anwendung bezieht). Ferner können, wenn mehrere Fremd-Anwendungen gleichzeitig ausgeführt werden, mehrere Prozesse nach Mitteilungen überwacht werden.
Bei einer Ausführungsform kann der Emulations-Schnittstellen-Code mit der Wx86-Erweiterung an dem Betriebssystem Windows NT schnittstellenmäßig verbunden sein.
In Fig. 6 ist nun eine Tabelle 140 gezeigt, die die von einer Ausführungsform der Befehlsschnittstelle 54 unterstützten Befehle darstellt. Weitere Ausführungsformen, die unterschiedliche Befehle oder Kombination von unterschiedlichen Befehlen und einen oder mehreren Befehle verwenden, die in Tabelle 140 gezeigt sind, werden in Erwägung gezogen.
Eine Lese-Register-Befehl wird zum Lesen von Emulations-Koprozessor-Registern von dem Host-Prozessor unterstützt. Der Emulations-Koprozessor antwortet auf das Lese-Register Befehl durch Bereitstellen der angeforderten Registerwerte. Es sei bemerkt, dass Speicherwerte von dem Kontext des Emulations-Koprozessors ebenfalls gelesen werden können. Da jedoch der Emulations-Koprozessor und der Host-Prozessor den gleichen physikalischen Speicher teilen, kann der Host-Prozessor die Speicherwerte direkt lesen. Wie es oben erwähnt ist, werden entweder die gleichen Übersetzungen von sowohl dem Host-Prozessor als auch dem Emulations-Koprozessor geteilt, oder die Übersetzungen werden gemäß sowohl der Befehlssatzarchitektur des Host-Prozessors als auch der Befehlssatzarchitektur des Emulations-Koprozessors für jede einem Fremd-Anwendungsprogramm zugeteilten Seite erzeugt. Demgemäss kann der Host-Prozessor den Kontext einer Fremd-Anwendung zugeteilten Speicher betrachten.
Ebenso wird ein Schreibe-Register-Befehl unterstützt, um es dem Host-Prozessor zu ermöglichen, Registerbefehle in dem Emulations-Koprozessor zu aktualisieren. Der Emulations-Koprozessor empfängt Daten, die in dem Schreibregister-Befehl bereitgestellt werden, und aktualisiert das spezifizierte Register mit dem empfangenen Wert. Auf ähnliche Weise wie die obigen Anmerkungen hinsichtlich des Speicherlesens, kann der Host-Prozessor-Speicher in dem Kontext des Emulations-Koprozessors ebenfalls aktualisieren.
Der Go-Befehl gibt dem Emulations-Koprozessor an, dass der Emulations-Koprozessor die Ausführung beginnen sollte. Vor dem Senden des Go-Befehls an den Emulations-Koprozessor wird ein Ausführungszeiger in dem Programm- Zähler-Register in dem Emulations-Koprozessor gespeichert. Der Emulations- Koprozessor beginnt bei Empfang des Go-Befehls das Abrufen und das Ausführen von Befehlen an dem Befehlszeiger. Alternativ kann der Befehlszeiger innerhalb des Go-Befehls kommuniziert werden, falls gewünscht.
Ein Stopp-Befehl wird von dem Emulations-Koprozessor übertragen, wenn bestimmt wird, dass eine Architektur-Umschaltung infolge der Ausführung des Fremd-Anwendungsprogramms durchzuführen ist, übertragen (z. B. der Host- Code ist auszuführen). Der Stopp-Befehl teilt dem Host-Prozessor mit, dass der Emulations-Koprozessor angehalten hat, und liefert ebenfalls den Grund für das Anhalten. Eine Vielfalt von Gründen für das Anhalten können verwendet werden, wie es gewünscht ist. Beispielsweise können Gründe für das Anhalten umfassen: (i) Ausführen eines Thunks (wie es oben beschrieben ist) für ein Betriebssystem-Aufruf; (ii) Detektieren des Endes der Ausführung des Fremd-Anwendungsprogramms; oder (iii) Erleben einer Ausnahme während der Ausführung des Anwendungsprogramms. Falls gewünscht, kann unter Verwendung der Lese-Register-Befehle und des Lesens des Speichers des Fremd-Anwendungsprogramms der Host-Prozessor zusätzliche Kontext-Information sammeln.
Es sei bemerkt, dass der Begriff "Mitteilungen" hier verwendet werden kann, um sich auf die Kommunikationen zwischen dem Host-Prozessor und dem Emulations-Koprozessor zu beziehen. Es ist in dieser Offenbarung beabsichtigt, dass die Begriffe Mitteilungen und Befehle synonym sind.
In Fig. 7 ist als nächstes eine zweite in Erwägung gezogene Ausführungsform des Prozessors 10 gezeigt. Die Ausführungsform von Fig. 7 kann beispielsweise bei der Ausführungsform des in Fig. 5 gezeigten Computersystems verwendet werden. Fig. 3 bis 6 können ebenfalls auf die Ausführungsform von Fig. 7 allgemein angewendet werden. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Wie es in Fig. 7 gezeigt ist, umfasst der Prozessor 10 einen Emulations-Koprozessor 150, einen Host-Prozessor 152 und eine Schnittstellen-Logik-Einheit 154. Der Emulations-Koprozessor 150 und der Host-Prozessor 152 sind mit der Schnittstellen-Logik-Einheit 154 gekoppelt, die ferner mit dem CPU-Bus 34 gekoppelt ist. Der Host-Prozessor 152 ist ferner mit dem L2-Cache-Speicher über die Backside-L2-Schnittstelle 52 gekoppelt.
Der Emulations-Koprozessor 150 kann ein Emulations-Koprozessor-Kern 50 ähnlich dem in Fig. 2 gezeigten sowie auch Cache-Speicher ähnlich dem Befehls-Cache-Speicher 44 und dem Daten-Cache-Speicher 46 und eine MMU ähnlich der MMU 42 umfassen. Der Host-Prozessor 152 kann den Host-Prozessor-Kern ähnlich den in Fig. 2 gezeigten sowie auch Cache-Speicher ähnlich dem Befehls-Cache-Speicher 44 und dem Daten-Cache-Speicher 46 und eine MMU ähnlich der MMU 42 umfassen.
Gemäß einer bestimmten Ausführungsform umfasst der Prozessor 10 gemäß Fig. 7 drei getrennte Halbleiter-Chips, die auf einem gedruckten Schaltungsplatte angebracht sind. Die gedruckte Schaltungsplatte kann einen Randverbinder aufweisen und zur Einbeziehung in das Computersystem 5 eingekapselt sein. Beispielsweise kann der Prozessor 10 in Übereinstimmung mit irgendeiner der von Intel und Advanced Micro Devices entwickelten Spezifikationen Slot 1, Slot 2 oder Slot 2000 ausgestaltet sein. Ein Chip nimmt den Emulations-Koprozessor 150 auf. Ein zweiter Chip nimmt den Host-Prozessor 152 und ein dritter Chip nimmt die Schnittstellen-Logik 154 auf. Beispielsweise können der Emulations-Koprozessor 150 und der Host-Prozessor 152 kundenspezifisch ausgestaltete Halbleiter-Chips sein, und die Schnittstellen-Logik-Einheit 154 kann eine anwender-spezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA) etc. sein. Weitere Organisationen sind möglich und werden in Erwägung gezogen, die die der Verwirklichung der Schnittstellen-Logik-Einheit 154 ebenfalls als ein kundenspezifischer Halbleiter-Chip umfassen.
Die in Fig. 7 gezeigte Ausführungsform ermöglicht, dass der vorher ausgestalteten Emulations-Koprozessor 150 und einem Host-Prozessor 152 (die möglicherweise unter Verwendung unterschiedlicher Halbleiter-Fertigungsprozesse hergestellt wurden) verwendet werden, um den Prozessor 10 zu bilden. Der Emulations-Koprozessor 150 und der Host-Prozessor 152 können jeweils eine Bus-Schnittstelle an der Schnittstellen-Logik-Einheit 154 bereitstellen (Bezugsziffern 156 bzw. 158). Beispielsweise können die Bus-Schnittstellen 156 und 158 mit dem CPU-Bus 34 logisch und elektrisch identisch sein. Alternativ können die Bus-Schnittstellen 156 und 158 gemäß unterschiedlicher Bus-Protokolle und/oder elektrischer Spezifikationen als diejenigen, die für den CPU- Bus 34 spezifiziert sind, arbeiten. Außerdem kann sich die Bus-Schnittstelle 156 von der Bus-Schnittstelle 158 unterscheiden, und die Schnittstellen-Logik-Einheit 154 kann Transaktionen auf den Bussen mit dem geeigneten Protokoll ähnlich der Arbeitsweise der Bus-Brücke 12 übersetzen.
Die Schnittstelle-Logik-Einheit 154 liefert die Befehlsschnittstellen- Funktionalität (z. B. Befehlsschnittstelle 54) bei der Ausführungsform von Fig. 7. Vordefinierte Buszyklen, die sich von den Speicher- und I/O-Bus-Zyklen unterscheiden, können auf den Bus-Schnittstellen 156 und 158 festgelegt sein, um die verschiedenen Befehle zwischen dem Emulations-Koprozessor 150 und dem Host-Prozessor 152 zu kommunizieren. Alternativ kann die Befehlsschnittstelle 52 einen Satz von FIFOs umfassen, in die der Emulations- Koprozessor und der Host-Prozessor 152 Befehle schreiben und aus denen der Emulations-Koprozessor 150 und der Host-Prozessor 152 Befehle lesen.
Zusätzlich zum Bereitstellen der Befehlsschnittstellen-Funktionalität leitet die Schnittstellen-Logik-Einheit 154 Nicht-Befehl- (z. B. Speicher und E/A-) Anforderungen von dem Emulations-Koprozessor 150 und dem Host-Prozessor 152 an den CPU-Bus 34 und optional an den nicht-anfordernden Prozessor. Fig. 8 ist ein Ablaufdiagramm, das eine Ausführungsform des Routings sowohl der Befehls- als auch der Nicht-Befehls-Anforderungen gemäß einer Ausführungsform der Schnittstellen-Logik-Einheit 154 darstellt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Die in Fig. 8 gezeigten Schritte werden manchmal in einer seriellen Reihenfolge zum leichten Verständnis dargestellt. Die Schritte können jedoch in jeder geeigneten Reihenfolge und parallel durchgeführt werden, wie es gewünscht ist.
Anforderungen (mit der Ausnahme von Kohärenz-Anforderungen auf dem CPU-Bus 34, die sowohl an den Host-Prozessor 153 als auch den Emulations- Koprozessor 154 geleitet werden) werden entweder von dem Host-Prozessor 152 oder dem Emulations-Koprozessor 150 eingeleitet. Wenn eine Anforderung auf der Bus-Schnittstelle 156 empfangen wird, wird die Anforderung von dem Emulations-Koprozessor 150 eingeleitet. Wenn die Anforderung von dem Host-Prozessor 158 empfangen wird, dann wird die Anforderung von dem Host-Prozessor 152 eingeleitet. Die Schnittstellen-Logik-Einheit 154 bestimmt den Initiator der Anforderung (Entscheidungsblock 160). Wenn die Anforderung von dem Host-Prozessor 152 eingeleitet wird, dann bestimmt die Schnittstellen-Logik-Einheit 154, ob die Anforderung ein Befehl für die Emulations-Schnittstelle ist (z. B. ein Befehl an den Emulations-Koprozessor 150 über die Befehlsschnittstelle 54 - Entscheidungsvorgang 162). Wenn die Anforderung ein Befehl an den Emulations-Koprozessor 150 ist, wird die Anforderung an den Emulations-Koprozessor 150 geleitet (Schritt 164). Der CPU- Bus 34 kann von dem Befehl unbeeinflusst sein. Wenn die Anforderung kein Befehl an den Emulations-Koprozessor 150 ist, feitet die Schnittstellen-Logik- Einheit 154 den Befehl an den CPU-Bus 34 (Schritt 166).
Wenn andererseits eine Anforderung von dem Emulations-Koprozessor 150 empfangen wird, wird die Anforderung an den Host-Prozessor 152 geleitet (Schritt 168). Emulations-Schnittstellen-Befehle werden an den Host-Prozessor 152 geleitet, da die Bestimmung Ziel der Anforderung der Host-Prozessor 152 ist. Speicher- und E/A-Anforderungen werden an den Host-Prozessor 152 geleitet, um dem Emulations-Koprozessor 150 zu ermöglichen, die L2-Cache- Speicher-Resourcen des Host-Prozessors 152 zu teilen (z. B. L2-Cache- Speicher 38). Die Speicher-Anforderung kann von der Schnittstellen-Logik- Einheit 154 in der Form einer Kohärenz-Anforderung bereitgestellt werden, so dass der Host-Prozessor 152 die angeforderten Daten liefert. Alternativ kann die Schnittstellen-Logik-Einheit 154 einen vorbestimmten Bus-Zyklus verschieden von den gemäß der Bus-Schnittstelle 158 bereitgestellten Bus- Zyklen verwenden, um ein Lesen des L2-Cache-Speichers 38 anzufordern. Auf diese Art und Weise können Kostenersparnisse durch Verwenden eines gemeinsam verwendeten L2-Cache-Speichers zwischen dem Host-Prozessor 152 und dem Emulations-Koprozessor 150 erreicht werden.
Wie es oben erwähnt ist, kann die Anforderung von dem Emulations- Koprozessor 150 entweder ein Befehl für die Emulations-Schnittstelle (z. B. einen Befehl an den Host-Prozessor 152 über die Befehlsschnittstelle 52 oder ein vorbestimmter Bus-Zyklus sein - Entscheidungsblock 170) oder eine Speicher- oder E/A-Anforderung. Wenn die Anforderung ein Emulations-Schnittstellen-Befehl ist, kann die Anforderung an den Host-Prozessor 152 geleitet werden (Schritt 168) und zusätzliche Maßnahmen müssen nicht erforderlich sein. Wenn andererseits die Anforderung kein Emulations-Schnittstellen-Befehl ist, bestimmt die Schnittstellen-Logik-Einheit 154 aus der Antwort des Host-Prozessors 152 an den dazu geleiteten Bus-Zyklus (Schritt 168), um zu bestimmen, ob die Anforderung von dem Host-Prozessor 152 erfüllt werden kann (Entscheidungsblock 172). Wenn die Anforderung von dem Host-Prozessor 152 erfüllt werden kann, werden die von dem Host-Prozessor 152 bereitgestellten Daten an den Emulations-Koprozessor 150 über die Schnittstellen- Logik-Einheit 154 geleitet (Schritt 174). Wenn die Anforderung von dem Host- Prozessor 152 nicht erfüllt werden kann, wird die Anforderung an den CPU- Bus 34 durch die Schnittstellen-Logik-Einheit 154 geleitet (Schritt 166).
In Fig. 9 wird als nächstes ein Blockdiagramm einer dritten Ausführungsform des Prozessors 10 gezeigt, der beispielsweise in dem in Fig. 1 gezeigten Computersystem 5 verwendet werden kann. Fig. 3 bis 6 können ebenfalls auf dieser Ausführungsform allgemein angewendet werden. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei der Ausführungsform von Fig. 9 umfasst der Prozessor 10 den Emulations-Koprozessor 150 und den Host-Prozessor 152. Der ausführlicher gezeigte Host-Prozessor 152 umfasst einen Kern 48, einen ICache-Speicher 44, einen DCache-Speicher 46, eine MMU 42 und eine Bus-Interface-Einheit 40. Der Emulations-Koprozessor 150 ist mit dem Host-Prozessor 152 über interne Verbindungen des Prozessors 10 gekoppelt, einschließlich der Befehls-Schnittstelle 54. Der Host-Prozessor 152 und insbesondere die Bus-Schnittstellen-Einheit 40 ist mit dem CPU-Bus 34 und dem L2-Cache-Speicher 38 über eine Backside-L2-Schnittstelle 52 gekoppelt.
Die Ausführungsform von Fig. 9 ermöglicht das Teilen von Cache- und MMU- Resourcen zwischen dem Emulations-Koprozessor 150 und dem Host- Prozessor 152. Mit anderen Worten kann der Emulations-Koprozessor 150 Cache-Speicher und MMU-Schaltungsanordnungen bei dieser Ausführungsform ausschließen. Anstatt kann der Emulations-Koprozessor 150 mit Zugriff auf den ICache-Speicher 44, den DCache-Speicher 46, die MMU 42 und indirekt auf die Bus-Schnittstellen-Einheit 40 versehen werden. Es ist möglich, dass die Menge an verwendeter Schaltung, um einen Emulations-Koprozessor 150 zu verwirklichen, vorteilhafterweise wesentlich verringert werden kann.
Es sei bemerkt, dass der Emulations-Koprozessor 150 konfiguriert ist, um Befehle aus entweder dem Daten-Cache-Speicher 46 oder dem Befehls-Cache- Speicher 44 bei verschiedenen Ausführungsformen ähnlich der obigen Beschreibung von Fig. 2 abzurufen. Außerdem kann der Emulations-Koprozessor 150 einen Befehls-Cache-Speicher zum Abrufen von Befehlen aufweisen und Befehls-Cache-Fehltreffer aus dem Daten-Cache-Speicher 46 abrufen.
Als eine Alternative zur Bereitstellung der Befehls-Schnittstelle 54 innerhalb des Prozessors 10 können FIFOs innerhalb des Hauptspeichers 14 unterhalten werden, um Befehls-Mitteilungen zwischen den Host-Prozessor 152 und dem Emulations-Koprozessor 150 zu leiten. Es sei bemerkt, dass bei der Ausführungsform von Fig. 9 der Prozessor 10 als ein Einzel-Halbleitersubstrat, ein Multichip-Modul oder zwei oder mehr Halbleiter innerhalb eines Gehäuses vom Slot 1, Slot A oder Schlitz 2000 Typ unter anderen verwirklicht werden kann.
In Fig. 10 ist als nächstes ein Blockdiagramm der zweiten Ausführungsform des Computersystems 5 gezeigt. Fig. 3 bis 6 können allgemein bei dieser Ausführungsform ebenfalls Anwendung finden. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei der Ausführungsform von Fig. 10 sind der Host-Prozessor 152 und der Emulations-Koprozessor 150 jeweils direkt mit der Bus-Brücke 12 gekoppelt. Als eine Alternative zu den unabhängigen CPU-Bus-Verbindungen 34 und 34a kann der Host-Prozessor 152 und der Emulations-Koprozessor 150 einen gewöhnlichen CPU-Bus 34 teilen. Ferner ist der Host-Prozessor 152 mit dem L2-Cache-Speicher 38 gekoppelt, und der Emulations-Koprozessor 150 ist auf ähnliche Weise mit dem L2- Cache-Speicher 38a gekoppelt.
Bei der Ausführungsform von Fig. 10 können der Host-Prozessor 152 und der Emulations-Koprozessor 150 jeweils interne Cache-Speicher- und Speicher- Verwaltungs-Einrichtungen aufweisen. Beispielsweise kann der Host-Prozessor 130 ein Prozessor sein, der ausgestaltet ist, um in einem Computersystem ohne einen Emulations-Koprozessor aufgenommen zu sein, und aus ähnliche Weise kann der Emulations-Koprozessor 150 ein Prozessor sein, der ausgestaltet ist, um mit einem Computersystem ohne einen Host-Prozessor aufgenommen zu sein (z. B. als die zentrale Verarbeitungseinheit des Computersystems). Mit anderen Worten können der Host-Prozessor 152 und der Emulations-Koprozessor 150 "aus dem Regal"-Teile sein. Die Befehls-Schnittstelle 54 kann mittels des Hauptspeichers 14 bereitgestellt werden, wie beispielsweise unter Verwendung von FIFOs, um Befehls-Mitteilungen zwischen den Prozessoren zu leiten. Alternativ kann die Befehls-Schnittstelle 54 innerhalb der Bus- Brücke 12 vorgesehen sein. Als eine noch weiter Alternative kann eine private Schnittstelle getrennt von den CPU-Bussen 34 und 34a verwendet werden, um die Befehls-Schnittstelle 54 bereitzustellen.
Bei der Ausführungsform von Fig. 10 umfassen der Host-Prozessor 152 und der Emulations-Koprozessor 150 eine logisch und elektrisch äquivalente Bus- Schnittstelle (d. h. CPU-Bus 34). Fig. 11 ist eine weitere Ausführungsform des Computersystems 5, bei der der Emulations-Koprozessor 150 eine unterschiedliche Bus-Schnittstelle als der CPU-Bus 34 aufweist. Demgemäss umfasst das in Fig. 11 gezeigte Computersystem 5 eine Bus-Brücke 180 zum Übersetzen von Transaktionen, die von dem Emulations-Koprozessor 150 erzeugt werden, aus den Protokoll- und elektrischen Signalisierungs-Merkmalen des Emulations-Koprozessors 150 der Bus-Schnittstelle zu demjenigen des CPU-Busses 34a. Demgemäss unterstützt die Ausführungsform von Fig. 11 einen Aus-dem-Regal-Host-Prozessor 152 und einem Aus-dem-Regal-Emulations-Koprozessor 150, sogar wenn unterschiedliche Busschnittstellen von dem Host-Prozessor und dem Emulations-Koprozessor verwendet werden.
Wie bei der Ausführungsform von Fig. 10 kann die Befehls-Schnittstelle 54 in einem Hauptspeicher in der Ausführungsform von Fig. 11 implementiert sein. Alternativ kann die Befehls-Schnittstelle 54 innerhalb der Bus-Brücke 12 vorgesehen sein. Als eine noch weitere Alternative kann eine private Schnittstelle getrennt von den CPU-Bussen 34 und 34a verwendet werden, um die Befehls- Schnittstelle 54 vorzusehen.
In Fig. 12 ist als nächstes eine vierte Ausführungsform des Computersystem 5 gezeigt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei der Ausführungsform von Fig. 12 ist der Emulations-Koprozessor auf einer Emulations-Koprozessor-Karte 22C aufgenommen. Die Emulations- Koprozessor-Karte 22C ist mit dem PCI-Bus 24 gekoppelt, wie es in Fig. 12 gezeigt ist. Die Hardware für die Emulations-Koprozessor-Karte 22C kann beispielsweise die Karten der Radius Detente AX oder MX sein, die von der Reply Corporation in Sunnyvale, Kalifornien, hergestellt werden.
Zusätzlich zu den oben mit Bezug auf Fig. 3 bis 6 beschriebene Operation kann die Ausführungsform von Fig. 12 ebenfalls verschiedene weitere Operationen aufweisen. Die Befehls-Schnittstelle kann in dem Speicher auf der Emulations-Koprozessor-Karte 22C unterhalten werden. Außerdem wird, da die Emulations-Koprozessor-Karte 22C eine E/A-Vorrichtung ist, ein Treiber in dem Betriebssystem zum schnittstellenmäßigen Verbinden mit der Emulations-Koprozessor-Karte 22C bereitgestellt. Außerdem wird ein Software-Exekutive für die Emulations-Koprozessor-Karte 22C bereitgestellt, um zu ermöglichen, das mehrfache Anwendungsprogramme gleichzeitig in Ausführung sein können. Demgemäss können Befehle, um Prozesse zu erzeugen und zu zerstören, und Threads innerhalb der Prozesse zu dem Satz von Befehlen hinzugefügt werden, die zwischen dem Emulations-Koprozessor und dem Host-Prozessor kommuniziert werden, wie es in Fig. 6 dargestellt ist. Außerdem werden Befehle bereitgestellt, um Seiten zur Benuzung durch Fremd-Anwendungsprogrammen zuzuteilen, die auf der Emulations-Koprozessor-Karte 22C ausgeführt werden. Da die Emulations-Koprozessor-Karte 22C dem Betriebssystem des Computersystems 5 als eine E/A-Vorrichtung erscheint, wird, wenn eine Seite dem Emulations-Koprozessor zugeteilt wird, die Seite im Hauptspeicher 14 verriegelt (d. h. die Seite wird nicht zum Auslagern an ein Plattenlaufwerk bei Empfang einer Seiten-Zuteilungs-Anforderung von dem Betriebssystem ausgewählt). Die Exekutive, die auf der Emulations-Koprozessor-Karte ausgeführt wird, bestimmt, wann eine Seite nicht lange von den auf dem Emulations-Koprozessor ausgeführten Anwendungsprogrammen im Gebrauch ist, und liefert eine Mitteilung, um eine Seite zu entriegeln, wenn bestimmt wird, dass sie nicht länger in Gebrauch ist.
Ferner umfasst, wenn der Emulations-Koprozessor innerhalb der Emulations- Koprozessor-Karte 22C einen oder mehrere Cache-Speicher aufweist, wobei die auf der Emulations-Koprozessor-Karte 22C ausgeführte Exekutive Cache- Kohärenz zwischen den Emulations-Prozessor-Cache-Speichern und den Cache-Speichern innerhalb des Host-Prozessors 150 und dem L2-Cache- Speicher 38 (und innerhalb des Host-Prozessors 150a und des L2-Cache- Speichers 38a, falls enthalten) unterhält. Alternativ können die Cache- Speicher innerhalb des Emulations-Koprozessors gesperrt sein, so dass Cache-Kohärenz kein Thema ist.
Bei einer bestimmten Ausführungsform verwendet das Computersystem 5 das Betriebssystem Windows NT für die Alpha-Befehlssatzarchitektur, und der Host-Prozessor 150 verwendet die Alpha-Befehlssatzarchitektur. Ferner umfasst das von dem Computersystem 5 verwendete Betriebssystem Windows NT die Wx86-Emulations-Erweiterungen. Der Code zum Emulieren des x86- Prozessors wird jedoch von dem oben beschriebenen Emulations- Schnittstellen-Code ersetzt. Der Treiber für die Emulations-Koprozessor-Karte 22C liefert die Seiten-Verriegelungs- und Entriegelungs-Funktionalität in Reaktion auf Verriegelungs- und Entriegelungs-Anforderungen von der Exekutive. Insbesondere fordert die Exekutive eine verriegelte Seite für entweder Code oder Daten an. Der Treiber verwendet in Reaktion auf die Anforderung die Memory-Manager-Anwendungs-Programmier-Schnittstelle(API)-Aufrufe von Windows NT, um die Seite zu verriegeln (d. h. verhindern des Austauschens der Seite mit der Platte, um zu ermöglichen, dass eine unterschiedliche virtuelle Seite dieser physikalischen Seite zugewiesen wird). Im Anschluss daran kann die Exekutive bestimmen, dass die Seite nicht länger für die Anwendungsprogramm-Ausführung benötigt wird, und kann eine Entriegelungs- Mitteilung senden. Als Antwort verwendet der Treiber die Windows-NT- Memory-Manager-API, um die Seite zu entriegeln. Außerdem ist der Treiber für das Initialisieren der Karte innerhalb des Betriebssystems und das Abbilden des Speichers auf der Karte verantwortlich.
Der Treiber und die Exekutive für die Ausführungsform von Fig. 12 basieren auf dem paket-basierten DMA-Bus-Master-Modell, das von dem Betriebssystem Windows NT festgelegt ist (insbesondere, wie es in der Windows-NT-DDK dokumentiert ist). Ein Adapter-Objekt wird unter Verwendung des IoAllocateAdapterChannel erzeugt. Speicher-Deskriptoren-Listen MDLs (memory descriptor lists) werden erzeugt, um die virtuelle in physikalische Abbildung der von dem Prozessen verwendeten Seiten zu beschreiben. Logische Adressen werden mit IoMapTransfer erzeugt und an den Emulations-Koprozessor auf der Emulations-Koprozessor-Karte 22C geliefert. Somit werden die Abbildungs-Register erzeugt, die die Übersetzung der logischen Adressen in physikalische Adressen innerhalb des Hauptspeichers 14 (d. h. des Host-System- Speichers) bereitstellen. Der Emulations-Koprozessor kann dadurch auf den Hauptspeicher 14 zugreifen, um Befehle und Lese/Schreib-Daten direkt abzurufen. Mit anderen Worten wird der Code ausgeführt und auf Daten wird im Hauptspeicher 14 zugegriffen. Diese Zugriffe können dem Host-System als DMA erscheinen. Befehle und Daten werden dadurch an die Emulations-Koprozessor-Karte 22C geliefert.
Es sei bemerkt, obgleich einer Software-Exekutive zum Steuern der Emulations-Koprozessor-Karte 22C beschrieben wurde, weitere Ausführungsformen möglich sind, in denen Teile der Steuerung in Hardware bereitgestellt werden. Derartige Ausführungsformen werden in Erwägung gezogen.
In Fig. 13 ist als nächstes ein Blockdiagramm einer Ausführungsform der Emulations-Koprozessor-Karte 22C gezeigt. Weitere Ausführungen sind möglich und werden in Erwägung gezogen. Wie es in Fig. 13 gezeigt ist, umfasst die Emulations-Koprozessor-Karte 22C eine PCI-Schnittstelle 190, den Emulations-Koprozessor 150 und einen Speicher 194. Die PCI-Schnittstelle 190 ist mit dem PCI-Bus 24, einem Speicher 194 und dem Emulations-Koprozessor 150 gekoppelt. Der Emulations-Koprozessor 150 ist ferner mit dem Speicher 194 gekoppelt. Der Speicher 194 umfasst Speicherplatz für das exekutive Programm 196 und für die Befehls-Warteschlangen 198, die verwendet werden, um Befehls-Mitteilungen zwischen dem Exekutive-Programm 196 und dem Treiber für die Emulations-Koprozessor-Karte 22C sowie auch dem Emulations-Schnittstellen-Code 92 weiterzuleiten. Mit anderen Worten können die Befehls-Warteschlangen 198 die Befehls-Schnittstelle 54 umfassen. Es sei bemerkt, dass, obwohl auf Befehle und Daten vorzugsweise von dem Hauptspeicher 14 direkt von dem Emulations-Koprozessor 150 zugegriffen wird, alternative Ausführungsformen von Seiten im Hauptspeicher 14 übertragene Befehle und Daten ebenfalls in dem Speicher 194 speichern können.
Wie es oben erwähnt ist, kann die Emulations-Koprozessor-Karte 22C eine Radius Detente AX oder MX Karte sein, die von der Reply Corporation hergestellt werden. Diese Produkte können zusätzliche Hardware-Merkmale aufweisen, die in Fig. 13 nicht gezeigt sind. Die Hardware-Merkmale können verwendet werden oder nicht verwendet werden, wie es gewünscht ist, wenn die Karte als Emulations-Koprozessor-Karte 22C verwendet wird.
In Fig. 14 ist nun ein Diagramm gezeigt, das eine Steuerstruktur darstellt, die von einer Ausführungsform des Exekutive-Programms 196 unterhalten wird. Weitere Ausführungsformen werden möglicherweise in Erwägung gezogen. Bei der Ausführungsform von Fig. 14 umfasst die Steuerstruktur eine Prozessliste 200, die eine doppelt verknüpfte Liste der aktiven Prozesse innerhalb der Emulations-Koprozessor-Karte 22C ist. Beispielsweise sind in Fig. 14 drei Prozesse 202A, 202B und 202C aktiv. Jeder Prozess kann ein oder mehrere Threads aufweisen. Beispielsweise umfasst der Prozess 202A die Threads 204A, 204B und 204C. Ebenso umfasst der Prozess 2028 die Threads 204D, 204E und 204F. Der Prozess 202C umfasst den Thread 204 G. Jeder Prozess kann ferner eine oder mehre Speicherseiten zugeteilt werden, in denen dem Prozess entsprechende Befehle und Daten gespeichert werden. Beispielsweise werden dem Prozess 202A die Seiten 206A, 206B und 206C zugeteilt. Ebenso werden dem Prozess 202B die Seiten 206D und 206E zugeteilt. Dem Prozess 202C sind die Seiten 206F und 206 G zugeteilt.
Wie es in Fig. 14 dargestellt ist, kann jedem Prozess 202A bis 202C eine unterschiedliche Anzahl von Seiten 206 und eine unterschiedliche Anzahl von Threads 204 als die anderen Prozesse 202A bis 202C zugeteilt sein. Wenn ein Prozess 202A bis 202C einen Seitenfehler erlebt, kann eine neue Seite diesem Prozess über das Exekutive-Programm 196 zugeteilt werden, das eine Seite über Befehls-Warteschlangen 196 anfordert. Die Seiten-Anforderung umfasst eine Angabe, dass die Seite zu verriegeln ist. Ein Prozess 202A bis 202C kann explizit eine Seite freigeben, wenn die Verarbeitung innerhalb dieser Seite abgeschlossen ist (z. B. dynamisch zugeteilter Speicher), woraufhin das Exekutive-Programm 196 eine Entriegel-Seite-Mitteilung übertragen kann. Ferner kann eine Seite einem bestimmten Thread innerhalb des Prozesses zugeordnet sein. Eine derartige Seite kann beim Ausstieg des Threads, dem die Seite zugeordnet ist, freigegeben werden. Außerdem kann, wenn ein Prozess zerstört ist, das Exekutive-Programm 196 Entriegel-Seiten-Mitteilungen für jede diesem Prozess zugewiesene Seite übertragen.
Das Exekutive-Programm 196 kann eine globale Mitteilungs-Warteschlange innerhalb der Befehls-Warteschlangen 198 für Erzeuge- und Zerstöre-Prozess- Befehls-Mitteilungen unterhalten, und kann Mitteilungs-Warteschlangen innerhalb der Befehls-Warteschlangen 198 für jeden Thread unterhalten, die Befehls-Mitteilungen für diesen Thread enthalten. Auf diese Art und Weise kann das Exekutive-Programm konfiguriert sein, um Mehrfach-Prozesse/Mehrfach-Thread-Anwendungen zu handhaben. Die Thread-spezifischen Befehls-Mitteilungen können die Verriegelungs- und Entriegelungs-Seiten-Mitteilungen sowie auch Erzeugungs- und Zerstörungs-Mitteilungen für jeden Thread, und Go- und Stopp-Mitteilungen für jeden Thread aufweisen. Demgemäss kann die Prozess-Planung von dem auf dem Computersystem 5 ausgeführten Betriebssystem gehandhabt werden. Die Go- und Stopp-Mitteilungen können verwendet werden, um die Planung durchzuführen. Ferner können die in der Tabelle 140 gezeigten Lese- und Schreibregister-Befehle ebenfalls auf einem Thread durch die Thread-Basis bereitgestellt werden.
In Fig. 15 ist ein Satz von Ablaufdiagrammen gezeigt, die die Arbeitsweise einer Ausführungsform des Exekutive-Programm 196 zeigt. Weitere Ausführungsformen sind möglich und werden in Erwägung gezogen. Bei der Ausführungsform von Fig. 15 veranschaulicht ein Ablaufdiagramm 220 das Rücksetzen der Koprozessor-Karte 22C, ein zweites Ablaufdiagramm 222 einen inaktiven Prozess, und ein drittes Ablaufdiagramm 224 veranschaulicht weitere Aspekte des Exekutive-Programms 196.
Beim Rücksetzen der Koprozessor-Karte 22C (z. B. beim Booten des Computersystems 5) wird das Ablaufdiagramm 220 ausgeführt. Das Exekutive- Programm 196 initialisiert seine Umgebung auf der Koprozessor-Karte 22C (Schritt 226). Beispielsweise kann das Exekutive-Programm 196 den Speicher 194 in einen bekannten Zustand löschen, Seiten-Tabelle für die Benutzung durch den Emulations-Koprozessor 150 erzeugen (und Einträge für die Benutzung des Exekutive-Programm 196 selber initialisieren) und Befehls- Warteschlangen 198 erzeugen. Nach dem Initialisieren des Koprozessors (Schritt 228), ist die Rücksetzprozedur abgeschlossen. Wie es von dem Ablaufdiagramm 222 veranschaulicht wird, führt der inaktive Prozess nichts aus (Schritt 230), bis er unterbrochen wird (z. B. mittels des Empfangs einer Mitteilung in der Befehls-Warteschlangen 198).
Das Ablaufdiagramm 224 veranschaulicht die Arbeitsweise des Exekutive- Programms 196, während Prozesse innerhalb der Koprozessor-Karte 22C aktiv sind. Das Ablauf-Diagramm 224 umfasst verschiedene Eintrittspunkte 232, 234 und 236, abhängig von einer Vielfalt von Ereignissen, die veranlassen können, dass das Exekutive-Programm 196 aufgerufen wird.
Der Eintrittspunkt 232 tritt aus, wenn eine Mitteilung von dem Treiber an die Befehls-Warteschlangen 198 geliefert wird. Der Empfang einer Mitteilung verursacht einen Interrupt des Emulations-Koprozessors 150, wobei zu dieser Zeit das Exekutive-Programm 196 aufgerufen wird. Beim Aufrufen infolge eines Interrupts, verarbeitet das Exekutive-Programm 196 die empfangene Mitteilung (Schritt 238). Eine Vielfalt von Mitteilungen kann empfangen werden. Beispielsweise kann eine Erzeuge-Prozess- oder Erzeuge-Thread-Mitteilung empfangen werden. Bei Empfang einer Erzeuge-Prozess-Mitteilung addiert das Exekutive-Programm 196 einen Prozess zu der Prozess-Liste 200. Ebenso addiert bei Empfang einer Erzeuge-Thread-Mitteilung das Exekutive-Programm 196 einen Thread 204 zu dem Prozess 202, der die Erzeuge-Thread-Mitteilung empfangen hat. Eine Lese-Kontext-Mitteilung (z. B. ein Lese-Register-Befehl) wird von dem Exekutive-Programm 196 durch Lesen des Registers von der diesem Prozess zugeordneten Kontext-Daten-Struktur (und/oder Thread) und Erzeugen einer Antwort-Mitteilung mit der angeforderten Information verarbeitet. Eine Schreib-Kontext-Mitteilung (z. B. ein Schreib-Register-Befehl) wird von dem Exekutive-Programm 196 durch Schreiben des Werts in die ausgewählte Kontext-Daten-Struktur verarbeitet. Das Exekutive-Programm 196 addiert ein Thread zu der Liste von bereiten Tasks in Reaktion auf eine Go-Mitteilung, und entfernt einen Thread aus der Liste von bereiten Tasks in Reaktion auf eine Stopp-Mitteilung. Eine Seite-Verriegelt-Mitteilung (ausgegeben Antwort auf eine vorher von dem Exekutive-Programm 196 gesendete Verriegele-Seite-Mitteilung) wird von dem Exekutive-Programm 196 durch Aktualisieren der Seiten-Tabellen mit einer Übersetzung für die verriegelte Seite und Addieren des Threads, der die Seitenfehler erlebt hat, zu der Liste von bereiten Tasks bedient.
Nach Verarbeiten der Mitteilung wählt das Exekutive-Programm 196 einen Task aus der Liste von bereiten Tasks aus und kehrt zu dem ausgewählten Task zurück (Schritt 240).
Der Eintrittspunkt 234 tritt auf, wenn ein Seitenfehler von einem Task erlebt wird (z. B. ein Prozess-Thread), der von dem Emulations-Koprozessor 150 ausgeführt wird. In Reaktion auf den Seitenfehler sendet das Exekutive-Programm 196 eine Verriegele-Seite-Mitteilung über die Befehls-Warteschlangen 198 (Schritt 242). Der Task, der den Seitenfehler erlebt, wird aus der Liste von bereiten Tasks entfernt, bis die Seite-Verriegelt-Mitteilung für die Seite empfangen wird. Wie es oben erwähnt ist, veranlasst der Empfang der Seite- Verriegelt-Mitteilung, dass der Task zu der List von bereiten Tasks hinzugefügt wird. Nachfolgend wählt das Exekutive-Programm 196 einen Task aus der Liste von bereiten Tasks aus und kehrt zu dem ausgewählten Task zurück (Schritt 240).
Der Eintrittspunkt 236 tritt auf, wenn eine illegale Operations-Code-Trap-Ausnahme von dem Emulations-Koprozessor 150 erlebt wird. Ein vordefinierter illegaler Kooperations-Code wird verwendet, um zu signalisieren, dass in einen Thunk eingetreten wurde (manchmal als ein "BOP" bezeichnet). Das Exekutive-Programm 196 bestimmt, ob der vorbestimmte illegale Operations- Code erfasst wurde (Entscheidungsblock 244). Wenn der vordefinierte illegale Operations-Code nicht erfasst wurde, wird eine Ausnahme-Mitteilung über die Befehls-Warteschlangen 198 gesendet, um den Betriebssystem mitzuteilen, dass eine illegale Operations-Code-Ausnahme für den Task empfangen wurde, der die illegale Operations-Code-Ausnahme erzeugt (Schritt 246). Wenn der vorbestimmte illegale Operations-Code erfasst wurde, wird eine Stopp-Mitteilung gesendet, um den Betriebssystem mitzuteilen, dass der Task infolge eines Übergangs zu dem Host-Code angehalten hat (Schritt 248). In jedem Fall wird der die Ausnahme erlebende Task von der Liste von bereiten Tasks entfernt, und ein bereiter Task wird von der Liste von bereiten Tasks ausgewählt (Schritt 240).

Industrielle Anwendbarkeit

Die vorliegende Erfindung kann bei Computersystemen anwendbar sein. In Übereinstimmung mit der obigen Offenbarung wurde ein Computersystem gezeigt, bei dem ein eine Befehlssatzarchitektur benutzender Emulations-Koprozessor verwendet wird, um Fremd-Anwendungsprogramme auszuführen, die in dieser Befehlssatzarchitektur in einem Computersystem codiert sind, das ein Betriebssystem verwendet, für die die Fremd-Anwendungsprogramme ausgestaltet wurden, das jedoch gemäß einer zweiten Befehlssatzarchitektur codiert ist. Vorteilhafterweise wird die Anzahl von Anwendungsprogrammen, die von dem Computersystem ausführbar sind, erhöht. Außerdem kann die Leistung der Anwendungsprogramme wesentlich größer als diejenige sein, die unter Verwendung von Software-Emulation und/oder binärer Übersetzung erreichbar ist. Außerdem wird die Modellierung von architektonischen Idiosynkrasien eliminiert, das der Emulations-Koprozessor die Architektur verkörpert. Das resultierende Computersystem bildet ein heterogenes Multi-Prozessor- Computersystem.
Zahlreiche Variationen und Modifikationen werden Fachleuten offensichtlich sein, sobald die obige Offenbarung voll gewürdigt ist. Es ist beabsichtigt, dass die folgenden Ansprüche interpretiert werden, um alle derartigen Variationen und Modifikationen zu umfassen.

Claims

1. Vorrichtung für ein Computersystem, mit:

einem ersten Prozessor (48; 152) zum Ausführen erster Befehle, die von einer ersten Befehlssatzarchitektur festgelegt sind, wobei ein von dem Computersystem (5) verwendetes Betriebssystem (84) mittels der ersten Befehle kodiert ist; und

einem mit dem ersten Prozessor (48; 152) gekoppelten zweiten Prozessor (50; 150) zum Ausführen zweiter Befehle, die von einer zweiten Befehlssatzarchitektur, die sich von der ersten Befehlssatzarchitektur unterscheidet, festgelegt sind;

wobei der erste Prozessor (48; 152) zum Ausführen des Betriebssystems (84) vorgesehen ist;

dadurch gekennzeichnet, dass: das Betriebssystem eine Routine aufweist, die ausgeführt wird in Reaktion auf einen Anwenderbefehl zum Starten eines im Betriebssystem (84) auszuführenden Anwendungsprogramms (82), wobei die Routine ein Dateiformat des Anwendungsprogramms (82) analysiert, um zu bestimmen, auf welcher Befehlssatzarchitektur dieses Anwendungsprogramm (82) kodiert ist, wobei, wenn das Anwendungsprogramm (82) auf der zweiten Befehlssatzarchitektur kodiert ist, der zweite Prozessor (50; 150) zum Ausführen des Anwendungsprogramms (82) vorgesehen ist, wobei der zweite Prozessor (50; 150) mit dem ersten Prozessor (48; 152) beim Detektieren einer Benutzung einer Betriebssystem-Routine (94) für das Anwendungsprogramm (82) kommuniziert.

2. Vorrichtung nach Anspruch 1, bei der der erste Prozessor (48) und der zweite Prozessor (50) mit einem oder mehreren Cache-Speichern (44, 46) gekoppelt sind, und bei der sich der erste Prozessor (48) und der zweite Prozessor einen oder mehrere Cache-Speicher (44, 46) teilen.

3. Vorrichtung nach Anspruch 2, bei der der erste Prozessor (48) und der zweite Prozessor (50) mit einer oder mehreren Speicherverwaltungseinheiten (42) gekoppelt sind, und bei der sich der erste Prozessor (48) und der zweite Prozessor (50) die Speicherverwaltungseinheiten (42) teilen.

4. Vorrichtung nach Anspruch 1, 2 oder 3, bei der der erste Prozessor (48; 152) und der zweite Prozessor (50; 150) über ein vorbestimmtes Steuerprotokoll kommunizieren, und bei der das Steuerprotokoll Mitteilungen enthält, die zwischen dem ersten Prozessor (48; 152) und dem zweiten Prozessor (50; 150) transportiert werden, und bei der die Mitteilungen einen Speicher (14) innerhalb des Computersystems (5) durchlaufen.

5. Vorrichtung nach Anspruch 1, 2, 3 oder 4, bei der der zweite Prozessor (50; 150) zum Detektieren der Benutzung der Betriebssystem-Routine durch Ausführen eines bestimmten illegalen Operationskodes vorgesehen ist.

6. Vorrichtung nach Anspruch 5, bei der der erste Prozessor (48; 152) zum Anfordern von Kontextinformationen vom zweiten Prozessor (50; 150), Ausführen der Betriebssystem-Routine (94) und Rückgabe der Steuerung des Anwendungsprogramms (82) an den zweiten Prozessor (50; 150) mittels Kommunikation mit dem zweiten Prozessor (50; 150) vorgesehen ist, und bei der die Kontextinformationen mindestens einen Registerwert von einem Register innerhalb des zweiten Prozessors (50; 150) enthält.

7. Vorrichtung nach einem der Ansprüche 1 bis 6, bei der, wenn das Anwendungsprogramm auf die erste Befehlssatzarchitektur kodiert ist, der erste Prozessor (48; 152) zum Ausführen des Anwendungsprogramms vorgesehen ist.

8. Verfahren zum Ausführen eines Anwendungsprogramms (82), das mittels Befehlen von einer ersten Befehlssatzarchitektur kodiert ist und zur Ausführung innerhalb eines Betriebssystems (84) vorgesehen ist, welches mit Befehlen aus einer zweiten Befehlssatzarchitektur, die sich von der ersten Befehlssatzarchitektur unterscheidet, kodiert ist, mit folgenden Schritten:

Detektieren, dass das Anwendungsprogramm (82) eingeleitet ist, wobei dieses Detektieren von dem Betriebssystem (84) durchgeführt wird, das auf einem ersten Prozessor (48; 152) arbeitet, der zum Ausführen von Befehlen aus der zweiten Befehlssatzarchitektur vorgesehen ist;

Herstellen eines Kontextes für das Anwendungsprogramm (82) in einem zweiten Prozessor (50; 150) zum Ausführen von Befehlen aus einer zweiten Befehlssatzarchitektur; und

Ausführen des Anwendungsprogramms (82) auf dem zweiten Prozessor (50; 150);

dadurch gekennzeichnet, dass

das Detektieren das Analysieren eines Dateiformats des Anwendungsprogramms (82) zum Bestimmen, auf welcher Befehlssatzarchitektur das Anwendungsprogramm (82) kodiert ist, umfasst, wobei das Herstellen in Reaktion auf die Detektierung, dass das Anwendungsprogramm auf die erste Befehlssatzarchitektur kodiert ist, erfolgt.

9. Verfahren nach Anspruch 8, ferner mit folgenden Schritten:

Detektieren eines Übergangs in dem Anwendungsprogramm (82) auf eine Betriebssystem-Routine (94) innerhalb des Betriebssystems (84);

Ausführen der Betriebssystem-Routine (94) auf dem ersten Prozessor (48; 152); und

Zurückkehren zum Anwendungsprogramm (82), das auf dem zweiten Prozessor (50; 150) arbeitet, und zwar nach dem Ausführen der Betriebssystem-Routine (94).

10. Verfahren nach Anspruch 8 oder 9, ferner mit dem Schritt des Ausführens des Anwendungsprogramms (82) auf dem ersten Prozessor (48; 152), der auf das Detektieren anspricht, dass das Anwendungsprogramm auf die zweite Befehlssatzarchitektur kodiert ist.