DE69826418T2

DE69826418T2 - Anordnung zum Abtasten mehrerer Instruktionen in einer Prozessorpipeline

Info

Publication number: DE69826418T2
Application number: DE69826418T
Authority: DE
Inventors: George Z. Marlboro Chrysos; Jeffrey A. Menlo Park Dean; James E. Newton Hicks; Daniel L. Cambridge Leibholz; Edward J. Holliston McLellan; Carl A. Atherton Waldspurger; William E. San Francisco Weihl
Original assignee: COMPAG COMP CORP; Compaq Computer Corp
Current assignee: COMPAG COMP CORP; Compaq Computer Corp
Priority date: 1997-11-26
Filing date: 1998-11-25
Publication date: 2005-03-03
Anticipated expiration: 2018-11-26
Also published as: EP0919924A2; JPH11272520A; US6163840A; EP0919924B1; DE69826418D1; JP4467094B2; EP0919924A3

Description

Die vorliegende Erfindung betrifft im Allgemeinen das Messen der Leistung eines Computersystems und insbesondere das Schätzen von Statistiken von Eigenschaften von Wechselwirkungen zwischen Befehlen, die von einer Prozessor-Pipeline verarbeitet werden.
Computerprozessoren werden schneller, jedoch hält die Leistung von Softwareanwendungen nicht damit Schritt. Bei großen kommerziellen Anwendungen können die durchschnittlichen Werte von Takt je Befehl (cycles-per-instruction – CPI) bis zu 2,5 oder 3 betragen. Bei einem Vierweg-Befehlsausgabe-Prozessor bedeutet ein CPI Wert von 3, dass lediglich ein Ausgabeschlitz von 12 genutzt wird. Es ist wichtig zu verstehen, wieso der Software-Durchsatz nicht mit Hardwareverbesserungen Schritt hält.
Normalerweise werden für derartige Probleme Speicherlatenzen verantwortlich gemacht, wobei es Tatsache ist, dass viele Software-Anwendungen viele Zyklen damit verbringen, auf den Abschluss von Datenübertragungen zu warten. Jedoch kommt es auch durch andere Probleme, wie beispielsweise Verzweigungs-Fehlvorhersagen zur Verschwendung von Prozessortakten. Unabhängig von den allgemeinen Ursachen müssen Systemarchitekten sowie Hardware- und Software-Ingenieure wissen, welche Befehle zu Verzögerungen führen und warum, um die Leistung von modernen Computersystemen zu verbessern, die komplexe Prozessoren enthalten.
Normalerweise wird dies getan, indem ein "Profil" des Verhaltens eines Systems im Betrieb erzeugt wird. Ein Profil stellt eine Aufzeichnung von Leistungsdaten dar. Häufig wird das Profil grafisch dargestellt, so dass Leistungsengpässe schnell erkannt werden können.
Die Profilbildung kann mit Messinstrumenten und durch Simulation ausgeführt werden. Bei Messinstrumenten wird ein zusätzlicher Code zu einem Programm hinzugefügt, um bestimmte Ereignisse während der Ausführung eines Programms zu überwachen. Bei der Simulation wird versucht, das Verhalten des gesamten Programms in einer künstli chen Umgebung zu simulieren, statt das Programm in dem tatsächlichen System auszuführen.
Jedes dieser beiden Verfahren hat seine Nachteile. Bei der Instrumentierung wird das wahre Verhalten des Programms aufgrund der hinzugefügten Befehle und zusätzlicher Datenbezüge gestört. Bei der Simulation wird die Störung auf Kosten einer erheblichen Verwaltungszeit (overhead) im Vergleich zur Ausführung des Programms auf einem realen System vermieden. Des Weiteren ist es sowohl bei der Instrumentierung als auch bei der Simulation normalerweise schwierig, ein Profil eines gesamten großen Software-Systems, d. h. einer Anwendung, eines Betriebssystems und eines Treiber-Codes, zu erzeugen.
In Hardware umgesetzte Ereignis-Abtastung kann ebenfalls eingesetzt werden, um Profilinformationen über Prozessoren zu erzeugen. Die Hardware-Abtastung weist eine Reihe von Vorteilen gegenüber der Simulation und Instrumentierung auf, d. h. Software-Programme müssen nicht modifiziert werden, um ihre Leistung zu messen. Abtastung funktioniert auf Gesamtsystemen, wobei die Zeit bzw. der Aufwand für die Verwaltung relativ gering ist. In jüngster Zeit ist nachgewiesen worden, dass Profilieren mit geringem Verwaltungsaufwand auf der Basis von Abtasten eingesetzt werden kann, um detaillierte Befehlsebenen-Informationen über Pipeline-Verzögerungen und ihre Ursachen zu gewinnen. Jedoch weisen viele Hardware-Abtastverfahren keine ausreichende Flexibilität auf, da sie zum Messen spezifischer Ereignisse ausgelegt sind.
Die meisten vorhandenen Mikroprozessoren, wie beispielsweise der DIGITAL (RTM) Alpha AXP 21164, der Intel (RTM) Pentium Pro und der MIPS (RTM) R10000 weisen Ereigniszähler auf, die eine Reihe von Ereignissen zählen können, so beispielsweise Daten-Cache (D-Cache) -Fehler, Befehls-Cache (I-Cache) -Fehler und Verzweigungs-Fehlvorhersagen. Die Ereigniszähler erzeugen eine Unterbrechung, wenn es zum Überlauf der Zähler kommt, so dass die Leistungsdaten in den Zählern von höheren Software-Ebenen abgetastet werden können.
Ereigniszähler sind nützlich, um Gesamtinformationen zu erfassen, so beispielsweise die Anzahl von Verzweigungs-Fehlvorhersagen, die in dem System aufgetreten sind, während ein bestimmtes Programm oder ein Teil desselben ausgeführt wurde. Bekannte Ereigniszähler eignen sich jedoch weniger gut dazu, einzelnen Befehlen Status-Informationen zuzuschreiben, so beispielsweise, welche Verzweigungs-Befehle häufig falsch vorhergesagt werden. Dies kann auf die Tatsache zurückzuführen sein, dass die Programmstufen-Zähler (program counters – PC) von Befehlen, die die Ereignisse verursachten, nicht mehr zur Verfügung stehen, wenn es zum Überlauf des Ereigniszählers und zu Unterbrechungen kommt.
Ein spezielles Problem besteht darin, die dynamische Funktion eines Prozessors abzuleiten, der Befehle außerhalb der Reihenfolge ausgeben kann. Das Verhalten von Software-Programmen, die in einem nicht der Reihenfolge nach arbeitenden Prozessor ausgeführt werden, kann sehr komplex und schwer zu verstehen sein. Als konkretes Beispiel betrachte man den Strom von Befehlen in dem nicht der Reihenfolge nach arbeitenden Prozessor Alpha 21264.
Superskalare Prozessorarchitektur
Ausführungsreihenfolge
Ein nicht der Reihenfolge nach arbeitender Prozessor ruft Befehle der Reihenfolge nach auf und legt sie ab, verarbeitet die Befehle jedoch entsprechend ihrer Daten-Abhängigkeiten. Zur Verarbeitung von Befehlen kann die Register-Abbildung, die Ausgabe und die Ausführung von Befehlen gehören. Ein Befehl wird von dem Zeitpunkt, zu dem er abgerufen wird, bis er abgelegt bzw. abgebrochen wird, als "unterwegs" seiend (in-flight) betrachtet.
Während jedes Prozessorzyklus ruft eine erste Stufe der Prozessor-Pipeline einen Satz von Befehlen aus dem Befehls-Cache (I-Cache) ab. Die Gruppe von Befehlen wird dekodiert. Der Befehls-Dekodierer identifiziert, welche Befehle in der abgerufenen Gruppe Teil des Befehlsstroms sind.
Da mehrere Zyklen erforderlich sein können, um den Programmstufenzähler (PC) eines nächsten abzurufenden Befehls aufzulösen, wird der PC normalerweise im Voraus durch einen Verzweigungs- bzw. Sprung-Vorhersager bzw. -Prädiktor vorhergesagt. Wenn die Vorhersage falsch ist, bricht der Prozessor die falsch vorhergesagten Befehle ab, die einen "schlechten" Ausführungsweg einnehmen, und beginnt erneut, Befehle auf dem "guten" Weg abzurufen.
Damit Befehle außerhalb der Reihenfolge ausgeführt werden können, werden Register, die in Operanden von Befehlen angegeben werden, dynamisch umbenannt, um Schreiben-nach-Lesen- und Schreiben-nach-Schreiben-Konflikte zu verhindern. Diese Umbenennung wird erreicht, indem architektonische oder "virtuelle" Register physischen Registern zugeordnet bzw. auf ihnen abgebildet werden. So können zwei Befehle, die in das gleiche virtuelle Register schreiben, sicher außerhalb der Reihenfolge ausgeführt werden, da sie in zwei verschiedene physische Register schreiben, und die Abnehmer der virtuellen Register erhalten die richtigen Werte.
Ein registerzugeordneter Befehl verbleibt in der Ausgabeschlange, bis seine Operanden berechnet worden sind und eine funktionelle "Ausführungs"-Einheit des geeigneten Typs zur Verfügung steht. Die physischen Register, die von einem Befehl benutzt werden, werden in dem Zyklus gelesen, in dem der Befehl ausgegeben wird. Nachdem Befehle ausgeführt worden sind, werden sie als zum Ausscheiden bzw. Ablegen bereit markiert und von dem Prozessor abgelegt, wenn alle vorherigen zum Ablegen bereiten Befehle in der Programmreihenfolge abgelegt worden sind, d. h. die Befehle scheiden in der richtigen Programmreihenfolge aus. Beim Ausscheiden hält der Prozessor die von dem Befehl an dem architektonischen "Zustand" des Systems vorgenommenen Veränderungen fest und gibt Ressourcen frei, die von dem Befehl benutzt wurden.
Fehlvorhersage
In einigen Fällen, so beispielsweise, wenn eine Verzweigung falsch vorhergesagt wird, müssen Befehle unterbrochen oder ausgesondert werden. Wenn dies auftritt, wird der momentane spekulative architektonische Zustand an einen Punkt während der Ausführung zurückgesetzt, an dem die Fehlvorhersage aufgetreten ist, und das Abrufen wird bei dem richtigen Befehl fortgesetzt.
Verzögerungen
Zahlreiche Ereignisse können die Ausführung eines Befehls verzögern. Am vorderen Ende der Pipeline kann die Abruf-Einheit aufgrund eines I-Cache-Fehlers aufgehalten werden, oder die Abruf-Einheit kann Befehle aufgrund einer Fehlvorhersage auf einem schlechten Weg abrufen. Die Zuordnungs- bzw. Abbildungseinrichtung (mapper) kann aufgrund des Fehlens freier physischer Register oder des Fehlens freier Schlitze in der Ausgabeschlange abgehalten werden. Befehle in der Ausgabeschlange können darauf warten, dass ihre Registerabhängigkeiten erfüllt werden oder auf die Verfügbarkeit von funktionellen Ausführungs-Einheiten.
Befehle können aufgrund von Daten-Cache-Fehlern verzögert werden. Befehle können unterbrochen werden, weil sie spekulativ auf einem schlechten Weg ausgegeben wurden oder weil der Prozessor eine Unterbrechung ausgeführt hat. Viele dieser Ereignisse lassen sich schwer statisch vorhersagen, beispielsweise durch eine Untersuchung des Codes, und alle verschlechtern die Leistung des Systems. Einfache Ereigniszähler reichen nicht aus, um diesen Typ Statusinformation festzuhalten. Des Weiteren ist es schwierig, die Länge der Verzögerungen exakt zu messen, um festzustellen, welche Verzögerungen besondere Aufmerksamkeit verdienen.
Es ist außerordentlich wünschenswert, Ereignisse direkt speziellen Befehlen und Gerätezuständen zuzuordnen, so dass Programmierer oder Optimierungswerkzeuge die Leistung von Software- und Hardware-Komponenten von komplexen Computersystemen, wie beispielsweise superskalaren oder nicht der Reihenfolge nach arbeitenden Prozessoren oder auch Prozessoren mit jedem beliebigen architektonischen Aufbau verbessern können.
Probleme bei Ereigniszählern nach dem Stand der Technik
Das Hauptproblem bei bekannten Ereigniszählern besteht darin, dass der Befehl, der das Ereignis verursacht hat, durch das es zum Überlaufen des Zählers gekommen ist, normalerweise lange vor dem Ausnahme-Programmstufenzähler (PC) abgerufen wurde, d. h. der PC bezieht sich nicht auf den Befehl, der das Überlaufen verursacht hat. Die Länge der Verzögerung zwischen dem Abrufen und der Unterbrechung hat normaler weise einen nicht vorhersagbaren Wert. Diese nichtvorhersagbare Verteilung von Ereignissen macht es schwierig, Ereignisse bestimmten Befehlen richtig zuzuordnen. Ausführung außerhalb der Reihenfolge und spekulative Ausführung verschärfen dieses Problem noch, es ist jedoch auch bei der Reihenfolge nach arbeitenden Geräten, wie beispielsweise dem Prozessor Alpha 21164, vorhanden.
Vergleichen wir beispielsweise Programmstufenzähler-Werte, die dem Leistungszähler-Unterbrechungs-Behandler zugeführt werden, während D-Cache-Bezugsereignis-Zählwerte überwacht werden, für den Prozessor Alpha 21164 (der Reihenfolge arbeitend) und den Prozessor Pentium Pro (außerhalb der Reihenfolge arbeitend). Ein Beispielprogramm besteht aus einer Schleife, die einen RAM-Zugriffsbefehl, beispielsweise einen Lade-Befehl, enthält, auf den hunderte von Nulloperations-Befehlen (null operation instructions-nop) folgen.
Bei dem der Reihenfolge nach arbeitenden Prozessor Alpha werden sämtliche Leistungszähler-Ereignisse (beispielsweise Cache-Fehler) dem Befehl zugeschrieben, der sechs Zyklen nach dem Ereignis ausgeführt wird, so dass es zu einer erheblichen Spitze von Abtastungen beim siebten Befehl nach dem Lade-Zugriff kommt. Diese verschobene Verteilung von Ereignissen ist nicht ideal. Da jedoch eine einzelne große Spitze vorhanden ist, kann die statische Analyse mitunter von dieser Spitze rückwärts arbeiten, um den Befehl zu identifizieren, der das Ereignis verursacht hat, wobei dies jedoch nicht mehr als eine beste Schätzung für ein recht einfaches Programm ist.
Wenn das gleiche Programm auf dem nicht der Reihenfolge nach arbeitenden Pentium Pro ausgeführt wird, werden die Ereignis-Abtastungen breit gestreut über die nächsten 25 Befehle verteilt, was nicht nur erhebliche Verschiebung, sondern auch ausgeprägte Verwischung darstellt. Die breite Verteilung von Abtastungen macht es nahezu unmöglich, dem speziellen Befehl, der das Ereignis verursacht hat, ein bestimmtes Ereignis zuzuordnen. Das gleiche Verhalten tritt auf, wenn andere Hardware-Ereignisse gezählt werden.
Zusätzlich zu der verschobenen bzw. verwischten Verteilung von Ereignis-Abtastungen weisen herkömmliche Ereigniszähler auch weitere Probleme auf. Es gibt normalerweise viel mehr interessierende Ereignisse als Ereigniszähler, wodurch es schwierig, wenn nicht unmöglich wird, gleichzeitig alle interessierenden Ereignisse zu überwachen. Die zunehmende Komplexität von Prozessoren macht es wahrscheinlich, dass dieses Problem noch akuter wird.
Des Weiteren zeichnen Ereigniszähler nur die Tatsache auf, dass ein Ereignis stattgefunden hat, und sie stellen keine zusätzlichen Statusinformationen über das Ereignis zur Verfügung. Für viele Arten von Ereignissen wären zusätzliche Informationen, wie beispielsweise die Latenz zur Ausführung eines Cache-Fehlerereignisses, außerordentlich nützlich.
Des Weiteren sind Zähler nach dem Stand der Technik im Allgemeinen nicht in der Lage, Ereignisse "blinden Flecken" in dem Code zuzuordnen. Ein blinder Fleck ist jeder beliebige nicht unterbrechbare Code, so beispielsweise System-Routinen hoher Priorität und PAL-Code, da das Ereignis erst dann erkannt wird, wenn seine Unterbrechung angenommen wird. Zu diesem Zeitpunkt kann sich der Prozessorstatus erheblich verändert haben, so dass es wahrscheinlich ist, dass falsche Informationen gegeben werden.
Verzögerungen vs. Engpässe
Bei einem der Reihenfolge nach arbeitenden Pipeline-Prozessor verhindert ein verzögerter Befehl in einer Pipeline, dass spätere Befehle diese Pipeline-Stufe durchlaufen. Daher ist es relativ einfach, "Engpass"-Befehle in einem der Reihenfolge nach arbeitenden Prozessor zu identifizieren, d. h. Engpass-Befehle neigen zur Verzögerung an einem Punkt in der Pipeline. Bei einem der Reihenfolge nach arbeitenden Prozessor ist es möglich, Verzögerungen zu identifizieren, indem die Latenz eines Befehls beim Durchlaufen jeder Pipeline-Stufe gemessen wird und die gemessene Latenz mit der idealen Latenz dieses Befehls in jeder Pipeline-Stufe verglichen wird. Es kann angenommen werden, dass ein Befehl in einer Stufe verzögert worden ist, wenn er länger als die minimale Latenz benötigt, um diese Stufe zu durchlaufen.
Bei einem nicht der Reihenfolge nach arbeitenden Prozessor jedoch können andere Befehle um einen Befehl herum, der in dieser Pipeline-Stufe verzögert wird, eine Pipeline-Stufe durchlaufen. Die zusätzliche Latenz des verzögerten Befehls kann sogar voll ständig durch die Verarbeitung anderer Befehle verschleiert werden, und verzögerte Befehle können den beobachteten Abschluss des Programms nicht verzögern.
Selbst bei der Reihenfolge nach arbeitenden Prozessoren können Verzögerungen in einer Pipeline-Stufe nicht zur Gesamt-Ausführungszeit eines Programms beitragen, wenn eine andere Pipeline-Stufe der Engpass ist. So können beispielsweise beim Ausführen eines speicherintensiven Programms die Abrufeinrichtung und die Abbildungs- bzw. Zuordnungseinrichtung der Befehls-Pipeline häufig Verzögerungen aufgrund des "Rückstaus" von einer Ausführungs-Einheit verursachen, bei der aufgrund von D-Cache-Fehlern Verzögerung auftrat.
Idealerweise werden die Speichervorgänge, die die Cache-Fehler verursachen, als die Hauptengpässe eingestuft. Die Verzögerungen der Abrufeinrichtung und der Zuordnungseinrichtung sind eigentlich nicht symptomatisch für die Verzögerungen aufgrund von Cache-Fehlern, d. h. es handelt sich um sekundäre Engpässe.
Es wäre wünschenswert, die Befehle zu identifizieren, deren Verzögerung nicht durch andere Befehle verschleiert wird, und sie als tatsächliche Engpässe zu identifizieren. Des Weiteren besteht, um das Programmverhalten zu verbessern, ein Bedarf danach, sich auf die ursächlichen (primären) Engpässe statt auf die nicht symptomatischen (sekundären) Engpässe zu konzentrieren. Diese Unterteilung von Engpässen der Pipeline-Stufe in kausal und nicht symptomatisch erfordert detailliertes Wissen über den Zustand der Pipeline sowie die Daten- und Ressourcen-Abhängigkeiten der im Verarbeitungszustand befindlichen bzw. unterwegs seienden Befehle, die nicht mit einfachen Ereigniszählern ermittelt werden können, wie sie bekannt sind.
Das US-Patent 5,151,981 "Instruction Sampling Instrumentation" (Befehlsabtastungs-Instrumentierung), das Westcott et al. am 29. September 1992 erteilt wurde, schlägt einen Hardware-Mechanismus für die befehlsbasierte Abtastung eines der Reihenfolge nach arbeitenden Ausführungs-Rechners vor. Das von Westcott et al. gewählte Vorgehen weist eine Reihe von Nachteilen auf. Zunächst kann mit ihrem Vorgehen der Strom von Befehlsabtastungen je nach der Länge des abgetasteten Codes und der Abtastrate verschoben werden. Des Weiteren tastet ihr System lediglich ausgeschiedene bzw. abgelegte Befehle und nicht alle abgerufenen Befehle ab, von denen einige möglicherwei se abgebrochen werden. Drittens konzentrieren sich die von dem Mechanismus von Westcott et al. gesammelten Informationen auf einzelne Ereigniseigenschaften, beispielsweise Cache-Fehler, und stellen keine nutzbaren Informationen zum Bestimmen von Beziehungen zwischen Befehlen dar.
In jüngerer Zeit ist ein Hardware-Mechanismus vorgeschlagen worden, der als "informing loads" bezeichnet wird, siehe Horowitz et al. "Informing memory operations: Providing memory performance feedback in modern processors", Proceedings 23^rd Annual International Symposium on Computer Architecture, S. 260–270, 22. Mai 1996. Dabei kann auf eine Speicheroperation eine abhängige Verzweigungs-Operation folgen, die nur dann ausgeführt wird, wenn die Speicheroperation bezüglich des Caches falsch abläuft. Obwohl er nicht speziell für das Profilieren bestimmt ist, könnte dieser Mechanismus insbesondere eingesetzt werden, um D-Cache-Fehler-Ereignisinformationen zu sammeln.
In anderer spezialisierter Hardware, die als Cache-Fehler-Vorgriffs(cache miss lookaside – CML)-Puffer bezeichnet wird, werden virtuelle Speicherseiten identifiziert, die eine Hochpegel-2-Cache-Fehlerrate aufweisen, wobei sich eine vollständige Beschreibung in Bershad et al. "Avoiding conflict misses dynamically in large direct-mapped caches", Proceedings of the Sixth International Conference on Architectural Support for Programming Languages and Operating Systems, S. 158–170, 4. Oktober 1994, findet.
Einige Prozessoren, wie beispielsweise der Intel Pentium ermöglichen es Software, den Inhalt des Verzweigungsziel-Puffers (branch target buffer – BTB) des Verzweigungs-Prädikators zu lesen. Durch periodisches Lesen des BTB in Software haben Conte et al. ein Verfahren mit sehr niedriger Verwaltungszeit zum Schätzen von Rand-Aufführungsfrequenzen eines Programms entwickelt, siehe "Using branch handling hardware to support profile-driven optimization", Proceedings of the 27^th Annual International Symposium on Microarchitecture, S. 12–21, 30. November 1994.
Das Verfahren erzeugt Informationen, die denen ähneln, die ermittelt werden könnten, wenn die Verzweigungsrichtungs-Informationen verfolgt werden, die in einem "Profil-Protokoll" enthalten sind, das damit zusammenhängende Abtastinformationen speichert. In jüngster Zeit haben Conte et al. ein zusätzliches Hardware-Element vorgeschlagen, das als Profil-Puffer bezeichnet wird, und die Häufigkeit zählt, mit der eine Verzweigung benutzt und nicht benutzt wird, siehe "Accurate and practical profile-driven compilation using the profile buffer", Proceedings of the 29^th Annual International Symposium on Microarchitecture, S. 36–45, 2. Dezember 1996.
Es werden eine Vorrichtung und ein Verfahren zum Messen der Funktion von Prozessoren geschaffen, die von den traditionellen Mechanismen abweichen. Statt Ereignisse zu zählen und den Programmstufenzähler abzutasten, wenn es zum Überlaufen von Ereigniszählern kommt, beruhen die vorliegende Vorrichtung und das Verfahren auf dem willkürlichen Auswählen einer Untergruppe/gleichzeitig ausgeführten Befehlen und dem Abtasten detaillierter Status-Informationen für die ausgewählten Befehle.
Periodisch wird während der Funktion eines Prozessors ein zu profilierender Befehl willkürlich ausgewählt, und ein Profil-Protokoll darüber, was während der Ausführung des Befehls geschieht, wird in einer Gruppe von internen Profil-Registern des Prozessors gespeichert. Wenn die Verarbeitung des ausgewählten Befehls abgeschlossen ist, d. h. der Befehl abgelegt, abgebrochen oder aufgehalten wird, wird eine Unterbrechung erzeugt. Die aufgezeichneten Informationen, die Details darüber angeben, wie der Befehl in der Pipeline verarbeitet wurde, können von den internen Profil-Registern über Software abgetastet werden.
Die Profil-Register können viele nützliche Fakten über die Ausführung eines Befehls aufzeichnen. Zu Beispielen für Leistungsinformationen gehören: die Anzahl von Zyklen, die der ausgewählte Befehl in jeder Stufe einer Ausführungs-Pipeline verbracht hat, d. h. Stufen-Latenzen, ob bei dem Befehl I-Cache- oder D-Cache-Fehler aufgetreten sind, die effektiven Adressen seiner Speicher-Operanden und/oder Verzweigungs/Sprungziele und ob der Befehl abgelegt oder abgebrochen wurde.
Bei der Reihenfolge nach arbeitenden Prozessoren ist es möglich, die Gesamtzahl von Verzögerungs-Zyklen zu schätzen, die jedem Befehl zuzuordnen sind, wenn die Abruf-Ablege-Latenzen abgerufener Befehle bekannt sind. Dies reicht aus, um Engpässe zu identifizieren, da ein verzögerter Befehl einen weiteren verzögerten Befehl überlappen kann.
Bei einem nicht der Reihenfolge nach arbeitenden Prozessor ist es wahrscheinlich, dass die meisten Verzögerung einander überlappen und durch andere Befehle verschleiert werden, die um den verzögerten Befehl herum außerhalb der Reihenfolge ausgegeben wurde. Damit wird die Identifizierung verzögerter Befehle erschwert. Des Weiteren kann es nötig sein, Informationen über den durchschnittlichen Pegel der Gleichzeitigkeit bzw. Simultanität beim Ausführen jedes Befehls zu sammeln, um Engpässe zu identifizieren.
Spezielle Hardware könnte die Anzahl von Befehlen zählen und aufzeichnen, die ausgegeben werden, während ein profilierter Befehl ausgeführt wird, um den Pegel der gleichzeitigen Ausführung zu messen. Damit werden jedoch Befehle, die ausgegeben, allerdings abgebrochen werden und daher nicht ausscheiden können, nicht berücksichtigt. Hier wird der Grad der nützlichen Gleichzeitigkeit gemessen. Die nützliche Gleichzeitigkeit ist die durchschnittliche Zahl von Befehlen, die parallel ausgegeben werden und bei einem bestimmten Befehl erfolgreich ausscheiden. Befehle, die ausgegeben werden, jedoch anschließend abgebrochen werden, haben keinen Nutzen. Damit können Befehle, deren Verzögerungen durch die nützliche Gleichzeitigkeit nicht verschleiert werden, als Engpässe eingestuft werden. Das heißt, ein ausschlaggebendes Maß zum Erkennen von Leistungsengpässen in einem nicht der Reihenfolge nach arbeitenden Prozessor ist die Anzahl von Ausgabeschlitzen, die nicht genutzt werden, während ein bestimmter Befehl ausgeführt wird.
Dementsprechend ist, um die nützliche Gleichzeitigkeit zu messen, ein Verfahren vorhanden, das als "paarweises Abtasten" bezeichnet wird. Die Grundidee besteht darin, eine verschachtelte Form des Abtastens einzusetzen. Dabei wird ein Fenster von Befehlen, die gleichzeitig mit einem ersten profilierten Befehl ausgeführt werden können, dynamisch definiert. Ein zweiter Befehl wird willkürlich zum Profilieren aus dem Fenster von Befehlen ausgewählt. Der profilierte und der zweite Befehl bilden ein Abtast-Paar, für das Profil-Informationen gesammelt werden können.
Das paarweise Abtasten erleichtert das Bestimmen der Anzahl von nicht genutzten Ausgabe-Schlitzen, die jedem Befehl zugeordnet werden können, und identifiziert Engpässe erheblich genauer als bekannte Verfahren. Im Allgemeinen ist das paarweise Abtasten sehr flexibel und bildet die Basis für eine Analyse, mit der ein breites Spektrum an interessierenden Größen des Auftretens und der Nutzung bestimmt werden können.
Höherstufige Software kann Nachverarbeitung von Informationen durchführen, die auf verschiedene Weise erfasst wurden, so beispielsweise durch das Zusammenfassen von Informationen von mehreren Ausführungen ein und desselben Befehls.
Zu Beispielen für Informationen, die erfasst werden können, gehören: die Befehls-Adresse (Programmstufenzähler bzw. PC), ob bei dem Befehl ein Befehls-Cache-Fehler aufgetreten ist und die zur Behebung des Fehlers aufgetretene Latenz. Wenn der Befehl eine Speicheroperation ausführt, wird bestimmt, ob bei dem Befehl ein Daten-Cache-Fehler aufgetreten ist, und die Latenz zur Erfüllung der Speicher-Anforderung wird gemessen. Des Weiteren kann die Länge der Zeit, die der Befehl in jeder Pipeline-Stufe verbringt, gemessen werden. Die Profil-Informationen können auch anzeigen, ob der Befehl ausgeschieden ist oder unterbrochen wurde, und in letzterem Fall, welches Hindernis bewirkt hat, dass die Ausführung des Befehls abgebrochen wurde.
Die Informationen werden in einer Gruppe Profilier- bzw. Profilbildungs-Registern gesammelt, wenn der Befehl die Ausführungs-Pipeline durchläuft. Wenn die Ausführung eines Befehls beendet wird und zwar entweder, weil er ausscheidet oder weil er abgebrochen wird, wird höherstufiger Software ein Interrupt bzw. eine Unterbrechung zugeführt. Die Software kann dann die in den Profilbildungs-Registern vorhandenen Informationen auf verschiedene Weise verarbeiten.
Obwohl die abgetasteten Leistungs-Informationen sehr nützlich für die profilgerichtete Optimierung sind, gibt es auch zahlreiche Einsatzgebiete für Hardware-Ereigniszähler, so beispielsweise das Zählen der Gesamthäufigkeit des Auftretens eines Ereignisses.
Die offenbarte Technologie stellt eine Verbesserung gegenüber vorhandener Leistungsüberwachungs-Hardware dar und kann zu relativ niedrigen Hardwarekosten in modernen Mikroprozessoren umgesetzt werden, die Befehle außerhalb der Reihenfolge ausgeben können.
Der Artikel "Instruction Match Function for Processed Performance Monitoring" im IBM Technical Disclosure Bulletin, Nr. 12, Dezember 1996, Seite 119–124 offenbart eine Vor richtung zum Abtasten von Befehlen, die vor dem Abtasten von einem Abwickler (dispatcher) identifiziert werden.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird eine Vorrichtung zum Abtasten von Befehlen in einer Prozessor-Pipeline eines Systems geschaffen, wobei die Pipeline eine Vielzahl von Verarbeitungsstufen aufweist, und die Vorrichtung umfasst:
eine Einrichtung, die Befehle in eine erste Stufe der Pipeline abruft, wobei jeder Befehl eine Vielzahl von Anzeige-Feldern aufweist, die ein Abtast-Bit und ein Feld für eine Abtast-Register-Datei-Kennung enthalten;
eine Einrichtung, die willkürlich jede beliebige Teilgruppe simultan ausgeführter abgerufener Befehle als ausgewählte Befehle zum Abtasten identifiziert, indem das Abtast-Bit in den ausgewählten Befehlen bestätigt wird;
eine Einrichtung, die Status-Informationen des Systems bereitstellt, während sich beliebige der ausgewählten Befehle in einer beliebigen Stufe der Pipeline befinden;
eine Vielzahl von Profil-Registern, die die Status-Informationen speichern; und
eine Einrichtung, die eine Software-Anwendung informiert, dass alle der ausgewählten Befehle die Pipeline verlassen haben, so dass die Software-Anwendung beliebige der Status-Informationen lesen kann.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Abtasten von Befehlen in einer Prozessor-Pipeline eines Systems geschaffen, wobei die Pipeline eine Vielzahl von Verarbeitungsstufen aufweist und das Verfahren die folgenden Schritte umfasst:
Abrufen simultan ausgeführter Befehle in eine erste Stufe der Pipeline, wobei jeder Befehl eine Vielzahl von Anzeige-Feldern aufweist, die ein Abtast-Bit und ein Feld für eine Abtast-Register-Datei-Kennung enthalten;
willkürliches Identifizieren jeder beliebigen Teilgruppe abgerufener Befehle als ausgewählte Befehle durch Bestätigen des Abtast-Bits in den ausgewählten Befehlen;
Bereitstellen von Status-Informationen des Befehls, während sich beliebige der ausgewählten Befehle in einer beliebigen Stufe der Pipeline befindet;
Speichern der Status-Informationen in einer Vielzahl von Profil-Registern; und
Informieren einer Software-Anwendung, dass alle der ausgewählten Befehle die Pipeline verlassen haben, so dass die Software-Anwendung beliebige der Zustands-Informationen lesen kann.
Bei den beigefügten Zeichnungen ist:
1 ein Blockschaltbild eines Computersystems mit befehlsausgelöster Zustands- bzw. Status-Abtastung;
2a ein Blockschaltbild einer Mikroprozessor-Ausführungs-Pipeline zum Verarbeiten abgetasteter Befehle;
2b ein Blockschaltbild der Pipeline, die Status-Informationen zeigt, die abgetastet werden können;
3 ein Blockschema einer Register-Datei zum Speichern von Profil-Informationen;
4 ein Blockschema eines verbesserten Befehls;
5 ein Blockschaltbild zum Profilieren ausgewählter Befehle;
6 ein Schema einer Schaltung zum Messen von Pipeline-Latenzen;
7a ein Flussdiagramm eines Prozesses zum Abtasten von Befehlen;
7b ein Flussdiagramm eines Prozesses zum Schätzen von Statistiken von Eigenschaften von Befehlen, die von der Prozessor-Pipeline verarbeitet werden;
8a eine Darstellung einer Abfolge abgerufener Befehle mit Abtast-Fenstern;
8b und 8c Darstellungen von Abruf-Abständen und zeitlicher Überlappung abgerufener Befehle; und
Übersicht über das System
1 zeigt ein Computersystem 100, bei dem das Verfahren und die Vorrichtung zum Abtasten, die hier beschrieben sind, eingesetzt werden können. Das System 100 enthält einen oder mehrere Prozessoren 110, externe Speicher 120 sowie Ein-/Ausgabe-Schnittstellen (I/O) 130, die durch Busleitungen 140 verbunden sind. Die Prozessoren 110 können auf integrierten Halbleiterchips als Mehrfachausführungs-Pipelines 111 ausgeführt werden, die funktionale Ausführungs-Einheiten, interne Daten-Caches (D-Cache) 113 und Befehls-Caches (I-Cache) 112 enthalten, wie beispielsweise der Prozessor Alpha 21264 von Digital Equipment Corporation. Der Prozessor-Chip 110 enthält des Weiteren Hardware 119 zum Abtasten von Prozessor-Zuständen für ausgewählte Befehle, die weiter unten ausführlicher beschrieben ist.
Die externen Speicher 120 können hierarchisch angeordnet sein, und Mehrzweck-Caches (B-Cache bzw. SRAM) 121, flüchtige Speicher (DRAM) 122 und Festspeicher (Platte) 123 enthalten. Die I/O 130 kann eingesetzt werden, um Daten in das System 100 ein- bzw. aus ihm auszugeben.
Funktion
Während der Funktion des Systems 100 werden Befehle und Daten von Software-Programmen in den Speichern 120 gespeichert. Die Befehle und Daten werden auf herkömmliche Weise unter Verwendung von Kompilier-, Binde- und Ladeverfahren erzeugt. Die Befehle und Daten werden über die Caches 112–113 zu der Ausführungs-Pipeline 111 eines der Prozessoren 110 übertragen. In der Pipeline werden die Befehle zur Ausführung dekodiert. Einige der Befehle verarbeiten die Daten. Andere Befehle steuern den Ausführungsstrom der Programme.
Es ist wünschenswert, detaillierte Leistungsdaten zu erfassen, während die Befehle ausgeführt werden. Die Leistungsdaten können sich auf Speicheroperationen und Ausführungsströme beziehen.
Prozessor-Pipeline
2a zeigt eine Ausführungs-Pipeline 200 eines der Prozessoren 110 in 1 mit einer Vielzahl von Stufen, die der Reihe nach angeordnet sind, so beispielsweise als Abruf-, Abbildungs- bzw. Zuordnungs-, Ausgabe-, Ausführungs- und Ausscheide- bzw. Ablege-Einheiten 210, 220, 230, 240 bzw. 250. Die Rate, mit der die Pipeline 200 Informationen (Daten und Befehle) verarbeitet, wird mit Systemtakt-Signalen in Leitungen 201, d. h. sogenannten Takt-"Zyklen", gesteuert.
Jeder Takt-Zyklus definiert einen "Schlitz" bzw. ein Zeitintervall, in dem eine Stufe der Pipeline 200 einen diskreten Verarbeitungsvorgang ausführen kann. Ein Verarbeitungs-Schlitz transportiert normalerweise Befehle und bei den Ausführungs-Einheiten, wie unten beschrieben, Daten, im Folgenden allgemein als "Daten-Elemente" bezeichnet. In einigen Fällen, so beispielsweise bei Verzweigungs-Fehlvorhersagen oder Cache-Fehlern oder Pipeline-Verzögerungen, läuft der Zyklus des Taktgebers weiter, jedoch werden keine sinnvollen Befehle transportiert.
Ein Vorteil der vorliegenden Vorrichtung und des Verfahrens besteht darin, dass mit ihnen Informationen über Prozessor-Schlitze abgetastet werden können, die "Abfall"- bzw. nutzlose Daten transportieren. Diese sind als "ungenutzte" Schlitze bekannt. Das Identifizieren und Abtasten von ungenutzten Schlitzen kann eine wichtige Vorstufe zum Optimieren von Aufgaben sein, da ungenutzte Schlitze keinen Nutzen bringen und daher die Leistung des Systems verschlechtern. Daher werden hier nicht wie dem Stand der Technik nach einfach "Ereignisse" oder "Befehle" abgetastet, sondern Status-Informationen, die sich auf den Durchlauf von Prozessor-Schlitzen durch die Pipeline 200 beziehen, unabhängig davon, ob sie sich auf wertvolle oder wertlose Befehle beziehen.
Abruf-Einheit
Der B-Cache 121 überträgt Datenelemente zu dem I-Cache 112 bzw. dem D-Cache 113. Die Abruf-Einheit 210, bei der ein Übersetzungs-Vorgriffs-Speicher (translation look-aside buffer – TLB) 205 eingesetzt wird, um virtuelle Adressen in physische Adressen aufzulösen, ruft die als nächstes auszuführenden Befehle aus dem I-Cache 112 ab. Die aus dem I-Cache 112 abgerufenen Elemente sind im Allgemeinen ausführbare Befehle. Es kann sich jedoch dabei auch um wertlose Befehle handeln, wie beispielsweise bei I-Cache-Fehlern um "Abfall"-Daten, d. h. nicht um einen Befehl.
Vorzugsweise wird eine Gruppe von "Befehlen" während eines einzelnen Prozessor-Zyklus abgerufen. Die Gruppe kann beispielsweise vier Befehle enthalten. Das heißt, die Pipeline 200 ist vier Schlitze breit. Die Anzahl von Schlitzen kann von der Anzahl zur Verfügung stehender Ausführungs-Einheiten abhängen. Bei anderen Typen von Prozessoren können weniger oder mehr Befehle während eines einzelnen Prozessor-Zyklus abgerufen werden. Im Allgemeinen bedeutet dies, dass jeder Zyklus vier Verarbeitungs-Schlitze aus dem Cache füllt. Einige der Schlitze werden möglicherweise nicht genutzt, wenn der I-Cache 112 die Daten nicht zur Verfügung hat. Statt anzuhalten und damit die gesamte Verarbeitung aufzuhalten, werden die Schlitze in jedem Fall weiter transportiert, um sie zum Abtasten bereitzustellen, obwohl ein nutzloser "Befehl" in einem Schlitz möglicherweise nie zur Ausführung ausgegeben wird.
Während des Abrufens können ausgewählte Befehle um zusätzliche Informationen erweitert werden, um Abtasten und System-Profilieren zu ermöglichen. Ein erweiterter Befehl wird weiter unten unter Bezugnahme auf 4 beschrieben. Es ist anzumerken, dass bei anderen Ausführungen die Erweiterung der ausgewählten Befehle in jeder der Stufen des Prozessors einschließlich der Ausgabe-Einheit 230 stattfinden kann.
Abbildungs-Einheit
In dem System werden die Operanden von Befehlen unter Verwendungen der Abbildungs-Einheit 220 in der nächsten Stufe der Pipeline 200 dynamisch physischen Registern zugewiesen bzw. auf diesen "abgebildet". Die Abbildungs-Einheit weist architekto nischen bzw. "virtuellen" Registern physische Register zu. Das heißt, es ist möglicherweise keine eins-zu-eins-Entsprechung zwischen virtuellen und physischen Registern vorhanden.
Ausgabe-Einheit
In der nächsten Stufe werden abgerufene Befehle durch eine Ausgabe-Einheit 230 geordnet. Die Ausgabe-Einheit 230 enthält eine Ausgabeschlange mit einem Schlangen-Anfangs-Eintrag 231 für den nächsten auszuführenden Befehl. Es ist anzumerken, dass ein oder mehrere Befehle in der Ausgabe-Einheit 230 verzögert werden können, weil von den Befehlen benötigte Ressourcen nicht zur Verfügung stehen. Daher können andere anhängige Befehle aus der Schlange 230 außerhalb der Reihenfolge "um" die verzögerten Befehle ausgegeben werden. Die richtige Ausführungsreihenfolge wird in der weiter unten beschriebenen Ablegeeinheit 250 bestätigt.
Ausführungs-Einheiten
Die Befehle werden an funktionale Ausführungs-Einheiten "E0, ..., E3) 241 sowie eine Id/st-Einheit 242 ausgegeben. Jede der Ausführungs-Einheiten 241 kann so ausgeführt sein, dass sie Befehle mit bestimmten Typen von Operator-Codes (opcodes) handhabt, so beispielsweise Integral- und Gleitkomma-Arithmetik, Verzweigungs- und Sprungbefehle, usw. Die Id/st-Einheit 240 führt Speicherzugriffs-Befehle aus, d. h. lädt Daten aus dem D-Cache 113 und speichert sie in ihm. Die Id/st-Einheit 242 ist gesondert angegeben, da bei ihr lange Verzögerungen auftreten können. Es ist des Weiteren anzumerken, dass Speicherzugriffsbefehle mit langen Latenzen lange vor dem Eintreffen der Daten in dem Prozessor "abgeschlossen" werden können, um den Durchsatz zu verbessern.
Ablege- bzw. Ausscheide-Einheit
Die Beendigung der Ausführung eines Befehls wird von der Ablege-Einheit 250 gehandhabt. Die Ablege-Einheit 250 hält den Verarbeitungs-Status fest. Es ist anzumerken, dass einige Befehle abgebrochen oder unterbrochen werden können. So kann sich beispielsweise der Ausführungsstrom ändern, nachdem ein Befehl abgerufen worden ist, oder ein Befehl kann ausnahmsweise unterbrochen werden. In diesen Fällen werden der Befehl und alle folgenden Befehle, die sich bereits in der Pipeline befinden, verworfen, und der spekulative Verarbeitungs-Status wird zurückgesetzt. Vorteilhafterweise werden dabei verworfene oder "abgebrochene" Befehle ebenfalls profiliert, wie dies auch für nichtgenutzte Prozessor-Schlitze zutrifft. Das heißt, Beendigung kann bedeuten, dass ein vollständig ausgeführter gültiger Befehl abgelegt wird, ein teilweise ausgeführter gültiger Befehl nachverarbeitet wird oder ein ungültiger Befehl oder ein nichtgenutzter Schlitz verworfen wird.
Die Grundidee, die dem vorliegenden Verfahren zugrunde liegt, folgt der Verarbeitung von "Datenelementen" in ausgewählten "Schlitzen", vorwiegend Befehlen, während sie sich durch die Stufen der Pipeline 200 bewegen. Profilierungs-Hardware sammelt dynamisch detaillierte Status-Informationen. Die Status-Informationen können aus jeder beliebigen der Pipeline-Stufen oder einer anderen Stelle in dem System 100 stammen, so beispielsweise aus Caches der ersten und der zweiten Stufe oder anderen Teilsystemen. Die Status-Informationen können direkt speziellen Ereignissen zugeordnet werden.
Dabei besteht die Ausführungsstrategie darin, Informationen, die schwer statisch bestimmt werden können, in einem Profil-Protokoll zu sammeln. Dadurch kann das Profil-Protokoll für Leistungswerkzeuge, die auf Profilierung gerichtete Optimierung oder für Ressourcenzuweisungs-Strategieentscheidungen in Betriebssystemen und bei Software auf Anwendungsbasis genutzt werden, wobei dies direkte dynamische Regulierung in Reaktion auf das Abtasten und die Analyse einschließt. Es ist zu wiederholen, dass das vorliegende Verfahren und die Vorrichtung für den Betrieb auf realen funktionierenden Systemen bestimmt sind.
Um zu bestimmen, welche Status-Informationen von Interesse für die Speicherung als Teil des Profil-Protokolls sind, ist es sinnvoll, die Informationen zu prüfen, die theoretisch für die verschiedenen Stufen der Pipeline 200 eines modernen, nicht der Reihenfolge nach arbeitenden Mikroprozessors zur Verfügung stehen, wie er in 2b dargestellt ist.
Die Stufen der Pipeline sind, wie in 2b dargestellt, der Abruf 210, die Abbildung bzw. Zuordnung 220, die Ausgabe 230, die Ausführung 240 und das Ablegen 250. Während jeder dieser Stufen kann in Abhängigkeit von der speziellen Ausführung jeder "un terwegs befindliche" Befehl 202, der von der Pipeline 200 verarbeitet wird, zum Abtasten durch Leitung 512 ausgewählt werden. Die Auswahl wird durch einen Wert eines Zählers 510 gesteuert. Der Wert des Zählers kann durch Leitung (init) 511 initialisiert werden.
Status-Informationen, wie beispielsweise Befehls-Adressen (PC) 281, Verzweigungsablauf-Bits (HIST) 282, Stufen-Latenzen 283, Verzweigungsweg-Anzeige (T) 287, Daten-Adressen (ADDR) 284, Daten-Fehler (MISS) 285, und Ausscheide-Status 286 können auf Leitungen 288 abgetastet werden. Der Abschluss der Bearbeitung der ausgewählten Befehle kann ein Unterbrechungs-Signal auf Leitung 289 erzeugen. Das Unterbrechungs-Signal 289 kann bewirken, dass Software die Status-Informationen 281–286 über Leitungen 299 abtastet. Als Alternative dazu kann Software die Leitung 289 über ein internes Prozessor-Register 541 abfragen.
Architektur supersklarer, nicht der Reihenfolge nach arbeitender Prozessoren
Ein nicht der Reihenfolge arbeitender Ausführungs-Prozessor nimmt das Abrufen und Ablegen von Befehlen der Reihenfolge nach vor, führt sie jedoch entsprechend ihrer Daten-Abhängigkeiten aus. Ein Befehl wird von dem Zeitpunkt, zu dem er abgerufen wird, bis zu seinem Abschluss, d. h. Ausscheiden oder Abbruch, als "unterwegs seiend" bezeichnet. Befehle werden nach Abbildung in die Ausgabe-Einheit 230 gebracht und warten, bis Register, die Eingangs-Operanden enthalten, aktualisiert werden.
In jedem Prozessorzyklus ruft die Abruf-Einheit 210 eine Gruppe von Befehlen aus dem Befehls-Cache 112 ab und decodiert sie. Der Befehls-Dekodierer, der Teil der Abruf-Einheit 210 sein kann, stellt fest, welche Befehle in der abgerufenen Gruppe Teil des Befehls-Stroms sind. Da mehrere Zyklen erforderlich sind, um den Programmstufenzähler (PC) eines nächsten abzurufenden Befehls aufzulösen, wird der nächste PC durch einen Verzweigungs- bzw. Sprung-Prädiktor vorhergesagt, der Teil der Abruf-Einheit 210 sein kann. Wenn die Vorhersage nicht stimmt, bricht der Prozessor die falsch vorhergesagten Befehle, d. h. die auf einem "schlechten" Weg abgerufenen Befehle, ab und beginnt erneut Befehle auf dem "guten" Weg abzurufen.
Damit Befehle außerhalb der Reihenfolge ausgeführt werden können, werden Register dynamisch durch die Abbildungs- bzw. Zuordnungseinheit 220 umbenannt, um Schreiben-nach-Lesen- und Schreiben-nach-Schreiben-Konflikte zu verhindern. Zwei Befehle, die in ein und dasselbe virtuelle Register schreiben, können sicher außerhalb der Reihenfolge ausgeführt werden, da sie in verschiedene physische Register schreiben, und Abnehmer der virtuellen Register erhalten die richtigen Werte. Befehle werden der Reihenfolge nach abgerufen, abgebildet und abgelegt, können jedoch außerhalb der Reihenfolge ausgeführt werden.
Die Register-Abbildungs-Einheit 220 weist Operanden abgerufener Befehle gültigen physischen Registern zu. Das heißt, die virtuellen Namen der Register-Operanden werden auf den physischen Registerraum des Prozessors umbenannt. Befehle werden dann zu der Befehls-Schlange 230 weitergeleitet, wo sie vor der Ausführung zwei Ereignisse abwarten. Zunächst müssen ihre Register-Abhängigkeiten aufgelöst werden. Zweitens müssen die Ressourcen, die der Befehl braucht, z. B. Ausführungs-Einheiten, Register, Cache-Ports, Speicher-Schlangen usw., zur Verfügung stehen. Das bedeutet, dass erforderliche Ressourcen nicht für alle momentan abgebildeten bzw. zugeordneten Befehle erneut zugeordnet werden können.
Wenn diese beiden Bedingungen für einen Befehl erfüllt sind, werden die Operanden des Befehls in der physischen Registerdatei nachgeschlagen. Der Inhalt der Operanden-Register und einige Informationen über den Befehl werden zu der entsprechenden Ausführungs-Einheit 240 gesendet und ausgeführt. Wenn die Ausführung des Befehls abgeschlossen ist und der Befehl der älteste "nicht abgelegte" Befehl in dem Prozessor ist, wird der Befehl abgelegt. Dadurch werden die Ressourcen freigesetzt, die von dem Befehl genutzt wurden, so beispielsweise physische Register und Cache-Ports.
Zahlreiche Ereignisse können die Ausführung eines Befehls verzögern. Am vorderen Ende der Pipeline kann es zur Verzögerung an der Abruf-Einheit 210 aufgrund eines Fehlers im I-Cache 112 kommen, oder die Abruf-Einheit 210 kann Befehle eines falsch vorhergesagten Weges abrufen. Bei der Abbildungs-Einheit 220 kann es aufgrund des Mangels an freien physischen Registern oder des Mangels an freien Schlitzen in der Ausgabe-Einheit 230 zu Verzögerungen kommen.
Befehle in der Ausgabe-Einheit 230 können darauf warten, dass ihre Register-Abhängigkeiten erfüllt werden, oder auf die Verfügbarkeit von Ausführungs-Einheiten 240. Es kann zu Verzögerungen von Befehlen aufgrund von Fehlern in dem D-Cache kommen. Befehle können aufgehalten werden, weil sie spekulativ auf einem schlechten Weg ausgegeben wurden, oder weil der Prozessor eine Unterbrechung vorgenommen hat, so beispielsweise aufgrund einer unzulässigen Operation oder Speicheradresse. Viele dieser Bedingungen lassen sich schwer in Kompilierungszeit vorhersagen, und alle führen zu einer Verschlechterung der Leistung des Systems 100. Daher ist es sinnvoll, die zur Verfügung stehenden Informationen auf den Leitungen 288 abzutasten.
Profilinformations-Register
Daher ist, wie in 3 dargestellt, ein Speicher 300 zum Speichern von Profil-Informationen für jeden abgetasteten Befehl vorhanden. Der Speicher 300 kann die Form einer Register-Datei bzw. eines Puffers haben. Das heißt, ein ausgewählter Befehl, der abgetastet wird, wird direkt mit der Register-Datei 300 identifiziert. Die Register-Datei 300 kann eine Vielzahl von Registern enthalten. Als Alternative dazu kann die Datei 300 als ein einzelnes indexierbares Register mit mehreren Feldern ausgeführt werden.
Die Datei 300 ist mit den Komponenten der Pipeline 200 über Leitungen 288 in 2b verbunden, so dass Leistungs-Informationen, die sich auf den ausgewählten Befehl beziehen, für jede Stufe der Pipeline 200 erfasst werden können. Es ist anzumerken, dass die Profil-Register 300 mehr als einfache "Ereignis"-Zähler sind, wie sie beim Stand der Technik vorhanden sind, da die Register hier Leistungs-Informationen sammeln, die bestimmten bekannten Befehlen und Ereignissen zugewiesen werden können.
In 3 hängt die Anzahl von Bits, die jedem Register zugeordnet wird, von dem Typ der Informationen ab, die darin gespeichert sind, so beispielsweise Befehls-Adressen (64 Bits), Zyklus-Zählwerten, d. h. Latenzen (8 bis 10 Bits), diskreten Ereignissen (1 Bit pro Ereignis) usw. Diese Zahlen stellen lediglich eine Richtlinie dar. Bei anderen Ausführungen können andere Bit-Zahlen für die verschiedenen Register 300 verwendet werden, d. h. es handelt sich um eine konstruktive Entscheidung.
Bei der bevorzugten Ausführung speichert ein Profil-Programmstufenzähler-Register 310 den Programmstufenzähler (PC) des ausgewählten Befehls. Bei einem Befehl, der profiliert wird, wird ein "Profil"-Bit bestätigt. Das PC-Register 310 kann des Weiteren den Opcode des ausgewählten Befehls enthalten. Darüber hinaus können bei Prozessoren, die Mehrfachpfad-Ausführung ermöglichen, zusätzliche Bits des Registers 310 die Kennung des Pfades speichern. Andere Felder des Registers 310 können die Prozess-Kennung, die Adressenraum-Nummer, die CPU-Nummer und die Befehls-Nummer (inum) des ausgeführten Befehls speichern. Des Weiteren kann Register 310 bei Prozessoren mit mehreren logischen Registergruppen, d. h. Hardware-Kontexten und gleichzeitig ausgeführten Pfaden, Hardware-Kontext und Pfad-Kennungen speichern. Indem diese Informationen gespeichert werden, können die Profil-Informationen direkt einem bestimmten Befehl zugeordnet werden. Des Weiteren können die abgetasteten Informationen entsprechend dem Bereich von Adressen, Opcode, Ausführungs-Pfaden, Adress-Räumen und dergleichen gefiltert werden.
In ein Profil-Effektivadressen-Register 320 wird eine Adresse geladen, die mit dem ausgewählten Befehl verbunden ist. Wenn es sich bei dem Befehl um einen Speicherzugriffs-Befehl, wie beispielsweise Laden oder Speichern, handelt, dann wird die effektive 64-Bit-Virtuellspeicher-Adresse erfasst. Wenn es sich bei dem Befehl um einen Sprung oder eine Verzweigung handelt, dann wird der Ziel-PC aufgezeichnet.
Ein Vorteil des vorliegenden Abtastverfahrens besteht darin, dass alle "Befehle", die von der Pipeline 200 verarbeitet werden, mit der gleichen Wahrscheinlichkeit zum Abtasten ausgewählt werden, und zwar unabhängig von der Abtastrate. Bei den Befehlen kann es sich um gültige Befehle, ungültige Befehle, nicht unterbrechbare Befehle oder "Abfall"-Befehle handeln. Die erfassten effektiven Adressen sind statistisch repräsentativ für das Gesamtverhalten des Programms. Indem die effektiven Adressen abgetasteter Befehle erfasst werden, können Speicherzugriffe und Ausführungs-Ströme genau tatsächlichen dynamischen Ausführungen zugeordnet werden.
Ein profiliertes Ereignis-Register 330 wird beispielsweise in 1-Bit-Felder unterteilt. Die 1-Bit-Felder zeichnen Ereignisse für den ausgewählten Befehl auf. Wenn ein Befehl ausgewählt wird, wird zunächst das Register gelöscht. Zu Ereignissen könnten Cache-Fehler, Verzweigungs-Fehlvorhersagen, Ressourcen-Konflikte, Unterbrechungen und Aus nahmezustände, Ausscheidung/Abbruch/Ungültigkeit, TLB-Fehler, Nutzung/Nichtnutzung, Datenabhängigkeits-Verzögerung, Ressourcenabhängigkeits-Verzögerungen usw. gehören. Es ist anzumerken, dass die vorliegende Ausführung es ermöglicht, einem einzelnen Befehl mehrere Ereignisse zuzuordnen. Es ist anzumerken, dass Ereignis-Informationen sowohl für ausgeschiedene als auch für abgebrochene Befehle gesammelt werden. Um die Größe des Ereignis-Registers 330 zu verringern, können einige der Bit-Felder verwendet werden, um je nach dem Opcode des Befehls unterschiedliche Typen einander ausschließender Ereignisse aufzuzeichnen.
Ein profiliertes Weg-Register 340 wird eingesetzt, um Verzweigungs-Nutzungs/Nichtnutzungs-Informationen aus einer Verzweigungs-Verlaufstabelle zu erfassen. Verzweigungs-Verlaufstabellen sind in der Technik für andere Einsatzzwecke bekannt. Der globale Verzweigungs-Nutzungsverlauf kann eingesetzt werden, um den Ausführungs-Weg anzuzeigen, der bewirkt, dass der ausgewählte Befehl abgerufen wurde. Es ist anzumerken, dass es sich bei dem Befehl nicht um einen Verzweigungs-Befehl handeln muss, um diese Informationen nutzen zu können. Die Nutzung der Weg-Informationen wird weiter unten ausführlicher beschrieben.
Latenz-Register 350 speichern Zeitablaufinformationen, die an Fixpunkten erfasst werden, während ein ausgewählter Befehl unterwegs ist, beispielsweise zwischen den verschiedenen Stufen der Pipeline 200. Die Fixpunkte können sich von Prozessor zu Prozessor unterscheiden, wobei dies davon abhängt, wo ein Befehl verzögert werden kann, wenn er auf ein Ereignis oder eine Ressource wartet. Jedes Latenz-Register 350 zählt die Anzahl von Zyklen, die ein Befehl zwischen zwei Fixpunkten verbracht hat.
Wenn der ausgewählte Befehl einen Fixpunkt passiert, d. h. in eine nächste Stufe in der Pipeline 200 eintritt, wird zunächst das entsprechende Latenz-Register 350 gelöscht und dann um einen Zyklus weitergerückt, bis der Befehl den nächsten Fixpunkt passiert, woraufhin das nächste Latenz-Register initialisiert wird und mit dem Zählen beginnt. Die Anzahl von Latenz-Registern 350 hängt von der Anzahl von Stufen der Pipeline 200 in einer speziellen Ausführung ab. Ein komplettes Latenz-Profil wird in den Latenz-Registern 350 gespeichert, wenn der Befehl abgebrochen oder ausgeschieden wird.
Eine Liste zu sammelnder Latenzen, die möglicherweise nützlich sind, enthält: Abrufen- bis-Abbilden, Abbilden-bis-Datenbereitschaft, Datenbereitschaft-bis-Ausführen, Ausführen-bis-Ablegebereitschaft, Ablegebereitschaft-bis-Ablegeverzögerungen. Für Speicher-Befehle (Laden und Speichern) kann es sich bei den Latenzen um Ausgabe-bis-Abschluss-Latenzen handeln. Diese letzte Latenz unterscheidet sich von anderen Latenzen dahingehend, dass einige Speicher-Operationen bereit zum Ablegen bzw. Ausscheiden sein können, bevor die Daten, die sie verarbeiten, tatsächlich in den Prozessor geleitet worden sind. Diese Latenzen könnten direkt in den Registern 350 gezählt werden, oder die Register können Roh-Zyklus-Zählwerte sammeln, wobei in diesem Fall Profilierungs-Software Differenzen zwischen Roh-Zählwerten für aufeinanderfolgende Stufen berechnet, um die tatsächlichen Latenzen zu bestimmen. Eine Schaltung, die Beispiel-Pipeline-Latenz-Taktzyklen zählt, wird weiter unten unter Bezugnahme auf 6 beschreben.
Das Aktualisieren der Informationen in dem/den Register/n 300 muss nicht sofort ausgeführt werden, d. h. eine Verzögerung ist akzeptabel. Es ist lediglich erforderlich, dass die Unterbrechung, die die Tatsache signalisiert, dass der ausgewählte Befehl abgeschlossen ist (ausgeschieden oder abgebrochen), verzögert wird, bis alle Informationen in der Register-Datei 300 aktualisiert worden sind, oder das Unterbrechungsprogramm kann solange warten, bis die Profil-Datei 300 aktualisiert worden ist.
Es ist anzumerken, dass die Profil-Register-Datei 300 kopiert werden kann. Wenn mehrere Kopien der Profil-Register-Datei vorhanden sind, können mehrere Befehle zum Profilieren ausgewählt werden, und zwar entweder seriell oder gleichzeitig. In diesem Fall wird jeder ausgewählte Befehl ausdrücklich mit einer speziellen Register-Datei identifiziert, wie dies weiter unten beschrieben ist. Mehrere Register-Dateien können in Reaktion auf ein einzelnes Unterbrechungs-Signal abgetastet werden, um das Maß des Verwaltungsaufwandes zu verringern.
Erweiterter Befehl
Jeder Befehl 400 enthält, wie in 4 dargestellt, ein Abtast-Feld. Bei dem Abtast-Feld kann es sich beispielsweise um ein Ein-Bit-Etikett handeln, das als das "Abtast"-Bit (S) 401 bezeichnet wird. Wenn das Abtast-Bit 401 bestätigt ist, wird der Befehl zum Abtas ten ausgewählt. Bestätigung des Bits 401 aktiviert die Abtast-Hardware, die die Profil-Informationen erfasst, und bewirkt des Weiteren die Unterbrechung, wenn der ausgewählte Befehl abgeschlossen (ausgeschieden oder abgebrochen) wird. Als Alternative dazu kann jeder "Befehl", der abgerufen worden ist, nacheinander mit einem "Inum"-Wert nummeriert werden. In diesem Fall können Befehle mit bestimmten Inum-Werten ausgewählt werden. Der Mechanismus zum Auswählen von Befehlen wird weiter unten beschrieben.
Die Profil-Register-Datei 300 kann gelesen werden, wenn die Felder aktualisiert worden sind und das Unterbrechungs-Signal erzeugt wird. Das Unterbrechungs-Signal kann bewirken, dass privilegierte Profilierungs-Software (privileged profiling software) den Inhalt der Profil-Register 300 verarbeitet. Es ist anzumerken, dass in dem Fall, in dem mehrere Abtastungen aufgezeichnet werden, eine einzelne Unterbrechung das Abtasten von Leistungs-Daten für mehrere ausgewählte Befehle bewirken kann.
Je nach der Ausführung kann der erweiterte Befehl 400 die folgenden zusätzlichen Felder enthalten, d. h. bis zu drei Befehls-Operanden (op1, op2 und op3) 411–413, den Programmstufenzähler (PC) 420, den Operator-Code (Opcode) 430. Ein Gültigkeitsfeld (V) 431 kann anzeigen, ob der "Befehl" in dem ausgewählten Schlitz gültig ist oder nicht, indem ein Ein-Bit-Feld entweder auf "wahr" oder "falsch" gesetzt wird. Die Felder 440 und 450 können reserviert werden, um I-Cache- bzw. TLB-Fehler bezüglich des Befehls anzuzeigen. Es ist anzumerken, dass, da ein einzelner Befehl mehrere Operanden enthalten kann, mehrere Fehler für diesen Befehl möglich sind.
Profil-Register-Datei ID
Bei einer etwas komplizierteren Ausführung können mehrere Befehle gleichzeitig profiliert werden. Bei dieser Ausführung sind eine Vielzahl von Register-Dateien 300 oder einzelne größere Register mit Teil-Feldern vorhanden, wobei die Anzahl von Dateien 300 der Anzahl von unterwegs seienden Befehlen entspricht, die gleichzeitig profiliert werden können. Um diesen Fall zu bearbeiten, wird der Befehl 400 ebenfalls so erweitert, dass er ein Feld 402 für eine Abtast-Register-Datei-Kennung (ID) enthält. Dies ermöglicht direkte Verknüpfung von Profil-Informationen mit einer der mehreren Register-Dateien 300. Dabei gibt es, wie oben angemerkt, eine direkte Verbindung zwischen ausgewählten Befehlen und Profil-Registern. Die Profil-Informationen, die in den Registern gesammelt werden, können daher direkt einem bestimmten Befehl zugeordnet werden.
Selbst wenn jeweils nur ein unterwegs befindlicher Befehl profiliert wird, kann es nützlich sein, die Datei bzw. das Register 300 mit dem ID-Feld 402 zu indexieren, so dass die Kosten für das Unterbrechungsprogramm der Profilierungs-Software über mehrere Befehls-Abtastungen amortisiert werden können. Um festzustellen, ob ein Befehl in einer Gruppe von Befehlen ein ausgewählter Befehl ist, kann eine "Phantom – ODER – Operation" ausgeführt werden.
Zufallsabtastung
Der Verwaltungsaufwand des vorliegenden Profilierungsvorganges wird verringert, indem die Anzahl von Befehlen eingeschränkt wird, die gleichzeitig profiliert werden können, indem beispielsweise Bit 401 gesetzt wird. Statt jeden Befehl in einem Programm oder einem Teil des Programms zu profilieren, werden hier zu profilierende Befehle während einer bestimmten Stufe der Prozessor-Pipeline 200, beispielsweise während des Abrufens, ausgewählt, und die ausgewählten Befehle werden markiert, indem das Abtast-Bit 401 bestätigt wird. Wenn das Abtast-Bit 401 bestätigt wird, leiten die Komponenten der Pipeline 200 Profil-Informationen zu der/den Profil-Register-Datei/en 300.
Die folgenden Abschnitte beschreiben zusätzliche Details des Profilierens auf Befehlsebene, wie es hier beschrieben ist.
Unterwegs-Zustände
Zunächst wird jeder dekodierte Befehls-Zustand bzw. -Status, der die Prozessor-Pipeline 200 durchläuft, um zusätzliche Informationen erweitert, wie dies oben beschrieben ist. Ein Befehl wird von dem Zeitpunkt an, zu dem er abgerufen wird, bis zum Ausscheiden bzw. Abbrechen als unterwegs seiend betrachtet. Der Befehl wird, wie oben erläutert, um wenigstens ein Abtast-Bit 401 erweitert. Das Abtast-Bit 401 ist Teil des Status jedes unterwegs seienden Befehls und der Cache-Speicher-Anforderung. Wenn das Bit 401 bestätigt wird, zeigt das Bit an, dass Profilierungs-Informationen für diesen Befehl aufgezeichnet werden, was ansonsten nicht der Fall ist.
Bei einer vereinfachten Ausführung kann nur das Abtast-Bit 401 jeweils eines Befehls bestätigt werden. Das Abtast-Bit 401 bleibt für den ausgewählten Befehl bestätigt, bis der Befehl abgelegt oder abgebrochen wird. Bei einer komplexeren Ausführung mit mehreren Register-Dateien 300 können mehrere unterwegs seiende Befehle einzeln profiliert werden, und zusätzliche Bits können bestätigt werden.
Auswahl und Abtastung profilierter Befehle
Bei einer Abrufstufen-Ausführung wird, wie in 5 dargestellt, die Auswahl der zu profilierenden Befehle und das Abtasten von Profil-Informationen wie folgt ausgeführt. Ein Abruf-Zähler 510 wird beispielsweise durch privilegierte Profilierungs-Software (PSW) 520 über Leitung 511 initialisiert. Die PSW 520 kann den Zähler 510 mit einem Wert initialisieren, der willkürlich aus einem Intervall von Werten mit einer vorgegebenen Größe ausgewählt wird. Daher gibt es keine Beziehung der abgetasteten Befehle zu speziellen Mustern bei der Ausführung der Befehle. Die Größe des Intervalls bestimmt die durchschnittliche Abtastfrequenz. Andere Randomisierungsverfahren zum Initialisieren des Wertes von Zähler 510, die auch Hardware einschließen, können ebenfalls eingesetzt werden.
Ohne Zufallsabtastung ist es, wenn beispielsweise Befehle mit einer festen Frequenz abgetastet werden, wie dies beim Stand der Technik der Fall ist, nicht möglich, ein statistisch korrektes Profil aller abgerufenen Befehle, z. B. der Gesamtfunktion des Systems 100, zu erzeugen. Dies gilt insbesondere für einen Ausführungs-Pfad mit Ausführungs-Schleifen, die eine Anzahl von Befehlen enthalten, die teilerfremd in Bezug auf die Abtastrate sind, so beispielsweise bei einer Schleife mit Befehlen und einem Abtastintervall von 65536 Befehlen. Bei anderweitig regelmäßiger Abtastung würde das gleiche Problem auftreten. Dabei werden stets Abtastwerte von nur einem der zwei Befehle erfasst. Zufällig ausgewählte Befehle erzeugen vorteilhafterweise Beziehungen, die unabhängig von der Länge des Abtastintervalls sind.
Für jeden abgerufenen Befehl 400 wird der Zähler 510 weiter gerückt, oder als Alternative dazu in einer anderen Ausführung von seinem Ausgangswert durch die Abruf-Einheit 210 der Pipeline 200 zurückgerückt. Wenn der Zähler 510 je nach der Ausführung entweder überläuft oder unterläuft, wird das Abtast-Bit 401 des momentan abgerufenen Befehls bestätigt, und das Kennungs-Feld 402 kann ebenfalls initialisiert werden, wenn mehrere Befehle zum Abtasten ausgewählt werden.
Bei einer alternativen Ausführung wird der Zähler 510 nicht bei jedem abgerufenen Befehl, sondern bei jedem Zyklus weiter gerückt, so zählt der Zähler 510 beispielsweise Abruf-Möglichkeiten und nicht tatsächlich abgerufene Befehle. Wenn beispielsweise die Abruf-Einheit 210 während jedes Taktzyklus vier Elemente aus dem I-Cache 112 abrufen kann, sind vier Abruf-Möglichkeiten vorhanden. Es ist möglich, dass einer oder mehrere Abrufe aus dem I-Cache fehlschlagen oder ein "schlechter" Befehl abgerufen wird. Bei einem Fehler enthält der für den fehlerhaften Befehl zur Verfügung stehende Schlitz "Abfall", und der Befehl muss als ungültig markiert werden. Ein schlechter Befehl ist ein Befehl, der auf einem schlechten Ausführungswert liegt oder anderweitig abgebrochen wird.
Wenn Zyklen anstelle abgerufener Befehle gezählt werden, wird die Konstruktion vorteilhafterweise vereinfacht. Das einfache Zählen von gültigen abgerufenen Befehlen kann recht kompliziert sein, da sich der Steuerungsstrom in die Gruppe abgerufener Befehle oder aus ihr heraus verzweigen kann, wodurch es nötig wird, alle Befehle zu dekodieren, um festzustellen, welche gültig sind, so dass der Zähler nicht mehr nur einfach um vier weiter gerückt muss.
Vorteilhafterweise können alle Elemente (gute Befehle, schlechte Befehle, Abfall-Befehle), die während eines Zyklus aus dem I-Cache abgerufen werden, zum Abtasten ausgewählt werden, so dass die tatsächliche Leistung des I-Cache 112 und der Pipeline 200 bestimmt werden kann. Dabei kommt es zu keiner Verschiebung, so dass die Ergebnisse einen statistisch korrekten Schätzwert der Leistung des Systems darstellen.
Dies ist ein Unterschied zu bekannten Verfahren, die nur jeden gültigen Befehl für einen kurzen Zeitraum oder in beabstandeten festen Intervallen auswählen können. In beiden Fällen besteht das strategische Ziel darin, den Overhead auf ein Minimum zu verringern. Mit keinem Verfahren können die Leistungsdaten ganzer Systeme erfasst werden.
Filtern von Befehlen
Die ausgewählten Elemente können mit einem Filter 505 gefiltert werden. Das Filtern kann auf der Basis des Befehls-Opcodes, von Operanden oder komplexeren Filterkriterien ausgeführt werden, so beispielsweise einem ersten Typ Befehl, auf den innerhalb eines Zeitraums ein anderer Typ Befehl folgt. Wenn der Eingang der Pipeline 200 gefiltert wird, kann der Zähler 510 zurückgesetzt werden. Es gibt eine Reihe von Möglichkeiten, dies auszuführen. Bei einem Verfahren wird der momentane Ausgangswert des Zählers 510 in einem Init-Register 513 gespeichert. Wenn ein Befehl gefiltert wird, wird der in dem Init-Register 513 gespeicherte Wert erneut in den Zähler 510 geladen, um die ursprüngliche Zufallsauswahl erneut aufzurufen.
Nachdem der Befehl erweitert worden ist, leitet die Pipeline 200 die Profilierungs-Informationen 281–286 in 2b zu der/den Register-Datei/en 300. Die Ablege-Einheit 250 schließt in Reaktion auf den Abschluss bzw. Abbruch des Befehls das Speichern von Profilinformationen ab und erzeugt ein Unterbrechungssignal auf Leitung 540, so dass die PSW 520 die Profil-Informationen abtasten kann.
Als Alternative dazu kann die PSW 520 Leitung 540 über ein internes Prozessor-Register oder eine Speicherposition (541) abfragen. Ein Merkmal des vorliegenden Verfahrens im Unterschied zu einigen Profilierungsverfahren nach dem Stand der Technik besteht darin, dass die Prozessor-Zykluszeit nicht beeinflusst wird, obwohl das vorliegende Verfahren genaue Informationen über Zustände in dem Prozessor liefert. Die einzige Zeiteinschränkung besteht darin, dass alle Profil-Informationen aufgezeichnet sein müssen, bevor die Profil-Register 300 abgetastet werden.
Latenz-Zähler
6 zeigt eine Schaltung 600 zum Zählen beispielhafter Latenzen: Abrufen-bis-Abbilden (FM), Abbilden-bis-Ausgeben (MI), Ausgeben-bis-Ablegen (IR), Abrufen-bis-Unter brechen (FT) und Ausgeben-bis-Idst (ILS). Die Schaltung 600 enthält einen Zykluszähler 610, der über Leitung 611 mit Signalspeichern 620 verbunden ist.
Der Zyklus-Zähler 610 und die Signalspeicher 620 werden durch Signal Pfetch auf Leitung 601 initialisiert. Dieses Signal wird erzeugt, wenn ein zu profilierender Befehl abgerufen wird, so beispielsweise ein Signal, das von dem Abtast-Bit 401 hergeleitet wird. Der Zähler 610 wird durch Takt-Signale auf Leitung 609 weitergerückt. Jedes Taktsignal entspricht einem Prozessor-Zyklus.
Wenn der Befehl 400 die Stufen der Pipeline 200 durchläuft, lösen Stufenübergänge in der Pipeline 200 Signale Pmap, Pissue, Pretire, Ptrap bzw. PLSdone auf den Leitungen 602–606 aus. Die entsprechenden Signalspeicher 620 können auf den Leitungen 612–616 gelesen werden, um Speicherung in den Profil-Latenz-Registern (bzw. Feldern) 350 in 3 auszuführen.
Profilierungs-Anwendungen
Die oben beschriebene Profilierungs-Hardware kann auf verschiedenste Weise genutzt werden. Da das vorliegende Verfahren sehr ausführliche Informationen über die Ausführung einzelner Befehle liefert, könnte mit einer Anwendung, eine große Anzahl von Befehlen profiliert werden. Die Abtast-Informationen können in einem Speicher-Puffer zur späteren Verarbeitung durch Profilierungs-Werkzeuge gespeichert werden, um detaillierte Informationen auf Befehlsebene zu erzeugen.
Die Informationen können genutzt werden, um beispielsweise Histogramme von Lade-Latenzen für jeden Lade-Befehl, Histogramme von Befehlsausführungs-Zeiten zu entwickeln, und möglicherweise auch für eine einigermaßen umfassende Analyse des Pipeline-Status für jeden Befehl. Da die Menge an Informationen, die mit diesem Verfahren erzeugt wird, wahrscheinlich sehr hoch ist, ist es auch wahrscheinlich, dass der gesamte Speicher-Verwaltungsaufwand bei dem vorliegenden Verfahren sehr groß ist, da erhebliche Speicheraktivitäten auftreten. So beträgt beispielsweise, wenn eine Milliarde Befehle pro Sekunde abgerufen werden und die Abtastung bei jedem 10.000sten abgerufenen Befehl ausgeführt wird, die Datenrate für die Profil-Informationen ungefähr 2,4 MB pro Sekunde.
Der folgende Abschnitt beschreibt in Software umgesetzte Verfahren zur Verringerung der Bandbreite durch das Zusammenfassen von Profil-Informationen.
Datenverringerung durch Filtern von Ausgangs-Profil-Informationen
Das Volumen abgetasteter Daten kann verringert werden, indem einige Felder des Profil-Protokolls ignoriert werden, so beispielsweise die Daten in den Profil-Registern 300, wenn sie nicht ausdrücklich angefordert werden. Ein Benutzer des Systems 100 wünscht möglicherweise unterschiedliche Ebenen der Profilierung. In einem Modus mit dem niedrigsten Verwaltungsaufwand kann die Profilierungs-Anwendungssoftware einen Profil-Bericht für ein ganzes Programm oder einen Teil desselben lediglich unter Verwendung des Programmstufenzählers (PC) und der Ausscheide-Verzögerungs-Felder erzeugen. Je nach der auszuführenden Optimierung können andere PC Werte durch Mitteln oder andere statistische Maße, wie beispielsweise Minimum, Maximum, zusammengefasst werden oder die Standardabweichung berechnet werden. Wenn mehr Zeit zum Verarbeiten von Daten vorhanden ist, kann die Profilierungs-Anwendung Histogramme verschiedener Befehls-Latenzen erzeugen.
Die effektive Speicher-Adresse, die Verzweigungs-Zieladresse und Verzweigungs-Verlaufs-Abtastungen machen aller Wahrscheinlichkeit nach umfangreichere Verarbeitung als die anderen Felder erforderlich. Diese Felder können möglicherweise ignoriert werden, außer wenn Daten zur Ausführung spezieller Optimierungsaufgaben erfasst werden. Wenn der Abrufabstand zwischen Befehlen in Zyklen bekannt ist, kann die Profilierungs-Anwendung auch Informationen über Werte der Gleichzeitigkeit erfassen.
Das Filtern der Profilierungs-Informationen kann auch mit Hardwaremitteln ausgeführt werden, so beispielsweise einem Masken-Register oder einer programmierbaren Logik. So kann beispielsweise nur abgetastet werden, wenn ein Cache-Fehler aufgetreten ist, oder wenn der Befehl ausgeschieden ist, oder bei anderen Bool'schen Kombinationen von Opcodes, Operanden, Adressen, Ereignissen und Latenzen.
Bestimmen der Hardware-Funktion
Das vorliegende Profilierungs-Verfahren kann eingesetzt werden, um ein genaues Verständnis der internen Funktion eines Prozessors mit Ausgabe außerhalb der Reihenfolge, wie beispielsweise des Prozessors Alpha 21264, zu erlangen. Als erstes ist bezüglich dieses Typs der Rechnerorganisation anzumerken, dass es viele Stellen gibt, an denen ein Befehl in der Pipeline 200 verzögert werden kann, sowie eine Vielzahl von Gründen, warum er verzögert werden kann.
So kann beispielsweise ein Befehl in der Ausgabe-Einheit 230 verzögert werden, und zwar entweder, weil bei einem seiner Operanden keine Datenbereitschaft vorliegt, weil einige der Ressourcen, die für die Ausführung des ausgewählten Befehls erforderlich sind, nicht zur Verfügung stehen, oder weil andere Befehle zur Ausführung vor ihm ausgewählt wurden.
Ein Befehl kann in der Abbildungs- bzw. Zuordnungsstufe verzögert werden, in der virtuelle in physische Register-Abbildungen umgewandelt werden, und zwar entweder, weil der Rechner über keine physischen Register mehr verfügt, oder weil zu viele Befehle unterwegs sind, oder weil die Ausgabe-Einheit 230 voll ist, d. h. kein Platz mehr für den auszuführenden Befehl vorhanden ist. Als Alternative dazu kann ein Befehl in der Ablege-Einheit verzögert werden, da zuvor ausgegebene Befehle in der Reihenfolge des Programms noch nicht abgeschlossen sind.
Die genaue Bestimmung des Ortes, an dem ein Befehl verzögert wird, des Grundes für die Verzögerung und der Dauer der Verzögerung hängt stark vom genauen Zustand des Rechners ab, wenn dieser Befehl ausgeführt wird. Da der Prozessor so dynamisch ist, ist es für Software-Leistungswerkzeuge schwierig, diesen Zustand statisch zu bestimmen.
Zusammenfassung der Funktion
Ein Verfahren 700 zum Profilieren kann, wie in 7a dargestellt, die folgenden Schritte einschließen. Der Profilierungs-Status wird in Schritt 710 initialisiert. Dabei werden Register gelöscht, und Zählern werden ihre Ausgangswerte zugewiesen. In Schritt 720 wird ein Befehl abgerufen und gezählt. In Schritt 730 wird der Befehl ausgewählt, wenn die Anzahl abgerufener Befehle seit der Initialisierung einer vorgegebenen Zufallszahl entspricht. Der ausgewählte Befehl wird erweitert, um seine Auswahl anzuzeigen.
Wenn der ausgewählte Befehl die Ausführungs-Pipeline 200 durchläuft, werden Profil-Informationen in Schritt 740 erfasst. Nach Abschluss (Ablegen oder Abbruch) werden die erfassten Informationen in Schritt 750 abgetastet. Die abgetasteten Informationen können zur anschließenden Verarbeitung zwischengespeichert werden. Es ist auch möglich, einen bestimmen Profilierungs-Status abzutasten, um detailliertere Informationen zu gewinnen.
Schätzen von Statistiken von Eigenschaften verarbeiteter Befehle
Ein Prozess 799 schätzt, wie in 7b dargestellt, Statistiken von Eigenschaften von Befehlen, die mit der Pipeline 200 verarbeitet werden. Der Prozess 799 kann die folgenden Schritte enthalten. Schritt 751 liest das Profil-Protokoll 300, das wie oben beschrieben in Schritt 750 abgetastet wurde. Das Protokoll wird gelesen, wenn der ausgewählte Befehl abgeschlossen ist. In Schritt 760 wird die Abtastung in Abhängigkeit von einer Funktion 755, die Status-Informationen des Systems berücksichtigt, ausgewählt oder ausgesondert.
So nimmt Funktion 755 als Eingangs-Status-Informationen 756 beispielsweise Adressen, Prozess-Kennungen, Adressen-Raum-Nummern, Hardware-Kontext-Kennungen oder Pfad-Kennungen der ausgewählten Befehle auf. Funktion 755 kann auch Status-Informationen, wie beispielsweise Pfad-Kennungs-Informationen, Opcodes, Operanden, Latenzen oder Ereignisse nutzen, die bei den ausgewählten Befehlen aufgetreten sind. Bei den Ereignis-Informationen kann es sich um den Ablege/Abbruchs/Ungültigkeits-Status, Cache-Treffer/Fehler, Verzweigungs-Fehlvorhersage, Unterbrechungs-Status, TLB-Treffer/Fehler und Daten-Ressourcenabhängigkeits-Status usw. handeln.
Schritt 760 erzeugt eine Untergruppe von Abtastungen auf der Basis der Funktion 755. In Schritt 780 wird die Statistik 790 bestimmt. Diese Statistik kann Mittelwerte, Standardabweichungen, Histogramme (Verteilung) und Fehlergrenzen der Eigenschaften der abgetasteten Befehle enthalten. So kann es sich beispielsweise um durchschnittliche Raten handeln, mit denen angegebene Ereignisse auftreten, um durchschnittliche La tenzen der Befehls-Ausführung und Speicherzugriffe. Mittelwerte von Ausführungs-Raten von Prozessen, Pfade oder Hardware-Kontexte können ebenfalls bestimmt werden. Die Histogramme können die Verteilung der Befehls-Ausführung, der Speicherzugriffs-Raten oder Latenzen anzeigen.
Die Grenze der Fehler kann durch einen Kehrwert einer Quadratwurzel der Anzahl von Abtastungen für die spezielle abgetastete Eigenschaft genähert werden.
N-bezogenes Abtasten (N-wise sampling)
Das hier beschriebene Profilierungs-Verfahren kann auch genutzt werden, um N-bezogenes Abtasten auszuführen. Dabei kann der dynamische Status von Wechselwirkungen zwischen mehreren, gleichzeitig ausgeführten Befehlen erfasst werden. Statt des Profilierens eines einzelnen, unterwegs seienden Befehls werden gleichzeitig zwei oder mehr separate Befehle profiliert. Der dynamische "Abstand" zwischen den ausgeführten Befehlen kann als die Anzahl abgerufener Befehle oder die Anzahl von Prozessorzyklen gemessen werden, die die unterwegs seienden Befehle "trennen". Jedes der Ereignisse, das von Zähler 510 gezählt wird, kann genutzt werden, um den Abstand zwischen ausgewählten Befehlen, z. B. Takt-Zyklen, abgerufenen Befehlen, usw. zu messen.
Profil-Informationen für N-bezogen abgetasteten Befehle können vielfach genutzt werden. Zunächst können die Informationen analysiert werden, um das Maß nützlicher Gleichzeitigkeit zu messen. Dies ermöglicht es, tatsächliche Engpässe zu lokalisieren. Tatsächliche Engpässe sind durch lange Verzögerungen in Verbindung mit geringer Gleichzeitigkeit gekennzeichnet. N-bezogene Abtastungen können darüber hinaus die Weg-Profilierung erleichtern und mögliche Ausführungs-Wege disambiguieren, indem die Wege so eingeschränkt werden, dass sie wenigstens zwei Punkte auf dem Weg enthalten. Des Weiteren ist es auch möglich, aus N-bezogener Abtastung statistisch detaillierte Prozessor-Pipeline-Zustände zu rekonstruieren. Dabei kann die Auswahl der Gruppe von Befehlen auf einem Maß der Ähnlichkeit zwischen den Befehlen beruhen, so beispielsweise dem aktuellen Verzweigungs-Verlauf, Verzögerungen, Befehlstypen oder anderen aktuellen Zustands-Verläufen.
Messen der nützlichen Gleichzeitigkeit
Die Lokalisierung von Leistungsengpässen in nicht der Reihe nach arbeitenden Prozessoren macht detaillierte Informationen sowohl über Verzögerungszeiten als auch über Niveaus der Gleichzeitigkeit erforderlich. Im Unterschied zu Prozessoren, die der Reihe nach arbeiten, ist ein Befehl mit langer Latenz nicht problematisch, wenn ausreichend Gleichzeitigkeit vorhanden ist, um den Prozessor effektiv zu nutzen, während der Befehl mit langer Latenz verzögert wird.
Ein Verfahren zum Gewinnen von Informationen über die Gleichzeitigkeit ist ein Schnappschuss des gesamten Status der Pipeline. Damit wird direkt sichtbar, wo sich Gruppen von gleichzeitig ausgeführten Befehlen in den Stufen der Pipeline zu einem bestimmten Zeitpunkt befinden. Das "Abladen" des gesamten Pipeline-Status in Abtast-Register und Puffer könnte jedoch sowohl zeitlich als auch räumlich extrem aufwendig sein. Des Weiteren könnten die erzeugten umfangreichen Daten wahrscheinlich nicht effektiv zusammengefasst werden, um die Kosten des Abtastens zu amortisieren. Noch nachteiliger ist, dass dieses Verfahren nicht ausreicht, da nur die Befehle, die ausgeschieden werden, als "nützlich" gezählt werden, und Informationen, welche Befehle abrufen, jedoch abgebrochen werden, noch nicht bekannt ist.
Verschachteltes paarweises Abtasten
Ein Typ N-bezogenes Abtasten führt zu einer Verringerung des Kompromisses zwischen Einzelbefehls-Profilierung und vollständigen Pipeline-Schnappschüssen auf ein Minimum. Dabei wird statistisches paarweises Abtasten auf verschachtelte Weise ausgeführt, so dass für einen bestimmten ausgewählten Befehl ein anderer Befehl, der gleichzeitig ausgeführt werden kann, direkt abgetastet wird.
Hardware-Unterstützung für das verschachtelte N-bezogene Abtasten
Das N-bezogene Abtasten umfasst die folgenden Hardware-Merkmale. Zunächst muss die Hardware es ermöglichen, dass Profil-Informationen für wenigstens zwei gleichzeitig unterwegs seiende Befehle erfasst werden. Die Gruppe von Profil-Registern muss kopiert werden, um mehrere einzelne Gruppen von Profil-Protokollen zu unterstützen, und das einzelne Abtast-Bit 401 muss auf ein mehr allgemeines ID-Feld 402 erweitert werden. Zweitens muss es die Hardware ermöglichen, den Abstand zwischen den ausgewählten Befehlen dynamisch zu verändern, indem die Abtastrate variiert wird. Dies könnte mit Hardware oder Software ausgeführt werden. Es ist anzumerken, dass die Größe der Gruppe von gleichzeitig abgetasteten Befehlen (N-bezogene, wobei N > 1) beim zusätzlichen Kopieren von Zählern und Registern vergrößert werden könnte.
So kann die privilegierte Profilierungs-Software 520 beispielsweise dynamisch die Größe des Intervalls verändern, aus dem, bei dem paarweisen Verfahren, zwei Abruf-Zähler 510 willkürlich ausgewählt werden. Dadurch kann der Abrufabstand zwischen den Abtastungen für das Paar Befehle zur gleichen Zeit vorgegeben werden. Die Hardware kann einen vergleichsweise großen Abrufabstand zwischen den Abtastungen unterstützen, um maximale Flexibilität auf der Software-Ebene zu ermöglichen.
Idealerweise hat der zweite Abruf-Zähler die gleiche Größe wie der Haupt-Zähler 510 für abgerufene Befehle, so dass zwei beliebige unabhängige Befehle, die weit genug voneinander entfernt sind, ausgebildet werden können. Ein 10-Bit-Counter würde für den Prozessor Alpha 21264 ausreichen. Ein kleinerer Zähler reicht möglicherweise aus, um die Gleichzeitigkeit zu messen, wenn abgerufene Befehle gezählt werden, und ein größerer Zähler kann erforderlich sein, wenn Zyklen gezählt werden. Für das verschachtelte N-bezogene Abtasten muss die Hardware auch die Abrufen-bis-Abrufen-Latenz zwischen den Abtastungen in Zyklen messen, so dass ein Zeitbezug zwischen mehreren Latenz-Registern 350 hergestellt werden kann.
Verschachtelte N-bezogene Abtast-Anwendung
Anwendungssoftware auf höherer Ebene kann das verschachtelte N-bezogene Abtasten nutzen, um die nützliche Gleichzeitigkeit zu messen. Die Grundidee dabei besteht darin, das Abtasten einer Gruppe von Befehlen zu ermöglichen, die möglicherweise gleichzeitig ausgeführt werden. Das verschachtelte Abtasten beruht auf den gleichen statistischen Grundlagen, die das normale Abtasten rechtfertigen, d. h., das Abtasten wird rekursiv ausgeführt. Da das N-bezogene Abtasten zwei Ebenen des Abtastens einschließt, ist es am wirkungsvollsten für stark ausgeführten Code. Es liegt auf der Hand, dass dies auch das Gebiet ist, auf dem es am wichtigsten ist.
Definition von Gleichzeitigkeit
Bei einem vorgegebenen ausgewählten Befehl I 810 in einer vier Bit breiten Pipeline sind potenziell gleichzeitige Befehle die Befehle, die während einer dynamischen Ausführung gleichzeitig mit Befehl I in der Prozessor-Pipeline resident sein können. Dies schließt Befehle ein, die sich in verschiedenen Ausführungsstufen befinden können, bevor Befehl I abgerufen wird, sowie Befehle, die abgerufen werden, bevor Befehl I abgelegt oder abgebrochen wird.
So ermöglicht beispielsweise der Prozessor Alpha 21264 achtzig Befehlle, die gleichzeitig unterwegs sind. In der Praxis jedoch ist die tatsächliche Zahl gleichzeitiger, d. h. unterwegs seiender, Befehle wahrscheinlich viel geringer als der Spitzenwert, der von der Hardware unterstützt wird. Andererseits kann eine spekulative Ausführung auf falsch vorhergesagten oder schlechten Wegen das Fenster möglicher Gleichzeitigkeit vergrößem.
Um die Gleichzeitigkeit auf dem Prozessor Alpha 21264 zu untersuchen, wird vorgeschlagen, dass eine angemessene Größe des Fensters 820 um Befehl I 810 herum ungefähr einhundert Befehle einschließt. Bei anderen Ausführungen kann die geeignete Größe des Fensters experimentell bestimmt werden.
Bei einem Fenster der Größe W von beispielsweise ungefähr einhundert möglichen gleichzeitigen Befehlen, kann das Abtaten ohne Abweichung ausgeführt werden, indem der Abruf-Abstand zwischen den ausgewählten Befehlen randomisiert wird. So wird beispielsweise bei jeder paarweisen Abtastung <I1, I2> (841 und 842) der Abruf-Abstand zwischen Abtastungen auf eine Pseudozufallszahl festgelegt, die gleichmäßig zwischen 1 und W verteilt ist. Indem der Abstand zwischen Abtastungen zwischen dem ersten ausgebildeten Befehl I1 und dem zweiten ausgebildeten Befehl I2 so zufällig variiert wird, wird ein großes Maß an statistischen Informationen darüber erfasst, welche Befehle einander zeitlich überlappen.
Analysieren gleichzeitiger Überlappung
Profil-Informationen für eine Gruppe gleichzeitig ausgebildeter Befehle mit verschiedenen Abruf-Abständen zwischen den Abtastungen ergibt direkt eine Statistik der nützlichen Gleichzeitigkeit. Jede Gruppe von entsprechenden Abtast-Informationen kann genutzt werden, um Gleichzeitigkeitsinformationen zu bestimmen, indem sowohl von dem ersten Befehl I1 zeitlich nach vom als auch von dem zweiten Befehl I2 zeitlich nach hinten geblickt wird.
Die Profil-Informationen, die für jeden N-bezogen ausgewählten Befehl aufgezeichnet werden, sollten Latenz-Daten enthalten, die genau den Punkt berücksichtigen, an dem sich beide Befehle <I1, I2> zu einem bestimmten Zeitpunkt in der Prozessor-Pipeline 200 befinden. Des Weiteren sollte die Zwischen-Abtastungs-Abruf-Latenz aufgezeichnet werden, um Beziehung zwischen der Gruppe Latenz-Registern herstellen zu können. Verschachteltes Profilieren kann auch anzeigen, wenn Befehle <I1, I2> auf verlassenen Ausführungs-Wegen abgeschlossen werden. Diese detaillierten Informationen können statistisch zusammengefasst werden, um verschiedene Maße zu erzeugen, die Niveaus nützlicher Gleichzeitigkeit anzeigen.

Claims

Vorrichtung zum Abtasten von Befehlen in einer Prozessor-Pipeline (200) eines Systems, wobei die Pipeline eine Vielzahl von Verarbeitungsstufen aufweist, und die Vorrichtung umfasst: eine Einrichtung (210), die Befehle in eine erste Stufe der Pipeline abruft, wobei jeder Befehl eine Vielzahl von Anzeige-Feldern aufweist, die ein Abtast-Bit (401) und ein Feld (402) für eine Abtast-Register-Datei-Kennung enthalten; eine Einrichtung, die willkürlich jede beliebige Teilgruppe simultan ausgeführter abgerufener Befehle als ausgewählte Befehle zum Abtasten identifiziert, indem das Abtast-Bit (401) in den ausgewählten Befehlen bestätigt wird; eine Einrichtung (288), die Status-Informationen des Systems bereitstellt, während sich beliebige der ausgewählten Befehle in einer beliebigen Stufe der Pipeline befinden; eine Vielzahl von Profil-Registern (300), die die Status-Informationen speichern; und eine Einrichtung, die eine Software-Anwendung informiert, dass alle der ausgewählten Befehle die Pipeline verlassen haben, so dass die Software-Anwendung beliebige der Status-Informationen lesen kann.
Vorrichtung nach Anspruch 1, wobei die ausgewählten Befehle gültige Befehle, die von der Pipeline (200) vollständig verarbeitet werden, gültige Befehle, die abgebrochen werden, bevor sie die Pipeline verlassen, und ungültige Befehle einschließen, die teilweise verarbeitet werden, bevor sie die Pipeline verlassen.
Vorrichtung nach Anspruch 1, wobei wenigstens eines der Anzeige-Felder (401, 402) anzeigt, dass die ausgewählten Befehle zum Überwachen ausgewählt worden sind.
Vorrichtung nach Anspruch 1, die des Weiteren eine Einrichtung umfasst, die das Abtast-Bit (401) bestätigt, um die Einrichtung zum Überwachen zu aktivieren.
Vorrichtung nach Anspruch 3, wobei die Anzeige-Felder (402) eine Befehls-Nummer anzeigen, die mit den ausgewählten Befehlen verbunden ist.
Vorrichtung nach einem der vorangehenden Ansprüche, wobei die Status-Informationen, die mit jedem ausgewählten Befehl verbunden sind, in einem Register (300) gespeichert werden, das durch wenigstens eines des einen bzw. der mehreren Anzeige-Felder indexiert wird.
Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Status-Informationen Ereignis-Zählungen von Ereignissen einschließen, die zwischen einem Paar der ausgewählten Befehle auftreten.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen die Anzahl von Taktzyklen einschließen, die zwischen den Vorgängen des Abrufens des Paars der ausgewählten Befehle auftreten.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen die Anzahl von Befehlen einschließen, die zwischen dem Paar der ausgewählten Befehle abgerufen werden.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen die Anzahl von Befehlen einschließen, die zwischen dem Paar ausgewählter Befehle in eine vorgegebene Stufe der Pipeline eintreten.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen die Anzahl von Verzweigungs-Befehlen einschließen, die zwischen dem Paar der ausgewählten Befehle abgerufen werden.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen eine Messung von Prozessor-, Speichersystem-, Netz- oder I/O-Teilsystemen-Ereignissen einschließen.
Vorrichtung nach einem der vorangehenden Ansprüche, die des Weiteren enthält: eine Vielzahl von Abtast-Zählern (510), die zum Zählen vorgegebener Ereignisse ausgeführt sind; eine Einrichtung, die jeden Abtast-Zähler auf einen vorgegebenen Wert initialisiert; und eine Einrichtung, die die Einrichtung zum willkürlichen Identifizieren in Reaktion auf einen Überlauf wenigstens eines der Abtast-Zähler aktiviert, der in Reaktion auf vorgegebene Ereignisse überläuft.
Vorrichtung nach Anspruch 13, wobei die Einrichtung zum willkürlichen Identifizieren eine Einrichtung enthält, die die ausgewählten Befehle mit einem separaten Anzeige-Feld anhand der Feststellung dahingehend identifiziert, welcher der Vielzahl von Abtast-Zählern übergelaufen ist.
Vorrichtung nach Anspruch 13, wobei jeder vorgegebene Wert willkürlich aus einem Intervall von Zahlen gewählt wird, um die durchschnittliche Häufigkeit vorzugeben, mit der die Einrichtung zum Identifizieren betätigt wird.
Vorrichtung nach Anspruch 15, wobei die Größen der Intervalle von Zahlen verändert werden, um dynamisch die durchschnittliche Häufigkeit zu ändern, mit der die Einrichtung zum Identifizieren betätigt wird.
Vorrichtung nach Anspruch 15, wobei jeder willkürlich gewählte vorgegebene Wert in Software berechnet und dann in Hardware-Registern gespeichert wird.
Vorrichtung nach Anspruch 15, wobei jeder willkürlich gewählte vorgegebene Wert von einer Hardware-Schaltung erzeugt wird.
Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Status-Informationen Informationen einschließen, die die ausgewählten Befehle identifizieren.
Vorrichtung nach Anspruch 19, wobei die Status-Informationen Adressen der ausgewählten Befehle einschließen.
Vorrichtung nach Anspruch 19, wobei die Status-Informationen eine Identifizierung des Prozesses einschließen, der die ausgewählten Befehle ausführt.
Vorrichtung nach Anspruch 19, wobei die Status-Informationen eine Adressraum-Nummer einschließen.
Vorrichtung nach Anspruch 19, wobei die Status-Informationen eine Hardware-Kontext-Kennung einschließen.
Vorrichtung nach Anspruch 19, wobei die Status-Informationen eine Thread-Nummer einschließen.
Vorrichtung nach einem der vorangehenden Ansprüche, wobei die Einrichtung, die die Software-Anwendung informiert, eine Unterbrechung erzeugt, um anzuzeigen, dass alle der ausgewählten Befehle die Pipeline (200) verlassen haben.
Vorrichtung nach einem der vorangehenden Ansprüche 1 bis 24, wobei die Einrichtung, die die Software-Anwendung informiert, ein Flag enthält, das durch die Software-Anwendung abgefragt werden kann, um anzuzeigen, dass alle der ausgewählten Befehle die Pipeline (200) verlassen haben.
Vorrichtung nach Anspruch 13, wobei die vorgegebenen Ereignisse gültige abgerufene Befehle sind.
Vorrichtung nach Anspruch 13, wobei eine Abrufrate durch einen Takt (609) bestimmt wird, und die vorgegebenen Ereignisse Unterteilungen von Taktzyklen sind, die einem einzelnen potentiellen abgerufenen Befehl entsprechen.
Vorrichtung nach Anspruch 13, wobei die vorgegebenen Ereignisse der Eintritt der Befehle in in jede beliebige spezielle Stufe der Pipeline sind.
Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Status-Informationen einen Ausscheide-/Abbruch-Status der ausgewählten Befehle einschließen.
Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Status-Informationen Pipeline-Verarbeitungszustände sind, die erfasst werden, während die ausgewählten Befehle verarbeitet werden.
Vorrichtung nach einem der Ansprüche 1 bis 5, wobei die Status-Informationen Latenzen einschließen, denen die ausgewählten Befehle unterliegen.
Vorrichtung nach Anspruch 7, wobei die Ereignis-Zählungen die Anzahl von Taktzyklen einschließen, die zwischen dem Paar ausgewählter Befehle vergangen sind, das in eine vorgegebene Stufe der Pipeline eintritt.
Computersystem, das eine Vorrichtung nach einem der Ansprüche 1 bis 33 enthält.
Verfahren zum Abtasten von Befehlen in einer Prozessor-Pipeline (200) eines Systems, wobei die Pipeline eine Vielzahl von Verarbeitungsstufen aufweist und das Verfahren die folgenden Schritte umfasst: Abrufen simultan ausgeführter Befehle in eine erste Stufe der Pipeline (200), wobei jeder Befehl eine Vielzahl von Anzeige-Feldern aufweist, die ein Abtast-Bit (401) und ein Feld (402) für eine Abtast-Register-Datei-Kennung enthalten; willkürliches Identifizieren jeder beliebigen Teilgruppe abgerufener Befehle als ausgewählte Befehle durch Bestätigen des Abtast-Bits (401) in den ausgewählten Befehlen; Bereitstellen von Status-Informationen des Befehls, während sich jeder beliebige der ausgewählten Befehle in einer beliebigen Stufe der Pipeline befindet; Speichern der Status-Informationen in einer Vielzahl von Profil-Registern; und Informieren einer Software-Anwendung, dass alle der ausgewählten Befehle die Pipeline verlassen haben, so dass die Software-Anwendung beliebige der Zustands-Informationen lesen kann.
Verfahren nach Anspruch 35, wobei wenigstens eines des einen bzw. der mehreren Anzeige-Felder anzeigt, dass die ausgewählten Befehle zum Überwachen ausgewählt worden sind.
Verfahren nach Anspruch 35, wobei die Status-Informationen, die mit jedem ausgewählten Befehl verbunden sind, in einem Register gespeichert werden, das durch wenigstens eines des einen bzw. der mehreren Anzeige-Felder indexiert wird.
Verfahren nach Anspruch 35, wobei der Schritt des Identifizierens in Reaktion auf ein Überlaufen wenigstens eines Abtast-Zählers durchgeführt wird und der Abtast-Zähler auf einen vorgegebenen Wert initialisiert wird und zum Zählen vorgegebener Ereignisse ausgeführt ist.
Verfahren nach Anspruch 38, wobei der vorgegebene Wert willkürlich aus einem Intervall von Zahlen ausgewählt wird, um die durchschnittliche Häufigkeit vorzugeben, mit der der Schritt des Identifizierens durchgeführt wird.
Verfahren nach Anspruch 35, wobei die Status-Informationen Informationen einschließen, die die ausgewählten Befehle identifizieren.