DE69209888T2

DE69209888T2 - Befehlablaufsteuerung für einen Rechner

Info

Publication number: DE69209888T2
Application number: DE69209888T
Authority: DE
Inventors: David Bernstein; Martin Edward Hopkins; Michael Rodeh
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1991-05-23
Filing date: 1992-02-06
Publication date: 1996-10-24
Anticipated expiration: 2012-02-07
Also published as: EP0515016B1; US5526499A; EP0515016A3; IL98248A0; JPH0792752B2; DE69209888D1; JPH05143332A; EP0515016A2

Description

Die vorliegende Erfindung betrifft eine Befehlablaufsteuerung für einen Rechner und insbesondere eine Befehlablaufsteuerung, die spektulativ den Ablauf bestimmter Kategorien von Ladebefehlen auf eine Weise planen kann, die sich für den Einsatz mit einem Parallel-/Pipeline-Rechner eignet.
Das Steuern von Befehlsabläufen ist ein Prozeß, bei dem Programmanweisungen umgeordnet oder transformiert werden, bevor sie von einem Prozessor ausgeführt werden, um mögliche Laufzeitverzögerungen zwischen kompilierten Befehlen zu reduzieren. Das Steuern von Befehlsabläufen erfolgt in der Regel auf einer mittleren Sprach- oder Assembliercode-Ebene. Solche Transformationen müssen Datendependenzen erhalten und unterliegen auch anderen Einschränkungen. Dies kann besonders dann von Vorteil sein, wenn für Pipeline- Maschinenarchitekturen kompiliert wird, die durch überlappende Befehlsausführung einen erhöhten Durchsatz ermöglichen. Wenn z. B. eine Verzögerung eines Zyklus zwischen dem Holen und dem Verwenden eines Wertes W eintritt, wäre es wünschenswert, diese Verzögerung mit einem Befehl "abzudecken", der von W unabhängig ist und zur Ausführung "bereit" ist.
Eine besondere Anwendung der Befehlablaufsteuerung liegt im Bereich der sogenannten RISC-Architektur (Reduced Instruction Set Computer, Rechner mit reduziertem Befehlssatz). Eine Einführung in RISC-Rechner findet sich in folgendem Artikel:
R1 D.A. Patterson, "Reduced instruction set computers", erschienen in den Communications of the ACM (Jan. 1985), Seite 8-21.
Das RISC-Konzept für den Bau von Hochgeschwindigkeitsprozessoren, das Ende der siebziger Jahre aufkam, betont die Notwendigkeit der Rationalisierung von Programmbefehlen. Dadurch wurden Befehle neu geordnet, in der Regel auf der mittleren Sprach- oder Assembliercode-Ebene, um das Pipelining voll zu nutzen und dadurch die Geschwindigkeit zu steigern. Die Aufgabe der Befehlablaufsteuerung wird optimierenden Kompilierern aufgebürdet, die den Code für RISC-Prozessoren erzeugen. In der Regel führen die Kompilierer die Befehlablaufsteuerung auf der Ebene der Grundblöcke durch, so daß die meisten Probleme gelöst werden, die sich aus der Pipeline-Struktur von RISC-Prozessoren ergeben.
Konzepte für die Ablaufsteuerung auf der Befehlsebene für Pipeline-Maschinen sind in folgendem Artikeln beschrieben:
R2 J.J. Hennessy und T. Gross, "Postpass Code Optimisation of Pipeline Constraints", erschienen in den ACM Transactions on Programming Languages and Systems 5 (Juli 1983), Seite 422-448.
R3 P.B. Gibbons und 5.5. Muchnick, "Efficient Instruction Scheduling for a Pipelined Architecture", erschienen in den Proceedings of the ACM Symposium on Compiler Construction (Juni 1986).
R4 H. Warren, "Instruction Scheduling for the IBM RISC System/6000 Processor", erschienen im IBM Journal of Research and Development, Bd. 34, Nr. 1, Jan. 1990, Seite 85-92.
Während es bei Maschinen mit n Funktionseinheiten darauf ankommt, daß pro Zyklus n Befehle ausgeführt werden können, geht es bei Pipeline-Maschinen darum, in jedem Zyklus einen neuen Befehl aus zugeben, so daß die sogenannten NOPs (Nulloperationen) effektiv entfallen. Bei beiden Maschinentypen wird jedoch vom Kompilierer verlangt, daß er im Code Befehle entdeckt, die datenunabhängig sind und die Erzeugung von Code erlauben, der die Betriebsmittel der Maschine besser nutzt.
Es war eine verbreitete Ansicht, daß solche datenunabhängigen Befehle innerhalb der Grundblöcke zu finden seien und keine Notwendigkeit bestehe, Befehle über die Grenzen der Grundblöcke hinaus zu verschieben. Ein Grundblock ist eine Sequenz aufeinander folgender Befehle, für die der Steuerungsfluß- ohne Warte- oder Sprungmöglichkeit, außer am Austrittspunkt, am Beginn der Sequenz eintritt und an ihrem Ende austritt. Praktisch alle bisherigen Arbeiten zur Implementierung der Befehlablaufsteuerung konzentrierten sich auf die Ablaufsteuerung innerhalb von Grundblöcken (siehe die obigen Referenzen R2, R3 und R4).
Doch selbst bei einfachen RISC-Architekturen kann ein so beschränkter Typ der Ablaufsteuerung bei einer Vielzahl von Programmen zu einem Code mit vielen NOPs führen, z. B. bei vielen UNIX-Programmen (UNIX ist ein Warenzeichen der UNIX System Laboratories Inc.) mit vielen kleinen Grundblöcken, die in unvorhersehbaren Sprüngen enden. Bei wissenschaftlichen Programmen, bei denen die Grundblöcke meist größer sind, sind diese Probleme meist nicht so schwerwiegend.
In letzter Zeit entwickelt sich ein neuer Architekturtyp, der RISC um die Möglichkeit erweitert, pro Zyklus mehrere Befehle auszugeben. Siehe dazu z. B. folgenden Artikel:
R5 R.D. Groves und R. Oehler, "An IBM second generation RISC processor architecture", erschienen in den Proceedings of the IEEE Conference on Computer Design, (Oktober 1989), Seite 134-137.
Diese Art der Organisation von Hochgeschwindigkeitsprozessoren, die sogenannte Superskalar- oder Superpipeline- Architektur, stellt an die Kompilierer höhere Anforderungen, da die Befehlablaufsteuerung auf der Grundblockebene nicht ausreicht, um die Erzeugung von Code zu erlauben, der die Betriebsmittel der Maschine im wünschenswerten Umfang nutzt. Siehe dazu z. B. folgenden Artikel:
R6 N.P. Jouppi und D.W. Wall, "Available instruction-level parallelism for superscalar and superpipelined machines", erschienen in den Proceedings of the Third ASPLOS Conference, (April 1989), Seite 272-282.
über einen neueren Versuch, der Befehlablaufsteuerung für superskalare Maschinen nachzugehen, wurde in folgendem Artikel berichtet:
R7 M.C. Golumbic und V. Rainish, "Instruction Scheduling beyond Basic Blocks", erschienen im IBM Journal of Research and Development, Bd. 34, Nr. 1, Jan. 1990, Seite 93-97.
In diesem Artikel werden Verfahren der Codewiederholung für die Ablaufsteuerung jenseits der Grenzen von Grundblöcken untersucht, die zu erheblichen Verbesserungen der Laufzeit des kompilierten Codes geführt haben. Dem Artikel zufolge könnte diese Codewiederholung auf jeden bedingten Sprung angewendet werden, für den die Wahrscheinlichkeit des Zielweges höher eingeschätzt wird als die des sequentiellen Weges.
In letzter Zeit wurden verschiedene Konzepte zum Verschieben von Befehlen über Grundblockgrenzen hinweg vergestellt, wie z. B. im folgenden Artikel:
R8 K. Ebcioglu und T. Nakatani, "A new compilation technique for parallelising loops with unpredictable branches on a VLIW architecture", erschienen in den Proceedings of the Workshop on Languages and Compilers for Parallel Computing, (August 1989), Urbana.
Allerdings ist der Effekt des Verschiebens von Befehlen über Grundblockgrenzen hinweg begrenzt, wenn der Ablauf der Befehle nicht spekulativ gesteuert werden kann. Spekulative Ablaufsteuerung bedeutet, daß Befehle im voraus ausgeführt werden, bevor ein vorausgegangener bedingter Sprung erfolgt ist. Dadurch werden die Ergebnisse solcher spekulativ geplanter Befehle in der nachfolgenden Programmausführung manchmal nicht verwendet.
Der Artikel von S. Melvin und Y. Patt, "Exploiting Fine- Grained Parallelism through a Combination of Hardware and Software Techniqus", erschienen in Computer Architecture News, Mai 1991, Bd. 19, Nr. 3, Seite 287-296, enthält eine allgemeine Diskussion dreier mikroarchitektonischer Mechanismen: die dynamische Ablaufsteuerung, bei der die Gruppe der Mikrooperationen, die gemeinsam ausgegeben werden, nicht zwangsläufig dieselbe ist, die dann geplant wird; die spekulative Ausführung, bei der ein Mechanismus vorhanden ist, durch den Sprünge vorhergesagt werden und Operationen in der Maschine ausgegeben werden, bevor die Ergebnisse der Vorhersage bestätigt sind; und die Grundblockvergrößerung, bei der aufgrund der spekulativen Ausführung die Grundblöcke aus der Sicht der Hardware vergrößert werden.
Eine wichtige Klasse spekulativer Befehle sind spekulative Ladebefehle. Dies liegt daran, daß eine Berechnungssequenz in der Regel damit beginnt, daß Operanden vom Speicher in die Register geladen werden. Wenn jedoch Ladebefehle spekulativ geplant werden, kann es in der Programmausführung durch den Zugriff auf eine nicht vorhandene oder geschützte Speicherstelle zu einer unerwünschten Ablaufunterbrechung kommen.
Aus R7 ist eine Befehlablaufsteuerung zur Umplanung einer Eingangsbefehlsfolge bekannt, um eine Ausgangsbefehlsfolge zur Ausführung auf einem Rechner zu bilden, wobei die Eingangsbefehlsfolge in Blöcke aufeinander folgender Befehle aufgeteilt ist, für die der Steuerungsfluß ohne Sprung- oder Wartemöglichkeit am Beginn des ersten Blocks eintritt und an seinem Ende austritt, wobei die Befehlablaufsteuerung Befehle spekulativ so planen kann, daß Datendependenzen erhalten bleiben und die umgeplanten Befehle ausgeführt werden, bevor ein bedingter Sprung erfolgt, der den Befehlen in der Eingangsbefehlsfolge vorausgeht, indem Befehle von einem Quellbefehlsblock zu einem Zielbefehlsblock verschoben werden, um die Ausgangsbefehlsfolge zu bilden.
Das Ziel der vorliegenden Erfindung ist es, die spekulative Planung von Ladebefehlen zu ermöglichen, ohne daß solche Programmunterbrechungen verursacht werden.
Daher wird gemäß einem ersten Aspekt der vorliegenden Erfindung eine Befehlablaufsteuerung des obigen Typs bereitgestellt, die gekennzeichnet ist durch: eine Logik zum Auswählen eines Ladebefehls als Kandidat für die Umplanung; eine Logik zum Feststellen, ob das Basisregister, das der ausgewählte Ladebefehl nutzt, und/oder dessen Inhalt eine von mehreren Bedingungen erfüllen, und eine Logik zum Verschieben des ausgewählten Ladebefehls von dem Quellblock zum Zielblock als Reaktion auf die Feststellung, daß eine der Bedingungen erfüllt ist.
Wie sicher die Umplanung eines Kandidaten für einen Ladebefehl ist, kann ermittelt werden, indem anhand der Frage, ob das Basisregister, das der Befehl nutzt, und/oder dessen Inhalt eine von mehreren Bedingungen erfüllen, die Ladebefehle in eine Anzahl von Kategorien eingeteilt werden.
Eine der Bedingungen kann sein, daß das Basisregister einen Zeiger auf einen Speicherbereich enthält, in dem Adressen von globalen Variablen gespeichert sind. Im allgemeinen kann davon ausgegangen werden, daß die spekulative Umplanung von Ladebefehlen, deren Basisregister einen Zeiger auf einen Speicherbereich, in dem Adressen von globalen Variablen gespeichert sind, keine Programmunterbrechung verursachen.
Eine andere Bedingung kann sein, daß das Basisregister des gewählten Ladebefehls dasselbe Register ist, das auch als Basisregister eines anderen Ladebefehls innerhalb des Zielblocks verwendet wird, und daß kein Befehl existiert, der den Inhalt dieses Registers auf dem Weg zwischen dein Zielblock und dem Quellblock ändert. In diesem Fall muß die Befehlablaufsteuerung vor und nach jedem Datensegment eines Programms ferner ein Mittel zum Zuweisen einer zusätzlichen Scheinseite umfassen, die im Nur-Lese-Modus definiert werden kann. Wenn die Ausführung eines ähnlichen, aber nicht spekulativen Ladebefehls im Zielblock nicht zu einer Programmunterbrechung führt, kann davon ausgegangen werden, daß auch die Ausführung eines spekulativen Ladebefehls nicht zu einer solchen führt, sofern der Inhalt des Registers nicht bei der Programmausführung zwischen Zielblock und Quellblock geändert wird. Die zusätzliche Scheinseite wird benötigt, um zu verhindern, daß ein spekulativer Ladebefehl einen größeren Versatz aufweist als sein nicht spekulatives Gegenstück und daher Datensegmentgrenzen überschreiten und in einen nicht vorhandenen oder geschützten Bereich führen kann. Diese zusätzlichen Seiten können möglichst im Nur-Lese-Modus definiert werden, so daß durch das Ausführen eines Ladebefehls von den Speicherstellen aus, die zu ihnen gehören, keine Programmunterbrechung verursacht wird.
Eine dritte Bedingung kann sein, daß der Inhalt des Basisregisters des Ladebefehls gleich null ist und daß er nicht auf dem Weg zwischen Zielblock und Quellblock geändert wird. In diesem Fall kann die Seite null durch das Betriebssystem des Rechners, auf dem der umgeplante Code laufen soll, im Nur-Lese-Modus definiert werden, und eine endliche Zahl von Bytes der Seite null, wie z. B. die ersten 64, können mit Nullen gefüllt werden.
Die Erfindung ermöglicht es ferner, daß zum Kompilieren von Code, der auf einem Rechner laufen soll, ein Kompilierer bereitgestellt wird, der eine Befehlablaufsteuerung gemäß der Erfindung umfaßt. Außerdem wird ein Rechner bereitgestellt, der eine solche Befehlablaufsteuerung enthält. In einer vorteilhaften Form der Erfindung weist der Rechner eine Superskalar- und/oder Superpipeline-Architektur auf.
Unter einem anderen Aspekt stellt die Erfindung ein Verfahren zur Neuplanung einer Eingangsprogrammbefehlsfolge bereit, wobei die Eingangsbefehlsfolge in Blöcke aufeinander folgender Befehle aufgeteilt ist, für die der Steuerungsfluß ohne Sprung- oder Wartemöglichkeit am Beginn des ersten Blocks eintritt und an seinem Ende austritt, wobei das Verfahren das spekulative Planen von Befehlen umfaßt, so daß Datendependenzen erhalten bleiben und die umgeplanten Befehle ausgeführt werden, bevor ein bedingter Sprung erfolgt, der den Befehlen in der Eingangsbefehlsfolge vorausgeht, indem Befehle von einem Quellbefehlsblock zu einem Zielbefehlsblock verschoben werden, um eine Ausgangsbefehlsfolge zu bilden, wobei das Verfahren durch folgende Schritte gekennzeichnet ist:
(a) Auswählen eines Ladebefehls aus dem Quellblock als Kandidat für die Umplanung;
(b) Feststellen, ob das Basisregister, das der Ladebefehl nutzt, und/oder dessen Inhalt eine von mehreren Bedingungen erfüllt; und, wenn ja,
(c) Umplanen der Eingangsprogrammbefehlsfolge, so daß der Kandidatenbefehl zum Zielblock verschoben wird.
Im folgenden wird ein Ausführungsbeispiel der Erfindung unter Bezugnahme auf die beiliegenden Tabellen am Ende der Beschreibung und auf die Zeichnung mit einem schematischen Überblick über eine Befehlabfolgesteuerung gemäß der Erfindung beschrieben.
In diesem Ausführungsbeispiel der Erfindung bildet die Befehlablaufsteuerung einen Teil eines Kompilierers, speziell eines Kompilierers aus der Familie IBM XL für Rechner des Typs IBM RISC System/6000. (IBM und RISC System/6000 sind Warenzeichen der International Business Machine Corporation.)
Die Zeichnung zeigt einen schematischen Überblick über eine Befehlabfolgesteuerung 10 gemäß der Erfindung. Die Befehlablaufsteuerung nimmt als Eingabe eine Eingangsbefehlsfolge 12. Die Auswahllogik 14 wählt einen datenunabhängigen Ladebefehl als Kandidaten für die spekulative Umplanung von einem Quellbefehlsblock zu einem Zielbefehlsblock aus. Die Feststellungslogik 16 stellt fest, ob der Ladebefehl in eine von drei Kategorien fällt, indem sie das Basisregister, das der Ladebefehl verwendet, sowie dessen Inhalt untersucht und ermittelt, ob eine der drei Bedingungen 18, die die Kategorien definieren, erfüllt ist. Wenn der Ladebefehl in eine der drei Kategorien fällt, verschiebt die Umplanungslogik 20 den Befehl von dem Quellbefehlsblock zum Zielbefehlsblock, um die Ausgangsbefehlsfolge 22 zu bilden.
Das Wesen der Kategorien und das Zustandekommen der Bedingungen, die ein Ladebefehl erfüllen muß, um zu einer der Kategorien zu gehören, wird weiter unten ausführlich erörtert. Zuerst jedoch soll ein kurzes Beispiel gegeben werden, um das Konzept spekulativer Ladebefehle zu verdeutlichen.
Die Tabelle I zeigt einen Auszug aus dem Pseudocode des IBM RISC System/6000, der von dem Kompilierer für die innere Schleife der Funktion XLYGETVALUE erzeugt, die dem Benchmark SPEC LI entnommen ist. Wir gehen hier bei allen Codebeispielen davon aus, daß die Muster des Codes denen ähneln, die der IBM-XL-Kompilierer für den in R5 erörterten Prozessor des IBM RISC System/6000 erzeugt. Die Benchmark- Suite SPEC wurde vor kurzem als Standard für die Messung der Leistung von Workstation-Systemen angenommen. Der Lisp- Interpreter (LI) gehört zu den Benchmark-Programmen, die in der Programmiersprache C geschrieben sind.
In den Beispielen bedeutet SHADOW4$ einen Speicherzugriff über einen Zeiger. Die Adresse der Speicherstelle, auf die ein Ladebefehl zugreift, wird durch die Summe aus dem Inhalt seines Basisregisters und seinem Versatz berechnet. So greift z. B. L r5=SHADOW4$(r5,8) auf die Speicherstelle bei dem Adreßinhalt (r5)+8 zu.
Für die Zeitverzögerungen, die in der Prozessor-Pipeline auftreten, wird folgende Struktur angenommen:
1. Zwischen einem Ladebefehl und einer anschließenden Nutzung des dadurch geladenen Operanden gibt es eine Verzögerung von einem Zyklus.
2. Zwischen einem Vergleichsbefehl und einem anschließenden Sprung unter der Bedingung, die durch den Vergleich gestellt wurde, gibt es eine Verzögerung von drei Zyklen. Tatsächlich gibt es bei dem Prozessor des IBM RISC System/6000 oft keine Verzögerung zwischen einem Vergleich und einem entsprechend bedingten Sprung, wenn dieser Sprung nicht erfolgt. Der Einfachheit halber wird jedoch hier davon ausgegangen, daß die Verzögerung immer eintritt.
Unter diesen Annahmen führt die Schleife, die in dem in Tabelle I dargestellten Beispiel präsentiert wird, pro Durchgang 14 Zyklen aus. Die Geschwindigkeit dieser Schleife kann nicht gesteigert werden, indem die Befehle innerhalb der beiden Grundblöcke neu geordnet werden.
Wenn jedoch Befehle spekulativ von dem zweiten Block (B2) zum ersten (B1) verschoben werden, erhalten wir den in Tabelle II dargestellten Code, der acht Zyklen pro Durchgang ausführt und eine verbesserte Version des in Tabelle I dargestellten Codes ist.
Der Ladebefehl L r5=SHADOW4$(r5,8) wurde nun spekulativ geplant, da ohne Verschiebung dieses Befehls überhaupt kein Befehl verschoben werden kann. Allerdings muß die Frage beantwortet werden, ob dieser Ladebefehl unter irgendwelchen Umständen eine Programmunterbrechung verursachen kann.
In diesem speziellen Beispiel stellen wir fest, daß es einen weiteren nicht-spekulativen Ladebefehl L r4=SHADOW4$(r5,4) gab, der dasselbe Basisregister mit einem etwas anderen Versatz verwendet. Es kann davon ausgegangen werden, daß diese beiden Ladebefehle verschiedene Felder desselben Datensatzes referenzieren. Daher ist mit großer Gewißheit anzunehmen, daß dieser spekulative Ladebefehl niemals zu einer Programmunterbrechung führen wird. Nachfolgend wird gezeigt, wie diese Beobachtung genutzt werden kann, um eine Software-Umgebung mit der vollen Gewißheit bereitzustellen, daß keine Unterbrechung auftritt.
Nehmen wir einmal an, daß wir einen Ladebefehl von einem Quellblock wie z. B. B2 zu einem Zielblock B1 verschieben wollen. Wir wollen daher wissen, ob es sicher ist, den Ladebefehl von B2 zu B1 zu verschieben.
Die Adresse der Speicherstelle, auf die ein Ladebefehl zugreift, wird durch die Summe aus dem Inhalt seines Basisregisters und seinem Versatz berechnet. So greift z. B. L r5=SHADOW4$(r5,8) auf die Speicherstelle bei dem Adreßinhalt (r5)+8 zu. Die Frage der Sicherheit kann daher auch wie folgt formuliert werden: Ist es auch dann zulässig, auf die referenzierte Speicherstelle zuzugreifen, wenn der Befehl sich im Zielblock statt im Quellblock befindet?
Je nach dem Basisregister, das ein Ladebefehl verwendet, und/oder dessen Inhalt lassen sich drei Kategorien sicherer spekulativer Ladebefehle, d. h. spekulativer Ladebefehle, die niemals zu einer Unterbrechung führen, unterscheiden.
Diese drei Kategorien sind:
1. Globale Ladebefehle, d. h. Ladebefehle für globale Skalarvariablen;
2. Ähnliche Ladebefehle, d. h. Ladebefehle, die einem Ladebefehl im Zielblock "ähnlich" sind;
3. NULL-Zeiger-Ladebefehle, d. h. Ladebefehle, deren Basisregisterinhalt gleich null ist.
Diese drei Kategorieren sicherer spekulativer Ladebefehle werden nun nacheinander erörtert.

1. Globale Ladebefehle

In der Umgebung des XL-Kompilierers werden die Adressen der globalen Skalarvariablen in der Ladezeit berechnet und in einem Inhaltsverzeichnis (TOC, Table of Contents) gespeichert. Ein spezielles Register wird für einen Zeiger auf das TOC zugewiesen, so daß es sicher ist, Daten aus den Adressen im TOC zu holen und auf sie zuzugreifen, wenn der Ladebefehl sich nicht im Quellblock, sondern im Zielblock befindet.
Um globale Ladebefehle zu erkennen, können wir den Ladebefehl auf dessen Basisregister hin durchsuchen, und wenn es sich um das spezielle Register mit dem TOC-Zeiger handelt, können wir davon ausgehen, daß der Ladebefehl sicher ist, und seine spekulative Planung zulassen.

2. Ähnliche Ladebefehle

Bei der Erkennung ähnlicher Ladebefehle geht es darum, einen anderen Ladebefehl im Zielblock zu suchen, der dasselbe Basisregister und einen ähnlichen Versatz verwendet. So sind sich z. B. in dem in Tabelle I dargestellten Beispiel die Ladebefehle L r5=SHADOW4$(r5,8) und L r4=SHADOW4$(r5,4) ähnlich. Außerdem vergewissern wir uns, daß das Basisregister des spekulativen Ladebefehls nicht auf dem Weg vom Zielblock zum Quellblock neu definiert wurde. Mit letzterem meinen wir, daß kein anderer Befehl dem Register auf dem Weg zwischen den Blöcken einen Wert zuweist, d. h. daß der Wert des Registers, der im Quellblock galt, auch im Zielblock noch gilt.
In diesem Fall gehen wir von folgender Annahme aus: Wenn es zulässig war, einen ähnlichen, aber nicht-spekulativen Ladebefehl im Zielblock auszuführen, dann muß auch die Ausführung des spekulativen Ladebefehls zulässig sein. Diese Annahme setzt eine bestimmte Unterstützung im Verknüpfungseditor voraus, denn es ist möglich, daß ein spekulativer ähnlicher Ladebefehl durch einen größeren Versatz, als ihn sein nicht-spekulatives Gegenstück hat, die Grenzen des Datensegments überschreitet und in einen geschützten oder nicht vorhandenen Bereich führt. Die Lösung dieses Problems besteht darin, im Verknüpfungseditor vor und nach jedem Datensegment des Programms eine zusätzliche Scheinseite zuzuweisen. Diese zusätzlichen Seiten sind im Nur-Lese-Modus definiert, so daß es durch die Ausführung eines Ladebefehls von Speicherstellen aus, die zu ihnen gehören, nicht zu einer Unterbrechung kommen kann.
Die Unterstützung im Betriebssystem ist erforderlich, weil bei der Ausführung des geplanten Befehls garantiert sein muß, daß nicht auf verbotene Speicherbereiche zugegriffen wird.

3. NULL-Zeiger-Ladebefehle

Betrachten wir nun eine neu geordnete Version des Codes, der im vorigen Beispiel verwendet wurde und in der Tabelle III dargestellt ist.
Die Tabelle III zeigt die drei Grundblöcke B1, B2 und B3 in einer Schleife, und alle Rechenbefehle befinden sich in B3. Nehmen wir einmal an, daß wir Ladebefehle von B3 zu B2 verschieben wollen. Keiner dieser Ladebefehle hat ein ähnliches Gegenstück in B2, so daß sie nicht in die Kategorie der ähnlichen Ladebefehle fallen, und es handelt sich auch nicht um globale Ladebefehle.
Die ersten zwei Ladebefehle von B3 verwenden jedoch r5 als Basisregister. Zu beachten ist auch, daß r5 in C cr0=r5,0 mit null verglichen wurde und BT OUT1,cr0,0·4/eq das Ergebnis dieses Vergleichs verwendet. Wenn also r5 nicht null ist, führen wir B3 aus, und alle Ladebefehle werden ausgeführt wie benötigt. Wenn aber r5 gleich null ist, soll das Programm die Schleife verlassen, ohne einen der Ladebefehle von B3 auszuführen.
Wenn die Seite null im Nur-Lese-Modus definiert ist, können solche NULL-Zeiger-Ladebefehle auf die Seite null zugreifen, ohne Programmunterbrechungen zu verursachen. Dadurch können die ersten zwei Ladebefehle von B3 nach B2 verschoben werden, ohne Programmunterbrechungen zu verursachen, wie der Code in Tabelle IV zeigt.
Der Algorithmus zur Erkennung von NULL-Zeiger-Ladebefehlen läßt sich wie folgt ausdrücken:
1. Finde das Basisregister des betreffenden spekulativen Ladebefehls.
2. Vergewissere dich, daß das Basisregister auf dem Weg vom Quellblock zum Zielblock nicht neu definiert wurde. (Wie schon bei den ähnlichen Ladebefehlen meinen wir mit letzterem, daß kein anderer Befehl dem Register auf dem Weg zwischen den Blöcken einen Wert zuweist, d. h. daß der Wert des Registers, der im Quellblock galt, auch im Zielblock noch gilt.)
3. Finde das bedingte Register, das bei dem Sprung des Zielblocks verwendet wird.
4. Finde den Vergleichsbefehl, der dieses bedingte Register setzt.
5. Überprüfe, ob der Vergleichsbefehl das Basisregister mit null vergleicht, und wenn ja, verschiebe den Befehl sicher zum Zielblock.
Zur Unterstützung von NULL-Zeiger-Ladebefehlen wird zuerst die Seite null im Nur-Lese-Modus definiert, so daß NULL- Zeiger-Ladebefehle effektiv darauf zugreifen können, ohne Unterbrechungen zu verursachen.
Nun fällt der dritte Ladebefehl von B3, L r0=SHADOW4$(r4,4) in keine der Kategorien sicherer spekulativer Ladebefehle, die wir hier beschrieben. Wenn wir jedoch annehmen, daß der durch L r4=SHADOW4$(r5,4) geladene Wert null ist, wird der dritte Ladebefehl wiederum ein NULL-Zeiger-Ladebefehl und darf als solcher nach B2 verschoben werden. Dazu müssen z. B. die ersten 64 Bytes der Seite null mit Nullen gefüllt werden, so daß zusätzliche spekulative Ladebefehle zur Kategorie der NULL-Zeiger-Ladebefehle gehören können.
Die Tabelle V enthält eine Statistik über die Häufigkeit des Vorkommens der drei Kategorien spekulativer Ladebefehle. XLSYM, XLEVAL und XLDMEM sind drei Quelldateien aus dem Benchmark SPEC LI. Jede von ihnen enthält 20 bis 30 relativ kleine C-Funktionen. In der Spalte SUMME ist die Gesamtzahl der Ladebefehle angegeben, die für eine spekulative Ausführung in Erwägung gezogen wurden, während die Spalten GLOB, ÄHNL und NULL die Anzahl der Ladebefehle enthalten, die für die Klassen der globalen, ähnlichen bzw. NULL-Zeiger- Ladebefehle gefunden wurden. Wie man sieht, fällt der größte Teil der spekulativen Ladebefehle (70-90%) in eine der drei Kategorien und kann daher sicher spekulativ geplant werden.
Die vorliegende Erfindung ermöglicht somit die Bereitstellung einer Befehlablaufsteuerung, in der die Sicherheit spekulativer Ladebefehle dadurch bestimmt ist, daß sichergestellt wird, daß ein Ladebefehl, der ein Kandidat für eine Umplanung ist, in eine der drei Kategorien fällt. Experimente mit einem Mustercode zeigen, daß ein großer Teil der Ladebefehle auf dieser Grundlage für eine spekulative Ausführung in Frage kommen, wenn eine bestimmte Unterstützung im Betriebssystem verfügbar ist. Dies spart den Siliziumplatz und auch die Designzeit, die nötig sind, um die spekulativen Ladebefehle in der Maschinenarchitektur zu unterstützen, und erhält die Kompatibilität des Objektcodes mit bestehenden Maschinen. TABELLE I
LOOP:
L r4=SHADOW4$(r5,4)
L r0=SHADOW4$(r4,4)
CL cr1=r3,r0
BT OUT, cr1, 0·4/eq
L r5=SHADOW4$(r5,8)
C cr0=r5,0
BF LOOP, cr0, 0·4/eq
return(not found)
OUT: return(found)

TABELLE II

LOOP:
L r4=SHADOW4$(r5,4)
L r5=SHADOW4$(r5,8)
L r0=SHADOW4$ (r4,4)
C cr0=r5,0
CL cr1=r3,r0
BT OUT,cr1,0·4/eq
BF LOOP,cr0,0·4/eq
return(not found)
OUT: return(found) TABELLE III
L r4=SHADOW4$(r5,4)
L r5=SHADOW4$(r5,8)
L r0=SHADOW4$(r4,4)
C cr0=r5,0
CL cr1=r3,r0
LOOP:
BT OUT,cr1,0·4/eq
BT OUT1,cr0,0·4/eq
L r4=SHADOW4$(r5,4)
L r5=SHADOW4$(r5,8)
L r0=SHADOW4$(r4,4)
C cr0=r5,0
CL cr1=r3,r0
B LOOP
OUT1: return(not found)
OUT: return(found)

TABELLE IV

L r4=SHADOW4$(r5,4)
L r5=SHADOW4$(r5,8)
L r0=SHADOW4$(r4,4)
C cr0=r5,0
CL cr1=r3,r0
LOOP:
BT OUT,cr1,0·4/eq
L r4=SHADOW4$(r5,4)
L r5=SHADOW4$(r5,8)
BT OUT1,cr0,0·4/eq
L r0=SHADOW4$(r4,4)
C cr0=r5,0
CL cr1=r3,r0
B LOOP
OUT1: return(not found)
OUT: return(found) TABELLE V DATEI GLOB ÄHNL NULL SUMME

Claims

1. Eine Befehlablaufsteuerung zur Umplanung einer Eingangsbefehlsfolge (12), um eine Ausgangsbefehlsfolge (22) zur Ausführung auf einem Rechner zu bilden, wobei die Eingangsbefehlsfolge in Blöcke aufeinander folgender Befehle aufgeteilt ist, für die der Steuerungsfluß ohne Sprung- oder Wartemöglichkeit am Beginn des ersten Blocks eintritt und an seinem Ende austritt, wobei die Befehlablaufsteuerung Befehle spekulativ so planen kann, daß Datendependenzen erhalten bleiben und die umgeplanten Befehle ausgeführt werden, bevor ein bedingter Sprung erfolgt, der den Befehlen in der Eingangsbefehlsfolge (12) vorausgeht, indem Befehle von einem Quellbefehlsblock zu einem Zielbefehlsblock verschoben werden, um die Ausgangsbefehlsfolge (22) zu bilden, wobei die Befehlablaufsteuerung gekennzeichnet ist durch:

eine Logik (14) zum Auswählen eines Ladebefehls als Kandidat für die Umplanung;

eine Logik (16) zum Feststellen, ob das Basisregister, das der ausgewählte Ladebefehl nutzt, und/oder dessen Inhalt eine von mehreren Bedingungen (18) erfüllen; und

eine Logik (20) zum Verschieben des ausgewählten Ladebefehls von dem Quellblock zum Zielblock als Reaktion auf die Feststellung, daß eine der Bedingungen erfüllt ist.

2. Eine Befehlablaufsteuerung nach Anspruch 1, bei der eine der Bedingungen (18) lautet, daß das Basisregister einen Zeiger auf einen Speicherbereich enthält, in dem Adressen globaler Variablen gespeichert sind.

3. Eine Befehlablaufsteuerung nach Anspruch 1 oder 2, bei der eine der Bedingungen (18) lautet, daß sowohl

(a) das Basisregister des ausgewählten Ladebefehls dasselbe Register ist, das auch als Basisregister eines anderen Ladebefehls innerhalb des Zielblocks dient, als auch

(b) kein Befehl existiert, der den Inhalt dieses Registers auf dem Weg zwischen dem Zielblock und dem Quellblock ändert,

wobei die Befehlablaufsteuerung ferner ein Mittel zur Zuweisung einer zusätzlichen, im Nur-Lese-Modus definierten Leerseite vor und nach jedem Datensegment eines Programms enthält.

4. Eine Befehlablaufsteuerung nach einem der obigen Ansprüche zum Bilden einer Ausgangsbefehlsfolge (22) zur Ausführung auf einem Rechner mit einem Betriebssystem, bei dem die Seite null im Nur-Lese-Modus definiert ist und eine endliche Zahl von Bytes der Seite null mit Nullen gefüllt ist, wobei eine der Bedingungen (18) lautet, daß sowohl

(a) der Inhalt des Basisregisters des Ladebefehls gleich null ist als auch

(b) der Inhalt des Basisregisters auf dem Weg zwischen dem Zielbefehlsblock und dem Quellbefehlsblock nicht verändert wird.

5. Eine Befehlablaufsteuerung nach Anspruch 4, wobei die endliche Zahl von Bytes der Seite null die ersten 64 Bytes der Seite null sind.

6. Ein Kompilierer zum Kompilieren von Code zur Ausführung auf einem Rechner, wobei der Kompilierer eine Befehlablaufsteuerung nach einem der obigen Ansprüche enthält.

7. Ein Rechner mit einer Befehlablaufsteuerung nach einem der Ansprüche 1 bis 5.

8. Ein Rechner nach Anspruch 7 mit Superskalar- und/oder Superpipeline-Architektur.

9. Ein Verfahren zur Neuplanung einer Eingangsprogrammbefehlsfolge, wobei die Eingangsbefehlsfolge (12) in Blöcke aufeinander folgender Befehle aufgeteilt ist, für die der Steuerungsfluß ohne Sprung- oder Wartemöglichkeit am Beginn des ersten Blocks eintritt und an seinem Ende austritt, wobei das Verfahren das spekulative Planen von Befehlen umfaßt, so daß Datendependenzen erhalten bleiben und die umgeplanten Befehle ausgeführt werden, bevor ein bedingter Sprung erfolgt, der den Befehlen in der Eingangsbefehlsfolge vorausgeht, indem Befehle von einem Quellbefehlsblock zu einem Zielbefehlsblock verschoben werden, um eine Ausgangsbefehlsfolge (22) zu bilden, wobei das Verfahren durch folgende Schritte gekennzeichnet ist:

(a) Auswählen (14) eines Ladebefehls aus dem Quellblock als Kandidat für die Umplanung;

(b) Feststellen (16), ob das Basisregister, das der Ladebefehl nutzt, und/oder dessen Inhalt eine von mehreren Bedingungen (18) erfüllt; und, wenn ja,

(c) Umplanen (20) der Eingangsprogrammbefehlsfolge, so daß der Kandidatenbefehl zum Zielblock verschoben wird.

10. Ein Verfahren nach Anspruch 9, bei dem der Feststellungsschritt (b) folgende Teilschritte umfaßt:

(b1) Identifizieren des Basisregisters des Kandidatenbefehls;

(b2) Feststellen, ob ein Befehl existiert, der den Inhalt des Basisregisters auf dem Weg zwischen dem Zielblock und dem Quellblock ändert, wobei die Bedingung als nicht erfüllt gilt, wenn dies der Fall ist;

(b3) Identifizieren des bedingten Registers, das in dem bedingten- Sprung verwendet wird, der dem Zielblock vorausgeht;

(b4) Identifizieren des Vergleichsbefehls, der das bedingte Register setzt;

(b5) Feststellen, ob der Vergleichsbefehl das Basisregister mit null vergleicht, wobei die Bedingung als erfüllt gilt, wenn dies der Fall ist.