DE3689915T2

DE3689915T2 - Verfahren zur Vektorisation und Objektkodekompilation.

Info

Publication number: DE3689915T2
Application number: DE3689915T
Authority: DE
Inventors: Randolph Gregory Scarborough
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1985-08-07
Filing date: 1986-07-31
Publication date: 1995-01-05
Anticipated expiration: 2006-08-01
Also published as: EP0214751A3; EP0214751A2; US4710872A; JPS6234275A; DE3689915D1; EP0214751B1

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Vektorisierung und Objektcodekompilation.
Die meisten für Rechner geschriebenen Programme enthalten Schleifen und verschachtelte Schleifen, um sich wiederholende Operationen mit Datenfolgen auszuführen. Diese Programme sorgen da für, daß die Operationen in einer wohldefinierten Ordnung durchgeführt werden. Da nun Maschinen, die jeweils eine Anweisung mit einfachem Datenpfad (Single-Instruction, Single-Data path - SISD) historisch gesehen die am weitesten verbreiteten Maschinen waren, ist diese Ordnung so eingerichtet, daß sie auf solchen SISD-Maschinen leicht abgearbeitet werden kann. Diese gleiche Ordnung ist möglicherweise für eine Maschine mit einfachen Anweisungen aber Mehrfachdatenpfad (Single-Instruction, Multiple-Data path - SIMD) nicht mehr zulässig, bei der aufeinanderfolgende Elemente in dieser Ordnung aufgegriffen werden und unabhängig voneinander im Parallelbetrieb abgearbeitet werden. Es können jedoch auch andere Ordnungen existieren, in denen die Elemente unabhängig voneinander im Parallelbetrieb gültig verarbeitet werden. Es besteht daher ein Erfordernis, diejenigen Programmteile und diese Ordnung von Operationen, für die die SIMD-Maschinen zur Abarbeitung der sich wiederholenden Operationen herangezogen werden, mit Sicherheit durchzuführen. Diese Forderung und ihr damit verbundenes Ergebnis ist als Vektorisierung bekannt. Es ist also erwünscht, ausgehend von einem für eine skalare SISD-Maschine geschriebenen Programm einen Objektcode zur Ausführung auf einer vektoriellen SIMD-Maschine zu erzeugen.
Die Vektorisierung ist aus mindestens drei Gründen bedeutsam. Als erster ist zu nennen die große Menge von Programmen, die für SISD-Maschinen geschrieben wurden. Ein automatischer Vektorisierer ermöglicht es, daß vorhandene Programme auf einer SIMD-Maschine laufen, ohne daß sie umgeschrieben werden müssen. Der zweite ist die Übertragbarkeit. Ein automatischer Vektorisierer ermöglicht die Abarbeitung des gleichen Programms, ohne Änderung, sowohl auf SISD- als auch auf SIMD- Maschinen. Der dritte Grund ist Schnelligkeit. Ein automatischer Vektorisierer macht es möglich, daß das gleiche Programm für skalare Abarbeitung auf einer SISD-Maschine, und für Vektorverarbeitung auf einer SIMD Maschine OPTIMIERT wird.
Aufgabe der Vektorisierung ist, sequentielle Skalaroperationen zu finden, die in gleichwertige parallele Vektoroperationen umgewandelt werden können, um die Vorteile der vektoriellen SIMD-Maschinen auszunützen. Operationen sind gleichwertig, wenn bei sich ihrer Benutzung das gleiche Ergebnis einstellt.
Ganz allgemein läßt sich eine Anweisung vektorisieren, wenn sie als Eingang bei einer Iteration einer Schleife keines Wertes bedarf, der bei einer vorangehenden Iteration eben dieser Schleife errechnet wurde. Wenn kein in einem Durchlauf einer DO-Schleife berechneter Wert für einen späteren Schleifendurchlauf benutzt wird, können alle Datenwerte im Parallelbetrieb errechnet werden. Diese Unabhängigkeit der Datenwerte von einem DO-Schleifen-Durchlauf zum nächsten ist ein Faktor, der die Abarbeitung auf einer SIMD-Maschine zuläßt. Wenn im Gegensatz dazu ein Wert in einem Durchlauf berechnet wird und dann in einem späteren Durchlauf gebraucht wird, kann die DO-Schleife im allgemeinen nicht vektorisiert werden.
Die Vektorisierung sequentieller Operationen setzt voraus, daß die Abhängigkeiten im Programm bestimmt werden. Eine Anweisung in einem Quellprogramm kann von einer anderen Anweisung im Programm abhängig sein, weil der Steuerfluß durch eine von ihnen beeinflußt wird, oder weil beide die gleiche Speicherstelle benutzen. Beide Arten der Abhängigkeit müssen betrachtet werden, wenn ein Programm für die Vektorisierung analysiert wird.
Unter den einschlägigsten Bezugsstellen auf dem Stand der Technik sind zu nennen: Allen, "Dependence Analysis for Subscripted Variables and Its Application to Program Transformations" [Analyse der Abhängigkeiten indizierter Variabler und ihre Anwendung auf Programmtransformationen], Dissertation für den Dr. phil., Computer Science, Rice University, April 1983; und Kennedy "Automatic Translation of FORTRAN Programs to Vector Forms" [Automatische Umsetzung von FORTRAN-Programmen in Vektorformen], Rice University Technical Report 476-029-4, Okt. 1980. Diese Bezugsstellen von Allen und Kennedy beschreiben die Skalar-Vektor-Umwandlungsschritte (a) Aufstellen eines Abhängigkeits-Graphen, (b) Aufteilung des Graphen in topologisch signifikante Bereiche, (c) Untersuchung dieser Bereiche, um festzustellen, welche von diesen Bereichen auf einer SIMD-Maschine ausführbar sind, und (d) Generieren eines Skalar- oder Vektorcodes auf der Grundlage der Ergebnisse in (c).
Auf dem Stand der Technik verhindert die Rekursion der Programmanweisungen in bestimmten verschachtelten Schleifen die Vektorisierung von Programmanweisungen in den Schleifen, die die Rekursion generieren, und verhindert ferner die Vektorisierung von Programmanweisungen in den äußeren Schleifen, die diese betroffenen Schleifen enthalten. Bekanntlich beeinflußt der Austausch der Schleifenordnung die Vektorisierbarkeit der Anweisungen innerhalb der Schleifen, jedoch wurde infolge der Kompliziertheit und der Aufwendigkeit bei der Identifizierung und beim Austausch der Schleifen dieser Weg nur sehr zögernd bei den innersten und zweitinnersten Schleifen beschritten.
Hingewiesen wird auch auf "The Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Developments", Environments, April 1984, Bd. 19, Nr. 5, Seiten 233-246. Die Abhandlung von J.R.Allen und K.Kennedy diskutiert die betreffenden Datenabhängigkeiten bei der Bestimmung, wann Schleifen sicher und günstig austauschbar sind. Die zugrundeliegende Theorie wurde anhand der Implementierung in einem Programm (PFC) beschrieben, das versucht, Operationen im sequentiellen FORTRAN-Code aufzufinden, die sicher als Vektoroperationen geschrieben werden können.
In einem Lehrmaterial "Supercomputers: Design and Applications", 1984, S. 186-203, IEEE, New York, beschreibt eine Abhandlung von J.R.Allen und K.Kennedy das PFC-Programm als eine Fallstudie zur Anwendung theoretischer Techniken auf ein praktisches Implementierungsproblem zwecks Verfügbarmachung von Vektoroperationen für den FORTRAN-Programmierer.
Aufgabe der vorliegenden Erfindung ist es, die Vektorisierungsverfahren auf dem Stand der Technik zu verbessern.
Gemäß der vorliegenden Erfindung ist also ein Betriebsverfahren für einen Rechner vorgesehen, das dazu dient, einen Objektcode zur Abarbeitung auf einer SIMD-Maschine zu kompilieren, wobei dieser Objektcode aus den Quellcodeanweisungen in der verfahrensorientierten Sprache abgeleitet wird, dieser Quellcode verschachtelte Schleifen enthält, von denen wenigstens eine Schleife die innerste und wenigstens eine Schleife die äußerste ist, und der die folgenden Schritte aufweist:
(a) Umwandeln des Quellcodes in eine Zeichenkette in einer Zwischensprache und Optimieren dieser Zeichenkette; (b) Bilden eines Abhängigkeits-Graphen aus der Zeichenkette, wobei dieser Abhängigkeits-Graph wenigstens einen Knoten aufweist und diese Knoten des Abhängigkeits-Graphen Anweisungen in der Zeichenkette darstellen; (c) Aufteilen dieses Abhängigkeits- Graphen in stark verbundene Bereiche, SCRs, und Analysieren dieser SCRs, um festzustellen, ob die äußersten Schleifen, die diesen SCRs entsprechen, vektorisiert werden können zwecks Abarbeitung auf der SIMD-Maschine; (d) rekursives Ausführen des Schritts (c) auf diese SCRs dieser Unterteilungen; (e) Generieren eines Codes für die SIMD-Maschine, gemäß dessen bestimmte Schleifen als vektorisierbar erkannt wurden; dadurch gekennzeichnet, daß diese Analyse des Schritts (c) umfaßt: (1) für jeden SCR Feststellen, ob die entsprechende äußerste Schleife jeweils mit der nachfolgenden inneren Schleife ausgetauscht werden kann, bis diese äußerste Schleife die innerste wird, ohne dabei die semantische Wirkung einer der Abhängigkeiten bezüglich dieser äußersten Schleife zu verändern; und (2) Bilden eines Subgraphen aller dieser austauschbaren Abhängigkeiten und aller schleifenunabhängigen Abhängigkeiten und Kennzeichnen der entsprechenden Schleifen als vektorisierbar wenn dieser Subgraph azyklisch ist.
Die Erfindung gründet sich auf die unerwartete kritische Beobachtung, daß im Abhängigkeits-Graphen, der einen Programmbereich auf und innerhalb einer ausgewählten Ebene, der Ebene n, nur die innerst-empfindlichen Abhängigkeitsränder der Ebene n und die schleifenunabhängigen Abhängigkeitsränder betrachtet werden müssen, um festzustellen, ob das Programm auf der Ebene n vektorisiert werden kann. Die Ränder verbinden Knoten des Graphen und stellen die Abhängigkeiten zwischen den Anweisungen dar, die an diesen Knoten repräsentiert sind. Der Bereich kann vektorisiert werden, wenn der eben aus diesen zwei Ränderklassen (der innerst-empfindlichen Ränder auf Ebene n und der schleifenempfindlichen Ränder) gebildete Graph keine Zyklen aufweist. Das widerspricht dem Verfahren auf dem Stand der Technik, bei dem alle Ränder in dem Bereich, einschließlich derer auf Ebene n, derer innerhalb der Ebene n und derer, die schleifenunabhängig sind, in den Graphen eingehen. Ein Zyklus ist vorhanden, wenn es möglich ist, ausgehend von einem Knoten entlang der Verbindungsränder nach Durchlauf wenigstens eines anderen Knotens zum ersten Knoten zurückzukehren.
Der Stand der Technik, der es versäumt hat, die Bedeutung der innerst-empfindlichen Ränder zu entdecken und zu identifizieren, hat auch die Abhängigkeitsränder im Inneren der Ebene n nicht aus dem Graphen ausgeschlossen. Durch Anwendung der vorliegenden Erfindung wird jetzt erkannt, daß diese Ränder für die Vektorisierbarkeit der Anweisungen auf Ebene n nicht relevant sind. Der Stand der Technik wird daher öfter einen Zyklus im Graphen feststellen, weil mehr Ränder im Graphen vorkommen, und wird daher nicht in der Lage sein, fest zustellen, daß eine sehr große Klasse von Anweisungen auf Ebene n vektorisiert werden kann. Zum Beispiel wird ein Zyklus, der von Rändern innerhalb der Ebene n verursacht wird, die Vektorisierung der Anweisungen auf Ebene n verhindern. Die angezogenen Abhandlungen von Allen und Kennedy verweisen nach Entdecken eines Zyklus die Programmanweisungen zur skalaren Verarbeitung auf Ebene n.
Nachstehend soll die vorliegende Erfindung anhand der begleitenden Zeichnungen noch näher beschrieben werden; in diesen ist
Fig. 1 eine Darstellung eines Fragments im FORTRAN Quellcode mit Schleifen und Abhängigkeiten;
die Fig. 2A-2B sind bildhafte Darstellungen von Abhängigkeitsgraphen, einschließlich der Abhängigkeitsränder, die gemäß dem Stand der Technik bzw. der Erfindung gefunden wurden;
die Fig. 3A-6A sind bildhafte Darstellungen der Lösungsergebnisse gemäß Stand der Technik zwecks Identifizierung vektorisierbarer Anweisungen im Abhängigkeitsgraphen; und
die Fig. 3B-6B sind bildhafte Darstellungen der entsprechenden Lösungsergebnisse laut dem erfindungsgemäßen Verfahren.
Um die Erfindung würdigen zu können, soll jetzt eine einleitende Darlegung der Konzepte der Steuerung und Datenabhängigkeit, Abhängigkeitsebenen und gegenseitigem Austausch, sowie eine Schnittdarstellung zur Vektorausführung gegeben werden. Anschließend wird dann eine allgemeine Diskussion des vorliegenden Verfahrens erfolgen. Zuletzt soll noch ein bildhaftes Beispiel unter Bezugnahme auf die obengenannten Zeichnungen erklärt werden.

Steuerungsabhängigkeit

Steuerungsabhängigkeiten entstehen, weil eine Anweisung festlegt, ob eine zweite Anweisung ausgeführt werden soll. Im nachfolgenden Beispiel ist die Anweisung 2 abhängig von der Anweisung 1:
DO 3 I=2,N
1 IF (A(I).GT.0.0) GOTO 3
2 A(I)=B(I)+1.0
3 CONTINUE
Die Ergebnisse der Prüfung in Anweisung 1 bestimmen, ob Anweisung 2 ausgeführt wird. Die Ausführung der Anweisung 2 hängt von der Ausführung der Anweisung 1 ab. Hier muß erkannt werden, daß die IF-Umwandlung eine Technik ist, die dazu benutzt wird, eine Steuerungsabhängigkeit in eine Datenabhängigkeit umzuwandeln. Nachstehend folgt eine Illustration einer solchen Umänderung:
DO 3 I=1,N
1 L=A(I),LE.0.0
2 IF(L) A(I)=B(I)+1.0
3 CONTINUE
Anweisung 2 enthält den logischen Skalar L. Bei jedem Schleifendurchlauf, bestimmt L, ob das entsprechende Ergebniselement in A(I) gespeichert werden soll oder nicht. Somit wurde die Steuerabhängigkeit in eine Anweisung einer bedingten Zuordnung umgewandelt, die die innerhalb dieser Anweisung angezogenen Datenelemente betrifft. Die zwei Schleifen haben die gleiche Wirkung.

Datenabhängigkeit

Datenabhängigkeit ergibt sich durch eine von drei Möglichkeiten. Erstens, eine Anweisung T hängt ab von einer Anweisung S, wenn S einen Wert definiert und T sich darauf bezieht. Zweitens, eine Anweisung T hängt ab von einer Anweisung S, wenn S einen Wert anzieht und T ihn definiert. Drittens, eine Anweisung T hängt ab von einer Anweisung S, wenn S einen Wert abspeichert, den auch T abspeichert.
Die erste Abhängigkeit heißt auch wahre Abhängigkeit. Sie kann dargestellt werden als:
S: X=
T: =X
Hier ist es klar, daß S ablaufen muß bevor T ablaufen kann, denn S definiert einen Wert, der von T benutzt wird. Die Ausführung von T hängt davon ab, daß die Ausführung von S abgeschlossen ist.
Die zweite Abhängigkeit wird auch als Anti-Abhängigkeit bezeichnet. Sie kann so dargestellt werden:
S: =X
T: X=
Wiederum muß S vor T ausgeführt werden; sonst würde T die Variable X abspeichern und S würde den falschen Wert benutzen. Und wieder hängt die Ausführung von T davon ab, daß die Ausführung von S abgeschlossen ist.
Die dritte Form der Datenabhängigkeit wird auch als Ausgangsabhängigkeit bezeichnet. Diese läßt sich so darstellen:
S: X=
T. Y=
Hier muß S vor T ausgeführt werden, sonst würde der falsche Wert in der Variablen X verbleiben. Wie schon in den obigen Fällen hängt auch hier die Ausführung von T vom Abschluß der Ausführung von S ab.

Abhängigkeitsebene

Abhängigkeiten sind mit einer bestimmten Ebene einer DO- Schleife in einer Schleife verbunden, die um eine Gruppe von Anweisungen läuft. Einige Abhängigkeiten sind immer vorhanden, zum Beispiel:
DO J=
DO I=
S: V=A(I,J)*B(I,J)
T: Z(I,J)=V
T hängt hier immer von S ab, weil bei jedem Durchlauf jeder Schleife eine echte Abhängigkeit unter Einbeziehung der Variablen V auftritt. Abhängigkeiten dieser Art werden als schleifenunabhängige Abhängigkeiten bezeichnet. Das heißt, sie sind unabhängig von der Durchführung der Schleifen, die sie umgeben.
Einige Abhängigkeiten sind wohl auf einer Schleifenebene vorhanden aber nicht auf einer anderen. So:
DO J=
DO I=
S: A(I+l,J)=A(I,J)
Hier gibt es eine wahre Abhängigkeit auf der Ebene der Schleife mit dem Index I. Ein zum Beispiel im Durchlauf 2 gespeichertes Element wird im -Durchlauf 3 abgerufen. Diese Art Abhängigkeit wird als Rekursion bezeichnet. Auf der Ebene J gibt es hingegen keine Abhängigkeit. Genauer gesagt, kein in einem Durchlauf der Schleife J gespeichertes Element wird in einem anderen Durchlauf angezogen.

Abhängigkeitsaustausch

Wenn eine gegebene Schleife in einer Verschachtelung von DO- Schleifen zur Ausführung in einer SIMD-Maschine gewählt wird, wirkt jede Vektor- (SIMD) -Anweisung auf nachfolgende Datenelemente, die von dieser gegebenen DO-Schleife mit diesem Index ausgewählt wurden. Wenn zum Beispiel die J-Schleife (die Schleife mit Index J) in der Verschachtelung
DO 1 K=1,N
DO 1 J=1,N,
DO 1 I=1,N
1 A (I, J, K) =B (I, J, K)
vektorisiert wird, dann würde eine Vektor-Anweisung LOAD die Elemente B holen und die Elemente A in der Ordnung (1,1,1), (1,2,1), . . . , (1,n,1) abspeichern. Das ist eine andere Ordnung, als sie im Skalarmodus benutzt werden würde, in der die innerste DO-Schleife mit dem Index I am schnellsten umlaufen würde. In der Tat, die Vektorordnung ist genau das, was im Skalarmodus gesehen würde, wenn die J-Schleife mit ihren inneren Nachbarn ausgetauscht würde, bis sie die innerste Schleife wird, d. h.
DO 1 K=1,N
DO 1 I=1,N
DO 1 J=1,N
1 A(I,J,K)=B(I,J,K)
Damit eine gegebene Schleife zur Ausführung in einer SIMD- Maschine ausgewählt wird, muß dieser Austausch auch zulässig sein. Das heißt, er muß die Semantik des Quellcodes beibehalten.
Damit die K-Schleife im ursprünglichen Beispiel vektorisierbar ist, muß die Schleifenordnung
DO 1 J=1,N
DO 1 I=1,N
DO 1 K=1,N
1 A(I,J,K)=B(I,J,K)
die gleichen Ergebnisse liefern wie das Original. Die anderen Schleifen brauchen nicht permutiert zu werden. Man muß nur überprüfen, ob die betroffene Schleife nach innerhalb aller anderen Schleifen verschoben werden kann.
Gelegentlich ist ein solcher Schleifenaustausch nicht möglich. In der Verschachtelung:
DO 1 J=1,N
DO 1 I=1,N
1 A(I-1,J+1)= A(I,J)
gibt es eine Abhängigkeit auf der Ebene der J-Schleife. Hier wird ein Wert, der in einem Durchlauf von J abgespeichert wurde, im nächsten abgerufen. Viele Abhängigkeiten beeinträchtigen die Ergebnisse eines Verfahrens nicht, wenn die Schleifen ausgetauscht werden. In diesem Beispiel jedoch kann die J-Schleife nicht mit der I-Schleife vertauscht werden, weil sich die Antworten ändern würden. Das zeigt eine den Austausch verhindernde Abhängigkeit. Natürlich wird dadurch die Vektorisierung der J-Schleife verhindert.
In einer Mehrebenen-Verschachtelung kann eine Abhängigkeit zunächst ein austauschbarer Teil auf dem Wege zur innersten Ebene sein, der aber dann blockiert ist. Eine solche Abhängigkeit wird als innerst-verhindernde Abhängigkeit genannt, weil diese Ebene der Schleife nicht auf die innerste Ebene geschoben werden kann. Wenn eine Schleife nicht auf die innerste Ebene verschoben werden kann, kann sie auch nicht vektorisiert werden.

Unterteilung für die Vektorausführung

Wie bereits oben ausgeführt, muß eine Schleife, damit sie vektorisierbar (zur SIMD Ausführung brauchbar) ist, auf zulässige Weise in die innerste Stellung geschoben werden können. Es ist nicht nötig, diesen Austausch auch physikalisch durchzuführen. Statt dessen werden im Kompiliererteil der Codegenerierung Vektoranweisungen generiert, die auf die Gruppen oder Abschnitte der von der gewählten Schleife erfaßten Elemente Zugriff nehmen. Die Schleifensteuerungen für die gewählte Schleife bleiben an ihren ursprünglichen Orten und werden verändert, so daß sie mit der Anzahl Elemente in den von den einzelnen Anweisungen verarbeiteten Gruppen inkrementiert werden.

Derzeitiges Verfahren

Im derzeitigen Verfahren wird ein Graph, der alle Abhängigkeitsränder im Programm enthält, in stark zusammenhängende Bereiche auf der obersten Ebene aufgeteilt. Jeder dieser Bereiche wird der Reihe nach betrachtet. In jedem Bereich wird jede Abhängigkeit auf derjenigen DO-Ebene betrachtet, die den Bereich definiert. Das Verfahren versucht die Abhängigkeit auszutauschen, bis die Originalschleife die innerste Schleife geworden ist. Wenn dieser Austausch nicht möglich ist, dann kann der Bereich auf einer SIMD-Maschine auf der für diesen Bereich zuständigen Ebene nicht ausgeführt werden. Damit endet das Verfahren für diesen Bereich auf dieser Ebene. Wenn andererseits ein Austausch möglich ist, aber die Abhängigkeit auf ihrem Weg zur innersten Schleife selbst verschwindet, weil sie von einer Abhängigkeit an einer aufgreifenden Schleife absorbiert wird, dann wird die Abhängigkeit ignoriert, weil sie die SIMD-Ausführung auf der Ebene, die diesen Bereich definiert, nicht betrifft. Andernfalls wird diese Abhängigkeit als "innerst-sensitive" Abhängigkeit für den Bereich bezeichnet.
Vorteilhafterweise werden daher Abhängigkeiten der inneren Schleifen und die während des Austauschs verschwundenen Abhängigkeiten auf Ebene n ausgeschlossen. Aber wenn eine Schleife auf Ebene n zwei oder mehr Schleifen auf Ebene n+1 enthält, kann die Vektorisierung auf Ebene n leider nicht ausgeführt werden, wenn Anweisungen von mehr als einer dieser Schleifen auf Ebene n stark verbunden sind.
Als nächstes wird dann unter Verwendung nur der "innerstempfindlichen" Abhängigkeiten und der schleifenunabhängigen Abhängigkeiten ein Graph gebildet. Wenn dieser Graph einen Zyklus aufweist, ist dieser Bereich auf der Ebene, die dieser Bereich definiert, auf einer SIMD nicht ausführbar. Sonst ist es möglich, den Bereich durch eine SIMD ausführen zu lassen, auch wenn andere Schleifen innerhalb derjenigen Schleife, die den Bereich definiert, Rekursionen aufweisen mögen.
An diesem Punkt wird angemerkt, daß der Bereich auf einer SIMD ausgeführt werden kann. Innere Bereiche werden dann rekursiv betrachtet, wobei jeder gleicherweise als SIMD- ausführbar oder nicht gekennzeichnet wird.
Hier wird offenbar, daß sich die Struktur von der auf dem Stand der Technik erzeugten eindeutig unterscheidet. Auf dem Stand der Technik erzeugten die Verfahren von Allen und Kennedy sequentielle DO-Anweisungen für alle Rekursionen-enthaltenden Bereiche. Ferner führten ihre Verfahren zu dem Schluß, daß die SIMD-Ausführung nur für solche innere Bereiche möglich sei, die keine Rekursionen aufweisen. Beim erfindungsgemäßen Verfahren jedoch wurde festgestellt, daß weitere zusätzliche Quellcode-Anweisungen vektorisierbar sind, auch auf zusätzlichen Verschachtelungsebenen.
Eine Verfeinerung der vorliegenden Erfindung läßt die Auswahl eines Anweisungspfades aus einem Satz zu erwartender Anweisungspfade zur Umwandlung des skalaren Sprach-Quellcodes in eine Codeform zu, die zur Ausführung auf einer SIMD- Maschine geeignet ist. In dieser Hinsicht beinhaltet das Verfahren die folgenden Schritte: (a) Umwandeln des Quellcodes in eine Zeichenkette in einer Zwischensprache und Optimieren dieser Zeichenkette; (b) Bilden eines Abhängigkeits-Graphen aus der Zeichenkette, wobei die Knoten des Graphen Anweisungen in der Zeichenkette darstellen; und (c) Festlegen eines Pfads durch den Abhängigkeits-Graphen mit den geringsten Kosten, der Typ, Anzahl und Verteilung der Anweisungen, ihre Ausführungszeit und die Kosten der angeschlossenen Systemelemente berücksichtigt.
Zur Typisierung dieser Verfeinerung betrachte man das folgende Beispiel. Es bestehe eine Schleifenverschachtelung, die im allgemeinen durch Skalar- oder Vektor-Anweisungen auf der Vektormaschine (SIMD) ausgeführt werden kann, in Anwendung auf eine beliebige, jedoch nur eine einzige Schleife in der Verschachtelung. Zum Beispiel, in der Verschachtelung
DO 1 K=1,N
DO 1 J=1,N
DO 1 1=1,N
A(I,J,K)=B(I,J,K)+P(J,K)*Q(J,K)
1 E(K,J,I)=F(K,J,I)+X(I,J)*Y(I,J)
gibt es vier Möglichkeiten für jede Anweisung (Vektorisieren nach K, J, I, oder überhaupt nicht). Somit gibt es für die Kombination der zwei Anweisungen 16 Möglichkeiten. Das verfeinerte Verfahren findet die am schnellsten auszuführende unter diesen Möglichkeiten. Bei der Kostenabschätzung müssen mehrere Faktoren berücksichtigt werden. Diese sind u. a. die Kosten für den Gesamtaufwand der einzelnen Schleife, die Kosten für die Hardware-Anweisungen, und die Kosten für das Holen und Abspeichern der Operanden. Es ist klar, daß sich diese Kosten für die gleiche Anweisung unterschiedlich darstellen, je nachdem, welche einschließende Schleife zur Ausführung auf der SIMD-Maschine vorgesehen ist.
Die Verfeinerung implementiert einen modifizierten, durch den Graphen laufenden Algorithmus für geringste Kosten. Heuristische Mittel müssen angewandt werden, wenn z. B. zwei ursprünglich aus der gleichen Schleifenverschachtelung stammende Anweisungen in unabhängige Bereiche des Graphen unterteilt werden, dann aber wieder zurück in den gleichen Schleifensteuerungssatz verschmolzen werden, wenn der Objektcode für die Anweisungen generiert wird.
Die im Grundverfahren identifizierten Bereiche (d. h. ohne die Verfeinerung), als jeder von ihnen als für die SIMD ausführbar oder nicht markiert wurde, werden jetzt in eine topologische Ordnung sortiert auf der Grundlage der Abhängigkeit als Teil dieses Prozesses. Die durch den Graphen laufende Querlinie der geringsten Kosten laut der Verfeinerung betrachtet diese Bereiche in topologischer Ordnung, beginnend mit einem ersten Null-Bereich und endend mit einem letzten Null- Bereich. Das verfeinerte Verfahren erzeugt und führt eine Liste für Prozessorzeit, die für die Ausführung dieser Anweisungen in Unterbereichen dieser Bereiche erforderlich ist. Diese Unterbereiche beginnen immer mit einem ersten Nullbereich in der topologischen Reihenfolge und enden mit einem anderen Bereich dieser Ordnung. Immer eingeschlossen sind alle zwischen diesen beiden liegenden Bereiche. Jeder Bereich auf dem betroffenen, betrachteten Pfad schätzt seine eigenen Kosten für eine SISD- bzw. SIMD-Ausführung ab, in Abhängigkeit von den Ausführungsmöglichkeiten, die von dem Pfad dargestellt werden.
Jedes Element auf der Liste stellt die Durchführung der Bereiche auf dem Pfad vom ersten Nullbereich bis zum letzten Bereich auf dem Pfad dar, wobei jeder Bereich auf besondere Weise ausgeführt wird, d. h. entweder als SISD oder als SIMD. Das verfeinerte Verfahren schätzt die Kosten für diese gesamte Sammlung der Bereiche ab unter heuristischer Minimierung der Schleifensteueranweisungen, die eingesetzt werden müssen. Sobald einmal diese Kosten bestimmt sind, werden die nächsten Bereiche zur Ausführung entlang des Pfades identifiziert. Diese Kandidaten sind der nächste in der topologischen Reihenfolge von SISD ausgeführte, und, falls für diesen Bereich zulässig, von SIMD ausgeführte Bereich. Diese Kandidaten und die eben abgeschätzten Durchführungskosten, um diese zu erreichen, werden auf die Liste der anstehenden, möglichen Ausführungspfade gesetzt.
Wenn ein Kandidatenbereich als SISD-Kandidat markiert ist, werden die inneren Bereiche dieses Kandidaten anschließend entweder als SISD- oder SIMD-Kandidat betrachtet. Wenn ein Kandidatenbereich als SIMD-Kandidat markiert ist, sind alle inneren Bereiche SISD-Kandidaten und werden übersprungen, um die Verarbeitung zu beschleunigen.
Das verfeinerte Verfahren arbeitet rekursiv durch Auswahl desjenigen Elements aus der Liste aller Elemente, dessen nächster Kandidat die geringsten Kosten aufweist entlang eines bestimmten Pfades für Ausführungsmöglichkeiten durch Feststellung der Kosten, wobei in seine Ausführung die Ausführung seiner Vorgänger mit eingeschlossen wird, durch Festlegung seiner möglichen Nachfolger und durch Zusammenstellung der Kosten für ihr Erreichen auf die Liste der anstehenden Kandidaten. Das verfeinerte Verfahren endet, sobald der End- Nullbereich als der am wenigsten aufwendige Kandidat ausgewählt wurde, der in einem Pfad eingeschlossen werden kann. Der gewählt Pfad bietet eine Entscheidung für jeden Bereich, ob dieser Bereich mit SISD oder mit SIMD ausgeführt werden soll. Er stellt ferner eine Entscheidung dar, wie die Bereiche zu weniger Bereichen zusammengefaßt werden sollen mit dem Ziel, die Schleifensteueranweisungen zu minimieren. Dann wird die Quellcode-Zeichenkette erneut durchgearbeitet, wobei diese Entscheidungen eingebaut werden. Die Optimierung einer Quellcode-Zeichenkette, insbesondere Registeroptimierung, kann dann durchgeführt werden und schließlich wird ein Objektcode generiert.

Darstellendes Beispiel

Ein darstellendes Beispiel kann die Unterschiede der Vektorisierbarkeit zwischen dem Stand der Technik und der vorliegenden Erfindung illustrieren.
Fig. 1 zeigt ein Fragment eines Quellcodes in FORTRAN. Dieses Fragment enthält vier Anweisungen, die fortlaufend von 1 bis 4 beziffert sind. Diese vier Anweisungen sind in vier DO- Schleifen eingebettet. Die erste dieser Schleifen, DO 9 L=1,10, schließt alle anderen ein. Sie ist die äußerste Schleife und wird als Schleife der Ebene 1 bezeichnet, weil man auf sie als erste stößt, wenn man in Richtung von den außenliegenden Bereichen des Codefragments zum innersten Bereich des Codefragments vorstößt. Die zweite Schleife ist die DO K Schleife. Diese Schleife ist die zweite Schleifenebene, auf die man stößt wenn man von außen nach innen vordringt; sie heißt daher Schleife der Ebene 2. DO J ist eine Schleife der Ebene 3, weil sie die nächste Schleifenebene ist, und DO I ist auf ähnliche Weise eine Schleife der Ebene 4. Kurz gesagt, die Schleifenebenen stellen die Verschachtelung dar: Ebene 1 ist die äußerste Ebene, Ebene n ist die n-te Ebene der Verschachtelung.
Die Abhängigkeiten im Fragment sind mittels eines Graphen dargestellt. Die Anweisungen im Fragment, beziffert 1 bis 4, werden im Graphen durch Kreise dargestellt, in denen die Ziffern 1 bis 4 stehen. Eine Abhängigkeit von einer Anweisung zu einer anderen wird durch einen Pfeil dargestellt, der vom Kreis für die eine dieser Anweisungen zu dem Kreis für die zweite dieser Anweisungen führt. Der Pfeil wird seinerseits mit einer Zahl bezeichnet, die angibt, in welcher DO Schleife die Abhängigkeit erzeugt wurde. Eine Abhängigkeit, die in einer DO Schleife auf Ebene 1 erzeugt wird, wird mit der Ziffer 1 bezeichnet.
Fig. 2A zeigt nun den Graphen, der auf dem Stand der Technik für dieses Programm konstruiert wurde. Blicken wir, zwecks besseren Verständnisses, auf einen Pfeil in diesem Graphen. Der Pfeil von Kreis 3 zu Kreis 4 stellt eine Abhängigkeit von der Anweisung 3 zur Anweisung 4 dar. Der Pfeil ist mit der Ziffer 4 bezeichnet, die angibt, daß die Schleife auf Ebene 4, die DO I Schleife, diese Abhängigkeit generiert. Wenn man aus dem Original-Codefragment nur den Code, der sich auf diesen Pfeil bezieht, herauszieht, wird diese Abhängigkeit, die durch diesen Pfeil dargestellt wird, klarer:
DO 9 I=1,10
3 C(T+1,J+1,K+1,L+1) =
4 . . . = C(I,J+1,K+1,L+1)
9 CONTINUE
Es gibt einen Pfeil von Anweisung 3 zu Anweisung 4, generiert von der DO I Schleife, weil die Anweisung 3 Daten abspeichert, die von Anweisung 4 auf einem nachfolgenden Durchlauf dieser Schleife abgerufen werden. Bei der ersten Iteration, wenn z. B. die Variable I den Wert 1 hat, speichert die Anweisung 3 die Bezugsgröße C(2,J+1,K+1,L+1) ab; in der zweiten Iteration, wenn die Variable I den Wert 2 hat, wird eben diese Bezugsgröße von der Anweisung 4 abgerufen. Somit hängt Anweisung 4 von der Anweisung 3 ab. Also, weil eine Abhängigkeit von der Anweisung 3 zur Anweisung 4 besteht, und weil diese Abhängigkeit durch die Operation der DO I Schleife verursacht wird (die in diesem Beispiel die Schleife der Ebene 4 ist), wird in diesem Graphen ein Pfeil vom Kreis 3 zum Kreis 4 gezogen und dieser Pfeil wird als Ebene 4 bezeichnet.
Blicken wir jetzt, ebenfalls zwecks besseren Verständnisses, auf einen zweiten Pfeil im Graphen. Der Pfeil von Kreis 4 zu Kreis 1 stellt eine Abhängigkeit von der Anweisung 4 zur Anweisung 1 dar. Der Pfeil wird mit der Ziffer 1 bezeichnet, die angibt, daß die Schleife auf Ebene 1, die DO L Schleife, diese Abhängigkeit generiert. Wenn wir aus dem Original- Codefragment nur den sich auf diesen Pfeil beziehenden Code entnehmen, wird die durch diesen Pfeil dargestellte Abhängigkeit deutlicher:
DO 9 L=1,10
1 . . . = D(I,J,K,L)
4 D(I+1,J+1,K+1,L+1) =
9 CONTINUE
Hier läuft ein Pfeil von der Anweisung 4 zur Anweisung 1, der von der DO L Schleife generiert wird, weil Anweisung 4 Daten abspeichert, die von Anweisung 1 bei einer nachfolgenden Iteration dieser Schleife abgerufen werden. Bei der ersten Iteration von DO L, z. B. wenn die Variable den Wert 1 hat, speichert Anweisung 4 die Bezugsgröße D(2,2,2,2) ab. (Sie speichert diese Bezugsgröße ab, wenn auch die inneren Schleifen auf ihrer ersten Iteration mit L=l sind) . Bei der zweiten Iteration von DO L, wenn die Variable L den Wert 2 hat, wird eben diese Bezugsgröße von der Anweisung 1 geholt. (Sie holt diese Bezugsgröße, wenn auch die inneren Schleifen auf ihrer ersten Iteration mit L=2 sind.) Somit hängt die Anweisung 1 von der Anweisung 4 ab - die Anweisung 1 kann die Ausführung für eine gegebene Iteration der Schleife L nicht abschließen, wenn nicht Anweisung 4 die Ausführung für eine vorhergehende Iteration der Schleife L abgeschlossen hat. Weil also eine Abhängigkeit von Anweisung 4 zu Anweisung 1 besteht, und weil diese Abhängigkeit von der Operation der DO L Schleife verursacht wird (die im vorliegenden Beispiel eine Schleife auf der Ebene 1 ist), wird im Graphen ein Pfeil von Kreis 4 zu Kreis 1 gezogen und dieser Pfeil wird als Ebene 1 bezeichnet.
Alle Pfeile in Fig. 2A sind nach dem Stand der Technik konstruiert. Sie alle haben Bedeutungen von der Art, wie oben bezeichnet. Ein Pfeil der Ebene 2 von Kreis 3 zu Kreis 1 bedeutet, z. B., daß Anweisung 3 eine Bezugsgröße in einer Iteration der Schleife auf Ebene 2 abspeichert und daß Anweisung 1 eben diese Bezugsgröße bei einer späteren Iteration der Schleife dieser Ebene 2 wieder abruft.
Die Fig. 2B unterscheidet sich von der Fig. 2A dadurch, daß bei Anwendung der vorliegenden Erfindung die Pfeile als darstellend bzw. nicht darstellend für innerst-empfindliche Abhängigkeiten kategorisiert werden. Eine innerst-empfindliche Abhängigkeit ist eine, die weiterbesteht, wenn die DO Schleife, die die Abhängigkeit generiert, zur innersten Schleife gemacht wird. Im Falle einer oben diskutierten Abhängigkeit von Anweisung 3 zu Anweisung 4 auf Ebene 4, ist Ebene 4 bereits die innerste Ebene, da die DO I Schleife, die sie verursacht, bereits die innerste Schleife ist, und daher wird der die Abhängigkeit repräsentierende Pfeil als innerstempfindlich markiert. Im Falle der Abhängigkeit auf Ebene 1, die oben als von Anweisung 4 zu Anweisung 1 diskutiert wurde, ist die Abhängigkeit jedoch nicht innerst-empfindlich.
Das läßt sich leichter feststellen anhand des Code Fragments:
DO 9 K=1,10
DO 9 J=1,10
DO 9 I=1,10
DO 9 L=1,10
1 . . . = D(I,J,K,L)
4 D(I+1,J+l,K+1,L+1) =
9 CONTINUE
in dem die DO L Schleife, die ursprünglich die Abhängigkeit hervorgerufen hatte, zur innersten Schleife gemacht wurde. Wenn wir jetzt den relevanten Teil dieses Codefragments betrachten:
DO 9 L=1,10
1 . . . = D(I,J,K,L)
4 D(I+1,J+1,K+1) =
9 CONTINUE
wobei jetzt DO L die innerste Schleife ist, sehen wir, daß bei keiner Iteration von DO L eine Bezugsgröße von der Anweisung 4 abgespeichert und von der Anweisung 1 abgerufen wird. Der Code kann z. B. D(2,5,5,5) bei der zweiten Iteration der Schleife abspeichern, aber auch wenn das geschieht, holt er bei der zweiten Iteration D(2,6,6,6). Wenn also DO L die innerste Schleife wird, gibt es keine Abhängigkeit von der Anweisung 4 zur Anweisung 1 für diese Schleife, und daher wird die Abhängigkeit als nicht innerst-empfindlich bezeichnet.
Sehen wir jetzt die Graphen 3 bis 6 an. Diese Graphen wurden konstruiert bei der Untersuchung der Vektorisierbarkeit des Programms auf den Ebenen 1 bis 4. Graph 3A untersucht die Vektorisierung auf Ebene 1 nach dem Stand der Technik. Ein Graph nach dem Stand der Technik für Ebene 1 wählt aus den Graphen für das Programm alle Pfeile aus, die Abhängigkeiten auf Ebene 1 und tieferliegenden Ebenen darstellen. Da Ebene 1 die äußerste Ebene dieses Programms ist, enthält dieser Graph alle Pfeile aus dem ursprünglichen Graphen. Der Stand der Technik betrachtet solche Anweisungen als vektorisierbar, die nicht direkt oder indirekt von sich selbst abhängig sind. Er stellt diese Abhängigkeit fest durch Untersuchen des gewählten Graphen.
Ausgedrückt als Graph hängt eine Anweisung von sich selbst ab, wenn es eine Reihe von Pfeilen gibt, die von einem Kreis, der die Anweisung bezeichnet, ausgehen und schließlich zurück zu diesem gleichen Kreis führen.
Somit ist jeder beliebige Kreis, für den es eine Reihe Pfeile gibt, die von diesem Kreis ausgehen und schließlich zu ihm zurückführen, die Darstellung einer Anweisung, die nicht vektorisierbar ist.
Die Untersuchung der Fig. 3A zeigt, daß jede Anweisung von sich selbst aus erreichbar ist. Der Stand der Technik schließt daher, daß auf Ebene 1, der DO L Ebene, jede Anweisung von sich selbst abhängt und daher keine Anweisung vektorisierbar ist.
Graph 3B untersucht die Vektorisierung auf Ebene 1 gemäß der vorliegenden Erfindung. Erfindungsgemäß wählt ein nach Ebene l konstruierter Graph aus dem Graphen für das Programm nur Pfeile von zwei Typen aus: Pfeile, die schleifenunabhängige Abhängigkeiten darstellen, und Pfeile die innerst-empfindliche Abhängigkeiten auf Ebene 1 darstellen. Gehen wir jetzt zu Graph 2B, der den Graph für das Programm beinhaltet. Wir suchen nach Pfeilen, die schleifenunabhängige Abhängigkeiten darstellen; diese Pfeile würden mit der Zahl 5 bezeichnet. Wir finden keine solchen Pfeile. Als nächstes suchen wir nach Pfeilen, die innerst-emfindliche Abhängigkeiten auf der Ebene 1 darstellen. Diese Pfeile würden mit "1 - innerst-empfindlich"bezeichnet, wie oben erklärt ist. Wieder finden wir keine solchen Pfeile, da alle Abhängigkeiten auf Ebene 1, die in Graph 2A dargestellt werden, erfindungsgemäß als nicht innerst-empfindlich befunden wurden. Der zur Untersuchung der Vektorisierbarkeit des Programms auf Ebene 1 konstruierte Graph, Graph 3B, enthält daher überhaupt keine Pfeile. Die Erfindung hat festgestellt, daß keine der in dem laut Stand der Technik konstruierten Graphen gefundene Abhängigkeit für die Vektorisierung des Programms auf Ebene 1 relevant ist. Fig. 3B zeigt daher, daß keine Anweisung durch eine Pfeilfolge erreicht werden kann, die in sich selbst zurückläuft und daher keine Anweisung von sich selbst abhängig ist. Mit anderen Worten, jede Anweisung auf Ebene 1 ist erfindungsgemäß vektorisierbar.
Graph 4B untersucht die Vektorisierung auf Ebene 2. Er wird aus denjenigen Pfeilen in Graph 2B konstruiert, die entweder mit "5" oder mit "2 innerst-empfindlich" gekennzeichnet sind. Wiederum gibt es keine solchen Pfeile, und wieder hat die Erfindung gefunden, daß keine der in dem laut Stand der Technik konstruierten Graphen vorhandene Abhängigkeiten relevant für die Vektorisierung des Programms auf Ebene 1 ist. Graph 5B ist ähnlich.
In Graph 6B, der die Vektorisierung auf Ebene 4 untersucht, schließen wir diejenigen Pfeile in Graph 2B mit ein, die entweder mit "5" oder mit "innerst-empfindlich" gekennzeichnet sind. Hier gibt es drei solche Pfeile. Sie verhindern die Vektorisierung nicht, weil sie im Graphen keinen Zyklus bilden.

Maschinenaus führbarkeit

Hier muß darauf hingewiesen werden, daß die obigen Bemerkungen eine Vertrautheit mit SISD und SIMD-Verarbeitung voraussetzen. Ein typischer SISD Prozessor wird beschrieben von Amdahl et al. in US-A-3,400,371, "Data Processing System", erteilt am 3. Sept. 1968. Amdahl beschreibt auch die erforderliche Betriebssystemumgebung, nach welcher Quellcode- Sequenzen so in Verfahrenssprache verarbeitet werden können, daß Objektcodes produziert werden, die ihrerseits auf SISD oder SIMD Prozessoren lauffähig sind. Ein FORTRAN Compiler für höhere Programmiersprache, der VSG FORTRAN Compiler von IBM, ist ein Beispiel für den Wandler von Quellcode zu Objektcode in höherer Verfahrenssprache, auf den die vorliegenden Erfindung anwendbar ist.
SIMD Prozessoren, die zur Ausführung von Vektoranweisungen geeignet sind, werden in Stokes et al., US-A-4,101,960 "Scientific Processor", erteilt am 18. Juli 1978; Lorie et al., US-A-4,435,758, "Method for Conditional Branch Execution in SIMD Vector Processors", erteilt am 6. März 1984, und in den dort angezogenen Bezugsquellen beschrieben.

Claims

1. Betriebsverfahren für einen Rechner, um einen Objektcode zur Abarbeitung auf einer SIMD-Maschine zu kompilieren, wobei dieser Objektcode aus den Quellcodeanweisungen in der verfahrensorientierten Sprache abgeleitet wird, dieser Quellcode verschachtelte Schleifen enthält, von denen wenigstens eine Schleife die innerste und wenigstens eine Schleife die äußerste ist, und der die folgenden Schritte aufweist:

(a) Umwandeln des Quellcodes in eine Zeichenkette in einer Zwischensprache und Optimieren dieser Zeichenkette;

(b) Bilden eines Abhängigkeits-Graphen aus der Zeichenkette, wobei dieser Abhängigkeits-Graph wenigstens einen Knoten aufweist und diese Knoten des Abhängigkeits-Graphen Anweisungen in der Zeichenkette darstellen;

(c) Aufteilen dieses Abhängigkeits-Graphen in stark verbundene Bereiche, SCRs, und Analysieren dieser SCRs, um festzustellen, ob die äußersten Schleifen, die diesen SCRs entsprechen, vektorisiert werden können zwecks Abarbeitung auf der SIMD-Maschine;

(d) rekursives Ausführen des Schritts (c) auf diese SCRs dieser Unterteilungen;

(e) Generieren eines Codes für die SIMD-Maschine, gemäß dessen bestimmte Schleifen als vektorisierbar erkannt wurden;

dadurch gekennzeichnet, daß diese Analyse des Schritts (c) umfaßt:

(1) für jeden SCR Feststellen, ob die entsprechende äußerste Schleife jeweils mit der nachfolgenden inneren Schleife ausgetauscht werden kann, bis diese äußerste Schleife die innerste wird, ohne dabei die semantische Wirkung einer der Abhängigkeiten bezüglich dieser äußersten Schleife zu verändern; und

(2) Bilden eines Subgraphen aller dieser austauschbaren Abhängigkeiten und aller schleifenunabhängigen Abhängigkeiten und Kennzeichnen der entsprechenden Schleifen als vektorisierbar wenn dieser Subgraph azyklisch ist.

2. Verfahren gemäß Anspruch 1, in dem Anweisungen im Quellcode einer Verfahrenssprache laufend aus einer stark typisierten Sprache ausgewählt werden, die aus einem Satz stark-typisierter Sprachen einschließlich FORTRAN, FL/1, PASCAL, ALGOL, ADA und ihnen gleichwertigen Sprachen ausgewählt wird.

3. Verfahren gemäß Anspruch 1 oder 2, in dem dieses Verfahren ferner den Schritt der Festlegung eines kostenoptimierten Pfades durch den Abhängigkeitsgraphen in der SIMD-Maschine unter Berücksichtigung eines vorgegebenen Typs, der Anzahl und der Verteilung der Anweisungen, der Durchführungszeit für die Anweisungen, und der Kosten der zugeordneten Betriebselemente beinhaltet.