WO1997042574A1 - Verfahren zur codetransformation - Google Patents

Verfahren zur codetransformation Download PDF

Info

Publication number
WO1997042574A1
WO1997042574A1 PCT/DE1997/000900 DE9700900W WO9742574A1 WO 1997042574 A1 WO1997042574 A1 WO 1997042574A1 DE 9700900 W DE9700900 W DE 9700900W WO 9742574 A1 WO9742574 A1 WO 9742574A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
object code
transformed
hardware
ttab
Prior art date
Application number
PCT/DE1997/000900
Other languages
English (en)
French (fr)
Inventor
Manfred Stadel
Original Assignee
Siemens Nixdorf Informationssysteme Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Nixdorf Informationssysteme Ag filed Critical Siemens Nixdorf Informationssysteme Ag
Publication of WO1997042574A1 publication Critical patent/WO1997042574A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/52—Binary to binary
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators

Definitions

  • the invention relates to a method for transforming hardware-specific program code into program code that can run on another hardware with a different computer architecture.
  • the architecture of a computer is characterized above all by the basic structure of its processor, that is by the number and size of the registers, the data types used, the supported arithmetic and logical operations, etc. With today's high-performance computers, e.g. in parallel computers, it is often not only a single processor that is used, but rather a whole set of processors, which are mostly of the same type. As a rule, the architecture definition of a computer is described by its instruction set, which includes all elementary instructions of the underlying processor.
  • CISC Complex Instruction Set Computer
  • RISC Reduced Instruction Set Computer
  • CISC processors usually had significant advantages over RISC processors, since on average they require fewer instructions to carry out the same task.
  • today's semiconductor memories are fast enough to largely avoid waiting times for the processor.
  • the higher memory requirement for RISC code compared to equivalent CISC code no longer plays an important role.
  • the manufacturing and, above all, performance advantages of computers with RISC architecture come to bear.
  • Starting point for a static object code transformation - e.g. according to WO 92/15939 - is a program code present as object code for the original hardware, for which the restriction applies that all command sequences and jump targets must be completely known and defined already during the transformation.
  • Calculated, non-symbolic jumps and addressing e.g. addressing based on basic registers in IBM System / 370 computers
  • commands that can be any, e.g. Interpreting bit patterns generated or read in only when the program is running can therefore at least not be completely transformed in general.
  • criteria are required in the static object code transformation with which commands and data in the input code can be delimited from one another.
  • An assembler transformation differs from the above. static object code transformation in that instead of object code mnemonic assembly code serves as source code for the transformation, which largely allows a clear distinction between commands and data as well as symbolic and absolute jumps.
  • Both of the above-mentioned transformation methods generate by translating the respective program code for an original jump code corresponding program code for a given target hardware, which, however, can only be executed without restriction after all parts of the code have been completely transformed.
  • MIMIC A FAST SYSTEM / 370 SIMULATOR *, SIGPLAN 22, 7, 1987
  • a program is only gradually transformed during its execution by emulation on the target hardware.
  • an address conversion table is used to dynamically check whether code for the target hardware has already been transformed for the calculated jump target. If this is the case, this code is jumped to directly. Otherwise, the code for the original hardware found at the jump target is first dynamically transformed into object code for the target hardware and then executed.
  • the dynamic object code transformation therefore does not require any additional information to distinguish commands and data in the output code. In the course of time, the commands are transformed automatically, while the data remain unchanged. Commands that cannot be clearly mapped to equivalent commands or command sequences of the target hardware are processed by emulation.
  • the object of the present invention is to provide an improved method compared to the known static and dynamic transformation methods for transforming program code written for an original hardware into program code executable on a target hardware with a different computer architecture.
  • the method for code transformation combines the advantages of an assembler transformation with those of a dynamic object code transformation. It is based on a program code available as assembler source code for original hardware and is carried out with the aid of an assembler and a code transformer, which are advantageously combined in a transformation program.
  • the assembler generates from the assembler source code object code for the original hardware, into which data fields and constants contained in the assembler source code are also adopted.
  • the code transformer generates corresponding object code for the target hardware from the assembler source code and an address conversion table which establishes the relationship between addresses in the object code for the original hardware and the associated addresses in the object code for the target hardware.
  • the one on the target hardware Executable program code is obtained by summarizing the object code for the original hardware, the object code for the target hardware, the address conversion table and an emulator which can emulate the object code for the original hardware.
  • address references used in the transformed object code always initially refer to the object code for the original hardware.
  • Address references that refer to commands are only converted into corresponding references to addresses in the object code for the target hardware when the transformed program is run with the aid of the address conversion table.
  • calculated jumps and addressings can therefore be transformed in full generality.
  • Commands or command sequences that are only fully defined during the execution of the code, such as for instructions that have any, e.g. interpret the bit pattern generated or read in only when the program is running, as is the case, are transformed by the code transformer when the object code for the target hardware is generated in calls to the emulator emulating the corresponding object code for the original hardware.
  • commands and command sequences that are not in the assembly source code as such, but e.g. are specified as data constants, transformed into emulator calls.
  • the disadvantages mentioned above, which occur in the case of dynamic code transformation, are avoided in the transformation method according to the invention, since the generation of the program code executable on the target hardware in one step by the transformation program and not only gradually over the course of several emulated program runs transforming codes.
  • a first embodiment of the method according to the invention - claim 2 - at least one of the registers of the original hardware is reversibly and uniquely mapped onto a register of the target hardware during the code transformation.
  • registers it is expedient to use registers to represent at least the registers of the original hardware, which are used frequently in the assembler source code or for time-critical program parts, in the transformed program code for the target hardware in order to generate short and effective code in this way.
  • a second embodiment is used of the invention - claim 3 - in the code transformation of at least one of the registers of the original hardware on the target hardware (M2) is simulated by a storage area.
  • entries are made in the address conversion table for all commands and data fields in the object code of the original hardware, as a result of which the addresses referring to commands in the object code of the original hardware are mapped to corresponding addresses in the transformed object code, while at Data-referencing addresses the absence of corresponding transformed object code is indicated.
  • This allocation rule which encompasses all code parts, enables simple and quick access to the individual table entries through indexing, although the resulting scope of the address conversion table can reach a considerable size.
  • the entries in the address conversion table can also be made only for the commands in the object code of the original hardware that are relevant as possible jump or access targets.
  • An advantage here is the generally significant reduction in the memory requirement required for the address conversion table compared to the above-mentioned embodiment according to claim 4, in which entries are made in the table for all commands and data. In this case, however, access to table entries requires search methods (for example binary search or hash search).
  • a jump instruction appearing in the assembler source code with a known jump target is transformed by the code transformer into a corresponding jump instruction in the object code for the target hardware.
  • the jump destination information in the transformed object code is linked via the address conversion table to the corresponding jump destination information in the object code for the original hardware.
  • a jump instruction occurring in the assembler source code with a jump target information that can only be evaluated at runtime is transformed according to a further development of the invention - claim 7 - by the code transformer into an emulator call in the object code for the target hardware, which, when executed, causes the emulator to use the jump target information then evaluated and the address translation table checks whether object code transformed to the jump target exists for the target hardware. If such a transformed object code exists, it is then jumped to directly, while otherwise the actual emulation of the corresponding object code of the original hardware takes place.
  • the method according to the invention for code transformation can also be used to deal with jumps with jump targets determined at runtime, for example calculated jumps.
  • the code transformer transforms every memory command occurring in the assembler source code into object code for the target hardware, which executes the following steps when it is executed:
  • the memory address relating to the original hardware is calculated and the address conversion table is used to check whether object code transformed to this memory address exists. If this is the case, the transformed object code is replaced at this point by a command sequence for calling the emulator, and the address conversion table is modified such that the occurrence of a jump into the address area modified by this command sequence leads to a call of the emulator. Otherwise it is not a self-modification of program code. In both cases, the store instruction relating to a store address in the address area of the source hardware is executed. With the method according to the invention for code transformation, it is thus possible to transform self-modifying code, which has so far not been available in any of the known methods, neither static nor dynamic. A severely restrictive requirement on the program code to be transformed is thus eliminated.
  • An alternative method for handling self-modifying code - claim 9 - can be used if write protection is provided on the target hardware, which leads to signaling if, during runtime of the program code, write access to an address referring to a command of the object code of the original hardware occurs.
  • the following steps are then initiated by the signaling: the write command to the address is executed and the address conversion table is used to check whether there is object code transformed to this memory address. If if this is the case, the transformed object code is replaced at this point by a command sequence for calling the emulator, and the address conversion table is modified such that the occurrence of a jump into the area of the transformed object code modified by this command sequence leads to a call of the emulator.
  • the advantage of this method for treating self-modifying code is that runtime losses only occur if a modification really takes place.
  • a further embodiment of the invention - claim 10 - relates to code transformations in which instructions appear in the assembler source code of the original hardware which dynamically interpret and execute the bit pattern of a data field at runtime, possibly after prior modification of the same, as an instruction, and for which there are no corresponding instructions in the instruction set of the target hardware.
  • a command or command sequence usually referred to as an execute command
  • the code transformer into an emulator call in the transformed object code.
  • a first possibility - claim 11 - is that in the event of a jump command occurring during emulation at runtime of the program code, the address conversion table is used to check whether there is object code transformed to the jump target. If this is the case, the emulation is used to jump to the corresponding jump target in the transformed object code. Otherwise, the emulation of the object code of the original hardware continues at the jump destination.
  • Source and target hardware based on the address conversion table
  • 5 shows a flowchart for the handling of a jump command with jump destination information that can only be evaluated at runtime by the emulator; 6 shows a flowchart for the transformation of a memory command;
  • FIG. 1 and FIG. 1 A program code present as an assembler source code AC1 for an original hardware M1 is converted into a program code PC2 executable on a target hardware M2 with the aid of a transformation program TP which runs on a computer COM and which contains an assembler ASS for the original hardware M1 and a code transformer CT transformed.
  • the assembler ASS generates the object code OCl for the original hardware Ml from the assembly source code AC1 after a syntax analysis, in which data fields (for example, data constants) present in the source code are also transferred.
  • the code transformer CT From the assembler source code AC1, the code transformer CT generates corresponding object code OC2 for the target hardware M2 and an address conversion table TTAB, which establishes the relationship between addresses in the object code OCl for the original hardware Ml and the associated addresses in the object code OC2 for the target hardware M2.
  • the object code OCl for the original hardware Ml (with data)
  • the object code 0C2 (without data) for the target hardware M2
  • the address conversion table TTAB and an emulator E which contains the object code OCl for can emulate the original hardware Ml, summarized.
  • the processor registers R ⁇ present on the original hardware are advantageously reversibly mapped in the code transformation onto registers r ⁇ of the target hardware corresponding in number and size.
  • registers t £ present on the target hardware become PC2 at runtime of the transformed program code used by the emulator E and as a temporary register by the transformed object code 0C2.
  • FIG. 3 shows the linking of the address areas of the source and target hardware Ml or M2 using the address conversion table TTAB as an example of an embodiment of the method in which entries are made in the table TTAB for commands as well as for data.
  • a command 1 in the object code OCl of the original hardware M1 has, for example, a length which corresponds to three memory cells and is stored in the object code OCl at address AI.
  • the address conversion table TTAB assigns the address AI an address A'l in the object code OC2, in which the command 1 'corresponding to command 1 of the target hardware M2 is stored.
  • a further command 2 in the object code OCl which is stored there, for example, starting at address A4, corresponds to a command sequence consisting of two instructions command 2 'and command 2a' in the transformed object code OC2.
  • a next command 3 is transformed analogously into a command 3 'in the object code OC2 etc..
  • corresponding commands or command sequences have different lengths and therefore different memory requirements for the source and target hardware M1 and M2.
  • FIG. 4 shows on the basis of a flow diagram how a jump instruction occurring in the assembler source code AC1 is transformed. Is it a jump instruction whose jump destination is already known during the transformation and e.g. is specified in the assembler source code on the basis of a symbolic jump label, it is transformed into a corresponding jump command with in the object code OC2 for the target hardware M2.
  • the jump target in the transformed object code OC2 is linked via the address conversion table TTAB to the corresponding jump target in the object code OCl for the original hardware Ml.
  • the jump destination is only at the runtime of the program code, e.g. depending on user input, the jump instruction to be transformed is translated into an emulator call in the object code OC2 of the target hardware.
  • FIG. 5 shows how such a jump command with jump destination information that can only be evaluated at runtime by the
  • Emulator being edited If a check of the jump destination determined using the address conversion table TTAB reveals that object code 0C2 which has already been transformed for this purpose is present, a branch is made to it. Otherwise, e.g. If the instruction sequence to be started in the assembler source code AC1 is specified not as mnemonic but as a definition of constant data and thus not recognized and transformed as an instruction sequence by the code transformer CT, the emulation of the corresponding object code OCl of the original hardware is continued .
  • each memory command occurring in the assembler source code AC1 is transformed into object code OC2 for the target hardware, which executes the following steps, represented by a flowchart in FIG. 6:
  • the store command to the memory address ADR is executed.
  • FIG. 7 schematically shows the handling of a jump command during emulation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Die Erfindung gibt ein gegenüber dem Stand der Technik verbessertes Verfahren zur Transformation von für eine Ursprungshardware (M1) geschriebenem Assemblerquellcode (AC1) in auf einer Zielhardware (M2) mit einer unterschiedlichen Rechnerarchitektur ablauffähigen Programmcode (PC2) an. Aus dem Assemblerquellcode (AC1) wird durch einen Assembler (ASS) Objektcode (OC1) für die Ursprungshardware (M1) und durch einen Codetransformator (CT) entsprechender Objektcode (OC2) für die Zielhardware (M2) sowie eine Adreßumsetztabelle (TTAB), die die Beziehung zwischen Adressen (A) im Objektcode (OC1) für die Ursprungshardware (M1) und den zugehörigen Adressen (A') im Objektcode (OC2) für die Zielhardware (M2) herstellt, generiert. Der Programmcode (PC2) für die Zielhardware (M2) wird durch Zusammenfassung dieser beiden Objektcodes (OC1, OC2), der Adreßumsetztabelle (TTAB) sowie eines Emulators (E), der den Objektcode (OC1) für die Ursprungshardware (M1) emulieren kann, gewonnen. Die im transformierten Objektcode (OC2) verwendeten Adreßbezüge beziehen sich zunächst stets auf den Objektcode (OC1) für die Ursprungshardware (M1) und werden 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. Befehle oder Befehlsfolgen, die erst während der Ausführung des Programmcodes (PC2) vollständig definiert werden oder im Assemblerquellcode (AC1) nur in Form von Datendefinitionen angegeben sind, werden in Aufrufe an den den entsprechenden Objektcode (OC1) für die Ursprungshardware (M1) emulierenden Emulator (E) transformiert.

Description

Beschreibung
Verfahren zur Codetransformation
Die Erfindung betrifft ein Verfahren zur Transformation von hardwarespezifischem Programmcode in auf einer anderen Hard¬ ware mit einer unterschiedlichen Rechnerarchitektur ablauf- fähigen Programmeode.
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 zugrunde- liegenden 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 Objekt code transformation - 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 Assemblertrans formation 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 Ursprungεhardware 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 0C2 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 Laufzeiteinbüß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- befehle;
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 ACl für eine Ursprungs- hardware Ml vorliegender Programmcode wird mit Hilfe eines auf einem Computer COM ablaufenden Transformationsprogramms TP, das einen Assembler ASS für die Ursprungshardware Ml 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 ACl nach einer Syntaxanalyse den dazu äquiva¬ lenten Objektcode OCl für die Ursprungshardware Ml, in den auch im Quellcode vorhandene Datenfelder (z.B. Datenkonstan¬ ten) übernommen werden. Der Codetransformator CT generiert aus dem Assemblerquellcode ACl entsprechenden Objektcode OC2 für die Zielhardware M2 sowie eine Adreßumsetztabelle TTAB, die die Beziehung zwischen Adressen im Objektcode OCl für die Ursprungshardware Ml 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 OCl für die Ursprungshardware Ml (mit Daten) , der Objektcode 0C2 (ohne Daten) für die Zielhardware M2, die Adreßumsetztabelle TTAB sowie ein Emulator E, der den Ob¬ jektcode OCl für die Ursprungshardware Ml emulieren kann, zu- saramengefaßt. Die auf der Ursprungshardware vorhandenen Pro¬ zessorregister R± werden vorteilhafterweise bei der Code¬ transformation umkehrbar eindeutig auf in Anzahl und Größe entsprechende Register rλ der Zielhardware abgebildet. Zu¬ sätzlich dazu auf der Zielhardware vorhandene Register t£ werden zur Laufzeit des transformierten Programmcodes PC2 durch den Emulator E und als temporäre Register durch den transformierten Objektcode 0C2 benutzt.
In FIG 3 ist die Verknüpfung der Adreßbereiche von Ursprungs- und Zielhardware Ml 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 OCl der Ursprungshardware Ml weist z.B. eine Länge auf, die drei Speicherzellen entspricht, und ist im Ob¬ jektcode OCl bei Adresse AI abgelegt. Durch die Adreßumsetz¬ tabelle TTAB wird der Adresse AI eine Adresse A'l 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 OCl, 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 Ml 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 OCl, wenn man dabei reine Datendefinitionen im CISC-Objektcode OCl außer acht läßt. Für z.B. als Datenkonstanten im Objektcode OCl der Ursprungshardware Ml enthaltenen Datenfelder erfolgen besondere Eintragungen in der Adreßumsetztabelle TTAB, z.B. Nullen, die anzeigen, daß zu den entsprechenden Stellen im Objektcode OCl kein äquivalenter, transformierter Objektcode OC2 vorhanden ist. Im Programm auftretende Zugriffe auf Daten erfolgen erfindungsgemäß ausschließlich auf den Objektcode OCl der Ursprungshardware Ml bezogen.
FIG 4 zeigt anhand eines Flußdiagramms, wie ein im Assembler- quellcode ACl 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 OCl für die Ursprungshardware Ml 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 0C2 vorliegt, so wird zu diesem verzweigt. Andernfalls, z.B. wenn die anzuspringen- de Befehlsfolge im Assemblerquellcode ACl nicht mnemonisch, sondern als Definition konstanter Daten spezifiziert und so¬ mit durch den Codetransformator CT nicht als Befehlfolge er¬ kannt und transformiert wurde, wird die Emulation des ent¬ sprechenden Objektcodes OCl der Ursprungshardware weiterge- führt.
Auch die Behandlung von selbstmodifizierendem Code ist mög¬ lich. Dazu wird jeder im Assemblerquellcode ACl 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 Ml bezogene Spei¬ cheradresse ADR berechnet. Anhand der Adreßumsetztabelle TTAB wird dann geprüft, ob zur Speicheradresse ADR transformierter Objektcode 0C2 existiert. Ist dies der Fall (selbst- modifizierender Code) , so wird der entsprechende Objektcode 0C2 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 OCl der Ursprungshardware fortgeführt.

Claims

Patentansprüche
1. Verfahren zur Transformation von für eine Ursprungshardwa¬ re (Ml) geschriebenem Assemblerquellcode (ACl) in auf einer Zielhardware (M2) mit einer unterschiedlichen Rechnerarchi¬ tektur ablauffähigen Programmcode (PC2) mit Hilfe eines As¬ semblers (ASS) und eines Codetransformatorε (CT) , wobei
- durch den Assembler (ASS) aus dem Assemblerquellcode (ACl) Objektcode (OCl) für die Ursprungshardware (Ml) generiert wird, in den auch im Assemblerquellcode (ACl) enthaltene Daten übernommen werden;
- durch den Codetransformator (CT) aus dem Assemblerquellcode (ACl) entsprechender Objektcode (OC2) für die Zielhardware (M2) sowie eine Adreßumsetztabelle (TTAB) , die die Bezie- hung zwischen Adressen im Objektcode (OCl) für die Ur¬ sprungshardware (Ml) 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 (OCl) für die Ursprungshardware (Ml) , der Objektcode (OC2) für die Zielhardware (M2) , die Adre߬ umsetztabelle (TTAB) sowie ein Emulator (E) , der den Ob¬ jektcode (OCl) für die Ursprungshardware (Ml) emulieren kann, zusammengefaßt werden; - sich die im transformierten Objektcode (OC2) verwendeten
Adreßbezüge auf den Objektcode (OCl) für die Ursprungshard¬ ware (Ml) 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 (0C2) für die Zielhardware (M2) aus dem Assem¬ blerquellcode (ACl) 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 (OCl) für die Ursprungshardware (Ml) emulierenden Emulator (E) transfor¬ miert.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , daß bei der Transformation von Programmcode zumindest eines der Register (RJ der Ursprungshardware (Ml) umkehrbar ein¬ deutig auf ein Register (r<) der Zielhardware (M2) abgebildet wird;
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet , daß bei der Transformation von Programmcode zumindest eines der Register (RJ der Ursprungshardware (Ml) 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 (OCl) der Ursprungshardware (Ml) jeweils Einträge in der Adreßumsetztabelle (TTAB) erfolgen, wodurch die auf Befehle verweisenden Adressen (A) im Objektcode (OCl) der Ursprungs- hardware (Ml) auf entsprechende Adressen (A' ) im transfor- mierten Objektcode (0C2) 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 (OCl) der Ursprungshardware (Ml) Einträge in der Adreßumsetztabelle (TTAB) erfolgen, wodurch die diese Befehle enthaltenden Adressen (A) im Objektcode (OCl) der Ursprungεhardware (Ml) auf entsprechende Adressen (A' ) im transformierten Objektcode (0C2) abgebildet werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet , daß ein im Assemblerquellcode (ACl) 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 (OCl) für die Ursprungshardware (Ml) verknüpft ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet , daß ein im Assemblerquellcode (ACl) 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 (0C2) für die Zielhardware (M2) existiert, woraufhin im Fall der Existenz eines solchen transformierten Objektcodes (0C2) , dieser direkt angesprungen wird, während anderenfalls die eigentliche Emulation des entsprechenden Ob¬ jektcodes (OCl) der Ursprungshardware (Ml) erfolgt.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Codetransformator (CT) zur Behandlung von selbstmodi¬ fizierendem Code jeden im Assemblerquellcode (ACl) auftreten¬ den Speicherbefehl in Objektcode (0C2) für die Zielhardware (M2) transformiert, der bei seiner Ausführung die folgenden Schritte durchführt:
- die auf die Ursprungshardware (Ml) 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 (Ml) 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 (OCl) der Ursprungshardware (Ml) 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 (0C2) existiert, wird dieser durch eine Befehlssequenz zum Aufruf des 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 (ACl) 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 (0C2) existiert, und wenn dies der Fall ist, unter Beendung der Emulation zum entsprechenden Sprungziel (TTAB[a]) im transformierten Objektcode (0C2) ge¬ sprungen wird, während andernfalls die Emulation des Ob- jektcodes (OCl) der Ursprungshardware (Ml) 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 (0C2) existiert, und wenn dies der Fall ist, unter Beendung der Emulation zum entsprechenden Stelle im transformierten Ob¬ jektcode (0C2) gesprungen wird, während andernfalls die Emu¬ lation des Objektcodes (OCl) der Ursprungshardware (Ml) fort¬ gesetzt wird.
PCT/DE1997/000900 1996-05-03 1997-05-02 Verfahren zur codetransformation WO1997042574A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19617842A DE19617842A1 (de) 1996-05-03 1996-05-03 Verfahren zur Codetransformation
DE19617842.8 1996-05-03

Publications (1)

Publication Number Publication Date
WO1997042574A1 true WO1997042574A1 (de) 1997-11-13

Family

ID=7793272

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1997/000900 WO1997042574A1 (de) 1996-05-03 1997-05-02 Verfahren zur codetransformation

Country Status (2)

Country Link
DE (1) DE19617842A1 (de)
WO (1) WO1997042574A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279150B1 (en) 1997-09-01 2001-08-21 Siemens Nixdorf Informationssysteme Aktiengesellschaft Method for converting an object code into a program code

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2797962B1 (fr) * 1999-08-23 2001-10-26 Trusted Logic Procede de conversion de types de variables codees dans un programme informatique et systeme de traduction de programme informatique correspondant
EP1429215A1 (de) * 2002-12-10 2004-06-16 Siemens Aktiengesellschaft Verfahren zur Ausführung eines ersten Softwareprogramms, welches für eine speicherprogrammierbare Steuerung entwickelt ist, auf einem Personal Computer
US7805716B2 (en) 2002-12-10 2010-09-28 Siemens Aktiengesellschaft Method for executing a first software program, developed for a stored-program controller, on a computer
US8423976B2 (en) 2003-03-13 2013-04-16 Northrop Grumman Corporation Extreme pipeline and optimized reordering technology
US9021454B2 (en) * 2012-11-08 2015-04-28 Unisys Corpoation Operand and limits optimization for binary translation system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0217068A2 (de) * 1985-09-30 1987-04-08 International Business Machines Corporation Befehlsemulationsmethode eines Zielrechners

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5313614A (en) * 1988-12-06 1994-05-17 At&T Bell Laboratories Method and apparatus for direct conversion of programs in object code form between different hardware architecture computer systems
DE69226093T2 (de) * 1991-03-07 1999-02-25 Digital Equipment Corp Verfahren und Gerät zur Rechnercode-Verarbeitung in einem Codeübersetzer

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0217068A2 (de) * 1985-09-30 1987-04-08 International Business Machines Corporation Befehlsemulationsmethode eines Zielrechners

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GABRIEL M. SILBERMAN ET AL.: "AN ARCHITECTURAL FRAMEWORK FOR SUPPORTING HETEROGENEOUS INSTRUCTION-SET ARCHITECTURES", COMPUTER, vol. 26, no. 6, June 1993 (1993-06-01), LOS ALAMITOS, CA, US, pages 39 - 56, XP000377627 *
KRISTY ANDREWS ET AL.: "MIGRATING A CISC COMPUTER FAMILY ONTO RISC VIA OBJECT CODE TRANSLATION", ACM SIGPLAN NOTICES, vol. 27, no. 9, 1 September 1992 (1992-09-01), pages 213 - 222, XP000330602 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279150B1 (en) 1997-09-01 2001-08-21 Siemens Nixdorf Informationssysteme Aktiengesellschaft Method for converting an object code into a program code

Also Published As

Publication number Publication date
DE19617842A1 (de) 1997-11-13

Similar Documents

Publication Publication Date Title
EP0502857B1 (de) Verfahren zur dynamischen bindung von definierbaren programmelementen eines interaktiven datenverarbeitungssystems
DE68926706T2 (de) Übersetzungsverfahren
DE69835062T2 (de) Gemischter Registerstapel und Ausnahmebehandlung
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE69924857T2 (de) Programm-kode-umwandlung
DE69819188T2 (de) Programmschnittstellenumsetzer für rechner mit mehreren umgebungen
DE60208710T2 (de) Plattformunabhängige im-voraus-kompilierung
DE68921776T2 (de) Prozessorssimulation.
DE60226019T2 (de) Verfahren und system zum steuern von ausführbaren dateien mit geteilten bibliotheken
DE69932964T2 (de) Verfahren, System und Rechnerprogrammprodukt zur Initialisierung einer Datenstruktur beim ersten Gebrauch
DE112012000303T5 (de) Dynamische binäre Optimierung
DE3750951T2 (de) Verfahren zur Kodeerzeugung für Rechner mit beschränktem Befehlssatz.
EP1738257B1 (de) Verfahren zum vermeiden von dateninkonsistenz zwischen zugriffen verschiedener funktionen einer anwendung auf eine globale variable in einer datenverarbeitungsanlage
EP2517105B1 (de) Verfahren zum komprimieren von bezeichnern
EP1497722A2 (de) Optimierung von compilergeneriertem programmcode
WO1999031584A1 (de) Verfahren zum umsetzen eines systemaufrufs
DE3853806T2 (de) Dynamische Umgebungsanpassung von Rechnerprogrammen.
WO1997042574A1 (de) Verfahren zur codetransformation
EP1010070B1 (de) Verfahren zum umsetzen eines objektcodes in einen programmcode
WO1998001805A1 (de) Verfahren zur migration von programmen mit portierbaren und nicht-portierbaren programmteilen
EP3935489A1 (de) Verfahren zum erzeugen einer darstellung einer programmlogik, dekompiliervorrichtung, rekompiliersystem und computerprogrammprodukt
DE102009041098A1 (de) Verfahren zur Kennzeichnung eines in einem Computerspeichersystem enthaltenden Computerprogrammabschnitts
DE2249852A1 (de) Computersystem
DE112022001713T5 (de) Ausführen von programmcode mit geringerer speicheradressbreite in einem adressraum mit grösserer speicheradressbreite
DE102010011583B4 (de) Verfahren zum Umsetzen von Befehlen mit Basisregister-relativer Adressierung bei einer Emulation

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97539430

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase