Probleme und Lösungskonzepte für die Transformation der Programmiersprache 370-Assembler

Zusammenfassung

Die Transformation von Assembler in eine 3. Generations-Sprache (3GL) hat eine sehr große Spannbreite von Problemen zu berücksichtigen. Beispielhaft werden die Problembereiche dynamische Codemodifikation, Typabschätzung von Variablen, und Erkennung von Tabellen- und Zeichenketten-Verarbeitung diskutiert. Die vorgestellten Lösungsansätze werden in ihrer Tragfähigkeit beleuchtet und mit anderen Lösungsansätzen verglichen.

Eine Gegenüberstellung der unterschiedlichen Sprachfeatures von Assember und einer typischen 3GL gibt einen ersten Eindruck von dem großen semantischen Abstand der beiden Sprachebenen:

Ein Beispiel für eine einfache 1:1-Transformationen, bei der sich in der Zielsprache ein analoges Konstrukt bilden lässt, ist

$$\begin{array}{l} \quad \quad \quad \quad \quad \quad \quad AP\quad FLD,\,SUM\quad addiere\,SUM\,auf\,FLD \\ wird\,in\,PLI\,zu\quad FLD\;: = \;FLD + SUM\quad \\ \end{array}$$

Aber meistens geht es schwieriger zu:

$$\begin{array}{l} L\quad {\kern 1pt} \quad \quad R15, = V(UPB112)\quad Zuweisung\,der\,Adresse\,UPB112\,nach\,R15 \\ BALR\quad R14,\,R15\quad \quad \quad \quad \quad Call\,auf\,die\,in\,{\mathop{\rm R}\nolimits} 15\,enthaltenen\,Adresse \\ \end{array}$$

ist eine typische Sequenz aus einem Anwendungsprogramm, die als CALL UPB112 interpretiert werden muß. Während die folgende Sequenz aus einem Betriebssytem-Makro

$$\begin{array}{l} L\quad \quad \quad R15,\,XYZ\quad \quad \quad \quad Zuweisung\,von\,XYZ\,nach\,R15 \\ BALR\quad R14,\,R15\quad \quad \quad \quad Call\,auf\,die\,in\,R15\,enthaltenen\,Adresse \\ \end{array}$$

in der Regel nicht mehr interpretierbar ist, weil über den Inhalt von XYZ nichts mehr ausgesagt werden kann.

Die erste Sequenz kann auch nur dann maschinell als CALL UPB112 interpretiert werden, wenn R15 evaluiert wird, d..h. über eine statische Datenfluß-Analyse der mögliche Inhalt von R15 bestimmt wird:

Diese Datenfluß-Analyse ist relativ aufwendig (sowohl was ihre Implementierung als auch was die Performance zur Laufzeit betrifft) und fuhrt nur deswegen zum Ziel, weil ein üblicher Stil in der kommerziellen Programmierung ist, die beiden Zeilen direkt hintereinander zu schreiben — während in der Systemprograrnmierung zum Stil gehört, die Adresse an irgendeiner Stelle nach XYZ zu laden. Es ist fast aussichtslos, XYZ zu evaluieren — jede Kontrollflußverzweigung macht es unwahrscheinlicher, daß genau 1 Quelle für XYZ bestimmt werden kann.

Der BALR könnte in der Sprache PL1 auch in ein “CALL LABXYZ” transformiert werden, mit LABXYZ als Label-Variable (eine Variable, der man Labels wie UPB112 zuweisen kann), in C wäre LABXYZ ein Function-Pointer. Das ist aber nicht Sinn einer Assembler-Transformation — die Sprachebene wird nicht wirklich verlassen. Der Fortschritt der 3. Generation-Sprachen gegenüber Assembler bestand u.a. gerade darin, die Freiheitsgrade des Assembler einzuschränken und damit mehr semantische Klarheit in den Programmcode zu bringen. In der Anweisung

$$BALR\quad R14,\,R15$$

ist Register 15 eine Variable (man könnte sagen: 1 Freiheitsgrad). Um zu bestimmen, wohin der Kontrollfluß verzweigt, muß der Inhalt von Register 15 bestimmt werden. Wohingegen in

$$\begin{array}{l} \quad \quad \quad BAL\quad R14,\,UBP112 \\ oder\quad CALL\,UPB112 \\ \end{array}$$

kein Freiheitsgrad mehr enthalten ist, der Kontrollfluß verzweigt zur Prozedur UPB112, die semantische Aussage des Programmcodes ist eindeutig.

Aus diesem kleinen Beispiel lassen sich bereits einige vorläufige Schlußfolgerungen ziehen, die in den folgenden Abschnitten noch vertieft werden:

• wie schwierig die automatische Transformation eines konkreten Programms ist, hängt weniger vom verwendeten Befehlssatz ab als davon, wie weit die Freiheitsgrade, die dieser Befehlssatz erlaubt, in dem Programm ausgenutzt wurden

• der Grad der Automatisierung hängt damit vom Programmierstil ab

• um einen Freiheitsgrad deterministisch einzuschränken, ist meist eine Datenfluß-Analyse notwendig

• erst als Ergebnis der Datenfluß-Analyse stellt sich heraus, ob die konkrete Assemblerformulierung auf 3GL-Niveau transformiert werden kann oder nicht.

Im folgenden werden einige grundlegende Probleme und Lösungsansätze für die Assemblertransformation vorgestellt. Diese sind in einem Tool mit Namen REASMQEN verwirklicht. Die Erfahrungen mit REASMQEN beleuchten die Tragfähigkeit und die Grenzen dieser Lösungsansätze.