DE19617842A1

DE19617842A1 - Verfahren zur Codetransformation

Info

Publication number: DE19617842A1
Application number: DE19617842A
Authority: DE
Inventors: Manfred Dr Stadel
Original assignee: Wincor Nixdorf International GmbH
Current assignee: Wincor Nixdorf International GmbH
Priority date: 1996-05-03
Filing date: 1996-05-03
Publication date: 1997-11-13
Also published as: WO1997042574A1

Description

Die Erfindung betrifft ein Verfahren zur Transformation von hardwarespezifischem Programmcode in auf einer anderen Hard ware mit einer unterschiedlichen Rechnerarchitektur ablauf fähigen Programmcode.

Die Architektur eines Rechners ist vor allem durch die grund legende Struktur seines Prozessors, also durch die Anzahl und Größe der Register, die verwendeten Datentypen, die unter stützten arithmetischen und logischen Operationen usw., ge kennzeichnet. Bei heutigen Hochleistungsrechnern, z. B. bei Parallelrechnern, kommt dabei auch oft nicht nur ein einzel ner Prozessor, sondern ein ganzer Satz meist untereinander gleichartiger Prozessoren zum Einsatz. In der Regel wird die Architekturdefinition eines Rechners durch seinen Befehlssatz beschrieben, der alle elementaren Instruktionen des zugrundeliegenden Prozessors umfaßt.

Viele der heute eingesetzten Rechner besitzen sog. CISC- Prozessoren, die über einen umfangreichen Befehlssatz mit teilweise sehr komplexen und leistungsfähigen Einzelbefehlen verfügen (CISC = Complex Instruction Set Computer). Dabei treten auch oft Befehle auf, die zeitaufwendige Speicher- Speicher-Operationen durchführen. Außerdem weisen die In struktionen in der Regel untereinander deutlich unterschied liche Längen und Ausführungszeiten auf.

In zunehmendem Maße kommen jedoch in modernen Computern auch sog. RISC-Prozessoren (RISC = Reduced Instruction Set Compu ter) zum Einsatz. Ihr Befehlssatz ist in bezug auf Anzahl, Komplexität und Leistungsfähigkeit der einzelnen Instruktio nen gegenüber einem CISC-Befehlssatz deutlich reduziert und alle arithmetischen und logischen Operationen werden ohne Be teiligung des Speichers von Register zu Register durchge führt. Als Speicherzugriffe sind nur einfache Lade-/Speicher- Operationen zugelassen und alle Instruktionen sind in der Re gel gleich lang.

Zu Zeiten, als Prozessoren wesentlich schneller als Speicher bausteine waren, hatten CISC-Prozessoren meist deutliche Vor teile gegenüber RISC-Prozessoren, da sie im Schnitt weniger Instruktionen benötigen, um die gleiche Aufgabe auszuführen. Heutige Halbleiterspeicher sind jedoch schnell genug, um War tezeiten für den Prozessor weitgehend zu vermeiden. Außerdem spielt der für RISC-Code gegenüber äquivalentem CISC-Code im Schnitt höhere Speicherbedarf keine bedeutende Rolle mehr. Dadurch kommen zunehmend die Herstellungs- und vor allem Per formance-Vorteile von Rechnern mit RISC-Architektur zum tra gen.

Die zunehmenden Anforderungen an das Leistungsvermögen von Rechenanlagen jeder Größenordnung machen vielfach den Wechsel zu neuen Computergenerationen, z. B. zu RISC-Computern, erfor derlich. Um jedoch die höhere Leistungsfähigkeit dieser Rech ner ausnützen zu können, ohne dabei auf die bereits vorhande ne, umfangreiche und wertvolle Softwarebasis verzichten zu müssen, ist eine Transformation der vorhandenen Programme für Betriebssysteme, Anwendungen, Sprachcompiler etc. nötig. Die im Quellcode einer standardisierten Hochsprache vorliegenden Teile dieser Programme können meist durch einfache Neucompi lierung auf dem im folgenden als Zielhardware bezeichneten neuen Rechner transformiert werden. Dagegen machen die hard wareabhängigen, z. B. in Assemblersprache geschriebenen Pro grammteile eine wesentlich aufwendigere Transformation erfor derlich, die zumindest weitgehend mit Hilfe von spezieller Transformationssoftware automatisiert sein muß, um unverhält nismäßigen Aufwand an Zeit und Kosten zu vermeiden.

Die Verwendung von Emulationsprogrammen, die die Ursprungs hardware auf der Zielhardware simulieren, kommt in der Regel wegen der vergleichsweise schlechten Performance der Software unter einer Emulation höchstens für nicht zeitkritische Pro grammteile in Frage.

Bisher verwendete Programme zur Transformation von für eine Ursprungshardware geschriebenem Programmcode in auf einer Zielhardware mit einer unterschiedlichen Rechnerarchitektur ablauffähigen Programmcode arbeiten in der Regel nach einer der folgenden Transformationsmethoden:
Ausgangspunkt bei einer statischen Objektcodetransformation - z. B. nach WO 92/15939 - ist ein als Objektcode für die Ur sprungshardware vorliegender Programmcode, für den die Be schränkung gilt, daß bereits während der Transformation alle Befehlsfolgen und Sprungziele vollständig bekannt und defi niert sein müssen. Berechnete, nicht-symbolische Sprünge und Adressierungen (z. B. Adressierung anhand von Basisregistern bei IBM System/370-Rechnern) oder auch Befehle, die ein be liebiges, z. B. erst beim Programmablauf erzeugtes oder einge lesenes Bitmuster als Befehlsfolge interpretieren, sind daher zumindest nicht in voller Allgemeinheit transformierbar. Au ßerdem werden bei der statischen Objektcodetransformation Kriterien benötigt, mit denen Befehle und Daten im Eingangs code gegeneinander abgegrenzt werden können.

Eine Assemblertransformation unterscheidet sich von der o.g. statischen Objektcodetransformation dadurch, daß anstatt von Objektcode mnemonisch angegebener Assemblercode als Quellcode für die Transformation dient, wodurch weitgehend eine klare Unterscheidung von Befehlen und Daten sowie von symbolischen und absoluten Sprüngen erreicht wird.

Beide bisher genannten Transformationsverfahren erzeugen durch Übersetzung des jeweiligen Programmcodes für eine Ur sprungshardware entsprechenden Programmcode für eine gegebene Zielhardware, der darauf jedoch erst nach der vollständigen Transformation aller Teile des Codes uneingeschränkt ausführ bar ist.

Bei einer dynamischen Objektcodetransformation, wie sie z. B. aus C.May: "MIMIC: A FAST SYSTEM/370 SIMULATOR", SIGPLAN 22, 7, 1987 bekannt ist, handelt es sich dagegen um eine Mischung aus statischer Objektcodetransformation und Emulation. Dabei wird ein Programm erst während seiner Ausführung durch Emula tion auf der Zielhardware nach und nach transformiert. Bei berechneten Sprüngen wird dynamisch anhand einer Adreßumsetz tabelle überprüft, ob zu dem errechneten Sprungziel bereits transformierter Code für die Zielhardware vorliegt. Ist dies der Fall, so wird dieser Code direkt angesprungen. Anderen falls wird der am Sprungziel vorgefundene Code für die Ur sprungshardware zunächst dynamisch in Objektcode für die Zielhardware transformiert und dann ausgeführt. Die dynami sche Objektcodetransformation benötigt daher keine zusätzli chen Informationen zur Unterscheidung von Befehlen und Daten im Ausgangscode. Im Laufe der Zeit werden automatisch die Be fehle transformiert, während die Daten unverändert übrigblei ben. Befehle, die nicht eindeutig auf äquivalente Befehle oder Befehlsfolgen der Zielhardware abgebildet werden können werden durch Emulation abgearbeitet.

Anders als bei den o.g. statischen Codetransformationen, kön nen berechnete Sprünge und Adressierungen, sowie auf der Zielhardware unbekannte Befehle bei einer dynamischen Ob jektcodetransformation behandelt werden. Von Nachteil ist je doch, daß die Transformation erst während des Programmablau fes erfolgt, wodurch sich deutliche Performance-Verluste er geben können, bis zumindest die zeitkritischen oder häufig durchlaufenen Programmteile als transformierter Code vorlie gen. Auch die nötige Abspeicherung von neu transformiertem Code während der Programmausführung sowie die z. B. bei Sprün gen nötigen Prüfungen auf Vorhandensein von bereits transfor miertem Code am jeweiligen Sprungziel kosten zusätzliche Zeit.

Sowohl die bekannten statischen als auch die dynamischen Ver fahren zu Codetransformation setzen außerdem beschränkend voraus, daß der zu transformierende Code keine sich beim Ab lauf selbst modifizierenden Programmteile enthält.

Die vorliegenden Erfindung stellt sich die Aufgabe ein gegen über den bekannten statischen und dynamischen Transformati onsmethoden verbessertes Verfahren zur Transformation von für eine Ursprungshardware geschriebenem Programmcode in auf ei ner Zielhardware mit einer unterschiedlichen Rechnerarchitek tur ablauffähigen Programmcode anzugeben.

Die Aufgabe wird gelöst durch ein Verfahren zur Codetransfor mation, das die im Patentanspruch 1 angegebenen Merkmale auf weist.

Das erfindungsgemäße Verfahren zur Codetransformation verei nigt die Vorteile einer Assemblertransformation mit denen ei ner dynamischen Objektcodetransformation. Es geht von einem als Assemblerquellcode vorliegendem Programmcode für eine Ur sprungshardware aus und wird mit Hilfe eines Assemblers und eines Codetransformators, die vorteilhafterweise in einem Transformationsprogramm zusammengefaßt sind, durchgeführt. Zunächst wird dabei durch den Assembler aus dem Assembler quellcode Objektcode für die Ursprungshardware generiert, in den auch im Assemblerquellcode enthaltene Datenfelder und -konstanten übernommen werden. Durch den Codetransformator wird aus dem Assemblerquellcode entsprechender Objektcode für die Zielhardware sowie eine Adreßumsetztabelle, die die Be ziehung zwischen Adressen im Objektcode für die Ursprungs hardware und den zugehörigen Adressen im Objektcode für die Zielhardware herstellt, generiert. Der auf der Zielhardware ablauffähige Programmcode wird durch Zusammenfassung des Ob jektcodes für die Ursprungshardware, des Objektcodes für die Zielhardware, der Adreßumsetztabelle sowie eines Emulators, der den Objektcode für die Ursprungshardware emulieren kann, gewonnen.

Wesentlich ist dabei, daß sich die im transformierten Ob jektcode verwendeten Adreßbezüge zunächst stets auf den Ob jektcode für die Ursprungshardware beziehen. Adreßbezüge, die auf Befehle verweisen, werden erst beim Ablauf des transfor mierten Programms mit Hilfe der Adreßumsetztabelle in ent sprechende Bezüge auf Adressen im Objektcode für die Ziel hardware umgesetzt. Berechnete Sprünge und Adressierungen sind daher anders als bei bekannten statischen Transformati onsverfahren in voller Allgemeinheit transformierbar. Befehle oder Befehlsfolgen, die erst während der Ausführung des Codes vollständig definiert werden, wie das etwa bei In struktionen, die ein beliebiges, z. B. erst beim Pro grammablauf erzeugtes oder eingelesenes Bitmuster als Be fehlsfolge interpretieren, der Fall ist, werden durch den Codetransformator bei der Generierung des Objektcodes für die Zielhardware in Aufrufe an den den entsprechenden Objektcode für die Ursprungshardware emulierenden Emulator transfor miert. Ebenso werden Befehle und Befehlsfolgen die im Assem blerquellcode nicht als solche, sondern z. B. als Datenkon stanten angegeben sind, in Emulatoraufrufe transformiert. Die weiter oben genannten, bei einer dynamischen Codetrans formation auftretenden Nachteile werden bei dem erfindungsge mäßen Transformationsverfahren vermieden, da die Generierung des auf der Zielhardware ablauffähigen Programmcodes in einem Schritt durch das Transformationsprogramm und nicht erst nach und nach im Zuge mehrerer emulierter Programmläufe des zu transformierenden Codes erfolgt.

Vorteilhafte Aus- und Weiterbildungen des erfindungsgemäßen Verfahrens sind Gegenstand der Unteransprüche.

Nach einer ersten Ausgestaltung des erfindungsgemäßen Verfah rens - Anspruch 2 - wird bei der Codetransformation zumindest eines der Register der Ursprungshardware umkehrbar eindeutig auf ein Register der Zielhardware abgebildet. So ist es z. B. zweckmäßig, zumindest die Register der Ursprungshardware, die im Assemblerquellcode häufig oder für zeitkritische Programm teile benutzt werden, auch im transformierten Programmcode für die Zielhardware durch Register darzustellen, um auf die se Weise kurzen und effektiven Code zu generieren.

Insbesondere wenn die Anzahl der Register entsprechender Größe auf der Zielhardware nicht ausreicht, um damit alle Regi ster der Ursprungshardware und zusätzlich die durch den Emu lator oder als temporäre Register durch den transformierten Objektcode OC2 verwendeten Register darzustellen, wird nach einer zweiten Ausgestaltung der Erfindung - Anspruch 3 - bei der Codetransformation zumindest eines der Register der Ur sprungshardware auf der Zielhardware (M2) durch einen Spei cherbereich nachgebildet wird.

Bei einer weiteren Ausbildung der Erfindung - Anspruch 4 - erfolgen für alle Befehle und Datenfelder im Objektcode der Ursprungshardware jeweils Einträge in der Adreßumsetztabelle, wodurch die auf Befehle verweisenden Adressen im Objektcode der Ursprungshardware auf entsprechende Adressen im transfor mierten Objektcode abgebildet werden, während bei auf Daten verweisenden Adressen das Fehlen von korrespondierendem transformierten Objektcode angezeigt wird. Durch diese alle Codeteile umfassenden Zuordnungsvorschrift wird durch Indi zierung ein einfacher und schneller Zugriff auf die einzelnen Tabelleneinträge erreicht, obwohl der sich daraus ergebende Umfangs der Adreßumsetztabelle eine erhebliche Größe errei chen kann.

Alternativ - Anspruch 5 - können die Einträge in der Adreß umsetztabelle auch nur für die als mögliche Sprung- oder Zu griffsziele relevanten Befehle im Objektcode der Ursprungs hardware erfolgen. Von Vorteil ist dabei die in der Regel deutliche Reduzierung des für die Adreßumsetztabelle benöti gen Speicherbedarfs gegenüber der o.g. Ausgestaltung gemäß Anspruch 4, bei der für alle Befehle und Daten Einträge in die Tabelle erfolgen. Der Zugriff auf Tabelleneinträge erfor dert in diesem Fall jedoch Suchverfahren (z. B. Binärsuche oder Hash-Suche).

Nach einer weiteren Ausgestaltung des erfindungsgemäßen Ver fahrens - Anspruch 6 - wird ein im Assemblerquellcode auftre tender Sprungbefehl mit bekanntem Sprungziel durch den Code transformator in einen entsprechenden Sprungbefehl im Ob jektcode für die Zielhardware transformiert. Dabei ist die Sprungzielangabe im transformierten Objektcode über die Adreßumsetztabelle mit der entsprechenden Sprungzielangabe im Objektcode für die Ursprungshardware verknüpft.

Ein im Assemblerquellcode auftretender Sprungbefehl mit einer erst zur Laufzeit auswertbaren Sprungzielangabe wird dagegen nach einer Weiterbildung der Erfindung - Anspruch 7 - durch den Codetransformator in einen Emulatoraufruf im Objektcode für die Zielhardware transformiert, der bei seiner Ausführung bewirkt, daß der Emulator anhand der dann ausgewerteten Sprungzielangabe und der Adreßumsetztabelle überprüft, ob zum Sprungziel transformierter Objektcode für die Zielhardware existiert. Im Fall der Existenz eines solchen transformierten Objektcodes wird dieser daraufhin direkt angesprungen, wäh rend anderenfalls die eigentliche Emulation des entsprechen den Objektcodes der Ursprungshardware erfolgt. Auf diese Wei se können mit dem erfindungsgemäßen Verfahren zur Codetrans formation im Gegensatz zu bekannten statischen Transformati onsverfahren auch Sprünge mit erst zur Laufzeit bestimmten Sprungzielen, z. B. berechnete Sprünge, behandelt werden.

Bei einer vorteilhaften Weiterbildung der Erfindung zur Be handlung von selbstmodifizierendem Code - Anspruch 8 - trans formiert der Codetransformator jeden im Assemblerquellcode auftretenden Speicherbefehl in Objektcode für die Zielhardwa re, der bei seiner Ausführung die folgenden Schritte durch führt:
Die auf die Ursprungshardware bezogene Speicheradresse wird berechnet und anhand der Adreßumsetztabelle wird geprüft, ob zu dieser Speicheradresse transformierter Objektcode exi stiert. Wenn dies der Fall ist, wird der transformierte Ob jektcode an dieser Stelle durch eine Befehlssequenz zum Auf ruf des Emulators ersetzt, und die Adreßumsetztabelle wird so abgewandelt, daß das Auftreten eines Sprunges in den durch diese Befehlssequenz modifizierten Adreßbereich zu einem Auf ruf des Emulators führt. Andernfalls handelt es sich nicht um eine Selbstmodifizierung von Programmcode. In beiden Fällen wird der sich auf eine Speicheradresse im Adreßbereich der Ursprungshardware beziehende Speicherbefehl ausgeführt. Damit ist mit dem erfindungsgemäßen verfahren zur Codetrans formation die Transformation von selbstmodifizierendem Code möglich, die bisher bei keinem der bekannten verfahren, weder statischer noch dynamischer Art, verfügbar ist. Eine stark einschränkende Forderung an den zu transformierenden Pro grammcode entfällt damit.

Ein alternatives Verfahren zur Behandlung von selbstmodifi zierendem Code - Anspruch 9 - ist anwendbar, falls auf der Zielhardware ein Schreibschutz vorgesehen ist, der zu einer Signalisierung führt, wenn zur Laufzeit des Programmcodes ein Schreibzugriff auf eine auf einen Befehl des Objektcodes der Ursprungshardware verweisende Adresse auftritt. Durch die Si gnalisierung werden dann die folgenden Schritte einleitet:
Der Schreibbefehl auf die Adresse wird ausgeführt und anhand der Adreßumsetztabelle wird geprüft, ob zu dieser Speicheradresse transformierter Objektcode existiert. Wenn dies der Fall ist, wird der transformierte Objektcode an die ser Stelle durch eine Befehlssequenz zum Aufruf des Emulators ersetzt, und die Adreßumsetztabelle wird so abgewandelt, daß das Auftreten eines Sprunges in den durch diese Befehlsse quenz modifizierten Bereich des transformierten Objektcodes zu einem Aufruf des Emulators führt. Von Vorteil ist bei die ser Methode zur Behandlung von selbstmodifizierendem Code, daß nur dann Laufzeiteinbußen entstehen, wenn wirklich eine Modifikation stattfindet.

Eine weitere Ausgestaltung der Erfindung - Anspruch 10 - be zieht sich auf Codetransformationen, bei denen im Assembler quellcode der Ursprungshardware Befehle auftreten, die zur Laufzeit das Bitmuster eines Datenfeldes, gegebenenfalls nach vorheriger Modifikation desselben, dynamisch als Befehl in terpretieren und ausführen, und für die keine entsprechenden Instruktionen im Befehlssatz der Zielhardware existieren. Da bei wird ein derartiger, meist als Execute-Befehl bezeichne ter Befehl bzw. eine derartige Befehlsfolge erfindungsgemäß durch den Codetransformator in einen Emulatoraufruf im trans formierten Objektcode umgesetzt. Bei den bekannten statischen Transformationsverfahren besteht die Möglichkeit, solche in ihrer Wirkung erst zur Laufzeit des Programmcodes festgeleg ten Befehle zu behandeln, dagegen grundsätzlich nicht.

Um eine möglichst hohe Ablaufgeschwindigkeit des transfor mierten Programmcodes zu erreichen, ist es zweckmäßig, zur Laufzeit eine einmal eingeleitete Emulation zu beenden, so bald für den weiteren Programmablauf wieder transformierter Objektcode zur Verfügung steht. So besteht eine erste Mög lichkeit - Anspruch 11 - darin, daß bei einem während einer Emulation zur Laufzeit des Programmcodes auftretendem Sprung befehl anhand der Adreßumsetztabelle geprüft wird, ob zum Sprungziel transformierter Objektcode existiert. Wenn dies der Fall ist, wird unter Beendung der Emulation zum entspre chenden Sprungziel im transformierten Objektcode gesprungen.

Andernfalls wird die Emulation des Objektcodes der Ursprungs hardware beim Sprungziel fortgesetzt.

Bei einer zweiten Variante - Anspruch 12 - wird statt dessen nach jedem während einer Emulation zur Laufzeit des Pro grammcodes abgearbeitetem Befehl anhand der Adreßumsetz tabelle geprüft, ob ein zum darauffolgenden Befehl korrespon dierender, transformierter Objektcode existiert. Wenn dies der Fall ist, wird wiederum unter Beendung der Emulation zur entsprechenden Stelle im transformierten Objektcode gesprun gen. Andernfalls wird die Emulation fortgesetzt.

Im folgenden werden Einzelheiten des Verfahrens zur Code transformation unter Bezugnahme auf Zeichnungen näher erläu tert.

Es zeigt

Fig. 1 eine schematische Darstellung zur Erläuterung des Grundprinzips des Verfahrens zur Codetransformation;

Fig. 2 ein Flußdiagramm zur Generierung des ablauffähigen transformierten Programmcodes;

Fig. 3 schematisch die Verknüpfung der Adreßbereiche von Ursprungs- und Zielhardware anhand der Adreßumsetz tabelle;

Fig. 4 ein Flußdiagramm für die Transformation eines Sprung befehls;

Fig. 5 ein Flußdiagramm für die Behandlung eines Sprungbefehls mit erst zur Laufzeit auswertbarer Sprungzielangabe durch den Emulator;

Fig. 6 ein Flußdiagramm für die Transformation eines Speicher befehls;

Fig. 7 schematisch die Behandlung eines Sprungbefehls bei der Emulation.

Das Grundprinzip des erfindungsgemäßen Verfahrens zur Code transformation ist in Fig. 1 und Fig. 2 schematisch darge stellt. Ein als Assemblerquellcode AC1 für eine Ursprungs hardware M1 vorliegender Programmcode wird mit Hilfe eines auf einem Computer COM ablaufenden Transformationsprogramms TP, das einen Assembler ASS für die Ursprungshardware M1 so wie einen Codetransformator CT enthält, in auf einer Ziel hardware M2 ablauffähigen Programmcode PC2 transformiert. Bei der Transformation erzeugt der Assembler ASS aus dem Assem blerquellcode AC1 nach einer Syntaxanalyse den dazu äquiva lenten Objektcode OC1 für die Ursprungshardware M1, in den auch im Quellcode vorhandene Datenfelder (z. B. Datenkonstan ten) übernommen werden. Der Codetransformator CT generiert aus dem Assemblerquellcode AC1 entsprechenden Objektcode OC2 für die Zielhardware M2 sowie eine Adreßumsetztabelle TTAB, die die Beziehung zwischen Adressen im Objektcode OC1 für die Ursprungshardware M1 und den zugehörigen Adressen im Ob jektcode OC2 für die Zielhardware M2 herstellt. Im auf der Zielhardware M2 ablauffähigen Programmcode PC2 sind der Ob jektcode OC1 für die Ursprungshardware M1 (mit Daten), der Objektcode OC2 (ohne Daten) für die Zielhardware M2, die Adreßumsetztabelle TTAB sowie ein Emulator E, der den Ob jektcode OC1 für die Ursprungshardware M1 emulieren kann, zu sammengefaßt. Die auf der Ursprungshardware vorhandenen Pro zessorregister R_i werden vorteilhafterweise bei der Code transformation umkehrbar eindeutig auf in Anzahl und Größe entsprechende Register r_i der Zielhardware abgebildet. Zu sätzlich dazu auf der Zielhardware vorhandene Register t_i werden zur Laufzeit des transformierten Programmcodes PC2 durch den Emulator E und als temporäre Register durch den transformierten Objektcode OC2 benutzt.

In Fig. 3 ist die Verknüpfung der Adreßbereiche von Ursprungs- und Zielhardware M1 bzw. M2 anhand der Adreßumsetztabelle TTAB beispielhaft für eine Ausgestaltung des Verfahrens, bei der sowohl für Befehle als auch für Daten Eintragungen in die Tabelle TTAB erfolgen, dargestellt. Ein Befehl 1 im Ob jektcode OC1 der Ursprungshardware M1 weist z. B. eine Länge auf, die drei Speicherzellen entspricht, und ist im Ob jektcode OC1 bei Adresse A1 abgelegt. Durch die Adreßumsetz tabelle TTAB wird der Adresse A1 eine Adresse A′1 im Ob jektcode OC2 zugeordnet, bei der der dem Befehl 1 entspre chende Befehl 1′ der Zielhardware M2 abgelegt ist. Einem wei teren Befehl 2 im Objektcode OC1, der dort z. B. ab Adresse A4 abgelegt ist, entspricht im transformierten Objektcode OC2 eine Befehlsfolge aus zwei Instruktionen Befehl 2′ und Befehl 2a′. Ein nächster Befehl 3 wird analog in einen Befehl 3′ im Objektcode OC2 transformiert usw.

Im allgemeinen weisen dabei einander entsprechende Befehle oder Befehlsfolgen unterschiedliche Längen und damit unter schiedlichen Speicherbedarf bei Ursprungs- und Zielhardware M1 bzw. M2 auf. Bei einer Transformation von CISC-Code in Programmcode für einen RISC-Rechner ergibt sich in der Regel wegen der im Schnitt geringeren Leistungsfähigkeit von RISC- Befehlen gegenüber den komplexeren CISC-Instruktionen ein deutlich höherer Speicherbedarf für den transformierten Ob jektcode OC2 als für den entsprechenden CISC-Objektcode OC1, wenn man dabei reine Datendefinitionen im CISC-Objektcode OC1 außer acht läßt. Für z. B. als Datenkonstanten im Objektcode OC1 der Ursprungshardware M1 enthaltenen Datenfelder erfolgen besondere Eintragungen in der Adreßumsetztabelle TTAB, z. B. Nullen, die anzeigen, daß zu den entsprechenden Stellen im Objektcode OC1 kein äquivalenter, transformierter Objektcode OC2 vorhanden ist. Im Programm auftretende Zugriffe auf Daten erfolgen erfindungsgemäß ausschließlich auf den Objektcode OC1 der Ursprungshardware M1 bezogen.

Fig. 4 zeigt anhand eines Flußdiagramms, wie ein im Assembler quellcode AC1 auftretender Sprungbefehl transformiert wird. Handelt es sich um einen Sprungbefehl, dessen Sprungziel schon bei der Transformation bekannt und z. B. im Assembler quellcode anhand einer symbolischen Sprungmarke angegeben ist, so wird er in einen entsprechenden Sprungbefehl mit im Objektcode OC2 für die Zielhardware M2 transformiert. Dabei ist das Sprungziel im transformierten Objektcode OC2 über die Adreßumsetztabelle TTAB mit dem entsprechenden Sprungziel im Objektcode OC1 für die Ursprungshardware M1 verknüpft. Wird das Sprungziel jedoch erst zur Laufzeit des Pro grammcodes, z. B. abhängig von Benutzereingaben, bestimmt, so wird der zu transformierende Sprungbefehl in einen Emulator aufruf im Objektcode OC2 der Zielhardware übersetzt.

In Fig. 5 ist dargestellt, wie ein solcher Sprungbefehl mit erst zur Laufzeit auswertbarer Sprungzielangabe durch den Emulator bearbeitet wird. Ergibt eine Überprüfung des ermit telten Sprungziels anhand der Adreßumsetztabelle TTAB, daß dazu bereits transformierter Objektcode OC2 vorliegt, so wird zu diesem verzweigt. Andernfalls, z. B. wenn die anzuspringen de Befehlsfolge im Assemblerquellcode AC1 nicht mnemonisch, sondern als Definition konstanter Daten spezifiziert und so mit durch den Codetransformator CT nicht als Befehl folge er kannt und transformiert wurde, wird die Emulation des ent sprechenden Objektcodes OC1 der Ursprungshardware weiterge führt.

Auch die Behandlung von selbstmodifizierendem Code ist mög lich. Dazu wird jeder im Assemblerquellcode AC1 auftretende Speicherbefehl in Objektcode OC2 für die Zielhardware, der bei seiner Ausführung die folgenden, in Fig. 6 durch ein Fluß diagramm dargestellten Schritte ausführt, transformiert:
Zunächst wird die auf die Ursprungshardware M1 bezogene Spei cheradresse ADR berechnet. Anhand der Adreßumsetztabelle TTAB wird dann geprüft, ob zur Speicheradresse ADR transformierter Objektcode OC2 existiert. Ist dies der Fall (selbst modifizierender Code), so wird der entsprechende Objektcode OC2 durch eine Befehlssequenz zum Aufruf des Emulators E er setzt, und die Adreßumsetztabelle TTAB wird so abgewandelt, daß das Auftreten eines Sprunges in den durch diese Be fehlssequenz modifizierten Adreßbereich im transformierten Objektcode OC2 zu einem Aufruf des Emulators E führt. Im Bei spiel wird dies durch Eintragen von Nullen (TTAB[ADR+x]=0, für x=0, . . . , L und L=Länge der o.g. Befehlssequenz) erreicht. Der Speicherbefehl zur Speicheradresse ADR wird ausgeführt.

In Fig. 7 ist schematisch die Behandlung eines Sprungbefehls bei der Emulation dargestellt.

Bei der Ausführung des transformierten Programmcodes PC2 auf der Zielhardware werden in der Regel Teile des Programms, z. B. bei selbstmodifizierendem Code, durch den Emulator E ab gearbeitet. Um eine möglichst hohe Ablaufgeschwindigkeit des Programms zu erreichen, ist es jedoch zweckmäßig, die Emula tion möglichst nur auf diejenigen Programmteile zu beschrän ken, zu denen kein transformierter Objektcode OC2 vorliegt. Dazu wird z. B. bei jedem zu emulierenden Sprungbefehl anhand der Sprungzielangabe und der Adreßumsetztabelle TTAB geprüft, ob zur entsprechenden Sprungadresse a transformierter Ob jektcode OC2 vorhanden ist (TTAB[a]=0?). Ist dies der Fall, wird zu der entsprechenden Stelle TTAB[a] im transfor mierten Objektcode OC2 gesprungen und die Emulation beendet. Andernfalls wird die Emulation am Sprungziel a im Objektcode OC1 der Ursprungshardware fortgeführt.

Claims

1. Verfahren zur Transformation von für eine Ursprungshardwa re (M1) geschriebenem Assemblerquellcode (AC1) in auf einer Zielhardware (M2) mit einer unterschiedlichen Rechnerarchi tektur ablauffähigen Programmcode (PC2) mit Hilfe eines As semblers (ASS) und eines Codetransformators (CT), wobei

- durch den Assembler (ASS) aus dem Assemblerquellcode (AC1) Objektcode (OC1) für die Ursprungshardware (M1) generiert wird, in den auch im Assemblerquellcode (AC1) enthaltene Daten übernommen werden;
- durch den Codetransformator (CT) aus dem Assemblerquellcode (AC1) entsprechender Objektcode (OC2) für die Zielhardware (M2) sowie eine Adreßumsetztabelle (TTAB), die die Bezie hung zwischen Adressen im Objektcode (OC1) für die Ur sprungshardware (M1) und den zugehörigen Adressen im Ob jektcode (OC2) für die Zielhardware (M2) herstellt, gene riert werden;
- im auf der Zielhardware (M2) ablauffähigen Programmcode (PC2) der Objektcode (OC1) für die Ursprungshardware (M1), der Objektcode (OC2) für die Zielhardware (M2), die Adreß umsetztabelle (TTAB) sowie ein Emulator (E), der den Ob jektcode (OC1) für die Ursprungshardware (M1) emulieren kann, zusammengefaßt werden;
- sich die im transformierten Objektcode (OC2) verwendeten Adreßbezüge auf den Objektcode (OC1) für die Ursprungshard ware (M1) beziehen und erst beim Ablauf des transformierten Programms (PC2) mit Hilfe der Adreßumsetztabelle (TTAB) in entsprechende Bezüge auf Adressen im Objektcode (OC2) für die Zielhardware (M2) umgesetzt werden, soweit es sich da bei um auf Befehle verweisende Bezüge handelt;
- der Codetransformator (CT) bei der Generierung des Ob jektcodes (OC2) für die Zielhardware (M2) aus dem Assem blerquellcode (AC1) Befehle oder Befehlsfolgen, die erst während der Ausführung des Codes vollständig definiert wer den oder in Form von Datendefinitionen angegeben sind, in Aufrufe an den den entsprechenden Objektcode (OC1) für die Ursprungshardware (M1) emulierenden Emulator (E) transfor miert.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß bei der Transformation von Programmcode zumindest eines der Register (R_i) der Ursprungshardware (M1) umkehrbar ein deutig auf ein Register (r_i) der Zielhardware (M2) abgebildet wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß bei der Transformation von Programmcode zumindest eines der Register (R_i) der Ursprungshardware (M1) auf der Ziel hardware (M2) durch einen Speicherbereich nachgebildet wird.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß für alle Befehle und Datendefinitionen im Objektcode (OC1) der Ursprungshardware (M1) jeweils Einträge in der Adreßumsetztabelle (TTAB) erfolgen, wodurch die auf Befehle verweisenden Adressen (A) im Objektcode (OC1) der Ursprungs hardware (M1) auf entsprechende Adressen (A′) im transfor mierten Objektcode (OC2) abgebildet werden, während bei auf Daten verweisenden Adressen (A) das Fehlen von korrespondie rendem transformierten Objektcode (OC2) angezeigt wird.

5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß nur für die als mögliche Sprung- oder Zugriffsziele rele vanten Befehle im Objektcode (OC1) der Ursprungshardware (M1) Einträge in der Adreßumsetztabelle (TTAB) erfolgen, wodurch die diese Befehle enthaltenden Adressen (A) im Objektcode (OC1) der Ursprungshardware (M1) auf entsprechende Adressen (A′) im transformierten Objektcode (OC2) abgebildet werden.

6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein im Assemblerquellcode (AC1) auftretender Sprungbefehl mit bekanntem Sprungziel durch den Codetransformator (CT) in einen entsprechenden Sprungbefehl im Objektcode (OC2) für die Zielhardware (M2) transformiert wird, wobei das Sprungziel im transformierten Objektcode (OC2) über die Adreßumsetztabelle (TTAB) mit dem entsprechenden Sprungziel im Objektcode (OC1) für die Ursprungshardware (M1) verknüpft ist.

7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein im Assemblerquellcode (AC1) auftretender Sprungbefehl mit einer erst zur Laufzeit auswertbaren Sprungzielangabe durch den Codetransformator (CT) in einen Emulatoraufruf im Objektcode (OC2) für die Zielhardware (M2) transformiert wird, der bei seiner Ausführung bewirkt, daß der Emulator (E) anhand der dann ausgewerteten Sprungzielangabe und der Adreß umsetztabelle (TTAB) überprüft, ob zum Sprungziel transfor mierter Objektcode (OC2) für die Zielhardware (M2) existiert, woraufhin im Fall der Existenz eines solchen transformierten Objektcodes (OC2), dieser direkt angesprungen wird, während anderenfalls die eigentliche Emulation des entsprechenden Ob jektcodes (OC1) der Ursprungshardware (M1) erfolgt.

8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Codetransformator (CT) zur Behandlung von selbstmodi fizierendem Code jeden im Assemblerquellcode (AC1) auftreten den Speicherbefehl in Objektcode (OC2) für die Zielhardware (M2) transformiert, der bei seiner Ausführung die folgenden Schritte durchführt:

- die auf die Ursprungshardware (M1) bezogene Speicheradresse (ADR) wird berechnet;
- anhand der Adreßumsetztabelle (TTAB) wird geprüft, ob zur Speicheradresse (ADR) transformierter Objektcode (OC2) exi stiert;
- falls zur Speicheradresse (ADR) transformierter Objektcode (OC2) existiert, wird dieser durch eine Befehlssequenz zum Aufruf des Emulators (E) ersetzt, und die Adreßumsetztabel le (TTAB) wird so abgewandelt, daß das Auftreten eines Sprunges in den durch diese Befehlssequenz modifizierten Adreßbereich im transformierten Objektcode (OC2) zu einem Aufruf des Emulators (E) führt;
- der Speicherbefehl zur Speicheradresse (ADR) wird ausge führt.

9. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß auf der Zielhardware (M1) zur Behandlung von selbstmodi fizierendem Code ein Schreibschutz vorgesehen ist, durch den ein zur Laufzeit des Programmcodes (PC2) auftretender Schreibzugriff auf eine einen Befehl des Objektcodes (OC1) der Ursprungshardware (M1) enthaltende Adresse zu einer Si gnalisierung führt, die die folgenden Schritte einleitet:

- der Schreibbefehl auf die Adresse wird ausgeführt;
- anhand der Adreßumsetztabelle (TTAB) wird geprüft, ob zur Speicheradresse transformierter Objektcode (OC2) existiert;
- falls zur Speicheradresse transformierter Objektcode (OC2) existiert, wird dieser durch eine Befehlssequenz zum Aufruf d,es Emulators (E) ersetzt, und die Adreßumsetztabelle (TTAB) wird so abgewandelt, daß das Auftreten eines Sprun ges in den durch diese Befehlssequenz modifizierten Adreß bereich im transformierten Objektcode (OC2) zu einem Aufruf des Emulators (E) führt.

10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß ein im Assemblerquellcode (AC1) auftretender Befehl, der zur Laufzeit das Bitmuster eines Datenfeldes, gegebenenfalls nach vorheriger Modifikation desselben, dynamisch als Befehl interpretiert und ausführt, und für den keine entsprechenden Instruktionen oder Befehlsfolgen im Befehlssatz der Zielhard ware (M2) existieren, durch den Codetransformator (CT) in ei nen Emulatoraufruf im transformierten Objektcode (OC2) umge setzt wird.

11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei einem während einer Emulation zur Laufzeit des Pro grammcodes (PC2) auftretendem Sprungbefehl anhand der Adreß umsetztabelle (TTAB) geprüft wird, ob zum Sprungziel (a) transformierter Objektcode (OC2) existiert, und wenn dies der Fall ist, unter Beendung der Emulation zum entsprechenden Sprungziel (TTAB[a]) im transformierten Objektcode (OC2) ge sprungen wird, während andernfalls die Emulation des Ob jektcodes (OC1) der Ursprungshardware (M1) beim Sprungziel (a) fortgesetzt wird.

12. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß nach jedem während einer Emulation zur Laufzeit des Pro grammcodes (PC2) abgearbeitetem Befehl anhand der Adreß umsetztabelle (TTAB) geprüft wird, ob ein zum darauffolgenden Befehl korrespondierender, transformierter Objektcode (OC2) existiert, und wenn dies der Fall ist, unter Beendung der Emulation zum entsprechenden Stelle im transformierten Ob jektcode (OC2) gesprungen wird, während andernfalls die Emu lation des Objektcodes (OC1) der Ursprungshardware (M1) fort gesetzt wird.