WO2004097628A2 - Optimierung und ausführung eines programms - Google Patents

Optimierung und ausführung eines programms Download PDF

Info

Publication number
WO2004097628A2
WO2004097628A2 PCT/EP2004/004400 EP2004004400W WO2004097628A2 WO 2004097628 A2 WO2004097628 A2 WO 2004097628A2 EP 2004004400 W EP2004004400 W EP 2004004400W WO 2004097628 A2 WO2004097628 A2 WO 2004097628A2
Authority
WO
WIPO (PCT)
Prior art keywords
program
instruction
optimized
operands
macro
Prior art date
Application number
PCT/EP2004/004400
Other languages
English (en)
French (fr)
Other versions
WO2004097628A3 (de
Inventor
Thomas Stocker
Original Assignee
Giesecke & Devrient Gmbh
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 Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to EP04729435A priority Critical patent/EP1620798A2/de
Publication of WO2004097628A2 publication Critical patent/WO2004097628A2/de
Publication of WO2004097628A3 publication Critical patent/WO2004097628A3/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/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation

Definitions

  • the invention relates generally to the technical field of optimizing a program and executing the optimized program by a machine, which in particular can be a virtual machine, but also a processor implemented directly in hardware. More particularly, the invention relates to program optimization using macro operations to reduce the memory space required for the optimized program.
  • a preferred area of application of the invention is the program execution by means of a portable data carrier, which can be configured, for example, as a chip card in different designs or as a chip module.
  • the storage space provided for accommodating executable program code is generally only limited. This applies in particular if the program code is not to be stored in a mask-programmed ROM, but in a non-volatile, writable EEPROM, since considerably more ROM memory than EEPROM memory is provided on data carriers which are common today.
  • the storage of program code in the EEPROM is desirable, however, because any changes to the program code can then be incorporated into the production of new data carriers with much less effort.
  • the object of the invention is to at least partially avoid the problems of the prior art and to provide a technique for optimizing and executing a program which reduces the storage space required for storing the program as much as possible.
  • the invention should be relatively easy to implement and should cause little or no additional effort in program development.
  • this object is achieved in whole or in part by a method for generating an optimized program according to claim 1, a method for executing a program according to claim 9, a computer program product according to claim 14 and a device according to claim 15, which in particular is designed as a portable data carrier can be.
  • the dependent claims relate to preferred embodiments of the invention.
  • the invention is based on the basic idea of separating the instruction codes from the operands when optimizing and executing the optimized program.
  • the optimized program contains at least one instruction code strand with instruction codes and at least one operand strand with operands.
  • command groups of the original program are searched for, the command codes of which can be summarized by a macro command.
  • the operands of such an instruction group are transferred to the operand line as operands of the macro instruction.
  • a machine with two instruction counters for executing the optimized program, the first of which is assigned to the instruction code strand and the second to the operand strand.
  • the first instruction counter is incremented according to the number of instruction codes in the instruction code strand
  • the second instruction counter is incremented according to the number of operands in the operand strand.
  • this "forwarding" of the second instruction counter is of course only to be understood conceptually, because the instruction counter is then advanced by "zero operands", ie the result is not changed.
  • the optimized program contains macro instructions, each of which replaces several instructions from the original program.
  • macro instruction is to be understood in particular to mean any instruction which, in its effect, corresponds to the effect of several individual instructions of the original program.
  • a macro instruction can be implemented, for example, as a special instruction that already contains information about the individual instructions to be executed in its instruction code, or as a general instruction that only codes the individual instructions to be executed in a second instruction code word or in an operand.
  • the macro instruction can comprise a subroutine call or a trap call or an instruction code which is reserved for extensions in a predetermined instruction set.
  • the instruction code sequence of an instruction group to be optimized is encoded in a macro instruction.
  • the macro instruction preferably only contains a reference to a macro definition, which in turn contains the sequence of instruction codes to be executed.
  • the called subroutine is regarded as a macro definition.
  • a fixed set of macro definitions are used which correspond to command sequences, which Experience has shown that they are often required.
  • the macro definitions are preferably created - exclusively or in addition to predetermined macro definitions - during the optimization process.
  • Such macro definitions generated during the optimization process are intended in particular to code sequences of command codes that occur as frequently as possible in the original program.
  • the separation according to the invention of the optimized program into at least one strand of instruction code and at least one strand of operands preferably arises only during the optimization.
  • the original program does not have this separation, but consists of an instruction sequence in which instruction codes and any operands that are present essentially alternate. This usual change between instruction codes and operands is resolved in the optimized program according to the present invention.
  • the program flow in the optimized program preferably corresponds to the program flow in the original program.
  • jump instructions and other commands influencing the program sequence are preferably generated during program optimization in such a way that they define both a jump destination in the instruction code strand and a corresponding jump destination in the operand strand.
  • the optimization process according to the invention can in principle be carried out in any stage of the automatic program implementation, for example by means of a compiler, a converter or a separate optimization program.
  • the optimization process is particularly preferably carried out by a loading program which, e.g. is contained in a portable data carrier in which the program to be executed is also to be written.
  • a loading program which, e.g. is contained in a portable data carrier in which the program to be executed is also to be written.
  • the computer program product according to the invention has program commands in order to implement the optimization and / or execution method according to the invention.
  • a computer program product can be a physical medium, for example a semiconductor memory or a floppy disk or a CD-ROM.
  • the computer program product can also be a non-physical medium, for example a Signal transmitted over a computer network.
  • the computer program product can be, for example, a compiler or a converter or an optimization program for execution by an ordinary workstation computer or an optimizing loader or a virtual machine for execution by a processor of a portable data carrier.
  • the data carrier and / or the computer program product have features which correspond to the features just described and / or the features mentioned in the dependent method claims.
  • FIG. 1 is a block diagram with functional units of a portable data carrier according to an embodiment of the invention
  • FIG. 2 shows a schematic representation of the memory content when executing a command in an optimized program
  • Fig. 4 is a schematic representation of the data flow in the program generation by a compiler and in the optimization.
  • the data carrier 10 shown in FIG. 1 is configured in the present exemplary embodiment as a chip card in accordance with the Java Card standard. On a single semiconductor chip, the data carrier 10 has a processor 12, a plurality of memory fields configured in different technologies and an interface circuit 14 for contactless or contact-based communication.
  • a working memory 16 a read-only memory 18 and a non-volatile memory 20 are provided as memory fields.
  • the working memory 16 is designed as RAM, the read-only memory 18 as a mask-programmed ROM and the non-volatile memory 20 as an electrically erasable and programmable EEPROM. Overall, the available storage space is relatively tight.
  • System programs 22 are contained in read-only memory 18 - and in some cases also in non-volatile memory 20.
  • the system programs 22 comprise an operating system 24 which provides a multitude of functions and services close to the hardware.
  • a code module 26 implements a virtual machine, specifically a JCVM (J ⁇ v ⁇ Card Virtual Machine) in the present exemplary embodiment.
  • a class library 28 contains a number of predefined application programming interfaces. The optimization processes described below are carried out in the present exemplary embodiment by an internal load program 30 which is located in the non-volatile memory 20 and which is conceptually part of the operating system 24 and part of the JCVM code module 26.
  • the operational data carrier 10 contains in the non-volatile memory 20 an optimized program 32 which has at least one instruction code strand 34 and at least one operand strand 36.
  • the program 32 is with regard to the space required statically in the non-volatile memory 20 (“footprint”) has been optimized by using macro instructions.
  • Macro definitions 38 which indicate the meaning of each macro instruction, are also located in the non-volatile memory 20.
  • the virtual machine implemented by the code module 26 manages a composite command counter 40 in the working memory 16.
  • the composite command counter 40 contains a first command counter 42, the status of which indicates the current command code in the command code strand 34, and a second instruction counter 44, the status of which indicates the current operands in the operand line 36.
  • a first instruction 46 is shown there by way of example, which is composed of an instruction code OC1 in the instruction code strand 34 and two operands OD1.1 and OD1.2 in the operand strand 36.
  • a second instruction 48 has an instruction code OC2 and a single operand OD2.1.
  • the first and second instruction counters 42, 44 point to the instruction code OC1 and to the first operand OD1.1.
  • the instruction counters 42, 44 are advanced, specifically for the instruction code strand 34 and the operand strand 36, depending on the number of instruction codes or operands in the executed instruction.
  • the first command counter 42 is advanced by one memory word and the second command counter 44 is advanced by two memory words.
  • the dashed arrows in Fig. 2 indicated state reached, in which the command counters 42, 44 point to the command code OC2 or the operand OD2.1 of the next command 48 to be executed.
  • the value of the second instruction counter 44 is of course not changed.
  • FIG. 3 shows larger sections from the instruction code strand 34 and the operand strand 36 of the optimized program 32.
  • the first two instructions with the instruction codes OC1, OC2 and the operands OD1.1, OD1.2, OD2.1 have already been described.
  • a third instruction contains only the instruction code OC3 and no operands.
  • the second command 48 (FIG. 2) and the commands with the command codes OC3, OC4 and OC6 are executed directly by the virtual machine implemented by the code module 26. These commands are therefore also referred to as "native" commands.
  • the first command 46 (FIG. 2) and the command with the command code OC5 are macro commands, the effect of which is defined in each case by a sequence of several native commands.
  • the additional information required to execute a macro command is contained in the macro definitions 38;
  • FIG. 3 shows an example of a definition 50 which assigns the macro instruction code "MAC2" of instruction 46 to the native instruction code sequence "ILOAD", "ILOAD”, "IADD".
  • the virtual machine implemented by the code module 26 is designed such that it resolves macro instructions according to the respective macro definitions 38 into a sequence of native instructions and executes the latter. More precisely, when executing a macro instruction, the virtual machine accesses the corresponding macro definition - for example, definition 50 - and processes the instruction codes contained therein in sequence, the operands stored in operand line 36 being also sequentially as needed be used.
  • the respective macro definition can be selected via the instruction code itself or via a pointer or index value, which can be stored either as an additional instruction code in the instruction code strand 34 or as an additional operand in the operand strand 36.
  • FIG. 3 also shows a section from an original program 52, the optimization of which generated the optimized program 32 and the macro definitions 38. This process is indicated in Fig. 3 by two thick arrows.
  • the original program 52 is in the format commonly used for virtual machines based on the Java Card standard. 3 shows ten instructions U1-U10 of the original program 52, each of which begins with an instruction code.
  • the commands U1, U2, U4, U6, U7 and U8 also each have a parameter which immediately follows the command code.
  • the task of the optimization process is to find instruction groups which occur as often as possible in the original program 52 and which correspond in terms of their instruction code sequences.
  • 3, for example, may contain two such instruction groups 54, 56, each of which has the instruction code sequence "ILOAD”, "ILOAD”, "IADD".
  • these command groups 54, 56 are each replaced by a macro command in the command code strand 34, and a corresponding entry 50 in the macro definitions 38 is generated.
  • the operands contained in the instruction group 54, 56 are transferred to the operand line 36.
  • the macro instruction 46 (FIG. 2) is formed from the original instructions U1-U3, and the operands of the second instruction group 56 are adopted as operands OD5.1 and OD5.2 in the operand line 36.
  • the aim of the optimization is to identify as many and as large as possible matching instruction groups in the original program 52.
  • a consideration is necessary here, as the number of matching command groups usually decreases with increasing size.
  • suitable heuristics or techniques of linear programming - however, a sufficiently good solution can be found. Since the operands of the optimized instruction groups 54, 56 do not have to match, a considerable code size reduction is possible in practical applications, which goes far beyond the relatively small savings in the example of FIG. 3.
  • Instructions of the original program 52 are generally adopted unchanged in the optimized program 32, with a splitting into the instruction code and, if present, the operand or operands.
  • command 48 (FIG. 2) corresponds to original command U4, and original command U10 was adopted unchanged in command code strand 34 with command code OC6.
  • An exception to the rule just mentioned is for jump instructions whose destination addresses must be adapted to the use of the composite instruction counter 40.
  • the jump instruction U6 of the original program 52 with a jump target offset of 8 bytes is converted during optimization into the jump instruction with the instruction code OC4, which has an offset of 3 bytes for the first instruction counter 42 and in in its first operand OD4.1 indicates its second operand OD4.2 an offset of 4 bytes for the second instruction counter 44.
  • the instruction code OC4 which has an offset of 3 bytes for the first instruction counter 42 and in in its first operand OD4.1 indicates its second operand OD4.2 an offset of 4 bytes for the second instruction counter 44.
  • FIG. 4 shows the process of program generation and optimization which begins with the known translation of a J ⁇ pß source program 58 by a compiler 60 into a class file 62.
  • the CAP file represents the original program 52, while in execution alternatives the optimization steps described above can already be carried out by the compiler 60 and / or the converter 64.
  • the original program 52 is imported into the data carrier 10 by an external loading program 66 via the interface circuit 14 during the manufacture or initialization or personalization of the data carrier 10.
  • the internal loader 30 controls the writing process into the non-volatile memory 20.
  • the internal loading program 30 also carries out the optimization steps described above, that is to say the generation of the optimized program 32 and the macro definitions 38 from the original program 52.
  • This has the advantage that the optimization described here is completely transparent to the user; the data carrier 10 therefore accepts all usual CAP files.
  • the optimization of the original program 52 can also be carried out by the external loading program 66 or by a further additional program. In this case, the optimization is carried out on an external computer, which as a rule provides considerably higher computing power than the data carrier 10.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Bei einem Verfahren zur Erzeugung eines optimierten Programms (32) aus einem ursprünglichen Programm (52) weist das optimierte Programm (32) einen Befehlscodestrang (34) mit Befehlscodes (OCx) und einen Operandenstrang (36) mit den zugehörigen Operanden (ODx.y) auf. Bei der Optimierung werden zumindest manche Befehlsgruppen (54, 56) des ursprünglichen Programms (52) in je einen Makrobefehl (46) des optimierten Programms (32) umgesetzt, wobei in dem Makrobefehl (46) die in der Befehlsgruppe (54, 56) enthaltenen Befehlscodes codiert sind und die Operanden (ODx.y) des Makrobefehls (46) den in der Befehlsgruppe (54, 56) enthaltenen Operanden entsprechen. Bei einem Verfahren zum Ausführen eines Programms (32), das insbesondere gemäss dem oben genannten Verfahren optimiert sein kann, ist die Verwendung eines ersten Befehlszählers für den Befehlscodestrang (34) und eines zweiten Befehlszählers für den Operandenstrang (36) vorgesehen. Ein Computerprogrammprodukt und eine Vorrichtung weisen entsprechende Merkmale auf. Die Erfindung verringert den zur Speicherung des Programms (32) erforderlichen Speicherplatz.

Description

Optimierung und Ausführung eines Pro ramms
Die Erfindung betrifft allgemein das technische Gebiet der Optimierung eines Programms und der Ausführung des optimierten Programms durch eine Maschine, die insbesondere eine virtuelle Maschine, aber auch ein unmittelbar in Hardware implementierter Prozessor sein kann. Spezieller betrifft die Erfindung die Programmoptimierung durch Verwendung von Makrooperationen, um den für das optimierte Programm benötigten Speicherplatz zu verringern. Ein bevorzugtes Einsatzgebiet der Erfindung ist die Programmausführung durch einen tragbaren Datenträger, der beispielsweise als Chipkarte in unterschiedlichen Bauformen oder als Chipmodul ausgestaltet sein kann.
Bei tragbaren Datenträgern und anderen ressourcenbeschränkten Systemen ist der zur Aufnahme von ausführbarem Programmcode vorgesehene Speicherplatz in der Regel nur knapp bemessen. Dies gilt insbesondere dann, wenn der Programmcode nicht in einem maskenprogrammierten ROM, sondern in einem nicht-flüchtigen, beschreibbaren EEPROM abgelegt werden soll, da auf heute gebräuchlichen Datenträgern wesentlich mehr ROM-Speicher als EEPROM-Speicher vorgesehen ist. Die Speicherung von Programmcode im EEPROM ist jedoch wünschenswert, weil dann eventuelle Änderungen des Programmcodes mit viel geringerem Aufwand in die Fertigung neuer Datenträger einfließen können.
Es ist bekannt, den zur Speicherung eines Programms benötigten Speicherplatz ("footprint" des Programms) durch einen Optimierungsdurchlauf zu reduzieren. Der Artikel "Liebling, ich habe den Code geschrumpft" von Christian Ferdinand und Reinhold Heckmann, erschienen in der Zeitschrift Design und Elektronik, Heft 01/2001, Seiten 113 bis 115, verfügbar unter htty://www.elektroniknet.de/fachthemen/pdf/pdf_^ beschreibt ein Optimierungsverfahren, bei dem wiederholt vorkommende Codestücke aus einem zu optimierenden Programm herausgezogen und durch ein gemeinsames Unterprogramm als Stellvertreter ersetzt werden. Ein ähnlicher Artikel in englischer Sprache von Christian Ferdinand mit dem Titel "Post Pass Code Compaction at the Assembly Level for Clβx" ist gegenwärtig unter http://www.spacetools.com/site/contact_v3_9/V3 _9p35.pdf 'verfügbar.
Das aus den gerade genannten Artikeln bekannte Verfahren ist jedoch darauf angewiesen, Befehlsgruppen zu finden, die sowohl hinsichtlich ihrer Befehlscodes als auch hinsichtlich der jedem Befehlscode zugeordneten
Operanden übereinstimmen. Dies schränkt die Optimierungsmöglichkeiten erheblich ein, da Befehlsgruppen, die z.B. identische Berechnungsfunktionen auf unterschiedlichen Daten ausführen, nicht als wiederholt vorkommende Codestücke angesehen werden. Es wäre daher wünschenswert, eine Code- größenoptimierung auch für solche Befehlsgruppen zu ermöglichen.
Die Erfindung hat demgemäß die Aufgabe, die Probleme des Standes der Technik zumindest zum Teil zu vermeiden und eine Technik zur Optimierung und Ausführung eines Programms bereitzustellen, die den zur Spei- cherung des Programms erforderlichen Speicherplatz möglichst stark verringert. In bevorzugten Ausgestaltungen soll die Erfindung relativ leicht zu implementieren sein und keinen oder allenfalls geringen Zusatzaufwand bei der Programmentwicklung verursachen.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren zur Erzeugung eines optimierten Programms gemäß Anspruch 1, ein Verfahren zum Ausführen eines Programms gemäß Anspruch 9, ein Computerprogrammprodukt gemäß Anspruch 14 und eine Vorrichtung gemäß Anspruch 15, die insbesondere als tragbarer Datenträger ausgestaltet sein kann. Die abhängigen Ansprüche betreffen bevorzugte Ausführungsformen der Erfindung.
Die Erfindung beruht auf der Grundidee, bei der Optimierung und bei der Ausführung des optimierten Programms die Befehlscodes von den Operanden zu trennen. Das optimierte Programm enthält mindestens einen Befehlscodestrang mit Befehlscodes und mindestens einen Operandenstrang mit Operanden. Bei der Optimierung werden Befehlsgruppen des ursprünglichen Programms gesucht, deren Befehlscodes sich durch je einen Makro- befehl zusammenfassen lassen. Die Operanden einer solchen Befehlsgruppe werden als Operanden des Makrobefehls in den Operandenstrang übernommen. Auf diese Weise ergeben sich deutlich mehr Optimierungsmöglichkeiten als im Stand der Technik, weil Befehlsgruppen schon dann zu Makrobefehlen zusammengefaßt werden können, wenn nur die Befehlscodefolgen - und nicht notwendigerweise auch die in den Befehlsgruppen enthaltenen Operanden - übereinstimmen.
Zur Ausführung des optimierten Programms ist erfindungsgemäß eine Maschine mit zwei Befehlszählern vorgesehen, von denen der erste dem Befehlscodestrang und der zweite dem Operandenstrang zugeordnet ist. Während oder vor oder nach der Ausführung jedes Befehls wird der erste Befehlszähler entsprechend der Anzahl der Befehlscodes im Befehlscodestrang weitergeschaltet, und der zweite Befehlszähler wird entsprechend der Anzahl der Operanden im Operandenstrang weitergeschaltet. Bei Befehlen, die keine Operanden aufweisen, ist diese "Weiterschaltung" des zweiten Befehlszählers natürlich nur konzeptuell zu verstehen, weil der Befehlszähler dann um "null Operanden" weitergeschaltet, also im Ergebnis nicht verändert wird. Dieses Prograrnmausführungsverfahren liefert die technischen Grundlagen, um Programme verarbeiten zu können, die gemäß der oben genannten Grundidee optimiert worden sind.
In bevorzugten Ausgestaltungen der Erfindung enthält das optimierte Programm Makrobefehle, die jeweils mehrere Befehle des ursprünglichen Programms ersetzen. Unter dem Begriff "Makrobefehl" soll im vorliegenden Dokument insbesondere jeder Befehl verstanden werden, der in seiner Wirkung der Wirkung mehrerer Einzelbefehle des ursprünglichen Programms entspricht. Ein Makrobefehl kann beispielsweise als spezielle Instruktion implementiert werden, die bereits in ihrem Befehlscode eine Information über die auszuführenden Einzelbefehle enthält, oder als allgemeine Instruktion, die erst in einem zweiten Befehlscodewort oder in einem Operanden die auszuführenden Einzelbefehle codiert. Insbesondere kann der Makrobefehl einen Unterprogrammaufruf oder einen Fangaufruf (trap) oder einen Befehlscode umfassen, der in einem vorgegebenen Befehlssatz für Erweiterungen reserviert ist.
Bei dem erfindungsgemäßen Optimierungsverfahren wird die Befehlscodefolge einer zu optimierenden Befehlsgruppe in einem Makrobefehl codiert. Dies bedeutet in der Regel nicht, daß sich die Befehlscodes ohne weitere Informationen aus dem Makrobefehl ableiten lassen. Der Makrobefehl enthält vielmehr vorzugsweise lediglich eine Referenz auf eine Makrodefinition, die ihrerseits die auszuführende Folge von Befehlscodes beinhaltet. In Ausführungsformen, bei denen der Makrobefehl als Unterprogrammaufruf ausge- staltet ist, wird das aufgerufene Unterprogramm als Makrodefinition angesehen.
In manchen Ausgestaltungen der Erfindung wird ein fest vorgegebener Satz von Makrodefinitionen verwendet, die Befehlssequenzen entsprechen, wel- che erfahrungsgemäß häufig benötigt werden. Bevorzugt werden jedoch die Makrodefinitionen - ausschließlich oder zusätzlich zu vorgegebenen Makrodefinitionen - beim Optimierungsvorgang erstellt. Solche beim Optimierungsvorgang erzeugten Makrodefinitionen sollen insbesondere Folgen von Befehlscodes codieren, die im ursprünglichen Programm möglichst häufig auftreten.
Die erfindungsgemäße Trennung des optimierten Programms in mindestens einen Befehlscodestrang und mindestens einen Operandenstrang entsteht vorzugsweise erst bei der Optimierung. In bevorzugten Ausführungsformen weist das ursprüngliche Programm diese Trennung nicht auf, sondern besteht aus einer Befehlsfolge, in der sich Befehlscodes und gegebenenfalls vorhandene Operanden im wesentlichen abwechseln. Dieser an sich übliche Wechsel zwischen Befehlscodes und Operanden ist im optimierten Pro- gramm gemäß der vorliegenden Erfindung aufgelöst.
Was die effektiv ausgeführten Befehle - nach Auflösung der Makrobefehle - angeht, entspricht der Programmfluß im optimierten Programm vorzugsweise dem Programmfluß im ursprünglichen Programm. Es werden daher bei der Programmoptimierung vorzugsweise Sprungbefehle und sonstige den Programmablauf beeinflussende Befehle derart erzeugt, daß sie sowohl ein Sprungziel im Befehlscodestrang als auch ein entsprechendes Sprungziel im Operandenstrang definieren.
Bestehende Prözessorarchitekturen können so angepaßt werden, daß sie erfindungsgemäß optimierte Programme als Maschinensprache ausführen. Grundsätzliche Schwierigkeiten sind damit nicht verbunden, wenngleich natürlich gewisse Arbeiten für die Entwicklung geänderter Hardwarestrukturen erforderlich sind. Mit besonders geringem Aufwand kann die Erfindung jedoch in einer virtuellen Maschine implementiert werden. Insbesondere ist vorgesehen, eine Java Card Virtual Machine an die erfindungsgemäß optimierte Programmstruktur anzupassen. Die genannte virtuelle Maschine ist - soweit die Ausführung nicht-optimierter Programme betrof- f en ist - gut bekannt; ausführliche Spezifikationen finden sich auf den Internet-Seiten der Firma Sun Microsystems, Inc., Palo Alto, USA, unter http://java.sun.com.
Der erfindungsgemäße Optimierungsprozeß kann prinzipiell in jeder Stufe der automatischen Programmumsetzung vorgenommen werden, beispielsweise durch einen Compiler, einen Konverter oder ein gesondertes Optimierungsprogramm. Besonders bevorzugt wird der Optimierungsvorgang jedoch von einem Ladeprogramm ausgeführt, das z.B. in einem tragbaren Datenträger, in den auch das auszuführende Programm eingeschrieben wer- den soll, enthalten ist. In diesem Fall braucht bei der gesamten Programmentwicklung keinerlei Rücksicht auf das erfindungsgemäße Optimierungsverfahren genommen zu werden; es wird vielmehr ein völlig normales unoptimiertes Programm - z.B. in Form einer sogenannten CAP-Datei - erzeugt, das auch von einem gewöhnlichen Datenträger ohne weiteres aus- geführt werden könnte. Wenn dieses Programm in einen erfindungsgemäß ausgestalteten Datenträger eingelesen wird, erfolgt automatisch die Optimierung.
Das erfindungsgemäße Computerprogrammprodukt weist Programmbe- fehle auf, um das erfindungsgemäße Optimierungs- und/ oder Ausführungsverfahren zu implementieren. Ein derartiges Computerprogrammprodukt kann ein körperliches Medium sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Das Computerprogrammprodukt kann z.B. ein Compiler oder ein Konverter oder ein Optimierungsprogramm zur Ausführung durch einen gewöhnlichen Arbeitsplatzcomputer oder ein optimierender Lader oder eine virtuelle Maschine zur Ausfüh- rung durch einen Prozessor eines tragbaren Datenträgers sein.
In bevorzugten Ausgestaltungen weisen der Datenträger und/ oder das Computerprogrammprodukt Merkmale auf, die den gerade beschriebenen und/ oder den in den abhängigen Verfahrensansprüchen genannten Merk- malen entsprechen.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden genauen Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen hervor. Es wird auf die schematischen Zeichnun- gen verwiesen, in denen zeigen:
Fig. 1 ein Blockdiagramm mit Funktionseinheiten eines tragbaren Datenträgers nach einem Ausführungsbeispiel der Erfindung,
Fig. 2 eine schematische Darstellung des Speicherinhalts bei der Ausführung eines Befehls in einem optimierten Programm,
Fig. 3 beispielhafte Ausschnitte eines ursprünglichen und des daraus erzeugten optimierten Programms,
Fig. 4 eine schematische Darstellung des Datenflusses bei der Programmerzeugung durch einen Compiler und bei der Optimierung. Der in Fig. 1 dargestellte Datenträger 10 ist im vorliegenden Ausführungsbeispiel als Chipkarte gemäß dem Java-Card-Standard ausgestaltet. Der Datenträger 10 weist auf einem einzigen Halbleiterchip einen Prozessor 12, mehrere in unterschiedlichen Technologien ausgestaltete Speicherfelder und eine Schnittstellenschaltung 14 zur kontaktlosen oder kontaktgebundenen Kommunikation auf. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein Arbeitsspeicher 16, ein Festwertspeicher 18 und ein nicht- flüchtiger Speicher 20 vorgesehen. Der Arbeitsspeicher 16 ist als RAM, der Festwertspeicher 18 als maskenprogrammiertes ROM und der nicht-flüch- tige Speicher 20 als elektrisch lösch- und programmierbares EEPROM ausgestaltet. Insgesamt ist der zur Verfügung stehende Speicherplatz relativ knapp bemessen.
Im Festwertspeicher 18 - und zum Teil auch im nicht-flüchtigen Speicher 20 - sind Systemprogramme 22 enthalten. In an sich bekannter Weise umfassen die Systemprogramme 22 ein Betriebssystem 24, das eine Vielzahl von hardwarenahen Funktionen und Diensten bereitstellt. Ein Codemodul 26 implementiert eine virtuelle Maschine, und zwar im vorliegenden Ausführungsbeispiel eine JCVM (Jαvα Card Virtual Machine). Eine Klassenbibliothek 28 ent- hält eine Reihe vordefinierter Anwendungsprogram-mierschnittstellen. Die im folgenden beschriebenen Optimierungsvorgänge werden im vorliegenden Ausführungsbeispiel von einem internen Ladeprogramm 30 durchgeführt, das sich im nicht-flüchtigen Speicher 20 befindet und das konzeptuell teils dem Betriebssystem 24 und teils dem JCVM-Codemodul 26 zuzuordnen ist.
Der betriebsbereite Datenträger 10 enthält im nicht-flüchtigen Speicher 20 ein optimiertes Programm 32, das mindestens einen Befehlscodestrang 34 und mindestens einen Operandenstrang 36 aufweist. Das Programm 32 ist hinsichtlich des im nicht-flüchtigen Speicher 20 statisch benötigten Speicherplatzes ("footprint") durch die Verwendung von Makrobefehlen optimiert worden. Makrodefinitionen 38, die die Bedeutung jedes Makrobefehls angeben, befinden sich ebenfalls im nicht-flüchtigen Speicher 20.
Bei der Ausführung des optimierten Programms 32 auf dem Datenträger 10 verwaltet die durch das Codemodul 26 implementierte virtuelle Maschine einen zusammengesetzten Befehlszähler 40 im Arbeitsspeicher 16. Der zusammengesetzte Befehlszähler 40 enthält einen ersten Befehlszähler 42, dessen Stand den jeweils aktuellen Befehlscode im Befehlscodestrang 34 angibt, und einen zweiten Befehlszähler 44, dessen Stand den jeweils aktuellen Operanden im Operandenstrang 36 angibt.
Die Verwendung des zusammengesetzten Befehlszählers 40 ist in Fig. 2 genauer dargestellt. Es ist dort beispielhaft ein erster Befehl 46 gezeigt, der sich aus einem Befehlscode OC1 im Befehlscodestrang 34 und zwei Operanden OD1.1 und OD1.2 im Operandenstrang 36 zusammensetzt. Ein zweiter Befehl 48 weist einen Befehlscode OC2 und einen einzigen Operanden OD2.1 auf. .
Vor der Ausführung des ersten Befehls 46 zeigen der erste und der zweite Befehlszähler 42, 44 auf den Befehlscode OC1 sowie auf den ersten Operanden OD1.1. Bei der Befehlsausführung werden die Befehlszähler 42, 44 weitergeschaltet, und zwar für den Befehlscodestrang 34 und den Operanden- sträng 36 getrennt je nach der Anzahl der Befehlscodes bzw. Operanden im ausgeführten Befehl. In dem Beispiel von Fig. 2 erfolgt bei der Ausführung des Befehls 46 also eine Weiterschaltung des ersten Befehlszählers 42 um ein Speicherwort und eine Weiterschaltung des zweiten Befehlszählers 44 um zwei Speicherwörter. Hierdurch wird der in Fig. 2 durch gestrichelte Pfeile angedeutete Zustand erreicht, in dem die Befehlszähler 42, 44 auf den Befehlscode OC2 bzw. den Operanden OD2.1 des nächsten auszuführenden Befehls 48 zeigen. Bei Befehlen, die keine Operanden aufweisen, wird der Wert des zweiten Befehlszählers 44 natürlich nicht verändert.
Fig. 3 zeigt größere Ausschnitte aus dem Befehlscodestrang 34 und dem Operandenstrang 36 des optimierten Programms 32. Die ersten beiden Befehle mit den Befehlscodes OC1, OC2 und den Operanden OD1.1, OD1.2, OD2.1 wurde bereits beschrieben. Ein dritter Befehl enthält lediglich den Befehlscode OC3 und keinen Operanden. Es folgen ein vierter Befehl mit dem Befehlscode OC4 und zwei Operanden OD4.1 und OD4.2, ein fünfter Befehl mit dem Befehlscode OC5 und zwei Operanden OD5.1 und OD5.2 sowie ein sechster Befehl, der nur den Befehlscode OC6 und keinen Operanden enthält.
Der zweite Befehl 48 (Fig. 2) sowie die Befehle mit den Befehlscodes OC3, OC4 und OC6 werden unmittelbar von der durch das Codemodul 26 implementierten virtuellen Maschine ausgeführt. Diese Befehle werden daher auch als "native" Befehle bezeichnet. Der erste Befehl 46 (Fig. 2) und der Be- fehl mit dem Befehlscode OC5 sind dagegen Makrobefehle, deren Wirkung jeweils durch eine Folge mehrerer nativer Befehle definiert ist. Die zur Ausführung eines Makrobefehls benötigten Zusatzinformationen sind in den Makrodefinitionen 38 enthalten; Fig. 3 zeigt beispielhaft eine Definition 50, die dem Makrobefehlscode "MAC2" des Befehls 46 die native Befehlscode- folge "ILOAD", "ILOAD", "IADD" zuordnet.
Im vorliegenden Ausführungsbeispiel ist die durch das Codemodul 26 implementierte virtuelle Maschine so ausgestaltet, daß sie Makrobefehle gemäß den jeweiligen Makrodefinitionen 38 in eine Folge nativer Befehle auflöst und letztere ausführt. Genauer greift die virtuelle Maschine bei der Ausführung eines Makrobefehls auf die entsprechende Makrodefinition - z.B. die Definition 50 - zu und arbeitet die darin enthaltenen Befehlscodes der Reihe nach ab, wobei je nach Bedarf - ebenfalls der Reihe nach - die im Operan- denstrang 36 gespeicherten Operanden herangezogen werden. Die Auswahl der jeweiligen Makrodefinition kann über den Befehlscode selbst oder über einen Zeiger oder Indexwert erfolgen, der entweder als ergänzender Befehlscode im Befehlscodestrang 34 oder als ergänzender Operand im Operandenstrang 36 gespeichert sein kann.
In Ausführungsalternativen kann auch vorgesehen sein, bei der Optimierung statt der Makrodefinitionen 38 eine geeignete Erweiterung für das Codemodul 26 zu erzeugen, so daß effektiv der Befehlssatz der virtuellen Maschine um die benötigten Makrobefehle - die dann wie native Befehle ausgeführt werden - ergänzt wird.
In Fig. 3 ist ferner ein Ausschnitt aus einem ursprünglichen Programm 52 gezeigt, durch dessen Optimierung das optimierte Programm 32 und die Makrodefinitionen 38 erzeugt wurden. Dieser Vorgang ist in Fig. 3 durch zwei dicke Pfeile angedeutet. Das ursprüngliche Programm 52 liegt in dem für virtuelle Maschinen nach dem Java-Card-Standard üblicherweise verwendeten Format vor. In Fig. 3 sind zehn Befehle Ul - U10 des ursprünglichen Programms 52 gezeigt, die jeweils mit einem Befehlscode beginnen. Die Befehle Ul, U2, U4, U6, U7 und U8 weisen ferner je einen Parameter auf, der jeweils unmittelbar auf den Befehlscode folgt.
Aufgabe des Optimierungsvorgangs ist es, Befehlsgruppen zu finden, die im ursprünglichen Programm 52 möglichst häufig vorkommen und die hinsichtlich ihrer Befehlscodefolgen übereinstimmen. In Fig. 3 sind beispiels- weise zwei solche Befehlsgruppen 54, 56 enthalten, die jeweils die Befehlscodefolge "ILOAD", "ILOAD", "IADD" aufweisen. Diese Befehlsgruppen 54, 56 werden bei der Optimierung durch jeweils einen Makrobefehl im Befehlscodestrang 34 ersetzt, und ein entsprechender Eintrag 50 in den Makrodefi- nitionen 38 wird erzeugt. Die in der Befehlsgruppe 54, 56 enthaltenen Operanden werden in den Operandenstrang 36 übernommen. Im Ergebnis wird z.B. der Makrobefehl 46 (Fig. 2) aus den ursprünglichen Befehlen Ul - U3 gebildet, und die Operanden der zweiten Befehlsgruppe 56 werden als Operanden OD5.1 und OD5.2 in den Operandenstrang 36 übernommen.
Das Ziel der Optimierung ist es, möglichst viele und gleichzeitig möglichst große übereinstimmende Befehlsgruppen im ursprünglichen Programm 52 zu identifizieren. Hier ist in der Regel eine Abwägung erforderlich, weil mit steigender Größe normalerweise die Anzahl der übereinstirnmenden Be- fehlsgruppen abnimmt. Durch an sich bekannte Techniken - z.B. geeignete Heuristiken oder Techniken der linearen Programmierung - kann jedoch eine hinreichend gute Lösung gefunden werden. Da die Operanden der optimierten Befehlsgruppen 54, 56 nicht übereinzustimmen brauchen, ist bei praxisnahen Anwendungen eine erhebliche Codegrößenreduktion möglich, die weit über die relativ geringe Einsparung bei dem Beispiel von Fig. 3 hinausgeht.
Befehle des ursprünglichen Programms 52, die bei der Optimierung nicht durch Makrobefehle ersetzt werden konnten, werden in der Regel unver- ändert in das optimierte Programm 32 übernommen, wobei eine Aufspaltung in den Befehlscode und - falls vorhanden - den oder die Operanden erfolgt. So entspricht beispielsweise der Befehl 48 (Fig. 2) dem ursprünglichen Befehl U4, und der ursprüngliche Befehl U10 wurde mit dem Befehlscode OC6 unverändert in den Befehlscodestrang 34 übernommen. Eine Ausnahme von der gerade genannten Regel besteht bei Sprungbefehlen, deren Zieladressen an die Verwendung des zusammengesetzten Befehlszählers 40 angepaßt werden müssen. So wird beispielsweise der Sprungbe- fehl U6 des ursprünglichen Programms 52 mit einem Sprungzielversatz von 8 Byte bei der Optimierung in den Sprungbefehl mit dem Befehlscode OC4 umgewandelt, der in seinem ersten Operanden OD4.1 einen Versatz von 3 Byte für den ersten Befehlszähler 42 und in seinem zweiten Operanden OD4.2 einen Versatz von 4 Byte für den zweiten Befehlszähler 44 angibt. Statt dieser relativ einfachen Ausgestaltung kann in Ausführungsalternativen eine kompaktere Darstellung von Sprungzieladressen vorgesehen sein, durch die neue Zählerstände der beiden Befehlszähler 42, 44 mit möglichst wenig Speicherbedarf definiert werden können.
Es versteht sich, daß bei der gesamten Ausführung des optimierten Programms 32 die Trennung zwischen dem Befehlscodestrang 34 und dem Operandenstrang 36 sowie die Existenz von zwei Befehlszählern 42, 44 berücksichtigt werden muß. Dies betrifft z.B. auch die Verwaltung von Rücksprungadressen in einem Stapelspeicher und die Ausführung sonstiger Befehle, die den Programmfluß steuern.
In Fig. 4 ist der Vorgang der Programmerzeugung und -Optimierung dargestellt, der mit der bekannten Übersetzung eines Jαpß-Quellprogramms 58 durch einen Compiler 60 in eine Klassendatei 62 beginnt. Ein Konverter 64, der oft auch als "Off-Card Virtual Machine" bezeichnet wird, wandelt die Klassendatei 62 - sowie gegebenenfalls benötigte Export-Dateien - in eine CAP-Datei (CAP = Converted Applet) um. Im vorliegenden Ausführungsbeispiel stellt die CAP-Datei das ursprüngliche Programm 52 dar, während in Ausführungsalternativen die oben beschriebenen Optimierungsschritte bereits durch den Compiler 60 und/ oder den Konverter 64 durchgeführt werden.
Das ursprüngliche Programm 52 wird bei der Herstellung oder der Initiali- sierung oder der Personalisierung des Datenträgers 10 von einem externen Ladeprogramm 66 über die Schnittstellenschaltung 14 in den Datenträger 10 eingespielt. Das interne Ladeprogramm 30 steuert den Schreibvorgang in den nicht-flüchtigen Speicher 20.
Im vorliegenden Ausführungsbeispiel führt das interne Ladeprogramm 30 überdies die oben beschriebenen Optimierungsschritte, also die Erzeugung des optimierten Programms 32 und der Makrodefinitionen 38 aus dem ursprünglichen Programm 52, aus. Dies hat den Vorteil, daß die hier beschriebene Optimierung für den Anwender völlig transparent ist; der Datenträger 10 nirnmt also alle üblichen CAP-Dateien an. In Ausführungsalternativen kann dagegen die Optimierung des ursprünglichen Programms 52 auch von dem externen Ladeprogramm 66 oder von einem weiteren Zusatzprogramm durchgeführt werden. In diesem Fall wird die Optimierung auf einem externen Computer ausgeführt, der in der Regel erheblich höhere Rechenleistung als der Datenträger 10 zur Verfügung stellt.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Erzeugung eines optimierten Programms (32) aus einem ursprünglichen Programm (52), das Befehle (Ux) mit Befehlscodes und Operanden aufweist, zur Verringerung des benötigten Speicherplatzes, wobei: das optimierte Programm (32) mindestens einen Befehlscodestrang (34) und mindestens einen Operandenstrang (36) aufweist, - jeder Befehl (46, 48) des optimierten Programms (32) aus mindestens einem Befehlscode (OCx) im Befehlscodestrang (34) und keinem, einem oder mehreren Operanden (ODx.y) im Operandenstrang (36) gebildet wird, bei der Optimierung zumindest manche Befehlsgruppen (54, 56) des ursprünglichen Programms (52) in je einen Makrobefehl (46) des optimierten Programms (32) umgesetzt werden, wobei in dem Makrobefehl (46) die in der Befehlsgruppe (54, 56) enthaltenen Befehlscodes codiert sind und die Operanden (ODx.y) des Makrobefehls (46) den in der Befehlsgruppe (54, 56) enthaltenen Operan- den entsprechen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß solche Befehlsgruppen (54, 56) des ursprünglichen Programms (52) optimiert werden, deren Folge von Befehlscodes im ursprünglichen Programm (52) mehrfach auftritt.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß Makrodefinitionen (38) vorgesehen sind, die jedem Makrobefehl (46) eine Folge von Befehlscodes zuordnen, die bei der Ausführung des Makrobefehls (46) abgearbeitet werden sollen.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekenn- zeichnet, daß die Makrodefinitionen (38) zumindest zum Teil im
Zuge der Optimierung des ursprünglichen Programms (52) erzeugt werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekenn- zeichnet, daß Sprungbefehle (U6) des ursprünglichen Programms
(52) in Sprungbefehle (OC4, OD4.1, OD4.2) des optimierten Programms (32) umgewandelt werden, die ein Sprungziel i Befehlscodestrang (34) und ein Sprungziel im Operandenstrang (36) des optimierten Programms (32) definieren.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß das ursprüngliche Programm (52) eine Folge von ineinander verzahnten Befehlscodes und Operanden aufweist.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das ursprüngliche und das optimierte Programm (52, 32) zur Ausführung durch eine virtuelle Maschine, insbesondere eine Java Card Virtual Machine, vorgesehen sind.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß das ursprüngliche Programm (52) beim Laden in einen Speicher (16, 18, 20) eines tragbaren Datenträgers (10) in das optimierte Programm (32) umgesetzt wird.
9. Verfahren zum Ausführen eines Programms (32) durch eine Maschine, wobei: das Programm (32) mindestens einen Befehlscodestrang (34) und mindestens einen Operandenstrang (36) aufweist, - die Maschine einen ersten Befehlszähler (42) für den Befehlscodestrang (34) und einen zweiten Befehlszähler (44) für den Operandenstrang (36) aufweist, jeder Befehl (46, 48) des Programms (32) mindestens einen Befehlscode (OCx) im Befehlscodestrang (34) und keinen, einen oder mehrere Operanden (ODx.y) im Operandenstrang (36) aufweist, und im Zusammenhang mit der Ausführung jedes Befehls (46, 48) der erste Befehlszähler (42) entsprechend der Anzahl der Befehlscodes (OCx) des Befehls (46, 48) im Befehlscodestrang (34) weiterge- schaltet wird und der zweite Befehlszähler (44) entsprechend der
Anzahl der Operanden (ODx.y) des Befehls (46, 48) im Operandenstrang (36) weitergeschaltet wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß zumindest manche Befehle (46, 48) des Programms (32) Makrobefehle (46) sind, von denen jeder bei einem Optimierungsvorgang aus mehreren in einem ursprünglichen Programm (52) vorgesehenen Befehlen (Ux) gebildet wurde, um den für das optimierte Programm (32) benötigten Speicherplatz zu verringern.
11. Verfahren nach Anspruch 9 oder Anspruch 10, dadurch gekennzeichnet, daß bei der Ausführung eines den Programmfluß verändernden Befehls (OC4, OD4.1, OD4.2) sowohl der erste als auch der zweite Befehlszähler (42, 44) auf je einen neuen Zählerstand gesetzt werden.
12. Verfahren nach einem der Ansprüche 9 bis 11, dadurch gekenn- zeichnet, daß das ausgeführte Programm (32) in einem Optimierungsverfahren nach einem der Ansprüche 1 bis 8 optimiert worden ist.
13. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekenn- zeichnet, daß die Maschine eine virtuelle Maschine, insbesondere eine Java Card Virtual Machine, ist.
14. Computerprogrammprodukt, das Programmbefehle aufweist, die einen Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 13 veranlassen.
15. Vorrichtung, insbesondere tragbarer Datenträger (10), mit einem Prozessor (12) und mindestens einem Speicher (16, 18, 20), wobei der Speicher (16, 18, 20) Programmbefehle enthält, die den Prozes- sor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 13 veranlassen.
PCT/EP2004/004400 2003-04-29 2004-04-26 Optimierung und ausführung eines programms WO2004097628A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04729435A EP1620798A2 (de) 2003-04-29 2004-04-26 Optimierung und ausführung eines programms

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2003119299 DE10319299A1 (de) 2003-04-29 2003-04-29 Optimierung und Ausführung eines Programms
DE10319299.9 2003-04-29

Publications (2)

Publication Number Publication Date
WO2004097628A2 true WO2004097628A2 (de) 2004-11-11
WO2004097628A3 WO2004097628A3 (de) 2005-06-16

Family

ID=33393977

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/004400 WO2004097628A2 (de) 2003-04-29 2004-04-26 Optimierung und ausführung eines programms

Country Status (3)

Country Link
EP (1) EP1620798A2 (de)
DE (1) DE10319299A1 (de)
WO (1) WO2004097628A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116466995A (zh) * 2023-06-16 2023-07-21 紫光同芯微电子有限公司 基于复合指令的指令及其操作数的优化方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0969357A2 (de) * 1998-06-30 2000-01-05 Sun Microsystems, Inc. Befehlsausführung mit Programmzähler und einem oder mehreren Datenzählern
US6263429B1 (en) * 1998-09-30 2001-07-17 Conexant Systems, Inc. Dynamic microcode for embedded processors

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0969357A2 (de) * 1998-06-30 2000-01-05 Sun Microsystems, Inc. Befehlsausführung mit Programmzähler und einem oder mehreren Datenzählern
US6263429B1 (en) * 1998-09-30 2001-07-17 Conexant Systems, Inc. Dynamic microcode for embedded processors

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DEBRAY S K ET AL: "COMPILER TECHNIQUES FOR CODE COMPACTION" ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS, ACM, NEW YORK, NY, US, Bd. 22, Nr. 2, März 2000 (2000-03), Seiten 378-415, XP001199871 ISSN: 0164-0925 *
FERDINAND C ET AL: "KOMPAKTIERUNG VON PROGRAMMCODE FUER MIKROCONTROLLER LIEBLING, ICH HABE DEN CODE GESCHRUMPFT" DESIGN UND ELEKTRONIK, MAGNA-MEDIA VERLAG. HAAR BEI MUENCHEN, DE, Bd. 1, 2001, Seiten 113-115, XP008043681 ISSN: 0933-8667 in der Anmeldung erwähnt *
ZASTRE M J: "COMPACTING OBJECT CODE VIA PARAMETERIZED PROCEDURAL ABSTRACTION" THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN THE DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF VICTORIA, XX, XX, 1995, Seiten I-VII,1, XP001199580 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116466995A (zh) * 2023-06-16 2023-07-21 紫光同芯微电子有限公司 基于复合指令的指令及其操作数的优化方法及装置
CN116466995B (zh) * 2023-06-16 2024-06-11 紫光同芯微电子有限公司 基于复合指令的指令及其操作数的优化方法及装置

Also Published As

Publication number Publication date
WO2004097628A3 (de) 2005-06-16
EP1620798A2 (de) 2006-02-01
DE10319299A1 (de) 2004-12-09

Similar Documents

Publication Publication Date Title
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
EP1088270B1 (de) Verfahren zur prüfung von java-bytecode-programmen auf sicherheitseigenschaften
DE2054835C2 (de) Steuereinrichtung in einem Prozessor einer Mehrprozessor-Datenverarbeitungsanlage
EP1497722B1 (de) Optimierung von compilergeneriertem programmcode
EP1738257B1 (de) Verfahren zum vermeiden von dateninkonsistenz zwischen zugriffen verschiedener funktionen einer anwendung auf eine globale variable in einer datenverarbeitungsanlage
DE19524402C2 (de) Programmausführungssteuereinrichtung mit einer Adressierbarkeit entsprechend einer M-reihigen Pseudo-Zufallszahlenfolge
DE2054947A1 (de) Adressenvorbereitungseinnchtung und verfahren und Speicherzugnffan forderungseinnchtung fur ein Infor mationsver arbeitungssystem
DE2548720C2 (de) Mikroprogramm-Steuerwerk
DE10234971B4 (de) Verfahren und Datenträger zum Erzeugen und Korrigieren von Programmcode
EP1709534B1 (de) Ausführung eines programms durch eine virtuelle maschine
WO1999012094A1 (de) Verfahren zum umsetzen eines objektcodes in einen programmcode
EP1620798A2 (de) Optimierung und ausführung eines programms
DE2249852A1 (de) Computersystem
DE10320062A1 (de) Speicherverwaltung bei einem tragbaren Datenträger
DE3104256C2 (de)
EP1543411B1 (de) Prozessor mit expliziter angabe über zu sichernde informationen bei unterprogrammsprüngen
EP1668494B1 (de) Verfahren und system zur sprachkonfigurierung eines computerprogramms
WO1997042574A1 (de) Verfahren zur codetransformation
DE19637883B4 (de) Datenverarbeitungsanlage zur Ausführung großer Programmsysteme
EP1516245B1 (de) Vorrichtung und verfahren zum verarbeiten einer sequenz von sprungbefehlen
DE102008044808B4 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers
EP1600855B1 (de) Erzeugen und Verwenden von Speicherbelegungsinformationen bei einem tragbaren Datenträger
DE2419836B2 (de) Schaltungsanordnung zur durchfuehrung von unterprogramm-sprungbefehlen in datenverarbeitungsanlagen
DE10254530A1 (de) Verfahren und System zur wissensbasierten Transformation von textuellen Programmen, die sich auf die Softwarekonfiguration eines verteilten Leitsystems beziehen
DE10145783A1 (de) Erzeugen einer Nachricht zur Fehlersuche bei einem tragbaren Datenträger

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004729435

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004729435

Country of ref document: EP