Download - Design und Implementierung einer Binding Time Analyse für C

Integrierte Schaltungen und SystemeProf. Dr.-Ing. Sorin A. Huss

Design und Implementierung einer Binding Time Analyse für C

Diplomarbeit

von

Daniel Kutzmann


Übersicht

• Einleitung• Partielle Evaluation• Binding Time Analyse• Die Implementierung• Verzweigungen und Pointer• Switch Statement• Weitere Analyseprobleme• Zusammenfassung

EinleitungPartielle EvaluationBinding Time AnalyseDie Implementierung Binding Time Phase Transformation Ph.Verzw. & PointerSwitch StatementWeitere AnalysenZusammenfassung


Einleitung

• Häufiges Problem in der Informatik: Lösen ähnlicher Aufgaben– entweder mit einem generischen

Programm,– oder mit vielen speziellen

Programmen.



• Generisches Programm– Vorteil

• Es muss nur ein Programm entwickelt werden (Zeitersparnis).

• Wird mit Parametern an Aufgabe angepasst

– Nachteil• Meist langsamer als ein spezielles Programm

• Spezielles Programm– Vorteil

• Schnell und klein

– Nachteil• Nur für eine Aufgabe einsetzbar• Deswegen müssen viele Programme entwickelt werden



• Generische Programme sind nur bei genügend Ressourcen möglich– Ressourcen sind in eingebetteten

Systemen meist knapp– Trotzdem soll hier generisch

programmiert werden

• Lösung: Partielle Evaluation– Automatisches spezialisieren eines

generischen Programms



Partielle Evaluation

• Ist eine Technik zur Programmoptimierung

• Folgende Idee der Mathematik steht dahinter– Eine Funktion mit 2 Parametern

„spezialisieren“ indem man ein Parameter festhält.

• Bsp f(x,y)=xy wird zu f(x)=x2 bei y=2

– Projektion der Funktion



• Bei der partiellen Evaluierung werden statt Funktionen Programmtexte benutzt.

• Ein partieller Evaluator erstellt aus einem Programm p[in1,in2] und einem Teil seiner Eingabedaten (in1) ein spezialisiertes Programm pin1

• pin1 hat als Eingabe dann nur noch in2



Die Funktionalität wird dadurch nicht verändert:



• Das spezialisierte Programm wird in 2 Phasen erstellt– Zunächst werden die

Transformationen der einzelnen Programmteile festgelegt

• Kann dieser Teil ausgewertet werden oder nicht?

• Dazu müssen die tatsächlichen Werte der Variablen nicht bekannt sein

– Danach wird mit dieser Information das Programm spezialisiert



Binding Time Analyse

• Ihre Aufgabe: Finde heraus, welche Konstrukte schon während der Spezialisierung berechnet werden können!– Dies sind die Konstrukte, die nur von bekannten

(statischen) Werten abhängen.– Hängt ein Konstrukt auch von unbekannten

(dynamischen) Werten ab, so muss es residualisiert werden.

– Die Partitionierung von globalen Variablen und den Parametern der Startfunktion in statisch und dynamisch wird vom Benutzer vorgegeben



• Beispiel: size, u sind statisch, v ist dynamisch

• size= 5 u=[1,5,8,7,2]

Binding Time Markierungen Residualprogramm



Bereits existierende BTAs

• Es gibt zwei partielle Evaluatoren für C: C-Mix & Tempo– Beide haben natürlich auch eine

BTA– Diese BTAs unterscheiden sich

deutlich

• Wenn es bereits BTAs für C gibt, warum dann eine neue entwickeln?



• Beide BTAs „verstehen“ nur einen kleinen Teil der C Syntax– Zu analysierende Programme

müssen vorher vereinfacht werden– Das Residualprogramm

unterscheidet sich sehr stark von Original

• C-Mix ist relativ „ungenau“– Nicht Programmpunkt abhängig– Monovariant



• Tempo ist hier besser...– Flow sensitiv

• Also BTs abhängig vom Programmpunkt

– Context sensitiv• Polyvariante Analyse von Funktionen

– Use sensitiv• Variablendefinitionen können gleichzeitig

ausgewertet und residualisiert werden

• ...aber es kann nicht alles Analysieren– Versteht keine Switch Statements– Ungenau bei Structs– ...



Die Implementierung

• Die erstellte Implementierung benutzt den selben Ansatz wie die BTA von Tempo, dieser wird– erweitert, so dass annähernd die

komplette C Syntax analysiert werden kann

– verbessert, so dass die Analyseergebnisse genauer sind

• Weniger Überabschätzungen



• Die BTs werden mittels abstrakter Interpretation berechnet– Interpretieren des Programms über

die abstrakten Werte statisch/dynamisch

– Abstrakter Speicher wird durch einen Zustand (State) repräsentiert

– Ergebnis wird außerdem am Konstrukt gespeichert



• Analyse wird in 2 Phasen durchgeführt– Binding Time Phase (vorwärts)

• Berechnet ob ein Konstrukt nur von statischen Werten abhängt (dann ist es statisch) oder auch von dynamischen (dann ist es dynamisch).

– Transformation Phase (rückwärts)• Berechnet ob ein Konstrukt während der

Spezialisierung ausgewertet und/oder residualisiert wird

• Dies hängt natürlich von der BT ab, aber zusätzlich noch von den Kontexten der Variablenbenutzung und dem Typ der Variablen (liftable?)



Binding Time Phase

• Ein Konstrukt bekommt hier immer eines von zwei Werten– Static: Wenn das Konstrukt nur von

statischen Werten abhängt– Dynamic: Wenn das Konstrukt auch

von dynamischen Werten abhängt

• In BTState wird der aktuelle Zustand gespeichert



int plus(int a, b, c) { int res; res= a + b; res= res + c; return res; res=2;}

BTState={(a,static),(b,static),(c,dynamic)}




BTState={(a,static),(b,static),(c,dynamic)}BTState={(a,static),(b,static),(c,dynamic)}




BTState={(a,static),(b,static),(c,dynamic)}




BTState={(a,static),(b,static),(c,dynamic) } ,(res,static)}




BTState={(a,static),(b,static),(c,dynamic), (res,static)}




BTState={(a,static),(b,static),(c,dynamic), (res,static)}BTState={(a,static),(b,static),(c,dynamic), (res,static)}




BTState={(a,static),(b,static),(c,dynamic), (res,static) }(res,dynamic)




BTState={(a,static),(b,static),(c,dynamic), (res,dynamic)}



Transformation Phase• Hier bekommt jedes Konstrukt eines der

folgenden Werte– Bottom: Dieses Konstrukt wird nicht benutzt (z.B.

toter Code)– Evaluate: Dieses Konstrukt wird ausgewertet– Residualize: Dieses Konstrukt wird residualisiert– Eval&Res: Dieses Konstrukt wird ausgewertet und

residualisiert

• Eine globale Variable tr gibt die aktuelle Transformation an

• In TrState werden die Transformations der Benutzungen einer Variablen seit ihrer letzten Definition gespeichert



int plus(int a, b, c) { int res; res= a + b; res= res + c; return res; res= 2;}


TrState={}tr=Bottom

{(res,Bottom)}





TrState={(res,Bottom)}tr=Bottom





TrState={(res,Bottom)}tr=BottomResidualize





TrState={(res,Bottom)}tr=Residualize

{(res,Residualize)}





TrState={(res,Residualize)}tr=Residualize





TrState={(res,Residualize)}tr=Residualize

{}





TrState={}tr=Residualize





TrState={}tr=Residualize

{(res,Evaluate)}





TrState={(res,Evaluate),(c,Residualize)}tr=Residualize





TrState={(res,Evaluate),(c,Residualize)}tr=ResidualizeEvaluate

{(c,Residualize)}





TrState={(c,Residualize)}tr=Evaluate



Verzweigungen und Pointer

• Die bisher gezeigten Konstrukte waren relativ einfach zu analysieren. Verzweigungen und Pointer werfen allerdings neue Fragen auf– Verzweigungen: Welche BT hat eine

Variable nach einem If Statement? Wovon hängt die BT hier ab?

– Pointer:Wie wird der Pointer benutzt? Wenn er dereferenziert wird, ist dann bekannt welche Variable benutzt wird? Zu welchem Zeitpunkt ist dies bekannt?



If Statement

• Eine Möglichkeit wäre es, nach einem If Statement zwei Programmstränge zu bearbeiten

• Diese BTA macht dies nicht– Sie vereinigt die zwei Stränge nach

einem If– Variablen die während der Partiellen

Evaluation bekannt sind, sollen dabei statisch bleiben



if (Static_Expr) { a= Static_Expr; b= Static_Expr;}else { a= Static_Expr; b= Dynamic_Expr;}

BTState={(a,dynamic),(b,static)}


BTState={(a,static),(b,static)}


BTState={(a,static),(b,dynamic)}

BTState= ?BTState={(a,static),(b,dynamic)}

Was ist zum Zeitpunkt der Partiellen Evaluation bekannt?



if (Dynamic_Expr) { a= Static_Expr; b= Static_Expr;}else { a= Static_Expr; b= Dynamic_Expr;}



BTState={(a,static),(b,static)}


BTState={(a,static),(b,dynamic)}

BTState= ?BTState={(a,dynamic),(b,dynamic)}

Was ist zum Zeitpunkt der Partiellen Evaluation bekannt?



Pointer

• Häufig interessiert in der BTA nicht der Wert des Pointers, sondern die Variablen auf die der Pointer zeigt

• Die BTA weiß nichts über den tatsächlichen Wert eines Pointers– Die Information, worauf ein Pointer zeigt,

ist allerdings für die Analyse zwingend notwendig

– Deswegen muss diese Information noch vor der BTA berechnet werden



• Diese Berechnung ist Aufgabe der UseDef Analyse– Sie errechnet für jedes Konstrukt welche

Variablen dort benutzt bzw. definiert werden– Diese Berechnungen sind nicht immer

eindeutig. Es werden also alle möglicherweise benutzen und definierten Variablen berechnet

• Die Qualität dieser Analyse ist entscheidend für die Qualität der BTA– Peac benutzt einen gegenüber bisherigen

Analysen verbesserten Algorithmus. Die Ergebnisse stehen der BTA zur Verfügung



int i,j *p;p= &i;*p=2; (p -> i)

int i,j *p;if (static) p= &i;else p= &j; *p=2; (p -> i,j)

BTState={(i,dynamic),(j,static)}

Zugewiesene Variable während BTA bekannt!

BTState={(i,static),(j,static)}

BTState={(i,dynamic),(j,static)}Zugewiesene Variable während BTA unbekannt aber während Partieller Evaluation bekannt!

BTState={(i,dynamic),(j,static)}



int i,j *p;if (dynamic) p= &i;else p= &j; *p=2; (p -> i,j)

BTState={(i,dynamic),(j,static)}Zugewiesene Variable während BTA unbekannt und während Partieller Evaluation unbekannt!

BTState={(i,dynamic),(j,dynamic)}



Switch Statement

• Bisher gab es keine Programmpunkt abhängige Analyse für Switchs

• In dieser Arbeit wurde eine Analyse dafür entwickelt– Relativ komplex durch die Möglichkeit des

breaks

• Die wichtige Frage ist immer: Auf welchem Weg kann ich an diesen Programmpunkt kommen?– Welcher State muss dann dort gelten?



switch (x) { case 1: ... break; case 2: ... if(y) break; case 3: ... default: ...}

Vom switch ist ein Sprung zu jedem case möglich

Bei einem case mit unbedingtem break ist der Kontrollfluss eindeutig

Bei einem case mit bedingtem break gibt es zwei Möglichkeiten

Bei einem case ohne break ist der Kontrollfluss wieder eindeutig



switch (statisch) { case 1: ... break; case 2: ... if(y) break; case 3: ... default: ...}

Welcher State ist nun an den cases aktuell?

• Dies hängt davon ab, wie das case erreicht werden kann

• Ein case kann immer vom Anfang des switchs erreicht werden

• Am case muss der aktuelle State mit dem State vom Beginn des switchs vereinigt werden

• Ein case kann vom vorherigen case erreicht werden, falls kein break davor steht

• Dies geschieht automatisch durch die Vereinigung. Ein break leert den aktuellen State. Dadurch wir erreicht, dass in diesem Fall nur der State vom Beginn des switchs eine Rolle spielt



switch (statisch) { case 1: ... break; case 2: ... if(y) break; case 3: ... default: ...}

Und welcher nach dem Switch?

• Auch hier müssen alle möglichen Pfade vom Beginn zum Ende des switchs beachtet werden

• Das Ende wird entweder nach dem letzten case oder von einem break erreicht.

• Jeder der dort aktuellen States kann auch am Ende des switchs gelten

• Deswegen wird bei einem break der dort aktuelle State aufgesammelt

• und dann am Ende mit dem dort aktuellen State vereinigt

•Hat das switch kein default, kann es sein, dass nichts aus dem switch ausgeführt wird

•In diesem Fall muss auch der State vom Anfang des switchs mit dem am Ende vereinigt werden



switch (dynamisch) { case 1: ... break; case 2: ... if(y) break; case 3: ... default: ...}

Was ist bei einem dynamischen switch?

• Hier ist auch während des Residualisierens nicht klar, welcher Pfad genommen wird

•An jedem case müssen also alle Variablen des switchs, die bis dahin definiert worden sein können, dynamisch werden

• das sind alle Variablen, die seit dem letzten break definiert wurden

•Am Ende des switchs müssen alle Variablen die irgendwo im switch definiert wurden dynamisch



Weitere Analyseprobleme

• Ebenfalls umfangreiche Überlegungen erfordert die Analyse von Funktionen und Schleifen

• Hier soll nur kurz auf die dabei entstehenden Probleme hingewiesen werden



Funktionen• Können mehrere Return Statements haben

– Wird ähnlich behandelt wie breaks in switchs

• Können Seiteneffekte haben– Es muss zwischen BT des Returns und BT der

Seiteneffekte unterschieden werden

• Können in unterschiedlichem BT Kontext vorkommen– Jede Funktion muss bei einem neuen Kontext

neu analysiert werden– Jedes Konstrukt kann mehr als eine BT haben



Schleifen

• Schleifen werden möglicherweise mehrmals durchlaufen– Eine Variablendefinition unterhalb des

aktuellen Programmpunkts kann das aktuelle Konstrukt beeinflussen

• Auch hier gibt es breaks und continues– Muss wieder ähnlich behandelt werden

wie beim switch



Zusammenfassung

• Es wurde eine Binding Time Analyse für C implementiert

• Anders als herkömmliche Analysen versteht sie nahezu die vollständige C Syntax

• Erstmals können Switch Statements flow sensitiv analysiert werden

• Auch die Programmpunkt abhängige Analyse von Structs ist ein Novum



Vielen Dank für Ihre

Aufmerksamkeit


Download - Design und Implementierung einer Binding Time Analyse für C

Top Related