EP1620798A2 - Optimierung und ausführung eines programms - Google Patents
Optimierung und ausführung eines programmsInfo
- Publication number
- EP1620798A2 EP1620798A2 EP04729435A EP04729435A EP1620798A2 EP 1620798 A2 EP1620798 A2 EP 1620798A2 EP 04729435 A EP04729435 A EP 04729435A EP 04729435 A EP04729435 A EP 04729435A EP 1620798 A2 EP1620798 A2 EP 1620798A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- program
- instruction
- optimized
- operands
- macro
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
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
Description
Claims
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 |
PCT/EP2004/004400 WO2004097628A2 (de) | 2003-04-29 | 2004-04-26 | Optimierung und ausführung eines programms |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1620798A2 true EP1620798A2 (de) | 2006-02-01 |
Family
ID=33393977
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04729435A Withdrawn EP1620798A2 (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) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116466995B (zh) * | 2023-06-16 | 2024-06-11 | 紫光同芯微电子有限公司 | 基于复合指令的指令及其操作数的优化方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6467037B1 (en) * | 1998-06-30 | 2002-10-15 | Sun Microsystems, Inc. | Utilizing a program counter with one or more data counters for executing instructions |
US6263429B1 (en) * | 1998-09-30 | 2001-07-17 | Conexant Systems, Inc. | Dynamic microcode for embedded processors |
-
2003
- 2003-04-29 DE DE2003119299 patent/DE10319299A1/de not_active Withdrawn
-
2004
- 2004-04-26 EP EP04729435A patent/EP1620798A2/de not_active Withdrawn
- 2004-04-26 WO PCT/EP2004/004400 patent/WO2004097628A2/de active Application Filing
Non-Patent Citations (1)
Title |
---|
None * |
Also Published As
Publication number | Publication date |
---|---|
DE10319299A1 (de) | 2004-12-09 |
WO2004097628A3 (de) | 2005-06-16 |
WO2004097628A2 (de) | 2004-11-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
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 | |
DE10234971A1 (de) | 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 | |
WO2004097628A2 (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 | |
EP0671678A1 (de) | Projektierbare Bedienoberfläche |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL HR LT LV MK |
|
17P | Request for examination filed |
Effective date: 20051216 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: STOCKER, THOMAS |
|
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20080208 |
|
APBK | Appeal reference recorded |
Free format text: ORIGINAL CODE: EPIDOSNREFNE |
|
APBN | Date of receipt of notice of appeal recorded |
Free format text: ORIGINAL CODE: EPIDOSNNOA2E |
|
APBR | Date of receipt of statement of grounds of appeal recorded |
Free format text: ORIGINAL CODE: EPIDOSNNOA3E |
|
APAV | Appeal reference deleted |
Free format text: ORIGINAL CODE: EPIDOSDREFNE |
|
APAF | Appeal reference modified |
Free format text: ORIGINAL CODE: EPIDOSCREFNE |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH |
|
APBT | Appeal procedure closed |
Free format text: ORIGINAL CODE: EPIDOSNNOA9E |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06F 8/41 20180101AFI20180518BHEP |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
INTG | Intention to grant announced |
Effective date: 20180716 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20181101 |