Digitale Hardware/ Software-Systeme- P20 doc

Wird hingegen f¨ur alle Verifikationsbe-reiche gezeigt, dass diese ¨aquivalent sind, so sind die beiden C-Programme ¨aquiva-lent.. Wird dies bei der Bestimmung der Quelltext-Unterschiede

Wird nun die Instruktion 1 aus Programm 1 und die Instruktion 3 aus Programm 2 symbolisch simuliert, erh¨alt man:

E1:= {b0,1 ,b0,2 ,tmp10,2 }

E2:= {c0,1,c0,2,tmp20,2}

E3:= {a0,1,b0,1+ c0,1}

E4:= {a0,2,tmp10,2+tmp20,2}

Mit den ¨Aquivalenzklassen E1und E2kann die ¨Aquivalenz von E3und E4gezeigt werden Aus diesem Grund werden ¨Aquivalenzklassen E3und E4vereinigt:

E3 := {a0,1,a0,2,b0,1+ c0,1,tmp10,2+tmp20,2}

Da dadurch a0,1und a0,2in der selben ¨Aquivalenzklasse sind, sind die beiden Pro-gramme in der Tat ¨aquivalent

¨

Aquivalenzpr ¨ufung mittels Programmabh¨angigkeitsgraphen

F¨ur große C-Programme st¨oßt die symbolische Simulation schnell an ihre Grenzen Aus diesem Grund bietet es sich an, zun¨achst diejenigen Stellen in den Program-men zu identifizieren, bei denen es sich lohnt die ¨Aquivalenz bzw Nicht¨aquiva-lenz von Variablen zu zeigen Hierzu wird in [315] ein Verfahren vorgestellt, bei dem zun¨achst Unterschiede in den Quelltexten der C-Programme identifiziert

wer-den Diese Quelltext-Unterschiede definieren die sog Verifikationsbereiche Nur f¨ur

die Verifikationsbereiche wird versucht, deren ¨Aquivalenz zu zeigen Ist dies nicht m¨oglich, wird versucht, den Verifikationsbereich zu erweitern Gelingt auch dieses nicht, sind die Programme nicht ¨aquivalent Wird hingegen f¨ur alle Verifikationsbe-reiche gezeigt, dass diese ¨aquivalent sind, so sind die beiden C-Programme ¨aquiva-lent Der gesamte Ablauf ist in Abb 7.4 zu sehen

Es kann aufgrund von Optimierungen vorkommen, dass die beiden zu verglei-chenden Programme an manchen Stellen keine zeilenweise Korrespondenz zeigen, was f¨ur die im Folgenden vorgestellte Bestimmung der Verifikationsbereiche aller-dings notwendig ist Wird dies bei der Bestimmung der Quelltext-Unterschiede fest-gestellt, werden in den Programmen neutrale Erweiterungen vorgenommen, also Er-weiterungen, die keinen Einfluss auf das Ergebnis der Verifikation haben: Handelt es

sich bei einem festgestellten Unterschied um eine Zuweisung an die Variable x, so kann in dem Programm, das diese Zuweisung nicht enth¨alt, die Anweisung x := x

hinzugef¨ugt werden Dies wird an einem Beispiel verdeutlicht

Beispiel 7.1.7 Gegeben sind die beiden Ausschnitte aus zwei Programmen:

Hierbei wurde in Programm 1 die dritte Zeile hinzugef¨ugt, um eine zeilenweise Kor-respondenz zwischen den Programmen zu schaffen

Programm 1 Programm 2

Nein

¨aquivalent?

Ja

Ja

erweiterbar?

Nein

Nein

nicht

¨aquivalent

Programme

¨aquivalent

Bereichs-erweiterung

symbolische Simulation

Bestimung Quell-text-Unterschiede

Unterschiede?

Verifikationsbe-reichsbestimmung

Abb 7.4 ¨Aquivalenzpr¨ufung von C-Programmen basierend auf Quelltext-Unterschieden [315]

Fehlen in einem Programm Kontrollanweisungen, so kann es um diese Anwei-sung erweitert werden In jedem der beiden folgenden Ausf¨uhrungszweige werden dann zum anderen Programm korrespondierende Zuweisungen von Variablen an sich selbst vorgenommen Basierend auf den so erweiterten Programmen, k¨onnen nun die Verifikationsbereiche bestimmt werden

F¨ur die Bestimmung der Verifikationsbereiche bietet sich eine spezielle

Da-tenstruktur an, der sog Programmabh¨angigkeitsgraph (engl Program Dependence Graph, PDG) [226].

Definition 7.1.1 (Programmabh¨angigkeitsgraph (PDG)) Ein

Programmabh¨angig-keitsgraph (PDG) ist ein gerichteter Graph GP(V,E), wobei die Knoten v ∈ V Zu-weisungen oder Pr¨adikate von konditionalen Spr¨ungen repr¨asentieren Es existiert

ein ausgezeichneter Startknoten v0∈ V Die Menge der Kanten E = V ×V ist bipar-titioniert, d h E = EC∪ EDmit EC∩ ED= ∅.

Die Kontrollflusskanten e ∈ ECstellen Kontrollabh¨angigkeiten dar und sind mit dem Wert F oder T beschriftet Kontrollflusskanten e = (v i ,v j ) ∈ ECbeginnen entwe-der bei einem Knoten v i , der ein Pr¨adikat repr¨asentiert, oder dem ausgezeichneten Startknoten v i = v0 Eine Kontrollflusskante, die mit T (F) beschriftet ist, stellt den Kontrollfluss f¨ur den Fall dar, dass das Pr¨adikat, das durch v i repr¨asentiert ist, erf¨ullt (nicht erf¨ullt) ist Die Datenflusskanten e ∈ EDstellen Datenabh¨angigkeiten dar Eine Datenflusskante e = (v i ,v j ) zwischen Knoten v i und v j existiert genau dann, wenn:

• In der Zuweisung, die durch v i repr¨asentiert wird, die Variable x geschrieben wird,

• in der Anweisung, die durch v j repr¨asentiert wird, die Variable x gelesen wird und

• ein Ausf¨uhrungspfad von v i nach v j existiert, d h ein Pfad im Kontrollflussgraph des Programms existiert, auf dem x nicht ein weiteres Mal geschrieben wird Ein PDG kann zu einem Systemabh¨angigkeitsgraph (engl System Dependence Graph, SDG) erweitert werden, in dem Funktionen und Prozeduren ebenfalls als

PDG dargestellt werden und Kontroll- und Datenflusskanten die PDGs der Funktio-nen und Prozeduren geeignet mit dem Programmabh¨angigkeitsgraph des Programms verkn¨upft [226]

Beispiel 7.1.8 Gegeben ist das folgende C-Programm mit Eingaben f¨ur die

Varia-blen x und y [315]:

1 if (x >= y)

5 return z;

Der zugeh¨orige Programmabh¨angigkeitsgraph ist in Abb 7.5 zu sehen Kontroll-flusskanten sind gestrichelt dargestellt Die Eingaben f¨ur x bzw y sind x in bzw

y in

Mit Hilfe der PDGs und den Quelltext-Unterschieden zweier C-Programme las-sen sich nun die Verifikationsbereiche definieren Ein Verifikationsbereich umfasst den Graphen, der durch die Knoten der PDGs, bei denen Unterschiede aufgetreten

sind, induziert wird F¨ur solche Verifikationsbereiche k¨onnen nun Eingabe- und Aus-gabevariablen definiert werden:

• Eingabevariablen eines Verifikationsbereichs sind durch die in den

Verifikations-bereich eingehende Datenflusskanten repr¨asentiert

• Ausgabevariablen eines Verifikationsbereichs sind durch die aus dem

Verifikati-onsbereich ausgehende Datenflusskanten repr¨asentiert

Lediglich f¨ur die Ausgabevariablen des Verifikationsbereichs, die in beiden Pro-grammen vorkommen, muss ¨Aquivalenz gezeigt werden Kann f¨ur alle Ausgabe-variablen deren ¨Aquivalenz gezeigt werden, so sind auch die beiden

Programmab-schnitte des Verifikationsbereichs ¨aquivalent Kann die ¨Aquivalenz allerdings nicht

T T T T

F T

return z

z := y-x

y := y in

x := x in

z := x-y

x >= y

Start

Abb 7.5 Programmabh¨angigkeitsgraph [226]

gezeigt werden, so muss der Verifikationsbereich erweitert werden Hierbei gibt es prinzipiell drei M¨oglichkeiten:

1 R¨uckw¨artserweiterung: Bei der R¨uckw¨artserweiterung wird ein

Vorg¨angerkno-ten im PDG, der ¨uber eine eingehende DaVorg¨angerkno-tenflusskante verbunden ist, zu dem Verifikationsbereich hinzugenommen Wenn verschiedene Zuweisungen f¨ur den Vorg¨angerknoten auf unterschiedlichen Kontrollflusspfaden existieren, so m¨us-sen alle Knoten, die diese Zuweisungen repr¨am¨us-sentieren, inklusive des kontrollie-renden Knoten mit dem zugeh¨origen Pr¨adikat, dem Verifikationsbereich zuge-ordnet werden

2 Vorw¨artserweiterung ¨uber eine Datenabh¨angigkeit: Hierbei wird ein direkter

Nachfolgerknoten, der ¨uber eine ausgehende Datenflusskante verbunden ist, zu dem Verifikationsbereich hinzugenommen

3 Vorw¨artserweiterung ¨uber eine Kontrollflusskante: Hierbei werden alle direkten

Nachfolgerknoten, die ¨uber eine ausgehende Kontrollflusskante eines Knoten im Verifikationsbereich verbunden sind, zu dem Verifikationsbereich hinzugenom-men

Die Frage, welche Erweiterung am sinnvollsten ist, h¨angt stark von dem gege-benen Programm ab Allerdings lassen sich Terminierungskriterien spezifizieren, die eine weitere Erweiterung des Verifikationsbereichs ¨uberfl¨ussig machen:

• Falls die ¨Aquivalenz der neu zugef¨ugten Knoten bereits gezeigt wurde, so ist eine

R¨uckw¨artserweiterung nicht mehr sinnvoll

• Falls die zugef¨ugten Knoten den Anfang oder das Ende des Programms

beschrei-ben, ist eine Erweiterung ¨uber diese Knoten hinaus nicht m¨oglich

Der erste Fall trifft auch f¨ur Eingabevariablen des Verifikationsbereichs zu Zwei Eingabevariablen sind ¨aquivalent, wenn diese nicht von anderen

Verifikationsberei-chen abh¨angen, f¨ur welche die ¨Aquivalenz noch nicht gezeigt wurde, oder f¨ur die beiden Variablen wurde bereits ¨Aquivalenz gezeigt Die ¨Aquivalenzpr¨ufung mittels Programmabh¨angigkeitsgraphen wird an einem Beispiel gezeigt [315]

Beispiel 7.1.9 Gegeben sind die beiden Programme:

1 if (in1 > in2) { if (in1 > in2) {

Die Eingabevariablen der beiden C-Programmen sind in1 und in2 Die Ausgabeva-riable in beiden Programmen heißt out Man beachte, dass das Programm 1 in Zeile

12 um die Anweisung x = x erweitert wurde, um eine zeilenweise Korrespondenz zwischen den Programmen zu erreichen

Die beiden Programmabh¨angigkeitsgraphen sind in Abb 7.6 zu sehen Der erste Quelltext-Unterschied ist in Zeile 10 der beiden C-Programme Entsprechend wird der Verifikationsbereich A in Abb 7.6 als erstes betrachtet Da f¨ur die Eingabevaria-blen des Verifikationsbereichs keine ¨Aquivalenzen bekannt sind, kann auch nicht die

¨

Aquivalenz der Variablen x gezeigt werden

F T

F

T

B

C

c

in2

a:=in1+in2 a:=in2-in1

x:=a+c

x:=a a:=in1+in2 a:=in2-in1

Abb 7.6 Programmabh¨angigkeitsgraphen und Verifikationsbereiche [315]

Die entsprechenden ¨Aquivalenzklassen lauten:

E1:= {a0,1}

E2:= {a0,2,x0,2}

E3:= {c0,1}

E4:= {x0,1,a0,1+ c0,1}

Um den Verifikationsbereich zu erweitern, bietet sich ein R¨uckw¨artserweiterung f¨ur die Variable a an Da a in einem konditionalen Kontrollpfad berechnet wird, muss auch die Zuweisung im alternativen Pfad sowie das Pr¨adikat selbst mit zur Erweite-rung geh¨oren Somit ist der neue Verifikationsbereich der Bereich B Die Eingabe-variablen f¨ur Verifikationsbereich B sind in1, in2 und c Die Eingabevariable in1 bzw in2 in Programm 1 ist ¨aquivalent mit in1 bzw in2 in Programm 2 Dennoch kann aufgrund der Unterschiede in der Zuweisung keine ¨Aquivalenz der Programme f¨ur den Verifikationsbereich B gezeigt werden Die entsprechenden ¨ Aquivalenzklas-sen lauten:

E1:= {in10,1 ,in10,2 }

E1:= {in20,1,in20,2}

E1:= {a0,1,a0,2,x0,2}

E3:= {c0,1}

E4:= {x0,1,a0,1+ c0,1}

Es folgt schließlich eine Vorw¨artserweiterung ¨uber die Datenabh¨angigkeit von

x Der neue Verifikationsbereich ist der Bereich C in Abb 7.6 In diesem Fall wird auch die Variable c in Programm 2 ber¨ucksichtigt Außerdem ist bekannt, dass die Variable c in Programm 1 ¨aquivalent zu Variable c in Programm 2 ist Somit kann auch die ¨Aquivalenz der Variable x in Programm 1 und Programm 2 gezeigt werden Damit ist gleichzeitig auch gezeigt, dass die beiden Programme ¨aquivalent sind Die abschließenden ¨Aquivalenzklassen lauten:

E1:= {in10,1 ,in10,2 }

E1:= {in20,1,in20,2}

E1:= {a0,1,a0,2}

E3:= {c0,1,c0,2}

E4:= {x1,1,x1,2,a0,1+ c0,1,a0,2+ c0,2}

¨

Aquivalenzpr ¨ufung ohne Abrollen der Schleifen

Die bis jetzt vorgestellten Verfahren zur ¨Aquivalenzpr¨ufung f¨ur C-Programme setzen Einschr¨ankungen voraus, die sich teilweise lockern lassen In [395] wird beispiels-weise eine ¨Aquivalenzpr¨ufung vorgestellt, welches das Abrollen der Schleifen nicht verlangt Gepr¨uft werden zwei Programme, die durch Transformationen auseinander

hervorgegangen sind Dabei werden im Folgenden nur Transformationen betrachtet, die zum Ziel haben, die Speicherzugriffe zu minimieren Im Wesentlichen lassen sich zwei Transformationen aus diesem Bereich unterscheiden:

• Globale Schleifentransformationen werden verwendet, um for-Schleifen

umzu-ordnen und neu zu strukturieren, wodurch sich die temporale und r¨aumliche Lo-kalit¨at der Daten verbessert Hierdurch werden Zugriffe auf den Hauptspeicher minimiert

• Globale Datenflusstransformationen werden verwendet, um beispielsweise

wie-derholte Berechnungen zu entfernen oder einen Flaschenhals, der durch die Be-rechnung von Datenabh¨angigkeiten hervorgerufen wird, aufzul¨osen

Die Transformationen basieren dabei auf dem Propagieren von Ausdr¨ucken (engl

expression propagation), was tempor¨are Variablen erzeugt oder eliminiert Daneben

wurden globale algebraische Transformationen eingesetzt, die auf algebraischen Ei-genschaften beruhen Da diese Transformationen fehleranf¨allige ¨Anderungen an den Berechnungen der Variablenindizes durchf¨uhren k¨onnen, ist hier eine Unterst¨utzung durch eine formale ¨Aquivalenzpr¨ufung besonders hilfreich

Beispiel 7.1.10 Betrachtet wird das folgende C-Programm [396]:

2 void prog1(int a[], int b[], int c[]) {

3 int k, tmp1[256], tmp2[256], tmp3[256];

4

5 for (k=0; k<256; k++)

6 s1: tmp1[k] = a[2*k] + f(B[k+1]);

7 for (k=10; k<138; k++)

8 s2: tmp2[k] = b[k-8];

9 for (k=10; k<266; k++) {

12 s4: tmp3[k-10] = f(a[2*k - 19]) + tmp2[k];

14 for (k=255; k>=0; k )

15 s5: c[3*k] = tmp1[k] + tmp3[k];

Ferner ist das folgende C-Programm gegeben, welches durch Propagieren von Aus-dr¨ucken, Schleifen- und algebraischen Transformation aus Programm 1 erhalten wurde [396]:

2 void prog2(int a[], int b[], int c[]) {

3 int k, tmp4[256], tmp5[256];

4

5 for (k=0; k<256; k++) {

6 t1: tmp4[k] = f(a[2*k+1]) + a[2*k];

7 t2: tmp5[k] = b[k+2] + tmp4[k];

8 t3: c[3*k] = f(b[k+1]) + tmp5[k];

Vernachl¨assigt man potentielle Wertebereichs¨uberl¨aufe, berechnen die beiden

Funk-tionen die selben Ausgaben f¨ur die selben Eingaben, d h sie sind

Eingabe/Ausgabe-¨aquivalent.

Es werden Programme mit den folgenden Eigenschaften betrachtet:

• Dynamische Einmalzuweisung (engl dynamic single assignment, DSA): Das

Pro-gramm ist in dynamischer Einmalzuweisung geschrieben Hierbei wird jede

Va-riable lediglich einmal geschrieben Im Gegensatz zur statischen Einmalzuwei-sung (engl static single assignment, SSA) [125], welche lediglich auf dem

Um-benennen einzelner Variablen basiert, wird bei DSA auch der dynamische Kon-trollfluss mit ber¨ucksichtigt, so dass auch in Schleifenr¨umpfen Variablen ledig-lich einmal geschrieben werden [158]

• St¨uckweise affine Ausdr¨ucke: Indizes f¨ur Arrays innerhalb von Schleifenr¨umpfen

sind st¨uckweise affin Auch sind die Operatoren mod, div, min, max, floor und ceil zugelassen Hierdurch k¨onnen die Relationen zwischen Arrayvariablen als affine Ungleichungen beschrieben werden

• Statischer Kontrollfluss: Die Programme enthalten keine datenabh¨angigen

Schlei-fen Es wird angenommen, dass datenabh¨angige Schleifen durch Schleifen mit konstanten Grenzen und einer if-Anweisung im Schleifenrumpf zum daten-abh¨angigen Abbruch der Schleife ersetzt werden

• Zeiger und Rekursionen: Zeiger und Rekursionen sind in den Programmen nicht

gestattet

ADDGs

Array-Datenabh¨angigkeitsgraphen (engl Array Data Dependency Graph, ADDG)

werden im Folgenden verwendet, um die Datenabh¨angigkeiten in Programmen mit den obigen Eigenschaften zu erfassen Skalare Variablen k¨onnen als einelementige Arrays angesehen werden Der Index einer zu schreibenden Variablen in einer An-weisung sowie die Indizes der dabei gelesenen Variablen k¨onnen von Schleifenva-riablen abh¨angen Diese Abh¨angigkeiten k¨onnen als Punkte in einem ganzzahligen mehrdimensionalen Raum angesehen werden Man erh¨alt somit eine geometrische Repr¨asentation

Zur Definition eines ADDG wird von der folgenden Anweisung s ausgegangen:

s : v[ fi1([k1, ,k d ])], ,[ f in ([k1, ,k d])]

= exp( ,u[ f j1([k1, ,k d ])], ,u[ f jm ([k1, ,k d ])], );

Die Anweisung s wird f¨ur verschiedene Iterationen berechnet, wobei diese durch

Elemente in dem sog Iterationsbereich D gegeben sind Der Iterationsbereich D :=

{k = [k1, ,k d ]} definiert, f¨ur welche Belegungen von Schleifenvariablen k1, ,k d

die Anweisung ausgef¨uhrt wird Aus dem Iterationsbereich l¨asst sich der sog Defi-nitionsbereich Wveiner Arrayvariablen v definieren:

Definition 7.1.2 (Definitionsbereich) Der Definitionsbereich Wveiner Variable v

in der Anweisung s mit Iterationsbereich D ist die Menge der Belegungen der Indizes [i1, ,i n ], d h.

Wv:= [i1, ,i n ] |



n



r=1

i r = f ir ([k1, ,k d])

∧ [k1, ,k d ] ∈ D

(

Analog l¨asst sich der sog Operandenbereich R ueiner in Anweisung s verwendeten Variablen u definieren

Definition 7.1.3 (Operandenbereich) Der Operandenbereich Rueiner Variablen u

in der Anweisung s mit Iterationsbereich D ist die Menge der Belegungen der Indizes [ j1, , j m ], d h.

Ru:= [ j1, , j m ] |

 n



r=1

j r = f jr ([k1, ,k d])

∧ [k1, ,k d ] ∈ D

(

Schließlich kann mit Hilfe der Iterations-, Definitions- und Operandenbereiche eine

sog Abh¨angigkeitsabbildung Mv,uder Variablen v und u in Anweisung s definiert werden:

Definition 7.1.4 (Abh¨angigkeitsabbildung) F¨ur eine Anweisung s l¨asst sich eine

Abh¨angigkeitsabbildung M v ,u , welche die Abh¨angigkeit der Variable v von der Va-riablen u beschreibt, wie folgt berechnen:

Mv,u:= [i1, ,i n ] → [ j1, , j m ] |

 n



r=1

i r = f ir ([k1, ,k d])

∧



n



r=1

j r = f jr ([k1, ,k d])

∧ [k1, ,k d ] ∈ D

(

Beispiel 7.1.11 F¨ur die Anweisung s4 in Programm Programm 1 aus dem Beispiel 7.1.10 ergibt sich der Iterationsbereich D zu:

D = {[k] | 10 ≤ k < 266 ∧ k ∈ Z}

Der Definitionsbereich f¨ur Variable tmp3 und die Operandenbereiche f¨ur die Varia-blen a und tmp2 ergeben sich zu:

Wtmp3 = {[d] | d = k − 10 ∧ k ∈ D}

Ra= {[d] | d = 2 · k − 19 ∧ k ∈ D}

Rtmp2 = {[d] | d = k ∧ k ∈ D}

Hieraus ergeben sich die Abh¨angigkeitsabbildungen Mtmp3,aund Mtmp3,tmp2zu:

Mtmp3,a= {[d1] → [d2] | d1= k − 10 ∧ d2= 2 · k − 19 ∧ k ∈ D}

Mtmp3,tmp2 = {[d1] → [d2] | d1= k − 10 ∧ d2= k ∧ k ∈ D}

Eine Datenabh¨angigkeit zwischen Anweisung s1 und s2 besteht, wenn s1 Va-riablenwerte schreibt, die in Anweisung s2gelesen werden, d h., wenn s1den

De-finitionsbereich Wv besitzt und Anweisung s2 den Operandenbereich Rv und gilt:

Wv∩ Rv= ∅ Die Menge an Datenabh¨angigkeiten kann als

Array-Datenabh¨angig-keitsgraph (ADDG) repr¨asentiert werden

Definition 7.1.5 (ADDG) Ein ADDG ist ein gerichteter Graph G = (V,E), wobei die Knoten die Variablen und Operationen eines Programms repr¨asentieren Die Kanten e ∈ E stellen Datenabh¨angigkeiten dar Kanten mit Operationen als Quell-knoten werden mit der Position des jeweiligen Operanden (Senke) und Kanten mit Variablen als Quellknoten werden mit der jeweiliger Anweisung im Programm be-schriftet.

W¨ahrend Datenabh¨angigkeitsgraphen in Compilern verwendet werden, um Da-tenabh¨angigkeiten von Operationen zu modellieren, werden in ADDGs die Abh¨an-gigkeiten von vielen Werten, die in einem Array gespeichert sind, modelliert Die Datenabh¨angigkeitskanten in ADDGs sind dabei r¨uckw¨arts gerichtet F¨ur die beiden Programme aus Beispiel 7.1.10, sind die ADDGs in Abb 7.7 zu sehen Man sieht, dass die Funktion f nicht interpretiert wird

Eine Variable v heißt im Folgenden

• interne Variable, fallsWv=Rvgilt, d h jeder produzierte Wert auch konsu-miert wurde

• Eingabevariable, fallsWv= ∅ ist, d h kein Element produziert wurde.

• Ausgabevariable, fallsRv⊂ Wv gilt, d h nicht alle produzierten Werte auch konsumiert wurden

Beispiel 7.1.12 Es wird wiederum das Programm 1 aus Beispiel 7.1.10 betrachtet.

Die Variablen a und b sind Eingabevariablen und Variable c ist eine Ausgabevariable Die Variablen tmp1, tmp2 und tmp3 sind interne Variablen

Neben der Abh¨angigkeitsabbildung aus Definition 7.1.4, die sich direkt aus den Anweisungen ablesen l¨asst, k¨onnen Datenabh¨angigkeiten auch ¨uber mehrere

Varia-blen hinweg als sog transitive Abh¨angigkeitsabbildung definiert werden.

Definition 7.1.6 (Transitive Abh¨angigkeitsabbildung) Sei v0,v1, ,v n  ein Pfad

im ADDG beginnend an Variablenknoten v0und endend in Variablenknoten v n mit

n ≥ 0 Die transitive Abh¨angigkeitsabbildung M ∗

v0,v n ergibt sich zu:

M v ∗0,v n:=

⎧

⎨

⎩

I (Die Identit¨at) f¨ur n= 0

M v0,v1◦ M v1,v2◦ ··· ◦ M v n −1 ,v n sonst Dabei ist ◦ die Konkatenation f¨ur zwei Relationen, d h x → z ∈ F ◦ G ⇔ ∃y : x →

y ∈ F ∧ y → z ∈ G.

Die transitive Abh¨angigkeitsabbildung von einer Ausgabevariable zu einer

Ein-gabevariable wird als Ausgabe-zu-Eingabe-Abbildung bezeichnet Die Menge der

Ausgabe-zu-Eingabe-Abbildungen definiert den Datenfluss des Programms