DE112006002582T5 - Bewirken einer Zusatzspeicherung in einem User-Levelspeicher - Google Patents

Bewirken einer Zusatzspeicherung in einem User-Levelspeicher Download PDF

Info

Publication number
DE112006002582T5
DE112006002582T5 DE112006002582T DE112006002582T DE112006002582T5 DE 112006002582 T5 DE112006002582 T5 DE 112006002582T5 DE 112006002582 T DE112006002582 T DE 112006002582T DE 112006002582 T DE112006002582 T DE 112006002582T DE 112006002582 T5 DE112006002582 T5 DE 112006002582T5
Authority
DE
Germany
Prior art keywords
processor
memory
status information
register
storage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE112006002582T
Other languages
English (en)
Inventor
Per Hillsboro Hammerlund
Martin Portland Dixon
Michael Hillsboro Cornaby
Michael Hillsboro Fetterman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112006002582T5 publication Critical patent/DE112006002582T5/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/461Saving or restoring of program or task context
    • G06F9/463Program control block organisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1438Restarting or rejuvenating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023Failover techniques
    • G06F11/2033Failover techniques switching over of hardware resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Digital Computer Display Output (AREA)

Abstract

Ein Verfahren mit:
Zuordnenen eines Bereichs eines Speichers als Zusatzspeicher für eine architekturale Statusinformation eines Prozessors, wobei die architekturale Statusinformation eine erstreckte Statusinformation aufweist, die einem Betriebssystem (OS) transparent ist, wobei die erstreckte Statusinformation einem erstreckten Prozessormerkmal entspricht, das von dem OS nicht unterstützt wird; und
Speichern der architekturalen Statusinformation in dem Zusatzspeicher über eine Anwendung und ohne OS-Unterstützung.

Description

  • Hintergrund
  • Ausführungsbeispiele der vorliegenden Erfindung betreffen die Datenverarbeitung in einem prozessor-basierten System und insbesondere das Ausführen von Prozessoroperationen, die für ein Betriebssystem (OS) transparent sind.
  • Systeme werden typischerweise aus Hardware- und Software-Komponenten gebildet. Typische Hardware weist einen Prozessor und zugehörige Schaltungen auf, einschließlich Sätze von Chips, Speichern, Eingang/Ausgangs (I/O) Einheiten und dergleichen. Software-Komponenten weisen typischerweise ein OS und grundlegende Eingangs/Ausgangs-System (BIOS) Programme, Treiber auf niedriger Ebene und Applikationen auf höherer Ebene wie Applikationen auf Verwenderebene zum Ausführen von gewünschten Aufgaben, wie Textverarbeitung, Datenbasenverarbeitung, wissenschaftliche Berechnungen und dergleichen auf.
  • Im Allgemeinen ist das OS der Hauptplaner von Aktivitäten des Systems und ist in Kenntnis der verschiedenen Prozesse, die auf dem Prozessor ausgeführt werden. Wenn zusätzliche Merkmale oder Extensionen zu der Hardware wie dem Prozessor zugefügt werden, ist ein OS-Support in durch Treiber oder anderer Software erforderlich, so dass das OS die Ausführung der vergrößerten Hardware beobachten kann. Wenn zusätzliche Prozessormerkmale und Extensionen bei jedem auf dem Prozessor ausgeführten Prozess sichtbar sein müssen, kann das OS eine Virtualisierung des Merkmals oder der Erstreckung auswählen, so dass jeder Prozessor annimmt, dass er seinen eigenen privaten Zugang oder eine Kopie des Merkmals oder der Extension hat.
  • Bei einer Initialisierung eines Prozesses schafft das OS einen Prozesssteuerblock (PCB), der eine Struktur zum Repräsentieren des Prozesses in einer privilegierten Ebene des Speichers (d. h., für Anwendungen auf der Anwenderebene nicht zugänglich) ist. Das PCB kann verschiedene Informationen bezüglich der Prozessausführung beinhalten, wie eine Identifikationsinformation, eine Statusinformation, Registerwerte, Speicherinformation und andere derartige Informationen. Die Schaffung einer solchen Information und die Beibehaltung einer Kohärenz zwischen der Information in dem Prozessor und dem Prozessorsteuerblock, der von dem OS beibehalten wird, ist eine schwierige und bei der Ausführung sensitive Aktivität.
  • Wenn bestimmte Instruktionen zu einer Befehlssatzarchitektur (ISA) zugefügt werden, kann ein zusätzlicher, erweiterter Zustand in einem Prozessor verfügbar sein. Wenn Erweiterungen der Hardware vorgenommen worden sind (beispielsweise eine Prozessorhardware wie Register und dgl.) ist ein OS Support erforderlich. Dieser Support kann in Form von Treibern für den gegenwärtigen OS sein oder neue OS Servicepakete oder zukünftige OS Versionen können einen zusätzlichen Code zum Unterstützen der Erweiterungen aufweisen. Auch ist ein zusätzlicher Speicherraum in einem PCB oder einer anderen OS Datenstruktur immer, wenn ein neues Merkmal zu dem Prozessor hinzugefügt wird, erforderlich.
  • Diese Extensionen können auch eine Auswirkung auf verschiedene Aktivitäten haben, etwa einen Kontextschalter zwischen zwei Prozessen. Wenn es unwahrscheinlich ist, dass der zusätzliche Zustand aufgrund dieser Extensionen bei den meisten Prozessen verwendet wird, kann die OS eine sogenannte träge Speicherung implementieren und Mechanismen speichern, die verwendet werden kann, um die Kontextschalter des zusätzlichen Zustandes aufgrund dieser Extensionen rückzustellen oder manchmal zu eliminieren, wodurch Zeit gespart wird. In einem Prozessorsystem wie einem symmetrischen Multiprozessorsystem (SMP) sind diese Mechanismen problematisch und typischerweise wird ein OS stattdessen eine Vollstatusspeicherung bei einem Kontextschalter ausführen, was ein relativ aufwendiger Vorgang sein kann. Beide Speicherungen erfordern das OS und sind ineffizient.
  • Es besteht daher ein Bedarf an einer verbesserten Weise des Implementierens von Erweiterungen zu der Hardware wie Prozessorextensionen.
  • Kurze Erläuterung der Zeichnungen
  • 1 ist ein Flussdiagramm eines Verfahrens in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 2 ist ein Flussdiagramm eines Verfahrens zum Initialisieren einer Zusatzspeicherung in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 3 ist ein Flussdiagramm eines Verfahrens des Aussonderns einer Aufgabe in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 4 ist ein Flussdiagramm eines Verfahrens zum Ausführen einer Prozessmigration in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 5 ist ein Blockdiagramm eines Prozessors in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 6 ist ein Blockdiagramm eines Abschnitts eines Systems in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 7 ist ein Blockdiagramm eines Systems in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • Eingehende Beschreibung
  • Bei verschiedenen Ausführungsbeispielen kann ein Applikationsspeicher (d. h. ein auf der Verwenderebene zugreifbarer Speicher) zur Speicherung einer Pro-Prozess- oder Pro-Thread-Zustandsinformation eines Prozessors verwendet werden, erfordert also nicht, dass das Betriebssystem (OS) eine Speicherung in seinem PCB oder anderen OS Strukturen vornimmt. Die Statusinformation kann der architekturalen Statusinformation, etwa Steuer- und Konfigurationsregistern, gegenständlichen Register, anderen Steuerstrukturen und dgl. entsprechen. Bei einigen Implementationen kann wenigstens ein Teil dieser Register Register in Vektorgröße sein, die im Wesentlichen breiter sind als die skalaren Register des Prozessors. Auf diese Weise kann das OS ohne Kenntnis eines zusätzlichen Zustands sein, der zu dem Prozessor zugefügt wurde. Weiter kann dieser zusätzliche Zustand durch gesonderte Applikationen ohne jede Interaktion oder Koordination zwischen den Applikationen verwendet werden. Dies wiederum ermöglicht die Verwendung neuer Prozessorextensionen wie eine neue Art von Operationen, Befehlsextensionen oder dgl., bei existierenden Betriebssystemen.
  • Bei der Verwendung von Ausführungsbeispielen der vorliegenden Erfindung kann der Prozessorzustand gespeichert werden und zurückgespeichert werden, ohne Verteiligung des OS. Der Zustand kann N Bytes des Zustands beinhalten, wobei N durch ein gegebenes Prozessormerkmal, das zu implementieren ist, bestimmt werden kann. Weiter kann der hier beschriebene Mechanismus für das Betriebssystem agnostisch und transparent sein und kann eine Zustandsspeicherung und Speicherbetriebe mit höherer Leistungsfähigkeit haben, als wenn das Betriebssystem volle Speicherungen und Rückspeicherungen bezüglich jedes Kontextspeichers durchführt. Zu diesem Zweck haben die Mechanismen einen minimalen Overhead zum Einstellen und zur Verwendung und können durch mehrere Prozesse verwendet werden, ohne ein Erfordernis für das Betriebssystem zum Kontextschalten dieses verwalteten Zustands. Zu diesem Zweck können die Mechanismen einen minimalen Overhead zum Einstellen und zur Verwendung haben und können durch mehrere Prozessoren ohne das Erfordernis für das OS, diesen verwalteten Zustand zu schalten, verwendet werden. Entsprechend können neue Register und Merkmale in einem Prozessor ohne zusätzliche Speicheranforderungen in einen Betriebssystem-Verarbeitungssteuerblock implementiert werden. Mit anderen Worten können Prozessorextensionen, die zusätzliche Hardware, Zustände und/oder Befehle beinhalten können (gemeinsam hier als "Extensionen" bezeichnet) zum Ausführen von neuen Merkmalen oder Funktionen unterstützt werden. Weiter kann jeder Support ohne OS Support vorgesehen werden. Das heißt, derartige Extensionen können in einem Prozessor eingeschlossen werden und eine geeignete Ausführung kann für das OS transparent geschehen. Der Prozessorzustand muss nicht unmittelbar bei einem Übergang der Steuerung auf eine andere Applikation gespeichert werden. Entsprechend kann der Performanceoverhead des beizubehaltenden Zustands minimiert werden und lediglich Kontextschaltungen, die absolut erforderlich sind, werden auftreten. Wenn die Natur der Extension derart ist, dass es vernünftigerweise unwahrscheinlich ist, dass mehrere Prozessoren gleichzeitig unter Verwendung der Extension auftreten, werden Kontextschaltungen für den nächsten Zustand im Allgemeinen vermieden. Das ist besonders vorteilhaft, wenn mehrere erstreckte Zustände nicht verwendet werden oder bei den meisten Anwendungen nicht häufig verwendet werden.
  • Auf diese Weise können erweiterte Extensionen (beispielsweise des Prozessors) auf einer Pro-Thread oder Pro-Prozessor-Basis unter Erfordernis eines minimalen Supports von einem Verwendercode virtualisiert werden, während das gesamte OS transparent ist. Auf diese Weise können Mehrthreads und/oder Prozesse die erweiterten Ressourcen effizient nutzen mit minimalem Overhead bezüglich Kontextänderungen.
  • Typischerweise werden Register, die für die Prozesse innerhalb eines OS verfügbar sind, explizit von der OS während einer Kontextschaltung gespeichert und rückgespeichert. Typischerweise weiß die OS, wo die Zusatzspeicherung für ein Prozessrückregister angeordnet ist, die Hardware weiß dies jedoch nicht. Hier kennt der Prozessor jedoch den Ort der Rückspeicherung nicht und bei einigen Ausführungsbeispielen weiß das Betriebssystem dies auch nicht. Statt explizierter Speicherungen und Rückspeicherungen während einer Kontextschaltung behält die Hardware eine oder mehrere Bits eines Zustands bei die angeben, ob die gegenwärtig authorisierte Kopie eines neuen erstreckten Zustands vorhanden ist, entweder in den Registern der Hardware oder in einer Zusatzspeicherung. Bei einigen Ausführungsbeispielen wird nur ein Statusbit verwendet, um alle erstreckten Zustände darzustellen, die gespeichert und rückgespeichert werden, wie dies von der Hardware benötigt wird. Bei einem anderen Ausführungsbeispiel können die neuen erstreckten Zustände in kleinere Stücke gebrochen werden, die jeweils einen derartigen Statusbit haben. Die Hardware kann dynamisch das Erfordernis zum Speichern oder Rückspeichern eines gegebenen Stücks eines erstreckten Status erkennen, d. h., basierend auf dem Status entsprechend einem der Statusbits und transparent das Speichern oder Rückspeichern, wie erforderlich, ausführen und das Statusbit entsprechend auffrischen.
  • Wenn die Zusatzspeicherung die authorisierte Kopie ist und der Verwender versucht, auf einiges des erstreckten Zustands zuzugreifen, speichert die Hardware transparent den Status in den Registern des Prozessors vor dem Fortschreiten. Diese Aktion könnte einen Seitenfehler bewirken, da das Rückspeichern gegenwärtig nicht erforderlich ist. Alle neuen Befehle, die auf einen solchen erstreckten Status zugreifen, sind spezifiziert, um derartige Aufruffehler zu erlauben.
  • Wenn der Verwender versucht, einiges des erstreckten Status zu modifizieren, verifiziert die Hardware zunächst, dass das Zusatzspeichern gegenwärtig vorhanden ist, beschreibbar und als schmutzig markiert ist.. Wenn dies nicht der Fall ist, wird der zugehörige Seitenfehler signalisiert. Auf diese Weise werden alle neuen Befehle, die einen solchen erstreckten Status modifizieren können, spezifiziert, um solche Seitenfehler zu erlauben. Wenn die Verifikation stattfindet, kann der Prozessor ein positives Ergebnis zwischenspeichern, bis bestimmte Ereignisse auftreten, wodurch das Erfordernis für häufige Verifikationen vermieden wird. Als ein Nebeneffekt einer solchen Verifikation entdeckt der Prozessor eine physikalische Übersetzung der virtuellen Adresse, die der Verwender für das Zusatzspeichern gegeben hat, die physikalische Übersetzung kann von der Hardware rückgehalten werden und wie unten beschrieben verwendet werden.
  • Wenn der Verwender versucht, einiges des erstreckten Status zu modifizieren, stellt der Prozessor bei einigen Ausführungsbeispielen die Zugehörigkeit der entsprechenden Zwischenspeicherleitungen in dem Zusatzspeicher sicher. Die Methode, dies zu tun, variiert in Abhängigkeit von der Natur des betroffenen Speichersystems.
  • Bei einigen Ausführungsbeispielen sind eines oder mehrere schmutzige Bits mit Stücken des erstreckten Status zugehörig. Derartige schmutzige Bits werden bereinigt, wenn Werte von dem Zusatzspeicher rückgespeichert werden und wenn Werte zurück in den Zusatzspeicher gesichert werden. Derartige schmutzige Bits werden immer dann gesetzt, wenn Befehle ausgeführt werden, die die Werte der entsprechenden erstreckten Register ändern.
  • Immer wenn die authorisierte Kopie des erstreckten Zustands in dem bzw. den Registern des Prozessors vorhanden sind und dieses schmutzig ist, ist immer eine gültige physikalische Übersetzung der gegenwärtigen Rückspeicherung, die in dem Prozessor gespeichert ist, vorhanden. Der Prozessor kann auf Speichertransaktionen, die sich auf diese Adressen beziehen, antworten. Der Prozessor kann auf eine Speicherleseanforderung mit Werten, die in den Registern gespeichert sind, antworten. Die Register wirken so im Wesentlichen als ein spezialisierter Zwischenspeicher, der lediglich den Speicher puffert, der als Zusatzspeicher verwendet wird. Für jede Cachelinie, die in dem Zusatzspeicher vorhanden ist, behält der Prozessor so den Zwischenspeicherstatus bei, der erforderlich ist, immer wenn das Speichersystem in dem System vorhanden ist.
  • Der Ort des Zusatzspeichers kann möglicherweise durch verschiedene Ereignisse geändert werden. In einigen Ausführungsbeispielen kann der Verwender ausdrücklich den Ort wechseln. Bei einigen Ausführungsbeispielen kann das OS den Zusatzspeicherzeiger kennen und kann diesen als Teil einer Kontextschaltung ändern. Da der Zeiger des Zusatzspeichers eine virtuelle Adresse sein kann, kann jede Änderung des Adressraums möglicherweise die physikalische Übersetzung des Zusatzspeichers ändern. Unmittelbar vor jedem dieser Ereignisse kann die authorisierte Kopie des erstreckten Status in einem Zusatzspeicher oder in den Registern des Prozessors vorhanden sein. Wenn die authorisierte Kopie in einem Zusatzspeicher ist, ist keine weitere Aktion erforderlich, wenn der Zeiger geändert wird. Wenn die authorisierte Kopie in den Registern des Prozessors vorhanden ist und nicht als schmutzig markiert ist, ist wiederum keine weitere Aktion erforderlich. Wenn die authorisierte Kopie in den Registern des Prozessors ist und als schmutzig markiert ist, können einige Ausführungsbeispiele, die den schmutzigen Status aus dem Zusatzspeicher sichern. Andere Ausführungsbeispiele können ein Mittel zum Unterdrücken dieser Statussicherung und möglicherweise deren Elimination bewirken. Beispielsweise könnte eine Implementation das Erlauben des Zeigens auf eine virtuelle Adresse auf den aufzufrischenden Zusatzspeicher wählen, jedoch ist die physikalische Übersetzung nicht weiterhin in Synchronisation mit dem neuen Zeiger. Solange keine Versuche gemacht werden, auf den neuen erstreckten Status zuzugreifen, wirken die alte physikalische Übersetzung und die erstreckten Register weiterhin als „normale" Zwischenspeicher für Zwischenspeicherlinien, die sie mappieren, entsprechend einem jedem Prüfvorgang und dergleichen. Diese Register oder Cachelinien können ungültig gemacht werden durch einen normalen Cacheverkehr, wenn ein anderer Agent das Eigentum übernimmt. Wenn ein nachfolgender Versuch gemacht wird, auf den erstreckten Status zuzugreifen, wird der gegenwärtige Rückspeicherzeiger übersetzt (wie oben angegeben) und dann mit der alten physikalischen Übersetzung verglichen. Wenn diese dieselben sind und der erstreckte Statuszwischenspeichertag noch gültig ist, ist keine Statusspeicherung oder Rückspeicherung erforderlich, diese werden vollständig eliminiert und die Bits werden gesetzt zum Angeben, dass die authorisierte Kopie in den Registern gespeichert ist. Wenn die Übersetzungen jedoch nicht übereinstimmen, werden die „Zwischenspeicherlinien", die noch gültig sind, in das Speicher geladen, bevor die neue Übersetzung verwendet wird, um die entsprechenden Registerwerte aus dem neuen Zusatzspeicher zu gewinnen.
  • Als eine beispielhafte Implementation kann eine Registerstatusinformation, die von einem Prozessor verwendet wird, einen Zusatzspeicher haben, der an einem von dem Verwender spezifizierten Ort an einem Seitenspeicher auf der Verwenderebene angeordnet ist. Während des Vorgangs der Initialisierung kann der Zusatzspeicherbereich angefordert werden, beispielsweise von dem OS als ein zugeordneter Block in dem Speicher. Während dieser Bereich von dem OS angefordert wird, ist das OS sich der Verwendung dieses Bereichs als ein Zusatzspeicher nicht bewusst. Der Verwender spezifiziert die Adresse dieses Speichers durch Setzen eines Registers zum Hinweisen auf diesen. Bei einigen Ausführungsbeispielen wird das Register gespeichert und von dem OS rückgespeichert als Teil einer normalen Kontextumschaltung, andere Ausführungsbeispiele existieren, die diese Anforderung nicht haben.
  • Es sind so zwei Orte, an denen Kopien des erstreckten Status vorhanden sein können: in den erstreckten Registern selbst und (unter der Annahme, dass der Verwender einen Zeiger vorgesehen hat) in dem Zusatzspeicher. Immer wenn der Zeiger auf den Zusatzspeicher gesetzt ist, wird die authorisierte Kopie des Status verstanden als in dem Zusatzspeicher. Jeder Versuch den neuen erstreckten Status zu verwenden oder auf diesen zuzugreifen, wird deren transparentes Laden in das Register verursachen.
  • Vor jeder Verwendung des erstreckten Status prüft der Prozessor, dass die Seiten des Speichers vorhanden sind und beschreibbar und als schmutzig markiert sind, wie dies von dem OS gesehen wird. Wenn über ein Aufrufsystem auf den Verwenderspeicher zugegriffen wird, erinnert sich der Prozessor der Übersetzung der Verwenderseite, die erforderlich sind zum Halten des neuen Zustands. Dies kann als eine besondere Aufgabe eines Übersetzungs-Nebenpuffers (TLB) angesehen werden. Nachdem diese Prüfung erfolgt ist und bis der Prozessor normalerweise einen solchen TLB-Eingang fallenlassen oder löschen müsste, kann der Prozessor einen ungehinderten Zugang auf den neuen Zustand und neue Merkmale erlauben. Bei einigen Ausführungsbeispielen kann der Prozessor einen neuen/erstreckten Status erlauben zu ändern unberücksichtigt der Beibehaltung der Konsistenz mit dieser Zusatzspeicherung. Durch ein solches vernachlässigen der Kohärenzanforderungen können bestimmte Vorteile bei einer gegebenen Implementation erreicht werden. Bei einigen Ausführungsbeispielen kann der Prozessor sowohl den Zeiger auf den Zusatzspeicher (eine lineare oder virtuelle Adresse) und die übersetzte physikalische Adresse in einer Struktur ähnlich einer TLB beibehalten. Auch bei einer Änderung des Schutzniveaus (CLP) kann der Prozessor jedoch auf Prüfungen dieses Bereichs mit geeigneten Antworten in Abhängigkeit von dem Status der Statusinformation (beispielsweise schmutzige oder bereinigte) Antworten. Bei einer CPL Änderung in einer Intel Architektur (IA-32) Umgebung kann die OS Schreiberlaubnisse auf eine gegebene Seite (beispielsweise das Speichern einer Rückspeicherung) ungültig machen und so unter der Annahme eines mehr privilegierten Status in einem weniger privilegierten Status (beispielsweise von dem OS auf eine Anwendung) prüft der Prozessor wieder, dass die Seiten des Speichers vorhanden und beschreibbar sind.
  • Es wird jetzt auf 1 Bezug genommen, die ein Flußdiagramm eines Verfahrens in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Wie in 1 gezeigt, kann ein Verfahren 10 eine Technik zum Erzeugen und Verwenden einer Rückspeicherung in einem Anwendungsspeicher auf der Verwenderebene implementieren. Wie in 1 gezeigt, kann das Verfahren 10 durch Anforderung einer Adresse für einen Zusatzspeicher anfordern (Block 20). Beispielsweise kann eine Anwendung, die auf einem Prozessor ausgeführt wird, einen Speicherbereich von einer OS anfordern. Die Anforderung eines Speicherbereichs kann ähnlich sein jeder Anwendungsanforderung für eine Speicheranwendung. In Antwort auf diese Anforderung kann das OS eine Anfangsadresse für den Speicherbereich übersenden, beispielsweise einen linearen Zeiger zu einem seitenweisen Speicher.
  • Obwohl dies in 1 nicht gezeigt ist, kann die Anwendungsanforderung an den Zusatzspeicher von einem OS bewirkt werden zum Ersetzen eines gegenwärtig laufenden Prozesses. Der gegenwärtig laufende Prozess kann ebenfalls ein Rückspeichern in einem Speicher auf der Verwenderebene haben. Unterschiedliche Weisen des Zugriffs auf das Zusatzspeichern der Anwendung (wenn dies eine hat) können bewirkt werden. Bei einigen Implementationen kann das Zusatzspeichern unter Verwendung eines festen Zeigers erfolgen, d. h., einem Zeiger, der in einem durch Konvention bestimmten Ort. gespeichert ist. Der Zeiger kann beispielsweise ein gegebener Offset in einem Speicher eines privaten Threads sein, der erreicht werden kann über, beispielsweise, ein maschinenspezifisches Register (MSR). Bei einem anderen Ausführungsbeispiel kann ein Zeiger auf einen Zusatzspeicher in Verbindung mit anderer Statusinformation, die Gegenstand eines OS implementierten Speicherung/Rückspeicherung Vorgangs ist, etwa einem Fließpunktstatussicherungsvorgang (FXSAVE), gehandhabt werden. Alternativ kann die Adresse des Zusatzspeichers in einem OS Prozesssteuerblock gespeichert sein. Bei derartigen Ausführungsbeispielen ist keine OS Modifikation oder eine minimale Modifikation erforderlich, um eine Speicherung eines Zeigers auf einen Zusatzspeicher zu ermöglichen, wie oben beschrieben.
  • Es wird jetzt wieder auf 1 Bezug genommen. Bei einer CPL Änderung zum Implementieren dieser Kontextschaltung kann die Adresse des Zusatzspeichers des gegenwärtig laufenden Prozesses gesichert werden. Weiter kann das OS den neuen Vorgang bestimmen (beispielsweise der Anwendung) und ebenfalls die Anfangsadresse des neuen Zusatzspeichers bestimmen, beispielsweise in einem Zeiger in dem Prozessor. Zu diesem Zeitpunkt kann der Prozessor die vorherigen Prozessdaten zurück in den Zusatzspeicher, die diesem Prozess zugehörig sind, speichern. Entsprechend ist der Prozessor jetzt fertig, den neuen Prozess, der mit dieser Anwendung verbunden ist, auszuführen.
  • Es wird jetzt weiter auf 1 Bezug genommen. Die nächste Prozessorstatusinformation kann in den Zusatzspeicher gespeichert werden (d. h., in den Anwendungsspeicher auf der Verwenderebene) (30). Insbesondere können verschiedene Prozessorstatusinformationen einschließlich einer Steuerinformation und Daten zur Verwendung in einem gegebenen Prozess in den seitenweise aufgebauten Speicher geladen werden. Zunächst kann die Prozessorstatusinformation in dem seitenweise aufgebauten Speicher in den Prozessor geladen werden (Block 40). Das heißt, verschiedene Informationen, die in dem Zusatzspeicher vorhanden sind, können in bestimmte Konfigurationsregister und Datenregister des Prozessors geladen werden. Unter Verwendung dieser Information können Erstreckungen jetzt von der Anwendung während der Ausführung verwendet werden (Block 50). Ein solcher Betrieb kann fortgesetzt werden, bis die Anwendung oder der Prozess abgeschlossen ist oder bis eine andere Aktivität auf dem Prozessor, beispielsweise von dem OS, bewirkt wird. Solange die gegenwärtige Anwendung oder der gegenwärtige Prozess ausgeführt wird, können die Prozessorstatusinformation in dem Prozessor und dem Zusatzspeicher inkoherent beibehalten werden. Das heißt, die Prozessorstatusinformation in dem Prozessor kann modifiziert werden, ohne dass derartige Änderungen zurück in den Zusatzspeicher in dem Speicher geschrieben werden.
  • Wenn sich dagegen ein privilegiertes Niveau ändert, beispielsweise wenn die Steuerung von einem Anwendungsprogramm zurück zu dem OS übergeht, bleibt die Konsistenz zwischen der Prozessorstatusinformation in dem Prozessor und in dem Zusatzspeicher erhalten (Block 60). Das tritt dann auf, wenn Modifikationen in der Prozessorstatusinformation auf einem unterschiedlich privilegierten Niveau ausgeführt wird, die schmutzigen Daten können zurück in den Speicher geschrieben werden und insbesondere in den Zusatzspeicher, um die Konsistenz beizubehalten. Bei verschiedenen Ausführungsbeispielen können verschiedene Arten des Beibehalten der Konsistenz implementiert werden.
  • Wenn ein privilegiertes Niveau von einem höher privilegierten Niveau auf ein geringer benötigtes Niveau ändert, wenn beispielsweise die Steuerung von dem OS zurück zu der Anwendung übergeben wird, muss das Vorhandensein der Rückspeicherung in dem Speicher verifiziert werden. Das heißt, die Speicherseite oder die Seiten, auf der die Anwendung eine Rückspeicherung hat, muss in dem Speicher vorhanden sein und von der Anwendung beschreibbar sein. Bei bestimmten Implementationen kann es erforderlich sein, zu prüfen, dass das Rückspeichern vorbereitet ist und vor der Verwendung etwaiger Erstreckungen oder Befehle, die den neuen Status benutzen initialisiert wird.
  • Bei verschiedenen Implementationen kann dann, wenn ein Prozess initiiert wird, der bestimmte Prozessor Erstreckungen oder -befehle verwenden und insbesondere dann, wenn solche Erstreckungen oder Befehle nicht von der gegebenen OS unterstützt werden, eine Rückspeicherung auf Verwenderebene eingestellt werden und verwendet werden zum Implementieren derartiger Erstreckungen und Instruktionen, ohne dass OS zu involvieren. Es wird jetzt auf 2 Bezug genommen. Diese zeigt ein Flußdiagramm eines Verfahrens zum Initialisieren einer Sicherungsspeicherung in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung. Wie in 2 gezeigt, kann das Verfahren 100 mit dem Ausführen eines Prozesses A (Block 110) beginnen. Bei dem Initiieren der Ausführung dieses Vorgangs kann es bestimmen, ob der Prozess einen oder mehrere Prozessormerkmale (beispielsweise Extensionen) verwenden muss (Raute 115). Als ein Beispiel, kann eine Prozessorerstreckung ein Vektor sein, der Single Instruction Multiple Data (SIMD) Extension (VSSE) sein. Ein solcher VSSE-fähiger Prozessor kann zusätzliche oder erstrecktere Register aufweisen zum Behandeln von Vektorbefehlen, wie dies weiter unten diskutiert werden wird. Falls nicht, kehrt die Steuerung zum Block 110 zurück und der Prozess A setzt die Ausführung fort. Wenn stattdessen in der Raute 115 bestimmt wird, dass neue Prozessormerkmale zu verwenden wird, geht die Steuerung zum Block 120 weiter. Dort kann die Anwendung eine gegebene Anzahl von Seiten des Speichers OS anfordern, beispielsweise N Bytes (Block 120). Die OS kann wiederum einen linearen Zeiger zu der Anwendung senden, der einen Startort der zugeordneten Seite des Speichers angibt. Bei verschiedenen Implementationen können die Anforderungen des OS in dem OS auftreten wie jede andere Anforderung an Speicher durch eine Anwendung. Das heißt, das OS kann bezüglich der Sicherungsspeicherung und deren Verwendung mit verschiedenen Prozessorerweiterungen unwissend bleiben.
  • Es wird weiterhin auf 2 Bezug genommen. Die Applikation kann nachfolgend den Prozessor instruieren, den Zeiger zu verwenden, der von dem OS vorgesehen ist als eine Sicherungsspeicherung für einen Statussicherungsbereich (Block 125). Weiter kann bei dem Block 125 der Sicherungsspeicher selbst mit der vorhandenen Prozessorstatusinformation geladen werden. Während die Prozessorstatusinformation verschiedene Formen annehmen kann, kann bei einigen Ausführungsbeispielen diese Statusinformation den Status von verschiedenen Steuerregistern und anderen Steuerstrukturen des Prozessors einschließen, als auch die Werte von bestimmten Registern, beispielsweise Registern mit erstreckten Längen, etwa Vektorlängenregistern in einem Prozessor, der Vektoroperationen unterstützt. Nachfolgend können der Zeiger und eine Übersetzung (d. h. eine physikalische Übersetzung) für den Speicherort in dem Prozessor gespeichert werden (Block 130). Beispielsweise kann die Übersetzung in einem Speicherort des Prozessors gespeichert werden, etwa einem Übersetzungspuffer, einem Tagort oder dgl.
  • Nachfolgend kann der Prozessor diesen Status lesen, der in dem Sicherungsspeicher vorhanden ist und diesen zurück in den Prozessor laden (Block 135). Entsprechend wird die gewünschte Statusinformation jetzt in den Prozessor geladen und eine weitere Ausführung der Applikation oder des Prozesses ist möglich. Die Ausführung des Prozesses kann so fortgesetzt werden. Während der Ausführung kann bestimmt werden, ob eine Änderung des privilegierten Niveaus vorliegt, beispielsweise des gegenwärtigen Schutzniveaus (CPL) (Raute 140). Falls nicht, werden Änderungen der Prozessorstatusinformation, die als Ergebnis der Ausführung des gegenwärtigen Prozesses oder einem anderen Prozess, der dasselbe privilegierte Niveau hat, auftreten, nicht zurück in den Speicher geschrieben. Es wird, mit anderen Worten, keine Konsistenz zwischen den Prozessorstatusinformation und dem Prozessor und dem Sicherungsspeicher (Block 145) beibehalten.
  • Wenn in der Raute 140 statt dessen bestimmt wird, dass das privilegierte Niveau sich geändert hat, geht die Steuerung zu der Raute 150 über. Dort kann während der Ausführung des neuen Vorgangs mit dem unterschiedlichen Privilegierungsniveau der Prozessor bestimmen, ob es eine Suchanforderung für eine oder mehrere Prozessorstatusorte erhält (Raute 150). Falls nicht, tritt eine kontinuierliche Ausführung des neuen Vorgangs in eine Schleife mit der Raute 150 auf. Wenn jedoch eine Suchanforderung für einen Ort der Prozessorstatusinformation empfangen wird, kann es nachfolgend bestimmen, ob der Treffer für einen schmutzigen Ort (Raute 155) vorliegt. Wenn der Suchort nicht schmutzig ist (das heißt bereinigt ist), bedeutet dies, dass der Zustand des Registers und der Zustand des Speichers als kohärent bekannt sind, eine Trefferantwort kann ausgesendet werden (Block 160) und die weitere Ausführung des neuen Vorgangs kann über eine Schleife zurück zu der Raute 150 fortgesetzt werden.
  • Wenn statt dessen in der Raute 155 die Suchanforderung einen schmutzigen Ort trifft, bedeutet dies, dass der Zustand des Registers und der Zustand des Speichers nicht als kohärent bekannt sind, die Steuerung geht zum Block 170 über. Dort wird eine Suchantwort mit den schmutzigen Daten (Block 170) ausgesendet. Bei einigen Implementationen kann der schmutzige Ort auch zurück in den Speicher geschrieben werden und insbesondere in den Sicherungsspeicher. Bei einigen Ausführungsbeispielen können Daten, die in den Rückspeicher (d. h. den Speicher) über entweder einen Mikrocodemechanismus oder einen Hardwaremechanismus geliefert werden. Auf diese Weise kann die Kontextschaltkonsistenz zwischen der Prozessorstatusinformation und der Sicherungsspeicherung erhalten werden. Entsprechend wirkt die Prozessorstatusinformationsspeicherung in dem Prozessor als ein Zwischenspeicher. Zu diesem Zweck kann bei verschiedenen Implementationen ein Prozessor einen zusätzlichen Suchfilter aufweisen, (wenn ein Suchfilter bereits vorhanden ist), um die eingehenden Suchanforderungen für diese Prozessorzustandsorte zu behandeln. Weiter können die Prozessorstatusorte erweitert werden mit einem oder mehreren Indikatoren zum Angeben des Vorhandenseins von gültigen und/oder schmutzigen Daten, obwohl der Schutzbereich der vorliegenden Erfindung nicht entsprechend eingeschränkt ist.
  • Bei der Verwendung von Ausführungsbeispielen der vorliegenden Erfindung können Sicherungsspeicherdaten auf ein unteres Niveau einer Speicherhierarchie (beispielsweise einer Disk) ausgelagert werden auf einem Aufgabenumschalter von einem Prozess unter Verwendung des Rückspeicherns zu einem unterschiedlichen Prozess bewirkt von einem OS werden. Es wird jetzt auf 3 Bezug genommen. Hier ist ein Flußdiagramm des Auslagerns einer Aufgabe in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung gezeigt. Wie in 3 gezeigt, kann das Verfahren 200 verwendet werden zum Implementieren eines Prozessors, der Prozessorextensionen benutzt, der den Vorteil einer Sicherungsspeicherung nutzt. Wie in 3 gezeigt, kann das Verfahren 200 mit dem Ausführen eines Prozesses (beispielsweise dem Prozess A) auf dem ersten Prozessor (Block 210) beginnen. Für dieses Ausführungsbeispiel kann angenommen werden, dass der Prozess A eine oder mehrere Prozessorextensionen verwendet und entsprechend eine Rückspeicherung in einem Anwendungsspeicher auf der Verwenderebene beibehält.
  • Es wird weiterhin auf 3 Bezug genommen. Nachfolgend kann das OS eine unterschiedliche Anwendung für den Prozessor A (Block 215) bestimmen. Weiter kann das OS Speicher entsprechend dem ersten Vorgang aus der Disk aufrufen (Block 220). Entsprechend kann das OS einen direkten Befehl für einen direkten Speicherzugriff (DMA) an einen DMA-Agenten senden, beispielsweise einen Diskdrivecontroller. Der DMA-Agent kann wiederum das Auslesen des Speichers beginnen, der zurück auf die Disk zu schreiben ist (Block 250). Der DMA-Agent kann solche Lese- und Schreibvorgänge fortsetzen, bis es eine Seite eines Speichers erreicht, die für eine Sicherungsspeicherung verwendet wird (Block 260). Wenn eine derartige Seite erreicht wird, kann der Agent wie bei anderen nicht-kohärenten Speicherstrukturen, eine oder mehrere Anforderungen für das Eigentum (RFO) an den ersten Prozessor senden. Entsprechend kann der erste Prozessor die Prozessorstatusorte innerhalb des Prozessors während des Ablaufs des Ausführen seines anderen (d. h., neuen) Prozesses (Block 225) suchen. Der Prozessor kann die Prozessorstatusorte als zugreifbare Speicherorte behandeln und diese können von dem Prozessor als ein üblicher Zwischenspeicher gesucht werden.
  • Basierend auf den Suchergebnissen kann bestimmt werden, ob ein Treffer an einem Ort in dem Prozessor auftritt (Raute 230). Beispielsweise kann ein spezialisiertes Suchfilter in dem Prozessor verwendet werden, um an diesen Statusspeicherorten in dem Prozessor Suchvorgänge auszuführen. Wie oben beschrieben, können solche Orte mit einem oder mehreren Indikatoren zum Angeben ihres Status (d. h., gültig, schmutzig oder dgl.) ausgedehnt werden. Wenn bei Raute 230 kein Treffer vorliegt, tritt ein Fehler auf und die Steuerung kann zurück zu dem DMA-Agenten übergeben werden, wie dies weiter unten beschrieben werden wird. Wenn ein Treffer aufgetreten ist, kann danach bestimmt werden, ob der Treffer einem schmutzigen Ort entspricht (Raute 235). Wenn der Ort, der dem Treffer entspricht, nicht schmutzig ist, wird eine Trefferantwort ausgesendet und die Steuerung kann zurück zu dem DMA-Agenten übergeben werden. Wenn stattdessen bei der Raute 235 bestimmt wird, dass ein Treffer an einem schmutzigen Ort auftritt, kann der erste Prozessor die schmutzigen Daten von dem Statusspeicher in dem Prozessor (beispielsweise in einem Registerfile) an den Sicherungsspeicher in dem Speicher (Block 240) bewegen.
  • Bei einigen Implementationen kann der Prozessor eine oder mehrere Antworten an den DMA-Agenten (beispielsweise eine treffermodifizierte (HITM) Antworten) aussenden, die den modifizierten Speicherort identifizieren, als auch die schmutzigen Daten zu dem DMA-Agenten liefern. In jedem Fall kann, wenn schmutzige Daten für den DMA-Agenten zugängig sind (entweder direkt oder über den Sicherungsspeicher) der DMA-Agent das Schreiben des in Seiten aufgebauten Speichers auf eine Disk (Block 270) vollenden.
  • Block 270 wird auch ausgeführt, wenn die Orte des Sicherungsspeicherns das Suchfilter verfehlen (oder nicht schmutzig sind), und unter Übernehmen der Steuerung von den Rauten 230 und 235, wie oben diskutiert. Obwohl bei dieser besonderen Implementation des Ausführungsbeispiels von 3 beschrieben worden ist, versteht es sich, dass der Schutzbereich der vorliegenden Erfindung nicht entsprechend eingeschränkt ist.
  • Bei einigen Implementationen kann der Vorgang, der auf dem ersten Prozessor ausgeführt wird, auf einen zweiten Prozessor übergeben werden, beispielsweise wie von einem OS bestimmt. Wenn der Prozess erweiterte Prozessorressourcen benötigt und die Verwendung eines Sicherungsspeichers kann die Sicherungsspeicherung zu dem zweiten Prozessor zurückgespeichert werden für eine geeignete Operation auf dem zweiten Prozessor. Es wird jetzt auf 4 Bezug genommen. Hier ist ein Flußdiagramm eines Verfahrens zum Durchführen einer Prozessübergabe in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt. Wie in 4 wiedergegeben ist, kann das Verfahren 300 durch Ausführen eines Prozesses (beispielsweise des Prozesses A) auf einen ersten Prozessor unter Verwendung von erweiterten Register beginne, beispielsweise (Block 310). Nachfolgend kann das OS eine unterschiedliche Anwendung für den ersten Prozessor bestimmen (Block 315).
  • In dem Block 320 bestimmt das OS einen Prozess B, der nicht die erweiterten Register verwendet. Weiter bestimmt das OS die Übergabe eines Vorgangs A auf einen zweiten Prozessor. Entsprechend wird, wie in 4 gezeigt, ein Prozess A veranlasst, die Ausführung auf den zweiten Prozessor zu beginnen (Block 355). Bei einem Ausführungsbeispiel kann ein Zeiger auf den Sicherungsspeicher durch das OS während eines Statussicherungsvorgangs gesichert werden, beispielsweise einem Fließzustandssicherungsvorgang (FXSAVE). Zum Implementieren der Ausführung eines Prozesses A kann der Kontext für den Vorgang A zu einem zweiten Prozessor rückgespeichert werden (360). Bei dem beschriebenen Ausführungsbeispiel des Kontextes in dem Sicherungsspeicher kann zu dem zweiten Prozessor ohne OS-Unterstützung rückgespeichert werden, beispielsweise ein Fließpunkt-Rückspeicherungsvorgang (beispielsweise RXRSTR). Daten in der Rückspeicherung können daher zu den Prozessorstatusregistern des zweiten Prozessors ermittelt werden.
  • Während der Ausführung des Prozesses A auf dem zweiten Prozessor können ein oder mehrere RFO von dem zweiten Prozessor ausgegeben werden (Block 365) wenn erstreckt Register verwendet werden. Das heißt, während der Ausführung des Prozesses B kann eine Registerstatusinformation bei einem Anforderungszugriff zu den Registern über einen Zwischenspeicherkohärenzmechanismus aufgenommen werden, zum Beispiel. Entsprechend kann der zweite Prozessor eine oder mehrere Anforderungen für die Zugehörigkeit (RFO) zu dem ersten Prozessor aussenden. Entsprechend kann der erste Prozessor die Prozessorstatusorte innerhalb des Prozessors während des Ablaufs der Ausführung des anderen (beispielsweise neuen Vorgangs) (Block 325) suchen.
  • Basierend auf den Suchergebnissen kann bestimmt werden, ob ein Treffer an einem Ort in dem Prozessor auftritt (Raute 330). Wenn nicht, kann eine Fehlermeldung an den zweiten Prozessor übermittelt werden und die Steuerung in dem zweiten Prozessor geht in den Block 370 über, wie unten diskutiert. Wenn stattdessen bei der Raute 330 ein Treffer auftritt, kann sodann bestimmt werden, ob der Treffer einem schmutzigen Ort in dem Prozessor entspricht (Raute 335). Es kann, beispielsweise, wie oben beschrieben, ein spezialisiertes Suchfilter in dem Prozessor verwendet werden, um die Prozessorzustandsorte zu suchen. Wenn der Ort bereinigt ist, wird eine geeignete Antwort an den zweiten Prozessor gesendet und die Steuerung in dem zweiten Prozessor wird an den Block 370 übergeben. Wenn stattdessen bei der Raute 335 bestimmt wird, dass ein Treffer an einem schmutzigen Ort vorliegt, kann der erste Prozessor die schmutzigen Daten von dem Zustandsspeicher (beispielsweise einem Registerfile) in dem ersten Prozessor zu dem Sicherungsspeicher in einem Speicher bewegen (Block 345). Weiter kann der erste Prozessor eine oder mehrere Antworten an den zweiten Prozessor aussenden (beispielsweise hitmodifizierte (HITM) Antworten), die den modifizierten Speicher angeben und bei einigen Implementationen können auch die schmutzigen Daten an den anfordernden Agenten übergeben werden (beispielsweise den zweiten Prozessor).
  • Nach dem Verarbeiten der Suchantworten kann der erste Prozessor die Ausführungen des Prozesses B (Block 350) fortsetzen. Weiter kann der zweite Prozessor die Ausführung des Prozess A (Block 370) fortsetzen. Entsprechend schließt der Prozess A auf dem zweiten Prozessor ab (Block 375).
  • Bei einigen Implementationen kann ein Prozess ausgeführt werden unter Verwendung mehrerer Threads oder Sub-Prozessoren. Um die Verwendung von erstreckten Registerstatusinformationen in derartigen mehreren Threads oder Sub-Prozessen zu ermöglichen, können eine oder mehrere zusätzliche Speicherräume in dem Anwendungsspeicher vorgesehen sein. Das heißt, ein Sub-Prozess eines gegenwärtig laufenden Prozesses kann eine gesonderte Zusatzspeicherung von dem OS verlangen, um eine Wiederholung der Zusatzspeicherungsinformation zu ermöglichen, was es erlaubt, beide Prozesse ungestört fortzusetzen. Auf diese Weise können beide Threads einen eigenen Satz von Registerzuständen haben, um einen Fehlerzustand zu vermeiden.
  • Ausführungsbeispiele können in vielen unterschiedlichen Prozessorarchitekturen implementiert werden. Es wird jetzt auf 5 Bezug genommen, die ein Blockdiagramm eines Prozessors in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Wie in 5 gezeigt, weist der Prozessor 400, der ein mehrstufiger Vektorprozessor sein kann, verschiedene Strukturen zur Verwendung mit einem Zusatzspeicher in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung aufweist.
  • Wie in 5 gezeigt, kann der Prozessor 400 eine Pipeline aufweisen, die einen Umbenenner 410 aufweist, der verwendet werden kann, um Instruktionsbytes in Instruktionen analysieren und etwaige Prefixe decodieren kann. Weiter kann der Umbenenner 410 Befehle in Mikrooperationen (μops) decodieren und weiter Registerreferenzen mit den μops von der logischen Repräsentation in eine physikalische Repräsentation umbezeichnen. Obwohl dies in 5 nicht gezeigt ist, versteht es sich, dass verschiedene frontseitige Komponenten eines Prozessors vor dem Umbenenner 410 gekoppelt sein können. Derartige frontseitige Komponenten können einen Instruktionnscache und Kontrollstufen aufweisen, neben anderen derartigen Komponenten.
  • Es wird weiter auf 5 Bezug genommen. Umbenannte Befehle können an einen Planer 420 geliefert werden, der die notwendigen Daten für den Befehl (beispielsweise Quellenoperanden) beinhalten kann und diese zu einem Registerfile 430 liefert, das eine Mehrzahl von physikalischen Registern aufweisen kann. Derartige Register können Register mit normaler Breite beinhalten als auch bei manchen Ausführungsbeispielen Register mit einer erstreckten Länge. Ein repräsentatives Register 435 ist in 5 gezeigt. Das Register 435 kann beispielsweise ein Register mit erstreckter Länge haben, beispielsweise zur Verwendung bei Vektoroperationen. Ein Register mit erstreckter Länge kann unterschiedliche Formen annehmen. Beispielsweise kann eine Mehrzahl von Vektorregistern eine größere Breite haben als die normale Datenbreite der Pipeline, beispielsweise 256 Bits oder eine andere derartige Anzahl. Bei anderen Implementationen kann ein Vektorregister eine erstreckte Länge haben, die eine Anzahl von skalaren Werten beinhaltet. Beispielsweise kann ein einzelnes Vektorregister einen Speicher für eine große Anzahl, (beispielsweise 128 Skalarvektoren beinhalten, obwohl der Schutzbereich der vorliegenden Erfindung nicht entsprechend eingeschränkt ist. Weiter kann das Register 435 zusätzliche Bits aufweisen um Indikatoren zur Verwendung für die Beibehaltung von Kohärenz mit Information in einem Zusatzspeicher einschließt. Insbesondere kann, wie in 5 gezeigt, ein Gültigkeitsbit 436 angeben, ob das Register 405 gültige Daten aufweist und ein Schmutzbit 437 kann angeben, dass die Inhalte des Registers 435 modifiziert worden sind.
  • Das Registerfile 430 kann, wie weiter in 5 gezeigt ist, eine Speicherung für zusätzliche Information beinhalten, etwa einen Übersetzungsspeicher oder einen Tag Speicher 470. Der Speicher 470, der ein Übersetzungspuffer oder ein Tagspeicher sein kann, kann zum Speichern einer Übersetzung von einer logischen Adresse in eine physikalische Adresse für den Zeiger, der von dem OS empfangen worden ist, der zu dem Beginn eines Zusatzspeichers in einem Speicher auf der Verwenderebene zeigt verwendet werden. Bei anderen Ausführungsbeispielen kann der Tagspeicher 470 jedoch außerhalb des Registerfiles 430 angeordnet sein.
  • Wenn alle notwendigen Daten für ein μop in dem Registerfile 430 vorhanden sind, kann das μop über eine der Ausführungseinheiten 440 ausgeführt werden. Bei verschiedenen Implementationen können unterschiedliche Ausführungseinheiten vorhanden sein. Beispielsweise können ganzzahlige, Fließpunkt-, Adressgenerations-, Einbefehl-Mehrdaten (SIMD) und Speicherdaten (STD) Einheiten vorhanden sein, obwohl der Schutzbereich nicht derart eingeschränkt ist. Nach der Ausführung können Ergebnisdaten zurück zu dem Registerfile 430 geliefert werden zum Speichern, bis der Befehl ausläuft. Sodann können die Ergebnisdaten zurück an einen gewünschten Ort (beispielsweise einer Speicherhierarchie) geschrieben werden.
  • Obwohl in dem Ausführungsbeispiel von 5 mit dieser Implementation gezeigt, sind viele Variationen möglich. Beispielsweise kann eine Rückschreibstufe mit Ausführungseinheiten 440 zum Aufnehmen von Ergebnisdaten zur späteren Lieferung zu der Speicherhierarchie gekoppelt sein. Alternativ können ein oder mehrere Puffer, wie Speicherpuffer, Ladepuffer oder dgl. mit dem Registerfile 430 gekoppelt sein. Als Beispiel können ein oder mehrere Ausscheidungspuffer mit dem Registerfile 430 gekoppelt sein zum Speichern von μops und zugehörigen Ergebnisdaten, bis zum Ausscheiden des zugehörigen Befehls.
  • In 5 ist weiter gezeigt, dass zusätzliche Strukturen innerhalb des Prozessors 400 verwendet werden können, um Operationen in Verbindung mit einer Zusatzspeicherung zu behandeln. Beispielsweise kann der Prozessor 400 eine Mehrzahl von Steuerregistern 450 aufweisen, die eine Speicherung der Prozessorstatusinformation bewirken können. Diese Steuerregister können Register zum Speichern von Steuerinformation aufweisen, die von dem Prozessor bei der Ausführung von Befehlen verwendet wird, beispielsweise Steuerregistern (CR). Zusätzliche Prozessorstatusinformation kann ebenfalls in Steuerregistern 450 gespeichert sein. Eine solche Prozessorstatusinformation kann verschiedene Extensionen und/oder Unterstützung für neue Prozessorbefehle aufweisen, beispielsweise kann bei einer Implementation zur Verwendung mit Vektorerstreckungen eine Mehrzahl von Vektorsteuerregistern vorhanden sein. Solche Register können eine Steuerinformation zur Verwendung bei der Implementierung von Vektorinformationen aufweisen. Beispielsweise können diese Vektorregister ein Vektorlängenregister und ein Vektorschrittregister aufweisen neben anderen derartigen Steuerregistern. Weiter können bei Implementationen, die in Verbindung mit Prozessorextensionen zur Verbesserung der Eigenschaft über profilgeführte Optimierungen, eine Mehrzahl von Steuerregistern entsprechend einem oder mehreren Kanälen zum Speichern von Information, die unterschiedlichen Eigenschaftsfehlern oder Prozessorereignissen zugehörig sind, vorhanden sein.
  • Auf diese Weise können die Steuerregister 450 eine architekturale Statusinformation liefern, die zum Handhaben von Prozessorextensionen oder ohne das Erfordernis einer OS Unterstützung verwendet wird. Ein repräsentatives Register 455 ist in 5 gezeigt.
  • Das Register 455 kann weiter zum Aufweisen von Indikatoren 456 und 457 erstreckt werden, die das Vorhandensein von gültigen Daten anzeigen und, beispielsweise, ob die Registerinhalte modifiziert worden sind. Wie in 5 gezeigt, können die Steuerregister 450 in Verbindung mit einem Suchfilter 460, das ein zusätzliches Suchfilter 460 sein kann (ein Hauptsuchfilter ist in 5 zur Vereinfachung der Darstellung gezeigt), das zum Handhaben von Anforderungen von anderen Systemagenten verwendet wird. Insbesondere kann das Suchfilter 460 Anforderungen für das Eigentum (RFO) oder andere Suchanforderungen für eine Information, die in dem Steuerregister 450 und dem Registerfile 430, zum Beispiel, gespeichert sind, anfordern. Auf diese Weise können diese Register des Prozessors 400 als ein Cache arbeiten. Entsprechend kann das Suchfilter 460 eingehende Anforderungen aufnehmen und bestimmen, ob eine angeforderte Adresse entweder einem der Steuerregister 450 oder dem Registerfile 430 entspricht. In 5 ist weiter gezeigt, dass das Suchfilter 460 ein Directory 465 aufweisen kann, das Übersetzungen in physikalische Adressen entsprechend den Orten in dem Registerfile 430 und den Steuerregistern 450 aufweisen kann. Auf diese Weise können logische Adressen, die als Suchanforderungen empfangen worden sind, auf das Directory 465 zugreifen zum Bestimmen, ob ein Treffer eintrifft.
  • Wenn ein Treffer in dem Directory 465 eintritt, kann Suchfilter 460 den physikalischen Ort in dem Registerfile 430 oder dem Steuerregister 450 suchen, um einen Status des Ortes zu bestimmen. Wenn der Ort schmutzig ist, kann das Suchfilter 460 dies dem Anforderungsagenten anzeigen und weiter die schmutzigen Daten sowohl an den anfordernden Agenten und zu dem Zusatzspeicher in dem Speicher liefern. Auf diese Weise kann das Prüfvorgang? Filter 460 eine Kohärenz zwischen den Inhalten dieser Orte und einem anfordernden Agenten sicherstellen, etwa einem DMA Agenten oder einem anderen Prozessor eines Mehrprozessorsystems. Obwohl dies in dem Ausführungsbeispiel von 5 mit einer besonderen Implementation gezeigt ist, versteht es sich, dass ein Prozessor viele unterschiedliche Formen in Abhängigkeit von einer gewünschten Architektur annehmen kann.
  • Es wird jetzt auf 6 Bezug genommen, in der ein Blockdiagramm eines Abschnitts eines Systems in Übereinstimmung mit der vorliegenden Erfindung gezeigt ist. Wie in 6 gezeigt, ist ein Prozessor 400 mit einem Speicher über einen Speichercontrollerhub (MCH) 475 gekoppelt. Obwohl dies in 6 mit dieser Implementation gezeigt ist, versteht es sich, dass der Prozessor 400 auch direkt mit dem Speicher 480 gekoppelt ist, beispielsweise über Point-to-Point Verbindungen oder in anderen derartigen Weise.
  • Wie in 6 gezeigt, weist der Prozessor 400 ein Registerfile 430 auf, das in unterschiedliche Abschnitte partitioniert sein kann. Insbesondere weisen die Abschnitte, die in 6 gezeigt sind, erstrecktere Ressourcen und insbesondere zusätzliche Register von variierender Länge auf. Wie gezeigt, weist ein erster Abschnitt ein erstrecktes Längsregister 435a und ein weiteres Register 435b auf. Jedes dieser Register kann unterschiedliche Statusbits haben, die diesen zugehörig sind. In dem in 6 gezeigten Ausführungsbeispiel kann ein Gültigkeitsbit 436a und ein Schmutzbit 437a mit dem Register 435 zugehörig sein, während ähnliche Bits 436b und 437b dem Register 435b zugehörig sein können. Weiter kann bei einigen Implementationen ein gegebenes Bit 438a einem definierten Abschnitt eines Registerfiles 430 zugehörig sein. Das gegenwärtige Bit 438a kann angeben, ob ein Rückspeicher entsprechend dem Abschnitt des Registerfiles 430 in dem Speicher vorhanden ist.
  • Es ist zu beachten, dass bei verschiedenen Ausführungsbeispielen unterschiedliche Granularitäten der verschiedenen Statusbits vorgesehen sein können. Beispielsweise kann, wie in 6 gezeigt, ein globales gegenwärtiges Bit 435 einem Registerfile 430 zugehörig sein um anzugeben, dass ein Zusatzspeicher entsprechend dem Zustand zugehörig zu einem gegenwärtig laufenden Prozess in einem Speicher vorhanden ist. Es ist weiter zu beachten, dass 2 zeigt, dass ähnliche Register und Statusbits entsprechend einer anderen Partition des Speichers auch vorhanden sind, nämlich zu Register 435c und 435d und ihre zugehörigen Statusbits, nämlich 436c und 436d, 437c und 437d und 438b.
  • Es wird weiterhin auf 6 Bezug genommen. Der Speicher 480 kann einen Zusatzspeicher 485 aufweisen, der dem Prozess, der gegenwärtig auf einem Prozessor 400 läuft, entspricht. Der Zusatzspeicher 485 kann globale Statusindikatoren 485 aufweisen zum Angeben des Vorhandenseins eines Speicheraufrufs entsprechend eines Zusatzspeichers, der gemeinsam mit anderer Statusinformation, etwa Gültigkeitsbits und/oder Schmutzigkeitsbits. Weiter zeigt der Zusatzspeicher 485, dass aufgrund der Größe der verschiedenen Register innerhalb der Registerbank 430 eine Rückspeicherungsinformation entsprechend dieser in einem oder mehreren Cachelinien vorhanden sein kann. Wie in 6 gezeigt, kann eine Zusatzspeicherinformation entsprechend den mehreren Registern mit normaler Größe in einer einzigen Cachelinie 490 gespeichert sein, die eine Unterstützung für mehrere Register als Zusatzspeicherinformation 493 und 496 beinhaltet gemeinsam mit entsprechenden Statusindikatoren, beispielsweise Indikatoren 491 und 492 zugehörig mit der Zusatzspeicherinformation 493 und den Anzeigern 494 und 495 zugehörig zu der Zusatzspeicherinformation 496. Diese Indikatoren können Gültigkeits- oder Schmutzigkeitsbits, zum Beispiel, entsprechen. Beispielsweise weist der Zusatzspeicher 485 mehrere Cachelinien 498 und 499 auf, die gemeinsam eine Zusatzspeicherinformation 495 bilden, die einem Register mit erstreckter Länge entsprechen, zum Beispiel. Entsprechend können die Anzeiger 497a und 497b der Zusatzspeicherinformation 498 und 499 zugehörig sein.
  • Obwohl bei dieser besonderen Information des Ausführungsbeispiels von 6 gezeigt, versteht es sich, dass der Schutzbereich der vorliegenden Erfindung nicht entsprechend beschränkt ist und bei verschiedenen Ausführungsbeispielen unterschiedliche granularities? der Statusindikatoren, etwa vorhanden/nicht vorhanden und schmutzig/sauber Bits entsprochen werden kann. Bei verschieden Ausführungsbeispielen kann die Granularität eine Pro-Register-Basis haben, eine Pro-Register-Bank-Basis oder eine Registerfile-Basis.
  • Entsprechend kann bei verschiedenen Ausführungsbeispielen Raum für Befehlssatzzufügungen und -erstreckungen zu einer Architektur zugewiesen sein, ohne das Erfordernis einer OS Unterstützung. Ausführungsbeispiele können in verschiedenen Prozessorarchitekturen implementiert sein, einschließlich, beispielsweise, Chip-Prozessoren (CMP) Felder mit kleinem Kern, andere Mehrkernprozessoren, Koprozessoren und andere Systeme.
  • Derartige Ausführungsbeispiele können in vielen unterschiedlichen Systemtypen implementiert sein. Es wird jetzt auf 7 Bezug genommen, die ein Blockdiagramm eines Systems in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Wie in 7 erkennbar, ist das Multiprozessorsystem ein Point-zu-Point-Verbindungssystem und weist einen ersten Prozessor 570 und einen zweiten Prozessor 580 auf, die über eine Point-zu-Point-Verbindung 550 gekoppelt sind. Wie in 7 gezeigt ist, kann jeder der Prozessoren 570 und 580 ein Mehrkern-Prozessor sein einschließlich ersten und zweiten Prozessorkernen (d. h., Prozessorkernen 574a und 475b und Prozessorkernen 584a und 584b). Obwohl dies zum Zwecke der Darstellung nicht dargestellt ist, können der erste Prozessor 570 und der zweite Prozessor 580 eine oder mehrere Registerbanken haben mit Vielzweck-Speicherregistern, als auch Steuerregister zur Verwendung bei der normalen Ausführung und erstreckten Ausführungsarten, beispielsweise Vektorextensionen. Der erste Prozessor 570 weist weiter einen Speichercontrollerhub (MCH) 572 und Point-zu-Point (P-P) Schnittstellen 576 und 578 auf. Entsprechend weist der zweite Prozessor 580 ein MCH 582 und P-P Schnittstellen 586 und 588 auf, wie in 7 gezeigt, koppeln die MCH 572 und 582 die Prozessoren an jeweilige Speicher, nämlich an Speicher 532 und einen Speicher 534, die Bereiche eines Hauptspeichers sein können, der örtlich an den jeweiligen Prozessoren angebracht ist. Diese Abschnitte eines Hauptspeichers können verwendet werden zum Implementieren eines Zusatzspeichers in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung.
  • Der erste Prozessor 570 und der zweite Prozessor 580 können zu einem Chipsatz 590 über P-P Schnittstellen 552 bzw. 554 gekoppelt sein. Wie in 7 gezeigt, weist ein Chipsatz 590 P-P Schnittstellen 594 und 598 auf. Weiter weist der Chipsatz 590 eine Schnittstelle 592 zum Koppeln des Chipsatzes 590 mit einer hoch leistungsfähigen Graphikmaschine 538 auf. Bei einem Ausführungsbeispiel kann ein Advanced Graphics Port (AGP) Bus 539 verwendet werden, um die Graphikmaschine 538 an den Chipsatz 590 zu koppeln. Der AGP Bus 539 kann dem Accelerated Graphics Port Interface Specification, Revision 2.0, veröffentlicht am 4. Mai 1998 von Intel Corporation, Santa Clara, Kalifornien, entsprechen. Alternativ kann eine Point-zu-Point Schnittstelle 539 diese Komponenten koppeln.
  • Der Chipsatz 590 kann wiederum mit einem ersten Bus 516 über eine Schnittstelle 596 gekoppelt sein. Bei einem Ausführungsbeispiel kann der erste Bus 516 ein Peripheral Component Interconnect (PCI) Bus sein, wie durch die PCI Local Bus specification, Production Version, Refision 2.1 von Juni 1995 oder ein Bus wie ein PCI Express Bus oder ein anderee I/O-Schnittstellenbus der dritten Generation verwendet werden, obwohl der Schutzbereich der Erfindung nicht entsprechend beschränkt ist.
  • Wie in 7 gezeigt ist, können verschiedene Eingangs/Ausgangs (I/O) Einheiten 514 mit dem ersten Bus 516 gekoppelt sein gemeinsam mit einer Busbrücke 518, die den ersten Bus 516 mit einem zweiten Bus 520 koppelt. Bei einem Ausführungsbeispiel kann der zweite Bus 520 ein Low Pin Count (LPC) Bus sein. Verschiedene Einheiten können mit dem zweiten Bus 520 gekoppelt sein, einschließlich, beispielsweise, einer Tastatur/Maus 522, Kommunikationseinheiten 526 und eine Datenspeichereinheit 528, etwa einem Disktreiber oder einer anderen Massenspeichereinheit, die bei einem Ausführungsbeispiel einen Code 530 aufweisen kann. Weiter kann ein Audio I/O 524 mit dem zweiten Bus 520 gekoppelt sein.
  • Ausführungsbeispiele können implementiert sein in einem Code und können gespeichert sein auf einem Speichermedium mit darauf gespeicherten Befehlen, die verwendet werden können zum Programmieren eines Systems zum Ausführen dieser Befehle. Das Speichermedium kann, ohne darauf begrenzt zu sein, jede Art von Disk einschließlich Floppydisks, optische Disks, Kompaktdisks Nur-Lese-Speicher (CD-ROM), beschreibbare Kompaktdisks (CD-RW) und magneto-optische Disks, Halbleitereinrichtungen, die Nur Lese-Speicher (ROM) Speicher mit wahlfreiem Zugriff (RAM) die dynamische Speicher mit wahlfreiem Zugriff (DRAM) statische Speicher mit wahlfreiem Zugriff (SRAM), löschbare programmierbare Nur-Lese-Speicher (EPROM), Flashspeicher, elektrisch löschbare programmierbare Nur-Lese-Speicher (EPROM), magnetische oder optische Karten oder andere Arten von Medien, die zum Speichern von elektronischen Befehlen geeignet sind.
  • Obwohl die Erfindung unter Bezugnahme auf eine begrenzte Anzahl von Ausführungsbeispielen beschrieben worden ist, versteht es sich für den Fachmann, dass verschiedene Modifikationen und Variationen möglich sind. Es ist beabsichtigt, dass die beiliegenden Ansprüche alle diese Modifikationen und Variationen als in den wahren Grundgedanken und Schutzbereich dieser Erfindung fallend aufnehmen sollen.
  • ZUSAMMENFASSUNG
  • Bei einem Ausführungsbeispiel weist die vorliegende Erfindung ein Verfahren zum Anfordern einer Zuordnung von Speicherplatz als ein Zusatzspeicher für eine architekturale Statusinformation eines Prozessors und Speichern einer architekturalen Statusinformation in den Zusatzspeicher unter Verwendung einer Anwendung auf. Auf diese Weise können der Zusatzspeicher und Prozessorerweiterungen, die Informationen in dem Zusatzspeicher verwenden, für ein Operationssystem transparent sein. Andere Ausführungsbeispiele werden beschrieben und beansprucht.

Claims (29)

  1. Ein Verfahren mit: Zuordnenen eines Bereichs eines Speichers als Zusatzspeicher für eine architekturale Statusinformation eines Prozessors, wobei die architekturale Statusinformation eine erstreckte Statusinformation aufweist, die einem Betriebssystem (OS) transparent ist, wobei die erstreckte Statusinformation einem erstreckten Prozessormerkmal entspricht, das von dem OS nicht unterstützt wird; und Speichern der architekturalen Statusinformation in dem Zusatzspeicher über eine Anwendung und ohne OS-Unterstützung.
  2. Das Verfahren nach Anspruch 1, weiter mit Empfangen eines Zeigers entsprechend einer Startadresse für den Zusatzspeicher von dem OS, wobei der Zusatzspeicher in einem Speicher auf der Verwenderebene liegt.
  3. Das Verfahren nach Anspruch 1, weiter mit Virtualisieren des erstreckten Prozessormerkmals.
  4. Das Verfahren nach Anspruch 1, weiter mit Modifizieren der architekturalen Statusinformation des Prozessors während der Ausführung der Anwendung, wobei die architekturale Zustandsinformation mit dem Zusatzspeicher inkohärent ist.
  5. Das Verfahren nach Anspruch 1, weiter mit Schreiben wenigstens eines Teiles der architekturalen Statusinformation in den Zusatzspeicher nach einer Änderung des privilegierten Niveaus.
  6. Das Verfahren nach Anspruch 5, weiter mit dem Schreiben von Schmutzdaten in den Zusatzspeicher in Antwort auf einen Treffer in einem Suchfilter des Prozessors.
  7. Das Verfahren nach Anspruch 1, weiter mit: Auslagern der Applikation für eine zweite Anwendung; und Suchen der architekturalen Statusinformation in dem Prozessor in Antwort auf ein Cache-Kohärenzprotokoll.
  8. Das Verfahren nach Anspruch 7, weiter mit: Umspeichern eines Kontextes für die Anwendung zu einem zweiten Prozessor von dem Zusatzspeicher; und Anfordern der Daten in dem Zusatzspeicher von dem Prozessor.
  9. Eine Vorrichtung mit: wenigstens einer Ausführungseinheit zur Ausführung von Operationen; einem Registerfile, das mit der wenigstens einen Ausführungseinheit zum Speichern von Daten gekoppelt ist, wobei das Registerfile einen Speicherort zu Speichern eines Zeigers auf einen Speicherort eines Zusatzspeichers in einem Speicher auf dem Verwenderniveau aufweist; und einem Suchfilter, das mit dem Registerfile gekoppelt ist zum Bestimmen, ob eine Suchanforderung für eine Adresse in dem Zusatzspeicher einem Ort in dem Registerfile entspricht.
  10. Die Vorrichtung von Anspruch 9, wobei das Registerfile wenigstens eine Ressource aufweist, die auf einer Pro-Prozess-Basis ohne Unterstützung durch das Betriebssystem (OS) virtualisiert wird.
  11. Die Vorrichtung von Anspruch 10, wobei die wenigstens eine Ressource ein Register mit erstreckter Länge ohne Unterstützung durch das OS aufweist.
  12. Die Vorrichtung von Anspruch 11, wobei der Zusatzspeicher eine Mehrzahl von Cache-Linien aufweist, um ein Register mit erstreckter Länge zu speichern.
  13. Die Vorrichtung von Anspruch 11, wobei die wenigstens eine Ressource weiter ein zweites und ein drittes Register aufweist, die von dem OS nicht unterstützt werden.
  14. Die Vorrichtung von Anspruch 13, wobei der Rückspeicher eine Cache-Linie zum Speichern der zweiten und dritten Register aufweist.
  15. Die Vorrichtung von Anspruch 9, wobei die wenigstens eine Ausführungseinheit zum Initiieren der Zusatzspeicher unter Steuerung auf der Verwenderebene und dem Betriebssystem transparent initiiert.
  16. Ein System mit: einem ersten Prozessor einschließlich einem Informationsspeicher und einem Filter zum Zugreifen auf die Statusinformationsspeicherung bei einer Anforderung bezüglich des Eigentums, wobei die Statusinformation in dem Statusinformationsspeicher auch in einem Zusatzspeicher in einem Speicher auf Verwenderebene vorhanden ist, das mit der Statusinformation inkohärent gehalten wird; einem Agenten, der mit dem ersten Prozessor gekoppelt ist, um die Anforderungen bezüglich des Eigentums an den ersten Prozessor zu kommunizieren und eine Antwort von dem ersten Prozessor auf die Anforderung des Eigentums zu erhalten; und einem dynamischen Speicher mit wahlfreiem Zugriff (DRAM), das mit dem ersten Prozessor und dem Agenten gekoppelt ist.
  17. Das Verfahren nach Anspruch 16, wobei der Agent einen Agneten mit direktem Speicherzugriff (DMA) zum Schreiben von Daten von dem DRAM in eine Massenspeichereinheit aufweist, wobei die Daten die Zusatzspeicherung beinhalten.
  18. Das Verfahren nach Anspruch 17, wobei das DRAM die Zusatzspeicherung beinhaltet, und die Zusatzspeicherung wiederum eine erste Cache-Linie aufweist zum Aufnehmen von Statusinformationen von einer Mehrzahl von Registern des Statusinformationsspeichers.
  19. Das System nach Anspruch 18, wobei der Zusatzspeicher eine zweite Cache-Linie und eine dritte Cache-Linie aufweist, wobei die zweite und dritte Cache-Linie der Statusinformation von einem erstreckten Register des Statusinformationsspeichers entsprechen.
  20. Das System nach Anspruch 16, wobei der Statusinformationsspeicher wenigstens ein Steuerregister für eine Prozessorerstreckung zum Ausführen ohne Unterstützung durch das Betriebssystem (OS) aufweist.
  21. Das System nach Anspruch 16, wobei der Agent einen zweiten Prozessor aufweist zum Ausführen eines Prozesses, der von dem ersten Prozessor ausgelagert ist, wobei der zweite Prozessor zum Aufnehmen einer Kontextinformation für den Prozess von dem Zusatzspeicher eingerichtet ist.
  22. Das System nach Anspruch 21, wobei der Prozessor zum Kommunizieren der Eigentümeranforderung für die Kontextinformation eingerichtet ist und wobei der erste Prozessor zum Aussenden der Antwort zu dem zweiten Prozessor einschließlich der Schmutzkontextinformation in dem Statusinformationsspeicher eingerichtet ist.
  23. Ein Artikel mit einem maschinenlesbaren Speichermedium einschließlich Befehlen, die bei einer Ausführung durch eine Maschine die Maschine dazu in die Lage versetzen, ein Verfahren auszuführen mit: Anfordern einer Adresse für einen ersten Zusatzspeicher in einem Speicher auf Verwenderebene für einen ersten Vorgang; Laden von Prozessorstatusinformationen in den ersten Zusatzspeicher, wobei die Prozessorstatusinformation eine Information eines Merkmals eines Prozessors aufweist, die durch ein Betriebssystem (OS) nicht unterstützt wird; Kopieren der Prozessorstatusinformation aus dem ersten Zusatzspeicher in eine Registerbank des Prozessors; und Ausführen des ersten Prozessors auf dem Prozessor unter Verwendung der Prozessorstatusinformation in der Registerbank.
  24. Der Artikel nach Anspruch 23, wobei das Verfahren weiter das Beibehalten des ersten Zusatzspeichers inkohärent mit der Prozessorstatusinformation in der Registerbank während der Ausführung eines privilegierten Niveaus für den ersten Prozess.
  25. Der Artikel nach Anspruch 24, wobei das Verfahren weiter das Beibehalten des ersten Zusatzspeichers kohärent mit der Prozessorstatusinformation in der Registerbank während der Ausführung eines unterschiedlichen Privilegierungsniveaus als erster Prozess aufweist.
  26. Der Artikel nach Anspruch 23, wobei das Verfahren weiter das Laden der Prozessorstatusinformation in einen ersten Zusatzspeicher und Kopieren der Prozessorstatusinformation für den OS transparent aufweist.
  27. Der Artikel nach Anspruch 23, wobei das Verfahren weiter das Bewegen des ersten Prozesses in einen zweiten Prozessor und das Suchen der Registerbank bei einer Eigentumsanforderung für die Prozessorstatusinformation aufweist.
  28. Der Artikel nach Anspruch 23, wobei das Verfahren weiter das Bestimmen aufweist, ob die Prozessorstatusinformation in der Registerbank die authorisierte Kopie einer Prozessorstatusinformation ist.
  29. Der Artikel nach Anspruch 28, wobei das Verfahren weiter aufweist: Modifizieren der Prozessorstatusinformation, wenn die authorisierte Kopie in der Registerbank vorhanden ist, und Laden der Prozessorstatusinformation aus dem ersten Zusatzspeicher in die Registerbank, wenn die authorisierte Kopie in dem ersten Zusatzspeicher vorhanden ist, wobei das Laden für das OS transparent ist.
DE112006002582T 2005-10-31 2006-10-31 Bewirken einer Zusatzspeicherung in einem User-Levelspeicher Ceased DE112006002582T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/263,628 US7500049B2 (en) 2005-10-31 2005-10-31 Providing a backing store in user-level memory
US11/263,628 2005-10-31
PCT/US2006/042619 WO2007053668A2 (en) 2005-10-31 2006-10-31 Providing a backing store in user-level memory

Publications (1)

Publication Number Publication Date
DE112006002582T5 true DE112006002582T5 (de) 2008-09-18

Family

ID=37997963

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112006002582T Ceased DE112006002582T5 (de) 2005-10-31 2006-10-31 Bewirken einer Zusatzspeicherung in einem User-Levelspeicher

Country Status (4)

Country Link
US (1) US7500049B2 (de)
CN (1) CN101371232B (de)
DE (1) DE112006002582T5 (de)
WO (1) WO2007053668A2 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8533696B1 (en) * 2006-09-29 2013-09-10 Emc Corporation Methods and systems for allocating hardware resources to instances of software images
US7899904B2 (en) * 2007-04-30 2011-03-01 Lsi Corporation Hardware processing of regular expressions
US7996663B2 (en) * 2007-12-27 2011-08-09 Intel Corporation Saving and restoring architectural state for processor cores
US8086801B2 (en) * 2009-04-08 2011-12-27 International Business Machines Corporation Loading data to vector renamed register from across multiple cache lines
US8234407B2 (en) * 2009-06-30 2012-07-31 Oracle America, Inc. Network use of virtual addresses without pinning or registration
US10078518B2 (en) * 2012-11-01 2018-09-18 International Business Machines Corporation Intelligent context management
US10102003B2 (en) * 2012-11-01 2018-10-16 International Business Machines Corporation Intelligent context management
CN105183668B (zh) * 2015-09-21 2018-05-18 华为技术有限公司 缓存刷新方法及装置
US9898408B2 (en) * 2016-04-01 2018-02-20 Intel Corporation Sharing aware snoop filter apparatus and method
US10255181B2 (en) * 2016-09-19 2019-04-09 Qualcomm Incorporated Dynamic input/output coherency
US11526445B2 (en) * 2019-05-13 2022-12-13 Rambus Inc. Managing memory maintenance operations in a memory system having backing storage media
CN112463652B (zh) * 2020-11-20 2022-09-27 海光信息技术股份有限公司 基于缓存一致性的数据处理方法、装置、处理芯片及服务器

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428779A (en) * 1992-11-09 1995-06-27 Seiko Epson Corporation System and method for supporting context switching within a multiprocessor system having functional blocks that generate state programs with coded register load instructions
US5551006A (en) 1993-09-30 1996-08-27 Intel Corporation Low cost writethrough cache coherency apparatus and method for computer systems without a cache supporting bus
US6075938A (en) 1997-06-10 2000-06-13 The Board Of Trustees Of The Leland Stanford Junior University Virtual machine monitors for scalable multiprocessors
US6145049A (en) * 1997-12-29 2000-11-07 Stmicroelectronics, Inc. Method and apparatus for providing fast switching between floating point and multimedia instructions using any combination of a first register file set and a second register file set
US6671762B1 (en) * 1997-12-29 2003-12-30 Stmicroelectronics, Inc. System and method of saving and restoring registers in a data processing system
US6487630B2 (en) * 1999-02-26 2002-11-26 Intel Corporation Processor with register stack engine that dynamically spills/fills physical registers to backing store
US6434677B1 (en) 1999-06-01 2002-08-13 Intel Corporation Method and apparatus for altering data length to zero to maintain cache coherency
US6456891B1 (en) * 1999-10-27 2002-09-24 Advanced Micro Devices, Inc. System and method for transparent handling of extended register states
US6629157B1 (en) 2000-01-04 2003-09-30 National Semiconductor Corporation System and method for virtualizing the configuration space of PCI devices in a processing system
US6651163B1 (en) * 2000-03-08 2003-11-18 Advanced Micro Devices, Inc. Exception handling with reduced overhead in a multithreaded multiprocessing system
US6434683B1 (en) * 2000-11-07 2002-08-13 Storage Technology Corporation Method and system for transferring delta difference data to a storage device
US8776050B2 (en) 2003-08-20 2014-07-08 Oracle International Corporation Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes

Also Published As

Publication number Publication date
US7500049B2 (en) 2009-03-03
CN101371232B (zh) 2011-10-19
CN101371232A (zh) 2009-02-18
WO2007053668A2 (en) 2007-05-10
WO2007053668A3 (en) 2008-05-29
US20070101076A1 (en) 2007-05-03

Similar Documents

Publication Publication Date Title
DE112006002582T5 (de) Bewirken einer Zusatzspeicherung in einem User-Levelspeicher
DE112005001798B4 (de) Verwalten von Prozessorressourcen während Architekturereignissen
DE102010035603A1 (de) Bereitstellen von Hardwareunterstützung für gemeinsam benutzten virtuellen Speicher zwischen physischem Lokal- und Fernspeicher
DE69022716T2 (de) Mehrrechnersystem mit verteilten gemeinsamen Betriebsmitteln und dynamischer und selektiver Vervielfältigung globaler Daten und Verfahren dafür.
DE60222402T2 (de) Verfahren und system zur spekulativen ungültigkeitserklärung von zeilen in einem cachespeicher
DE69031433T2 (de) Speicherzugriffsausnahmebehandlung bei vorausgelesenen Befehlswörtern in dem Befehlsfliessband eines Rechners mit virtuellem Speicher
DE68923490T2 (de) Prüfpunkt-Wiederholungssystem.
DE112005003098B4 (de) Verfahren und Vorrichtung zum Zugreifen auf einen physikalischen Speicher von einer CPU oder einem Prozessorelement mit hoher Leistung
CN100373344C (zh) 用于在实时与虚拟化操作系统之间共享资源的系统和方法
DE19681660C2 (de) Verfahren zum Ausführen von Befehlssätzen, die Operationen an verschiedenen Datenarten und Register eines gemeinsamen logischen Registersatzes spezifizieren
DE60102017T2 (de) Räumungsfilter für adressenübersetzungspuffer
DE102013200503A1 (de) Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik
DE112010003758T5 (de) Instruktionen zum Verwalten einer parallelen Cache-Hierarchie
DE112011103433B4 (de) Verfahren, System und Programm zum Steuern von Cache-Kohärenz
DE102018213430A1 (de) Beschleuniger mit geringer Latenzzeit
DE102008062044B4 (de) 1Speicherinterne, seiteninterne Verzeichnis-Chache-Kohärenz-Konfiguration
DE112012002241T5 (de) Migration eines transparenten Dateisystems zu einem neuen physischen Speicherort
DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013017510A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102010034555A1 (de) Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE10393727T5 (de) Prozessor-Cache-Speicher als RAM zur Ausführung von Boot-Code
DE112005003339T5 (de) Transaktionsgestützter Verarbeitungsbetrieb mit gemeinsam genutzten Daten in einer Multiprozessorumgebung
DE112015000430T5 (de) Einheitliche Speichersysteme und -verfahren
DE112010004971T5 (de) Ein System, Verfahren und eine Vorrichtung für einen Cache-Flush eines Seitenbereichs und TLB Invalidierung eines Bereichs von Einträgen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R003 Refusal decision now final
R011 All appeals rejected, refused or otherwise settled