DE69131830T2 - Verfahren zur optimierung der befehlsablauffolge - Google Patents

Verfahren zur optimierung der befehlsablauffolge

Info

Publication number
DE69131830T2
DE69131830T2 DE69131830T DE69131830T DE69131830T2 DE 69131830 T2 DE69131830 T2 DE 69131830T2 DE 69131830 T DE69131830 T DE 69131830T DE 69131830 T DE69131830 T DE 69131830T DE 69131830 T2 DE69131830 T2 DE 69131830T2
Authority
DE
Germany
Prior art keywords
instruction
instructions
execution
time
object code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69131830T
Other languages
English (en)
Other versions
DE69131830D1 (de
Inventor
James Rasbold
Don Van Dyke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cray Research LLC
Original Assignee
Cray Research LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US07/537,466 external-priority patent/US5179702A/en
Application filed by Cray Research LLC filed Critical Cray Research LLC
Application granted granted Critical
Publication of DE69131830D1 publication Critical patent/DE69131830D1/de
Publication of DE69131830T2 publication Critical patent/DE69131830T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12Replacement control
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/43Checking; Contextual analysis
    • G06F8/433Dependency analysis; Data or control flow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/445Exploiting fine grain parallelism, i.e. parallelism at instruction level
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/45Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Advance Control (AREA)
  • Devices For Executing Special Programs (AREA)

Description

    TECHNISCHES GEBIET
  • Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Software-Compilertechnologie und auf die Ablaufsteuerung von Maschinenbefehlen in bezug auf die mehreren funktionalen Betriebsmittel in einem Prozessor. Genauer bezieht sich die vorliegende Erfindung auf ein Verfahren zum Neuordnen der Reihenfolge, in der Maschinenbefehle innerhalb eines Basisblocks von Befehlen an einen Prozessor ausgegeben werden, der mehrere funktionale Betriebsmittel enthält, um die Gesamtausführungszeit des Basisblocks von Befehlen zu reduzieren.
  • STAND DER TECHNIK
  • Bei dem Versuch, die Leistungsfähigkeit von Computerverarbeitungssystemen zu verbessern, nutzen die derzeitigen Computerprozessoren mehrfache funktionale Betriebsmittel für die gleichzeitige Ausführung mehrerer Operationen innerhalb eines einzelnen Prozessors. Für die Zwecke der vorliegenden Erfindung kann ein funktionales Betriebsmittel irgendein Hardware-Betriebsmittel enthalten, das einem Prozessor direkt zur Verfügung steht, wie z. B. Register, Steuerelemente und insbesondere arithmetische und logische Funktionseinheiten. Zum Beispiel ist im US- Patent Nr. 4.128.880 der Vektorprozessor mit drei Vektor- Funktionseinheiten und vier Skalar-Funktionseinheiten versehen. Das Vorhandensein von mehreren Funktionseinheiten erlaubt diesem Prozessor, z. B. gleichzeitig zwei Additionsoperationen (eine skalare und eine für Vektoren) durchzuführen, wobei die Gesamtleistungsfähigkeit des Prozessors erhöht wird. Mehrfache funktionale Betriebsmittel sind meistens Matrix- oder Vektorprozessoren und Skalar/Vektor-Prozessoren zugeordnet, können jedoch auch in herkömmlichen Skalarprozessoren verwendet werden.
  • Ein weiterer Mechanismus zum Verbessern der Prozessorleistung, der häufig mit Hochleistungsprozessoren in Verbindung gebracht wird, die mehrere funktionale Einheiten besitzen, ist die Pipelinesteuerung. Die Pipelinesteuerung ist eine Prozessor-Implementierungstechnik, die typischerweise in Vektorprozessoren verwendet wird und den Strom der ausgeführten Befehle durch den Prozessor erhöht durch gleichzeitiges Überlappen der verschiedenen Ausführungsstufen der mehreren Befehle, die jeweils mehr als einen Taktzyklus benötigen, um abgeschlossen zu werden. Die von jedem Mehrfachzyklusbefehl bewerkstelligte Arbeit wird in kleine Stücke zerlegt, so daß zu einem beliebigen gegebenen Zeitpunkt viele Befehle in unterschiedlichen Stufen der Ausführung in der Pipeline vorhanden sind. Pipelinetechniken werden ferner implementiert in Verfahren, die verwendet werden, um die Befehle dem Prozessor zuzuführen, wobei viele Hochgeschwindigkeitscomputer des Standes der Technik Befehlspipelines verwenden. Eine Befehlspipeline erhöht den Befehlsfluß zum Prozessor durch Aufrechterhalten einer vollen Warteschlange wartender Befehle, die bereit sind, dem Prozessor mit dem nächsten Taktzyklus, zu dem der Prozessor den Befehl annehmen kann, zugeführt oder an diesen ausgegeben zu werden.
  • Während ein Prozessor mit mehreren funktionalen Betriebsmitteln das Potential zu einer deutlich erhöhten Leistungsfähigkeit besitzt, erhöht das Vorhandensein mehrfacher funktionaler Betriebsmittel erheblich die Komplexität des Ausführungsflusses von Befehlen in einem Prozessor. Für Hochleistungsprozessoren wird die Komplexität des Ausführungsflusses weiter gesteigert durch die Verwendung von Pipelinetechniken, sowohl von Funktionseinheit-Pipelines als auch Befehlpipelines. Es sei z. B. der Ausführungsfluß betrachtet, der unterschiedlichen arithmetischen Funktionen zugeordnet ist, die unterschiedliche Zeitspannen zur Ausführung benötigen, wie z. B. ein Divisionsbefehl gegenüber einem Multiplikationsbefehl. In dieser Situation besitzen die unterschiedlichen Funktionseinheit-Pipelines unterschiedliche Latenzzeiten. Wenn ein Prozessor mehrfache funktionale Einheiten mit unterschiedlichen Latenzzeiten besitzt, ist es möglich, daß der Befehl B mit der Ausführung beginnt, nachdem der Befehl A mit der Ausführung begonnen hat, und abschließt, während der Befehl A immer noch ausgeführt wird. Diese Latenzzeiten beeinträchtigen im allgemeinen nicht die Leistungsfähigkeit der Funktionseinheitspipeline, solange die Befehle nicht voneinander abhängig sind.
  • Leider können Situationen, die als Gefahren bekannt sind, verhindern, daß der nächste Befehl in der Befehlswarteschlange während eines bestimmten Taktzyklus beginnt. Die Befehlsabhängigkeit ist eine gewöhnliche Gefahr dieses Typs. Zum Beispiel kann ein ADD-Befehl die Verwendung des Ergebnisses von einem derzeit ausgeführten MULTIPLY- Befehl als einen Operanden erfordern. Somit ist der ADD- Befehl abhängig vom MULTIPLY-Befehl und kann nicht ausgeführt werden, bis das Ergebnis vom vorherigen Befehl zur Verfügung steht. Um solche Gefahren zu handhaben, verwendet die Hardware im Prozessor eine Befehlspipeline-Verriegelung, die die Befehlspipeline beim aktuellen Befehl anhält, bis die Gefahr nicht mehr besteht. Im hier angegebenen Beispiel wird die Befehlspipeline-Verriegelung aufgehoben, wenn das Ergebnis des MULTIPLY-Befehls für den abhängigen ADD-Befehl zur Verfügung steht.
  • Eine der Möglichkeiten zum Optimieren der Leistungsfähig keit eines Prozessors als Antwort auf das Vorhandensein solcher Gefahren ist die Befehlsablaufsteuerung. Die Befehlsablaufsteuerung ist ein Compiler oder eine Laufzeittechnik, die die Ausführungsreihenfolge und die funktionale Betriebsmittelzuweisung der von einem Computerprogramm kompilierten Befehle umordnet, so daß die Befehle in der schnellsten und effizientesten möglichen Reihenfolge ausgeführt werden. Während der ungeordnete Strom von Befehlen semantisch äquivalent ist zum ursprünglichen Strom, ordnet die Befehlsablaufsteuervorrichtung die Ausführung der Befehle so an und läßt diese so überlappen, daß die Gesamtausführungszeit reduziert wird. Die Befehle werden so im Ablauf gesteuert, daß versucht wird, irgendwelche Kombinationseinflüsse zu minimieren, die deren Abhängigkeit und Funktionseinheits- Latenzzeit auf die Pipelineleistungsfähigkeit haben kann. Das Vorhandensein mehrfacher funktionaler Betriebsmittel und die Parallelität zwischen wechselweise unabhängigen Befehlen kann ferner der Ablaufsteuervorrichtung erlauben, die Latenzzeit einer oder mehrerer funktionaler Einheiten des Prozessors zu verdecken und somit eine Pipeline-Befehlsausführung aufrechtzuerhalten.
  • Derzeit wird die Befehlsablaufsteuerung typischerweise bewerkstelligt unter Verwendung dynamischer und/oder statischer Ablaufsteuertechniken. Einige Prozessoren, wie z. B. der CDC 6600 und der IBM 360/91, führen eine dynamische Befehlsablaufsteuerung durch als ein Verfahren der Funktionsbetriebsmittelzuweisung zum Ausführungszeitpunkt, das eine Technik verwendet, die als Scoreboarding bezeichnet wird. Scoreboarding ist ein Verfahren des Zuweisens von Registerraum, das sicherstellt, daß die Befehle nicht ausgegeben werden, solange nicht ihre benötigten Registerbetriebsmittel zur Verfügung stehen. Fortschritte in der Prozessorarchitektur von Hochleistungsprozessoren, wie z. B. das Hinzufügen mehrfacher arithmetischer und logischer Funktionseinheiten, erfordert Ablaufsteuertechniken, die über die Fähigkeiten des Scoreboardings hinausgehen. Für diese Prozessoren muß die Befehlsablaufsteuerung nicht nur die funktionalen Betriebsmittel wie z. B. die Register handhaben, sondern muß auch die Funktionseinheits-Latenzzeiten und andere Zeitanforderungen handhaben. Folglich kann auch die Befehlsablaufsteuerung des Standes der Technik die statische Befehlsablaufsteuerung bei einem Versuch verwenden, diese Probleme zu lösen.
  • Die statische Befehlsablaufsteuerung ist eine Technik auf Softwarebasis, die zum Kompilierungszeitpunkt nach dem Erzeugen der Maschinenbefehle durchgeführt wird. Typischerweise erstellt der Compiler einen Befehlsabhängigkeitsgraphen auf der Grundlage der Abhängigkeiten zwischen den Befehlen im Befehlsstrom, der im Ablauf gesteuert werden soll. Die Ablaufsteuervorrichtung erzeugt zuerst unter Verwendung des Befehlsabhängigkeitsgraphen eine vorläufige Reihenfolge der Befehle im Strom. Als nächstes schätzt der Compiler die Funktionseinheit-Latenzzeit (die Zeitspanne, die für den Befehl normalerweise zur Ausführung erforderlich ist) und die Zeitspanne, die erforderlich ist, um für den jeweiligen Befehl die Datenübertragung vom Speicher zu bewerkstelligen. Auf der Grundlage der Informationen aus diesen zwei Schätzungen erzeugt die Ablaufsteuervorrichtung eine endgültige Reihenfolge der Befehle.
  • In Befehlsablaufsteuervorrichtungen des Standes der Technik, wie z. B. derjenigen, die beschrieben wird von Wei-Chung Hsu in "Register Allocation and Code Scheduling for Load/Store Architectures", wird angenommen, daß alle Pipelineverriegelungen zum Befehlsausgabezeitpunkt aufgelöst sind. Diese Annahme beruht auf einem typischen Modell der Befehlsausgabe, bei dem sowohl skalare Befehle als auch Vektorbefehle sequentiell ausgegeben werden. In der Praxis können die längeren Ausführungszeiten der Vektorbefehle die Ausgabepipeline verstopfen und das Ausgeben aller Befehle anhalten. In Systemen der Standes der Technik beeinträchtigen diese Halte die Rate der Befehlsausführung. Eine neue Architektur für einen Skalar/Vektor-Prozessor, die vom Anmelder der vorliegenden Erfindung vorgeschlagen worden ist, löst dieses Problem durch Vorsehen eines Vektoreinleitungsmechanismus, der vom Befehlsausgabemechanismus getrennt ist, um den Rückstand von Vektorbefehlen zu verhindern, die aufgrund einer Hardwareverriegelung angehalten werden. Dieser Typ von Prozessor wird von Befehlsablaufsteuervorrichtungen des Standes der Technik nicht betrachtet.
  • Obwohl Befehlsablaufsteuervorrichtungen des Standes der Technik für viele Pipelineprozessoren angemessen sind, ist eine der Unzulänglichkeiten derzeitiger Befehlsablaufsteuervorrichtungen die Ablaufsteuerung der Funktionsbetriebsmittel für Skalar/Vektor-Pipelineprozessoren mit mehrfachen Vektorfunktionseinheiten. Solche Prozessoren besitzen wenigstens zwei Funktionseinheiten, die denselben Satz von Vektor-Arithmetikoperationen durchführen. In einem Vektorprozessor mit mehrfachen Funktionseinheiten kann ein Befehl in irgendeinem der mehreren Funktionseinheiten ausgeführt werden, die fähig sind, die erforderlichen Arithmetikoperationen durchzuführen. Dieser Umstand ergibt neue Alternativen, die eine Befehlsablaufsteuervorrichtung analysieren muß und in die Ablaufsteuerungsentscheidungen einfließen lassen muß. Es besteht daher Bedarf an einem Befehlsablaufsteuerverfahren, das diesen Satz von Informationen berücksichtigt und daß die Befehlsablaufsteuervorrichtung befähigt, den optimalen Befehlsausführungsweg aus einem Satz alternativer Wege auszuwählen. Außerdem besteht Bedarf an einer Befehlsablaufsteuervorrichtung, die ferner das Vorhanden sein alternativer Modelle für die Befehlsausgabe und Einleitung in einem Vektorprozessor mit mehrfachen Funktionseinheiten berücksichtigt.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß der vorliegenden Erfindung wird ein Verfahren geschaffen für die Ablaufsteuerung von Befehlen in einem Basisbefehlsblock für die Ausführung in einem Computersystem, das ein Quellcodeprogramm kompiliert oder assembliert, um Objektcodebefehle zu erzeugen, mit den folgenden Schritten: Identifizieren einer Kopfmenge von Befehlen als jene Befehle ohne Betriebsmittelabhängigkeiten von anderen Befehlen im Basisbefehlsblock; Assemblieren einer Bereitmenge aus der Kopfmenge; und Ausgeben des Befehls in der Bereitmenge mit den höchsten kumulativen Anhängigkeitskosten, wobei die kumulativen Anhängigkeitskosten die Kosten bei Nichtausgabe des Befehls anhand der Tatsache, wie andere Befehle von diesem ausgegebenen Befehl abhängen können, repräsentieren; dadurch gekennzeichnet, daß der Schritt des Assemblierens der Bereitmenge die folgenden Schritte umfaßt: Simulieren eines Abschlußzeitpunkts für jeden Befehl im Basisbefehlsblock, wobei der Abschlußzeitpunkt für jeden Befehl auf der sofortigen Ausgabe des Befehls basiert; Simulieren eines gewünschten Ausgabezeitpunkts für jeden Befehl in der Kopfmenge, wobei der gewünschte Ausgabezeitpunkt der späteste Zeitpunkt ist, zu dem der Befehl ausgegeben und noch vor dem Abschlußzeitpunkt abgeschlossen werden kann; und Identifizieren einer Bereitmenge von Befehlen als jene Befehle in der Kopfmenge, deren gewünschter Ausgabezeitpunkt unmittelbar folgt bzw. augenblicklich ist oder früher liegt.
  • Die vorliegende Erfindung ist ein Verfahren für die Ablaufsteuerung von Befehlen für einen Prozessor mit mehrfachen funktionalen Betriebsmitteln, wobei die Aufzeichnung der Befehle durchgeführt wird in Reaktion auf eine Simulation der Laufzeitumgebung der Zielmaschine. Die Simulation der Laufzeitumgebung der Zielmaschine wird zum Kompilierungszeitpunkt durchgeführt, nachdem die Maschinenbefehle vom Compiler erzeugt worden sind, oder nach der Befehlserzeugung durch einen Assembler. Die vorliegende Erfindung ordnet die Maschinenbefehle für einen Basisblock von Befehlen neu in einer Reihenfolge an, die auf der Grundlage der Ergebnisse der Simulation der Wechselwirkung der mehrfachen Funktionsbetriebsmittel in der Zielmaschine zur schnellsten Ausführung führt.
  • Das Verfahren der vorliegenden Erfindung arbeitet mit einem Basisblock von Befehlen und ermittelt zuerst in einer ähnlichen Weise wie statische Befehlsablaufsteuervorrichtungen des Standes der Technik, welche Befehle Elemente der Kopfmenge sind. Der gewünschte Ausgabezeitpunkt (DIT) wird anschließend für jeden Befehl in der Kopfmenge ermittelt, wobei diejenigen Befehle, die von einer frühen Ausgabe profitieren können (was anhand der DIT-Berechnung ermittelt wird), in die Bereitmenge bewegt werden. Aus der Bereitmenge werden die Befehle für die Ausgabe in der Reihenfolge der höchsten kumulativen Kosten eingeteilt.
  • Kopfmengenbefehle sind diejenigen Befehle, die die führenden Kandidaten für die nächste Einteilung sind. Ein Befehl ist in der Kopfmenge enthalten, wenn alle Befehle, von denen er abhängt, ausgegeben worden sind. Da die derzeitigen statischen Befehlsablaufsteuervorrichtungen die Latenzzeiten und die Hardwareverriegelungen zwischen den mehreren Funktionsbetriebsmitteln nur schätzen können, enthält die Bereitmenge im Stand der Technik alle Befehle innerhalb der Kopfmenge, deren Abhängigkeiten zum Zeitpunkt der Ausgabe aufgelöst worden sind.
  • Im Gegensatz zu statischen Befehlsablaufsteuervorrichtungen des Standes der Technik ermittelt die vorliegende Erfindung auf der Grundlage der Ergebnisse einer Simulation zum Kompilierungszeitpunkt, welche Befehle Elemente der Bereitmenge sind.
  • Nach der Ermittlung der Kopfmenge in der üblichen Weise berechnet die vorliegende Erfindung anschließend einen gewünschten Ausgabezeitpunkt (DIT) für jeden Befehl in der Kopfmenge. Der DIT für einen Befehl ist der späteste Zeitpunkt, zu dem der Befehl ausgegeben werden kann und immer noch die Ausführung zu dem Zeitpunkt abschließen kann, zum dem sie abgeschlossen würde, wenn der Befehl sofort ausgegeben würde. Dies dient dazu, diejenigen Befehle zu identifizieren, die von einer sofortigen Ausgabe profitieren können, sowie diejenigen, die für einen späteren Ausgabezeitpunkt vorgesehen werden können, ohne daß sich ein Nachteil beim Abschlußzeitpunkt ergibt. Diejenigen Befehle, deren DIT kleiner ist als der aktuelle Wert der simulierten Zeit in der Simulation zum Kompilierungszeitpunkt, werden in die Bereitmenge bewegt. Dieses Verfahren bewirkt die Verzögerung der Ausgabe irgendeines Befehls, der von einer frühen Ausführung nicht profitieren kann. Durch Verschieben eines Befehls, der von einer frühen Ausgabe nicht profitieren kann, in der Ausgabereihenfolge nach hinten erlaubt die vorliegende Erfindung, daß Befehle, die von einer frühen Ausführung profitieren können, in die Bereitmenge bewegt werden, d. h. sie "steigen" an die Spitze der einzuteilenden Befehle. Im Gegensatz zu Ablaufsteuervorrichtungen des Standes der Technik schließt außerdem die vorliegende Erfindung diejenigen Befehle aus der Bereitmenge aus, die eine Hardwareverriegelung verursachen würden, wenn sie sofort ausgegeben würden. Ein Befehl, dessen DIT größer ist als der aktuelle Wert des simulierten Zeitpunkts, ist ein Befehl, der eine Verriegelung verursachen würde, wenn er sofort ausgegeben würde, so daß das Verfahren der vorliegenden Erfindung den Befehl so behandelt, als ob er nicht zur Ausgabe bereit wäre.
  • Im Vergleich zu statischen Ablaufsteuerverfahren des Standes der Technik bietet die Simulation der aktuellen Latenzzeiten und der Hardwareverriegelungen unter den mehrfachen Betriebsmitteln in einem Prozessor seitens der vorliegenden Erfindung ein genaueres Verfahren, um zu ermitteln, welche Befehle sich in der Bereitmenge befinden sollten. Die Genauigkeit der Mitgliedschaft in der Bereitmenge wird erhöht, sowohl hinsichtlich derjenigen Befehle, die in der Bereitmenge enthalten sein sollten, jedoch aufgrund einer zu konservativen Schätzung der Latenzzeit oder der Verriegelung nicht wären, als auch derjenigen Befehle, die nicht in der Bereitmenge enthalten sein sollten, jedoch wären, da nicht bekannt war, daß sie zu einem späteren Zeitpunkt ausgegeben werden könnten und immer noch zum gleichen Zeitpunkt abschließen, zu dem sie abschließen würden, wenn sie früher ausgegeben würden.
  • Die vorliegende Erfindung ermittelt den DIT, indem sie zuerst den frühestmöglichen Ausgabezeitpunkt (EPIT) für einen Befehl vorhersagt (auf der Grundlage von Skalar- Verriegelungen), und indem sie anschließend den Befehlsabschlußzeitpunkt simuliert (auf der Grundlage der eben vorhergesagten EPIT) und die Abschlußzeiten für alle Kombinationen der verfügbaren Funktionsbetriebsmittel vergleicht. Der DIT ist der späteste Simulationszeitpunkt, zu dem ein Befehl ausgegeben werden kann und immer noch zum frühesten Abschlußzeitpunkt abschließt. In diesem Sinne wird der DIT als der optimale Befehlsausführungsweg unter einer Menge von alternativen Wegen ausgewählt.
  • Sobald die Elemente der Bereitmenge ermittelt worden sind, teilt das Verfahren der vorliegenden Erfindung die Befehle aus der Bereitmenge in eine Reihenfolge ein, die mittels der relativen Kosten der Befehle ermittelt worden ist. Die "Kosten" eines Befehls stellen die Kosten der Nichtausgabe des Befehls dar, dadurch ausgedrückt, wieviele andere Befehle vom Abschluß dieses Befehls abhängen. Ein Befehl, von dem viele andere Befehle abhängen, besitzt höhere Kosten als ein Befehl, von dem wenige andere Befehle abhängen. Diejenigen Befehle in der Bereitmenge mit den höchsten Kosten werden für die Ausführung zuerst eingeteilt. Diese Kostenerhebung dient zum Identifizieren und Einteilen derjenigen Befehle für eine frühe Ausführung, die für die Ausführung des gesamten Basisblocks kritisch sind.
  • Obwohl die vorliegende Erfindung auf einen beliebigen Typ von Prozessor mit mehrfachen Funktionsbetriebsmitteln angewendet werden kann, wird die vorliegende Erfindung vorzugsweise in Verbindung mit Skalar/Vektor-Pipelineprozessoren verwendet, die mehrfache Skalar- oder Vektorfunktionseinheiten besitzen, die die gleichen arithmetischen Operationen ausführen können, sowie einen Vektoreinleitungsmechanismus, der vom Befehlsausgabemechanismus getrennt ist. Bei diesem Typ von Prozessor umfaßt der Vektoreinleitungsmechanismus eine sekundäre Vektorbefehlsausgabepipeline, die eine Vektorbefehlswarteschlange (fünf Befehle tief), eine Vektoreinleitungswarteschlange (einen Befehl tief) sowie Sätze einer Einleitung/Abhängigeinleitung-Steuerlogik umfaßt, durch die ein wartender Vektorbefehl entweder eingeleitet oder zur Ausführung in einer Funktionseinheit zugewiesen wird, oder unabhängig mit reservierten Vektorregistern, jedoch keiner sofort verfügbaren Funktionseinheit eingeleitet wird. Im Gegensatz zu den Vektorbefehlen wird ein Skalar befehl in diesem Prozessor nicht ausgegeben, bis alle seine Operandendaten verfügbar sind. Sobald ein Skalarbefehl ausgegeben wird, wird seine Ausführung (mit Ausnahme von Speicherlade- und Speichersicherungsbefehlen) in einer festen Anzahl von Zyklen abgeschlossen.
  • Die höchste Ebene des Befehlsflusses und der Ablaufsteuerungsanalyse für die bevorzugte Ausführungsform wird deutlich, wenn Befehle von der Befehlsausgabepipeline ausgegeben werden. Die Befehlsablaufsteuervorrichtung kann mehrere Vektorbefehle in der Serie von Warteschlangen abladen, die in der Vektoreinleitungspipeline enthalten sind. Die Vektoreinleitungserweiterung für die Befehlsausgabe versieht die Ablaufsteuervorrichtung mit einem "Startfenster", aus dem die signifikanten Vektorbefehls-Betriebsmittelanforderungen für Register, Speicher und Funktionseinheiten aufgereiht werden. Stark vektorisierte Abschnitte des Codes werden somit innerhalb des Vektorprozessors effizient gestapelt, wodurch die Verriegelungs-Halte in der Befehlsausgabepipeline und in der Ausgabe der Skalarbefehle aufgrund einer Ansammlung wartender Vektorbefehle reduziert werden.
  • Die nächste Ebene des Befehlsflusses und der Ablaufsteuerungsanalyse für die bevorzugte Ausführungsform wird in der Vektoreinleitungspipeline deutlich. Vektorbefehle bewegen sich durch die Vektoreinleitungspipeline, wobei diese verriegelt wird, bis die Vektorbefehle freigegeben werden und die Ausführung in einer Funktionseinheit beginnt. Für eine Maschine mit einer Vektoreinleitungswarteschlange werden Skalarpipeline-Verriegelungen zum Ausgabezeitpunkt aufgelöst, jedoch Vektorpipeline-Verriegelungen bis nach dem Vektoreinleitungszeitpunkt nicht aufgelöst. Die Ablaufsteuervorrichtung der vorliegenden Erfindung verwendet Simulationszeitpunkte für die Vektorbefehlsausgabe, die Einleitung, den Start, die Ausführung und die Abschlußzeitpunkte und hat die Speicherübertragungszeiten bei der Ordnung des Vektorbefehlsstroms geschätzt. Ferner berücksichtigt die Ablaufsteuervorrichtung die Abhängigkeiten zwischen den Vektorbefehlen und den Skalar/Vektor-Befehlen mit Skalaroperandenabhängigkeiten in der eingeteilten Reihenfolge. Somit werden die in die Vektoreinleitungspipeline abgeladenen Befehle in der Reihenfolge der optimalen Ausführungsabschlußzeitpunkte eingeteilt.
  • Aufgrund des Vorhandenseins mehrfacher Funktionseinheiten, die dieselbe arithmetische oder logische Funktion im bevorzugten Skalar/Vektor-Prozessor ausführen können, schafft die vorliegende Erfindung ein Verfahren zum Erzeugen von wegweisenden Befehlen, die dem Prozessor anzeigen, wann die Standardregeln für die Vektoreinleitung vermieden werden sollten. Wenn ein Vektorbefehl ausgegeben wird und dieser Befehl auf mehr als einer Funktionseinheit ausgeführt werden kann, wird der Befehl normalerweise auf der Funktionseinheit eingeleitet, die die längste Zeit keinen Befehl eingeleitet hat. Auf der Grundlage der Simulation zum Kompilierungszeitpunkt kann jedoch die Ablaufsteuervorrichtung der vorliegenden Erfindung ermitteln, wann ein Vektorbefehl, der durch Vorgabe auf einer Funktionseinheit eingeleitet würde, aktuell auf einer anderen Funktionseinheit früher starten würde. Wenn die Ablaufsteuervorrichtung feststellt, daß dies der Fall ist, wird unmittelbar vor dem eingeteilten Vektorbefehl ein einzigartiger Befehl eingefügt, der als PATH-Befehl bezeichnet wird. Der PATH-Befehl spezifiziert die Nummer der Funktionseinheit, zu der der nachfolgende Befehl geleitet werden soll, und überschreibt die Vorgabewahl, die von der Steuerlogik in der Vektoreinleitungspipeline ermittelt wurde.
  • Die Ablaufsteuervorrichtung der vorliegenden Erfindung verwendet viele Arten herkömmlicher Informationen, die den Befehlsablaufsteuervorrichtungen des Standes der Technik auf Compilerbasis zur Verfügung stehen, einschließlich der Schätzungen für Speicherübertragungszeiten und Befehlsabhängigkeiten. Um die Wahl der Funktionseinheiten zu optimieren und genau zu ermitteln, welche Funktionseinheit den frühesten Start für einen bestimmten Befehl bietet, betrachtet die Ablaufsteuervorrichtung der vorliegenden Erfindung ferner mehrere Arten von Informationen. Um den Befehlsstrom zu ordnen, umfassen die betrachteten Informationen Simulationszeitpunkte für die Befehlsausgabe, den Start, die Ausführung und die Abschlußzeitpunkte, Vektoreinleitungszeitpunkte sowie den Vorausschaustatus der Vektorfunktionseinheiten. Durch das Erfassen des Status der Vektorfunktionseinheiten schaut die Ablaufsteuervorrichtung im Ausführungsstrom, der in allen Funktionseinheiten vorhanden ist, voraus, und ermittelt anhand dieser Vorausschau die optimale Wahl der Funktionseinheit für einen bestimmten Befehl. Für diese Vorausschau ist es nützlich, die Analyse von 100 bis 200 Befehlen zu berücksichtigen.
  • Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zu schaffen zum Optimieren der Neuordnung der Befehle, die auf einem Prozessor mit mehrfachen funktionalen Betriebsmitteln ausgeführt werden sollen, in Reaktion auf eine Simulation der Laufzeitumgebung der Zielmaschine.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Befehlsablaufsteuerverfahren zu schaffen, das den Satz an Informationen berücksichtigt, der die Befehlsablaufsteuervorrichtung befähigt, den optimalen Befehlsausführungsweg aus einem Satz alternativer Wege unter mehrfachen Funktionseinheiten auszuwählen.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, eine Befehlsablaufsteuervorrichtung zu schaffen, die das Vorhandensein alternativer Modelle für die Befehlsausgabe und die Einleitung in einem Vektorprozessor mit mehrfachen Funktionseinheiten berücksichtigt und fähig ist, die effektive statische Befehlsablaufsteuerung für Pipelineprozessoren mit einer erweiterten Vektorbefehlseinleitung durchzuführen.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren zu schaffen zum Erzeugen wegweisender Befehle, die dem Prozessor anzeigen, welche arithmetische oder logische Funktionseinheit zur Durchführung eines gegebenen Befehls verwendet werden soll.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, die Rate des Befehlsflusses zu erhöhen und die Befehlsausgabepipeline-Halte in einem Skalar/Vektor-Prozessor mit mehrfachen Funktionseinheiten zu verringern.
  • Diese und weitere Aufgaben der vorliegenden Erfindung werden deutlich mit Bezug auf die Zeichnungen, die genaue Beschreibung der bevorzugten Ausführungsform und die beigefügten Ansprüche.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Fig. 1a ist ein Venn-Diagramm der Kopfmenge und der Bereitmenge für einen Basisblock, wie sie von statischen Befehlsablaufsteuervorrichtungen des Standes der Technik erzeugt werden.
  • Fig. 1b ist ein Venn-Diagramm, das zu demjenigen in Fig. 1a äquivalent ist, für die Kopfmenge und die Bereitmenge für einen Basisblock, wie sie von der vorliegenden Erfindung erzeugt werden.
  • Fig. 2 ist ein Beispiel eines gerichteten azyklischen Abhängigkeitsgraphen, der von der Befehlsablaufsteuervorrichtung der vorliegenden Erfindung verwendet wird.
  • Fig. 3 ist ein Prozeßschaubild, das ein typisches Befehlsablaufsteuerverfahren des Standes der Technik zeigt.
  • Fig. 4 ist ein Prozeßschaubild, das das Befehlsablaufsteuerverfahren der vorliegenden Erfindung zeigt.
  • Fig. 5 ist ein Prozeßschaubild, das das Verfahren zum Berechnen der DIT der Befehle und zum Einsetzen der PATH- Befehle, wo angemessen, gemäß der vorliegenden Erfindung zeigt.
  • GENAUE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Mit Bezug auf die Fig. 1a und 1b wird im folgenden ein Überblick über die Unterschiede zwischen der vorliegenden Erfindung und den Verfahren des Standes der Technik zum Erzeugen der Kopfmenge und der Bereitmenge für eine Befehlsablaufsteuerung beschrieben. Die derzeitigen Compiler manipulieren die Quellcodeprogramme bei dem Prozeß des Erzeugens einer ausführbaren Datei durch Identifizieren der Basisblöcke des Programms. Ein Basisblock 10 ist definiert als ein Satz von Befehlen mit einem einzigen Eingang und einem einzigen Ausgang. Die Kopfmenge 12 ist ein Satz von Befehlen in einem Basisblock, die die führenden Kandidaten für die nächste Einteilung sind. Sie umfaßt alle Befehle in einem Basisblock, bei dem die Befehle, von denen der fragliche Befehl abhängt, wenigstens ausgegeben worden sind. Die Befehlsablaufsteuervorrichtungen sowohl des Standes der Technik als auch der vorliegenden Erfindung erzeugen die Kopfmenge 12 in ähnlicher Weise, wie in Verbindung mit den Fig. 2 und 3 genauer beschrieben worden ist. Die Bereitmenge 14, 16 ist die Menge der Befehle für einen Basisblock, die zu einem gegebenen Zeitpunkt als ausgabebereit ermittelt werden. Wie gezeigt, ist die Bereitmenge 14, 16 eine Teilmenge der Kopfmenge 12.
  • Der Unterschied zwischen dem Stand der Technik und der vorliegenden Erfindung besteht in der Erzeugung der Bereitmenge 14, 16. Obwohl es nicht offensichtlich ist, erkennt ein Fachmann, daß die Aufgabe irgendeines Befehlsablaufsteuerprogramms darin besteht, die Bereitmenge 14, 16 so klein wie möglich zu machen, wodurch die Wahrscheinlichkeit erhöht wird, daß die Befehle in der Bereitmenge 14, 16 tatsächlich ohne Hardwareverriegelung bis zum Abschluß ausgeführt werden. Da die derzeitigen statischen Befehlsablaufsteuervorrichtungen die Latenzzeiten und die Hardwareverriegelungen zwischen den mehrfachen Funktionsbetriebsmitteln nur schätzen können, enthält die Bereitmenge 14 des Standes der Technik alle Befehle, deren Abhängigkeiten zum Ausgabezeitpunkt aufgelöst worden sind. Im Gegensatz zu den statischen Befehlsablaufsteuervorrichtungen des Standes der Technik ermittelt die vorliegende Erfindung auf der Grundlage der Ergebnisse einer Simulation zum Kompilierungszeitpunkt, welche Befehle Elemente der Bereitmenge 16 sind.
  • Die vorliegende Erfindung prüft jedes Element der Kopfmenge 12 auf das Einschließen in die Bereitmenge 16, in dem sie zuerst einen gewünschten Ausgabezeitpunkt (DIT) für jeden Befehl in der Kopfmenge 12 berechnet. Diejenigen Befehle, deren DIT kleiner ist als der aktuelle Wert des simulierten Zeitpunkts in der Simulation zum Kompilierungszeitpunkt, werden in die Bereitmenge 16 eingeschlossen. Dieses Verfahren bewirkt eine verzögerte Ausgabe jedes Befehls, der nicht von einer frühen Ausgabe profitieren kann. Die Befehle, die nicht von einer sofor tigen Ausgabe profitieren können, sind diejenigen, die eine Verriegelung verursachen würden, wenn sie sofort ausgegeben würden, wobei sie in Fig. 1b dargestellt werden durch "Befehle mit Verriegelungen" 18. Durch Verschieben dieser Befehle in der Ausgabereihenfolge nach hinten erlaubt die vorliegende Erfindung, daß Befehle, die von einer sofortigen Ausführung profitieren können, in die Bereitmenge bewegt werden, d. h. sie "steigen" zur Spitze der einzuteilenden Befehle. Mit anderen Worten, die Simulation der wirklichen Latenzzeiten und Hardwareverriegelungen unter den mehrfachen Betriebsmitteln in einem Prozessor durch die vorliegende Erfindung schafft ein genaueres Verfahren, um zu ermitteln, welche Befehle in der Bereitmenge sein sollten. Obwohl für irgendeinen gegebenen Basisblock die Anzahl der Befehle in der Bereitmenge zu einem beliebigen gegebenen Zeitpunkt anders sein kann als in der Bereitmenge des Standes der Technik, wird die Genauigkeit der Mitgliedschaft in der Bereitmenge erhöht. Diejenigen Befehle, die in der Bereitmenge enthalten sein sollten, jedoch aufgrund einer zu konservativen Schätzung der Latenzzeit oder der Verriegelung nicht enthalten waren, werden zur Bereitmenge hinzugefügt. Diejenigen Befehle, die nicht in der Bereitmenge enthalten sein sollten, jedoch waren, da nicht bekannt war, daß sie zu einem späteren Zeitpunkt ausgegeben werden könnten und immer noch zum selben Zeitpunkt abschließen, zu dem sie abschließen würden, wenn sie früher ausgegeben würden, werden aus der Bereitmenge gelöscht. Das Endergebnis ist, daß die Neuordnung der Befehle durch die Ablaufsteuervorrichtung der vorliegenden Erfindung zu einer optimaleren Organisation der Befehle und somit zu einer erhöhten Leistungsfähigkeit des Prozessors führt.
  • Bei der Ermittlung der Mitgliedschaft in der Kopfmenge 12 konstruiert die Befehlsablaufsteuervorrichtung der vorliegenden Erfindung zuerst einen Abhängigkeits-DAG (DAG = gerichteter azyklischer Graph) für den Block des Codes 10, der im Ablauf gesteuert werden soll. Typischerweise führt die Befehlsablaufsteuervorrichtung die Ablaufsteuerung über einen Basisblock einer Zwischensprache durch, wobei die Zwischensprache sich stark der Assemblersprache der Zielmaschine nähert.
  • In der folgenden Beschreibung wird der Prozeß der Ablaufsteuerung der Befehle für die Ausführung beschrieben. Die Ablaufsteuerung wird durchgeführt zum Kompilierungszeitpunkt (oder Assemblierungszeitpunkt) und wird bewerkstelligt durch Analysieren einer Simulation der Laufzeitumgebung der Zielmaschine. Es ist daher konzeptionell nützlich, über Befehle nachzudenken, die im Sinne der Simulation als "ausgegeben" eingeteilt worden sind. Da das Verfahren der vorliegenden Erfindung Codeoptimierungstechniken zum Kompilierungs- oder Assemblierungszeitpunkt betrifft, werden Fachleute erkennen, daß der Bezug auf einen ausgegebenen Befehl in Wirklichkeit auf die Ausgabe in der Simulation und nicht auf der Zielmaschine Bezug nimmt.
  • In Fig. 2 sind der Quellcode, der Zwischensprachencode und ein entsprechender Abhängigkeits-DAG gezeigt. Die Quellengleichungen 20 sind zusammen mit ihrer Darstellung in einer Serie von neun Zwischensprachenanweisungen 21 gezeigt, die den Befehlen auf Assemblerebene ähnlich sind. Aus den Zwischensprachenbefehlen 21 erzeugt die Ablaufsteuervorrichtung einen Abhängigkeits-DAG 22. Jeder Knoten des Abhängigkeits-DAG 22 entspricht einem Assemblersprachenbefehl, wie in Fig. 2 entsprechend angegeben ist. Zum Beispiel entspricht der Knoten 22a des Abhängigkeits-DAG 22 dem Assemblersprachenbefehl 21a. Die Kanten zwischen den Knoten im DAG 22 sind als Pfeile gezeigt und zeigen die Abhängigkeiten zwischen den Befehlen. Die Kante 24 zwischen dem Knoten 22b und dem Knoten 22g zeigt, daß der Befehl 21b vor dem Befehl 21g ausgeführt werden muß. Knoten ohne ankommende Kanten besitzen keine Abhängigkeiten im Basisblock und müssen nicht auf irgendeinen anderen Befehl warten, bevor sie ausgegeben werden können.
  • Die Knoten im Abhängigkeits-DAG 22 erhalten jeweils einen kumulativen Kostenwert in umgekehrter Reihenfolge zugewiesen. Konzeptionell sind die "Kosten" eines Befehls die zeitliche Konsequenz der Nichtausgabe des Befehls. Mit anderen Worten, ein Befehl, von dem viele andere abhängen, besitzt höhere Kosten als ein Befehl, von dem weniger andere abhängen. Arithmetisch werden die Kosten eines Befehls als die Ausführungszeit des Befehls plus der kumulativen Ausführungszeiten aller anderen Befehle, die davon abhängen, berechnet. Eine weitere Möglichkeit zum Ausdrücken derselben ist, daß die Kosten eines Befehls die Kosten aller Nachfolgeknoten innerhalb des Basisblocks plus der Zeitspanne der Ausführung des aktuellen Knotens sind. Die relativen Kosten, die auf diese Weise aus dem Abhängigkeits-DAG 22 berechnet werden, identifizieren die kritischen Wege der Befehle im Basisblock. Insgesamt ergibt sich somit aus dem Abhängigkeits-DAG 22 eine Teilordnung der Befehle im Basisblock. Die Ablaufsteuervorrichtung kann die Befehle auf der Grundlage der Abhängigkeiten frei umordnen, solange die Teilordnung erhalten bleibt.
  • Der Prozeß der Umordnung der Befehle gemäß der vorliegenden Erfindung geschieht durch eine Simulation der Laufzeitumgebung der Zielmaschine. Durch die Verwendung des DAG 22 wird jeder Befehl im Basisblock, der noch nicht eingeteilt worden ist, in der Kopfmenge 12 plaziert, wenn er nicht von irgendwelchen nicht ausgegebenen Befehlen abhängt. Ein Kopfbefehl wird in einem DAG als ein Knoten ohne Vorgänger identifiziert. Zum Beispiel sind im DAG 22 die Knoten 22a, 22b, 22d und 22e Kopfknoten, die die Zwischensprachenbefehle 21a, 21b, 21d und 21e darstellen.
  • Ein Befehl kann nicht zur Ausgabe ausgewählt werden, solange er nicht ein Führer wird. Wenn Befehle ausgegeben werden, werden ihre Knoten aus dem DAG 22 entfernt, wobei bestimmte Nachfolgeknoten neue Führer werden. Sobald ein Befehl der Kopfmenge 12 zugeordnet worden ist, verbleibt ein Befehl in der Kopfmenge 12, bis er ausgegeben worden ist.
  • Die Fig. 3 zeigt ein Befehlsablaufsteuerverfahren des Standes der Technik. Die Ablaufsteuerung wird bewerkstelligt durch Manipulation eines DAG, der für den ablaufgesteuerten Basisblock erzeugt worden ist, wie oben beschrieben worden ist. Zuerst identifiziert das Verfahren des Standes der Technik die Kopfmenge 12 im Schritt 40 als die Befehle, die den Knoten im DAG 22 ohne ankommende Kanten entsprechen. Von den Befehlen in der Kopfmenge 12 werden diejenigen, die keine geschätzten Verriegelungen besitzen, im Schritt 42 in die Bereitmenge 14 bewegt. Verriegelungen werden verursacht durch Maschinenbetriebsmittel wie z. B. Register, die von einem Befehl benötigt werden, jedoch nicht verfügbar sind, typischerweise weil sie von einem noch ausgeführten vorherigen Befehl verwendet werden. Verriegelungen werden auf der Grundlage einer vordefinierten Befehlsausführungszeit statisch geschätzt. Befehle in der Kopfmenge 12 ohne Verriegelungen sind zur Ausführung bereit und werden daher geeignet in der Bereitmenge 14 plaziert, entsprechend dem Verfahren des Standes der Technik.
  • Wenn die Bereitmenge 14 einen oder mehrere Befehle im Schritt 44 enthält, teilt das Verfahren des Standes der Technik den Befehl mit den höchsten Kosten im Schritt 46 in die Bereitmenge 14 ein. Der eingeteilte Befehl wird anschließend aus dem DAG 22 im Schritt 48 entfernt, die Maschinenbetriebsmittel werden dem eingeteilten Befehl im Schritt 50 zugewiesen und irgendwelche Befehle in der Bereitmenge 14, die nun eine Verriegelung hervorrufen würden, wären im Schritt 52 aus der Bereitmenge 14 in die Kopfmenge 12 bewegt. Der Prozeß iteriert anschließend, indem er zum Anfang zurückkehrt und weitere Befehle im Ablauf steuert.
  • In dem Fall, in dem die Bereitmenge 14 im Schritt leer ist, prüft der Prozeß die Kopfmenge 12 im Schritt 54, um zu ermitteln, ob diese ebenfalls leer ist. Wenn die Bereitmenge 14 und die Kopfmenge 12 beide leer sind, zeigt dies an, daß keine weiteren Befehle im Basisblock im Ablauf zu steuern sind, wobei der Prozeß endet. Wenn die Kopfmenge 12 im Schritt 54 nicht leer ist, werden anschließend die Verriegelungen aufgrund der derzeit ausgeführten Befehle im Schritt 56 für den Befehl gelöscht, der als nächster abzuschließen wäre. Dies erfordert selbstverständlich, daß der Prozeß Schätzungen der Befehlsausführungszeiten und der Befehlsabschlußzeiten erstellt, um zu schätzen, wann die durch die Ausführung der Befehle verursachten Verriegelungen aufgehoben werden.
  • Nach jeder Iteration des in Fig. 3 gezeigten Verfahrens des Standes der Technik wählt die Ablaufsteuervorrichtung den Befehl mit den höchsten kumulativen Kosten aus dem Satz der Befehle, die keine anhängigen Pipelineverriegelungen besitzen. Der Stand der Technik ist effektiv, da er die Ausgabe des Befehls ohne Verriegelungen auf dem kritischsten Pfad wählt. Sobald der jeweilige Befehl ausgegeben worden ist, wird er bis zum Abschluß ausgeführt.
  • Obwohl das obenbeschriebene Verfahren in Maschinen des Standes der Technik effektiv ist, ist es weniger effektiv, wenn ein Vektorprozessor eine erweiterte Vektorausgabepipeline besitzt, wie dies in der bevorzugten Ausführungsform der Fall ist, oder wenn die Maschine mehrfache funktionale Einheiten besitzt, die jeweils einen gegebenen Funktionstyp ausführen können. Unter diesen Umständen können Vektorbefehle unter Pipelineverriegelungen nach dem Ausgabezeitpunkt leiden, da zum Ausgabezeitpunkt ein Vektorbefehl nur skalare Verriegelungen aufgehoben hat und in die Einleitungswarteschlange eintreten konnte. Ein Vektorbefehl kann weitere Verzögerungen aufgrund von Vektor-Register-Zugriffsbeschränkungen oder Funktionseinheitbeschränkungen erfahren oder kann einen Halt aufgrund einer Verriegelung erfahren, die einen vorangehenden Vektorbefehl in der Einleitungswarteschlange beeinflußt.
  • Im Gegensatz zum Ablaufsteuerverfahren des Standes der Technik wird die Ablaufsteuerung gemäß der vorliegenden Erfindung bewerkstelligt durch eine Simulation der Laufzeitumgebung der Zielmaschine sowie durch eine Manipulation eines DAG 22, der für den ablaufgesteuerten Basisblock erzeugt worden ist. Die vorliegende Erfindung unterscheidet sich vom Stand der Technik durch das Verfahren für die Bewegung der Vektorbefehle in die Bereitmenge 14 und durch das Verfahren zum Verfolgen der simulierten Zeitspanne der Ablaufsteuervorrichtung. Durch Ausführen einer gründlichen Simulation der Zielmaschine auf System-Taktzyklusebene, können die Befehlsausführungszeiten genau vorhergesagt werden, statt sie lediglich zu schätzen, wobei die Ausführungszeiten unter Verwendung alternativer Ausführungswege durch alternative Funktionseinheiten ermittelt werden können, um die effizienteste der verfügbaren Ausführungsweg-Optionen auszuwählen. Fachleute erkennen, daß die Einzelheiten der Simulation von der fraglichen Zielmaschine abhängen, weshalb sie außerhalb des Umfangs der vorliegenden Be schreibung liegen. In der bevorzugte Ausführungsform wird die Simulation erleichtert durch Verwendung einer Befehlsbeschreibungstabelle, die Informationen über jede Ausführungszeit des Befehls enthält, die während der Ausführung implizit gelesenen oder geschriebenen Steuerregister (wie z. B. die Vektormaske) und die expliziten Register (wie z. B. Operanden oder Ergebnisse).
  • In Fig. 4 ist ein Verfahren der Ablaufsteuerung der Befehle gemäß der bevorzugte Ausführungsform der vorliegenden Erfindung gezeigt. Wie beim Stand der Technik arbeitet der Prozeß gemäß der vorliegenden Erfindung mit einem Basisblock des Codes und beginnt im Schritt 40, indem er alle Befehle in die Kopfmenge 12 bewegt, deren entsprechende Knoten im DAG 22 keine ankommenden Kanten besitzen. Der gewünschte Ausgabezeitpunkt (DIT) für jeden der Kopfbefehle wird anschließend im Schritt 60 berechnet. Der DIT für einen Befehl ist der späteste Zeitpunkt, zu dem ein Befehl ausgegeben werden kann und immer noch zum selben Zeitpunkt abschließt, zu dem er abschließen würde, wenn er sofort ausgegeben würde. Wenn z. B. ein zum Zeitpunkt t = 0 ausgegebener Befehl bei t = 200 abschließen würde, ist der DIT für diesen Befehl der späteste Zeitpunkt für die Ausgabe des Befehls, bei dem er die Ausführung bei t = 200 abschließt. Einzelheiten der DIT-Berechnung werden mit Bezug auf Fig. 5 beschrieben.
  • Sobald der DIT für alle Befehle in der Kopfmenge 12 im Schritt 60 berechnet worden ist, bewegt der Prozeß anschließend im Schritt 62 alle Befehle, deren DIT kleiner ist als die aktuelle Simulationszeit, in die Bereitmenge 16. Wenn die Bereitmenge 16 im Schritt 44 leer ist und die Kopfmenge 12 im Schritt 54 leer ist, sind alle Befehle im Basisblock im Ablauf gesteuert worden und der Prozeß endet. Wenn die Bereitmenge 16 im Schritt 44 nicht leer ist, ist der Befehl in der Bereitmenge 16 mit den höchsten Kosten im Schritt 46 im Ablauf gesteuert worden, wobei sein Knoten und die abgehenden Kanten im Schritt 48 aus dem DAG 22 entfernt werden. Die Simulationszeit wird anschließend im Schritt 64 auf den Zeitpunkt vorgerückt, zu dem die Simulation ermittelt, daß der gerade im Ablauf gesteuerte Befehl wirklich ausgegeben wird. Die Maschinenbetriebsmittel, wie z. B. Register und die Funktionseinheit, werden dem im Ablauf gesteuerten Befehl im Schritt 50 zugewiesen, wobei irgendwelche neuen Verriegelungen, die durch die Zuweisung der Maschinenbetriebsmittel erzeugt werden, geprüft werden, um festzustellen, ob die Befehle in der Bereitmenge 16 im Schritt 52 in die Kopfmenge 12 zurückbewegt werden müssen. Der Prozeß kehrt anschließend zum Anfang zurück, um den nächsten Befehl im Ablauf zu steuern.
  • In dem Fall, daß die Bereitmenge 16 im Schritt 44 leer ist und die Kopfmenge 12 im Schritt 54 nicht leer ist, wird anschließend die Simulationszeit auf den Zeitpunkt vorgerückt, zu dem ein Befehl in der Kopfmenge 12 im Schritt 66 in die Bereitmenge 16 bewegt werden kann. Der Prozeß kehrt anschließend zum Anfang zurück und fährt fort, bis alle Befehle im Basisblock im Ablauf gesteuert worden sind.
  • Fachleute erkennen, daß viele Abwandlungen an dem in Fig. 4 beschriebenen Verfahren vorgenommen werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Zum Beispiel ist die Reihenfolge der Ausführung der Schritte 48, 64 und 50 für eine geeignete Operation des Verfahrens nicht kritisch.
  • In Fig. 5 ist ein Verfahren zum Ermitteln des DIT eines Befehls 60 gezeigt. Zuerst wird im Schritt 70 der frühestmögliche Ausgabezeitpunkt (EPIT) für den Befehl ermittelt. Dies findet statt, wenn Skalarverriegelungen in der Maschine für den fraglichen Befehl aufgehoben worden sind. Wenn im Schritt 72 der Befehl ein Skalarbefehl ist, wird im Schritt 74 der DIT gleich dem EPIT gesetzt, woraufhin der Prozeß endet, da dann, wenn der Skalarbefehl zum EPIT ausgegeben wird, der Befehl bis zum Abschluß ausgeführt wird, ohne irgendwelche Verriegelungen hervorzurufen. Die Verzögerung der Ausgabe eines Skalarbefehls über den EPIT hinaus verzögert somit den Abschlußzeitpunkt des Befehls.
  • Wenn der fragliche Befehl ein Vektorbefehl (Schritt 72) ist, sagt die Simulation den Abschlußzeitpunkt des Befehls im Schritt 76 voraus, unter der Annahme, daß der Befehl zum EPIT an die Vorgabefunktionseinheit ausgegeben worden ist. In der bevorzugte Ausführungsform der vorliegenden Erfindung besitzt die Zielmaschine eine Vektorbefehlspipeline und eine Befehlseinleitungsprozedur. Die Signifikanz der Zielmaschinenarchitektur für das in Fig. 5 gezeigte Verfahren besteht nur darin, daß die Simulation der Ziel-Laufzeitumgebung die spezielle verwendete Maschinenarchitektur berücksichtigen muß, um die Befehlsabschlußzeiten genau vorherzusagen. Somit wird in der bevorzugte Ausführungsform dann, wenn ein Vektorbefehl in die Kopfmenge 12 bewegt wird, der früheste Einleitungszeitpunkt des Befehls auf der Grundlage des EPIT und der Vektorpipeline-Verriegelungen berechnet, die der Befehl in der Einleitungswarteschlange hervorrufen wird. Der DIT wird anschließend ermittelt durch Berechnen des spätestmöglichen Ausgabezeitpunkts des Befehls, der zu der Einleitung zum frühestmöglichen Zeitpunkt führt. Der DIT wird immer größer oder gleich dem EPIT sein. In der bevorzugte Ausführungsform bewegt sich ein Befehl von der Kopfmenge 12 zur Bereitmenge 16, wenn die simulierte Zeit den DIT erreicht.
  • Der Prozeß ermittelt als nächstes im Schritt 78, ob mehr als eine Funktionseinheit vorhanden ist, auf der der Befehl ausgeführt werden kann, Falls nicht, wird der DIT im Schritt 80 gleich dem letzten Zeitpunkt gesetzt, zu dem der Befehl ausgegeben werden kann, so daß er immer noch zur vorhergesagten Abschlußzeit abschließt. Wenn mehr als eine Funktionseinheit vorhanden ist, auf der der Befehl abgeschlossen werden kann (Schritt 78), sagt der Prozeß die Abschlußzeit für den Befehl im Schritt 82 für jede der alternativen Funktionseinheiten vorher, wobei erneut die Ausgabe zum EPIT angenommen wird. Wenn der Abschluß auf einer alternativen Funktionseinheit früher stattfindet (Schritt 84), wird der Befehl im Schritt 86 als einen PATH-Befehl erfordernd markiert, um die Vorgabewahl der Funktionseinheiten zu überschreiben. Wenn dieser Befehl im Ablauf gesteuert wird, wird dann, wenn ein alternativer Weg bevorzugt wird, ein PATH-Befehl in den Befehlsstrom eingefügt. Jedenfalls setzt der Prozeß den DIT im Schritt 80 entsprechend dem frühestens vorhergesagten Abschlußzeitpunkt, der vorher ermittelt worden ist.

Claims (4)

1. Verfahren zur Zuweisung von Zeit an Befehle in einem Basisbefehlsblock (10) für die Ausführung in einem Computersystem, das ein Quellcodeprogramm kompiliert oder assembliert, um Objektcodebefehle zu erzeugen, mit den folgenden Schritten:
Identifizieren (40) einer Kopfmenge (12) von Befehlen als jene Befehle ohne Betriebsmittelabhängigkeiten von anderen Befehlen im Basisbefehlsblock;
Assemblieren (62) einer Bereitmenge (16) aus der Kopfmenge; und
Ausgeben (46) des Befehls in der Bereitmenge mit den höchsten kumulativen Anhängigkeitskosten, wobei die kumulativen Anhängigkeitskosten die Kosten bei Nichtausgabe des Befehls anhand der Tatsache, wie andere Befehle von diesem ausgegebenen Befehl abhängen können, repräsentieren; dadurch gekennzeichnet,
daß der Schritt des Assemblierens der Bereitmenge die folgenden Schritte umfaßt:
Simulieren eines Abschlußzeitpunkts für jeden Befehl im Basisbefehlsblock (10), wobei der Abschlußzeitpunkt für jeden Befehl auf der sofortigen Ausgabe des Befehls basiert;
Simulieren (60) eines gewünschten Ausgabezeitpunkts für jeden Befehl in der Kopfmenge (12), wobei der gewünschte Ausgabezeitpunkt der späteste Zeitpunkt ist, zu dem der Befehl ausgegeben und noch vor dem Abschlußzeitpunkt abgeschlossen werden kann; und
Identifizieren (62) einer Bereitmenge (16) von Befehlen als jene Befehle in der Kopfmenge, deren gewünschter Ausgabezeitpunkt unmittelbar ist bzw. folgt oder früher liegt.
2. Verfahren nach Anspruch 1, bei dem der Schritt des Simulierens eines Abschlußzeitpunkts den Schritt des Vorhersagens eines alternativen Abschlußzeitpunkts für jeden Befehl auf der Grundlage einer Simulation der Ausführung jedes Befehls für alle Kombinationen der verfügbaren funktionalen Einheiten im Computer umfaßt.
3. Verfahren nach Anspruch 2, bei dem der Schritt des Vorhersagens des alternativen Abschlußzeitpunkts die folgenden Schritte umfaßt:
Bestimmen für irgendeinen Objektcodebefehl, der von zwei oder mehr ähnlichen der funktionalen Einheiten ausgeführt werden kann, eines optimalen Ausführungsweges unter sämtlichen verfügbaren ähnlichen der funktionalen Einheiten für diesen Objektcodebefehl; und
dann, wenn der optimale Ausführungsweg von einem voreingestellten Weg der Ausführung eines Objektcodebefehls abweicht, Einfügen eines Weg-Objektcodebefehls in die vom Computer erzeugten Objektcodebefehle vor dem Objektcodebefehl mit dem abweichenden optimalen Ausführungsweg, der den als nächstes im Computer auszuführenden Objektcodebefehl längs des optimalen Ausführungsweges lenkt.
4. Verfahren nach Anspruch 3, bei dem der Schritt des Bestimmens eines optimalen Ausführungsweges die folgenden Schritte umfaßt:
Simulieren verschiedener Ausführungssequenzen für die Objektcodebefehle für sämtliche Kombinationen aller verfügbaren funktionalen Einheiten; und
Wählen jener Ausführungssequenz, die die schnellste Ausführungsgeschwindigkeit während des Simulationsschrittes ergibt, als optimalen Ausführungsweg für jeden Objektcodebefehl, der von zwei oder mehr ähnlichen der funktionalen Einheiten ausgeführt werden kann.
DE69131830T 1990-06-11 1991-06-10 Verfahren zur optimierung der befehlsablauffolge Expired - Lifetime DE69131830T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US07/537,466 US5179702A (en) 1989-12-29 1990-06-11 System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling
US57150090A 1990-08-23 1990-08-23
PCT/US1991/004073 WO1991020031A1 (en) 1990-06-11 1991-06-10 Method for optimizing instruction scheduling

Publications (2)

Publication Number Publication Date
DE69131830D1 DE69131830D1 (de) 2000-01-13
DE69131830T2 true DE69131830T2 (de) 2000-06-21

Family

ID=27065494

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69131830T Expired - Lifetime DE69131830T2 (de) 1990-06-11 1991-06-10 Verfahren zur optimierung der befehlsablauffolge

Country Status (4)

Country Link
EP (1) EP0535107B1 (de)
JP (1) JP3288372B2 (de)
DE (1) DE69131830T2 (de)
WO (1) WO1991020031A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5202993A (en) * 1991-02-27 1993-04-13 Sun Microsystems, Inc. Method and apparatus for cost-based heuristic instruction scheduling
US5493687A (en) 1991-07-08 1996-02-20 Seiko Epson Corporation RISC microprocessor architecture implementing multiple typed register sets
DE69311330T2 (de) 1992-03-31 1997-09-25 Seiko Epson Corp., Tokio/Tokyo Befehlsablauffolgeplanung von einem risc-superskalarprozessor
JP3531166B2 (ja) * 1992-12-31 2004-05-24 セイコーエプソン株式会社 レジスタ・リネーミングのシステム及び方法
US5712996A (en) * 1993-03-15 1998-01-27 Siemens Aktiengesellschaft Process for dividing instructions of a computer program into instruction groups for parallel processing
TW440793B (en) * 1998-02-25 2001-06-16 Koninkl Philips Electronics Nv A method for structuring a multi-instruction computer program from basic blocks that compose from internal instructions and external jumps in an internal directed acyclic graph, and a processor loaded with such program
US6584611B2 (en) * 1999-02-17 2003-06-24 Elbrus International Limited Critical path optimization—unload hard extended scalar block

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4179737A (en) * 1977-12-23 1979-12-18 Burroughs Corporation Means and methods for providing greater speed and flexibility of microinstruction sequencing
US4298933A (en) * 1978-07-08 1981-11-03 Tokyo Shibaura Denki Kabushiki Kaisha Data-processing device including means to suppress the execution of unnecessary instructions
US4399507A (en) * 1981-06-30 1983-08-16 Ibm Corporation Instruction address stack in the data memory of an instruction-pipelined processor
US4567574A (en) * 1983-03-14 1986-01-28 International Business Machines Corporation Optimizing cobol object code instruction path length with respect to perform statements

Also Published As

Publication number Publication date
EP0535107A4 (en) 1993-11-24
EP0535107A1 (de) 1993-04-07
JP3288372B2 (ja) 2002-06-04
JPH05508040A (ja) 1993-11-11
DE69131830D1 (de) 2000-01-13
EP0535107B1 (de) 1999-12-08
WO1991020031A1 (en) 1991-12-26

Similar Documents

Publication Publication Date Title
DE69209888T2 (de) Befehlablaufsteuerung für einen Rechner
DE69229365T2 (de) Verfahren und Anordnung zur kostenbezogenen heuristischen Befehlsreihenfolgeplanung
US5202975A (en) Method for optimizing instruction scheduling for a processor having multiple functional resources
DE69132675T2 (de) Parallelfliessband-Befehlsverarbeitungssystem für sehr lange Befehlswörter
DE3587218T2 (de) Verfahren zur Ausführung von in einer hohen Programmiersprache geschriebenen Anwenderprogrammen.
DE3650696T2 (de) Paralleles prozessorsystem und zugehöriges verfahren zur behandlung von natürlichen nebenläufigkeiten
DE69613732T2 (de) Betriebsmittelzuweisungsgerät
DE69311330T2 (de) Befehlsablauffolgeplanung von einem risc-superskalarprozessor
DE19506435C2 (de) Verfahren und Einrichtung zum Vermeiden von Rückschreibkonflikten zwischen einen gemeinsamen Rückschreibpfad verwendenden Ausführungseinheiten
DE4217012C2 (de) Mit einer Vielzahl von Befehlsströmen und statischer Verschachtelung arbeitender Mikroprozessor
DE69736105T2 (de) Hierarchische durchsuchlogik für ungeordnete lade/speicherausführungssteuerung
DE68925646T2 (de) Pipeline-multiprozessorsystem
DE19945992B4 (de) Dynamisch optimierender Objektcode-Übersetzer zur Architekturemulation und dynamisches optimierendes Objektcode-Übersetzungsverfahren
DE69327637T2 (de) Superskalar-Computersystem
DE69622305T2 (de) Verfahren und Gerät für einen optimierenden Kompiler
DE102013017982A1 (de) COMPILER gesteuerte Gebietsdisponierung für SIMD-Ausführung von Strängen
DE69715328T2 (de) System und Verfahren zur Parallelisierung der Durchführung von Speichertransaktionen mittels mehreren Speichermodellen
DE69636861T2 (de) Mikroprozessor mit Lade-/Speicheroperation zu/von mehreren Registern
DE69325086T2 (de) Verfahren und System für spekulative Befehlsausführung
DE19534752A1 (de) Verfahren und System zum Liefern einer Unterstützung für eine spekulative Ausführung
DE10393260T5 (de) Nachdurchgangs-Binäranpassung für eine auf Software basierende spekulative Vorberechnung
US5307478A (en) Method for inserting a path instruction during compliation of computer programs for processors having multiple functional units
DE102017109239A1 (de) Computerimplementiertes verfahren, computerlesbares medium und heterogenes rechnersystem
DE69032394T2 (de) Minimierung von Pipelineunterbrechungen mittels Software-Ablaufplanungsverfahren während der Kompilation
DE102020110655A1 (de) Verfahren und vorrichtung zum verbessern der verwendung eines heterogenen systems, das software ausführt

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: KUDLEK & GRUNERT PATENTANWAELTE PARTNERSCHAFT, 803