JP2003515203A - Optimization of N-base type arithmetic expression - Google Patents

Abstract

(57) Abstract A method for arithmetic expression optimization receives a first instruction (80) formed for a first processor having a first base and including an operator and at least one operand. Stage, if all operands have no potential overflow (82) or if the operator is not sensitive to overflow, a second with a second base smaller than the first base Converting the first instruction (80) into a second instruction (88) optimized for the processor, and wherein at least one of the operands is subject to overflow, and the operator is If overflow sensitive, the method includes converting the third instruction (86), which is the source of the overflow, to a wider base. An apparatus for arithmetic expression optimization receives at least one memory having program instructions and a first instruction (80) formed for a first processor having a first base, and at least one operand Are not accompanied by a potential overflow (82), or if the operator is not sensitive to overflow, the first instruction is passed to a second base that is smaller than the first base. A second instruction (88) optimized for the second processor, wherein at least one of the operands is subject to overflow (84) and the operator is When sensitive, it includes at least one processor configured to use program instructions to convert the overflow instruction, third instruction (86), to a wider base.

Description

Detailed Description of the Invention

[0001] CROSS-REFERENCE This application to (art) related application is related to the following patents: entitled "Object-oriented instruction set for resource-limited device" Sussa and by Gerhard Wave 1999 February 2 U.S. patent application filed on April 15, 1997 by Levi and Schwabe, entitled "Virtual Machine with Reliably Distributed Bytecode Matching". The present invention relates to computer systems. More specifically, the present invention relates to optimization of n-base type arithmetic expressions.

BACKGROUND ART The preparation of a computer program is shown in FIG. The user writes the program in the high level programming language 10. A program written in the high-level programming language 10 is compiled into a low-level machine language 12 that can be executed by a target computer. For example, a program written in the high-level Java (registered trademark) programming language is compiled into low-order bytecode instructions. A bytecode instruction is a machine language for “Java (registered trademark) virtual computer”. "Java (
"Registered Trademark) Machine Language Specification" is described in Second Edition "Java Machine Language Specification" by Lindholm et al., Published by Addison Wesley in 1999.

Common high-level programming languages support arithmetic expressions. Arithmetic expressions are formed by arithmetic operators that operate on one or more operands. Commonly supported operators are addition, subtraction, multiplication, division, remainder, negate, shift,
Bit-type logical sum, bit-type logical product, and bit-type exclusive logical sum are included. Intermediate values are the result of one or more arithmetic operations. Higher level languages also generally support multiple or n-based integer types, with arithmetic operations overloaded. Overloading allows operators to accept operands with mixed types. For example, the Java programming language supports four base integer types: byte, short, int, and long. These types support 8, 16, 32, and 64-bit values, respectively. Operators such as the "+" operator will accept any operand of these integer types. The following three examples show overloading of the "+" operator for operations on operands with mixed base types. int a, b; a + b; short a, b; a + b; byte a, b; a + b;

This overload generally spreads the values to a wider base type, then
It is done by performing arithmetic operations. For example, "C" and Java compilers typically assign values of type byte and short to type int.
Spread to. In the Java language, the type int is always 32 bits. That is, a 16-bit value of type short and 8 of type byte
A bit value is expanded to a 32-bit type int before performing an arithmetic operation. In the Java language, the following bytecodes are generated for each of the three examples listed above. iload a iload b iadd

The iload instruction loads either an 8, 16 or 32-bit variable,
Put a 32-bit operand on the stack. The iadd instruction takes two 32-bit operands from the stack, adds them together, and places the 32-bit result back on the stack. Unlike Java, some high-level languages only specify the relationship between integer types, not the size of each type. For example, one of the "C" compiler vendors may specify the bit sizes of the byte, short, and int types to be 8, 16, and 32 bits, respectively. However, other "C" compiler vendors will specify the same type sizes as 16, 32, and 64 bits, respectively. Yet another compiler may define its bit size to be 16, 32, and 32 bits, respectively. In all cases, the relationship between the sizes of each type is maintained (number of values represented by type byte <number of values represented by type short, number of values represented by type short <type int , The actual number of bits used to represent each type may vary. However, like Java (registered trademark),
C "performs arithmetic operations on int-type sizes defined by each particular compiler. This requires extending values with smaller base types to type int.

This type expansion technique reduces the number of machine instructions and thus the target computer complexity. However, this type extension generally requires more computational stack space. For example, adding two 16-bit values of type short after they have been expanded to a 32-bit type is a stack space that adds two 32-bit values of type int, as shown in FIGS. 2A and 2B. Use the same amount.

Referring now to FIG. 2A, there is shown a flow diagram illustrating stack usage when adding two 16-bit values of type short in the Java language. At reference numeral 20, the first 16-bit operand is loaded and pushed onto the operand stack. The operand stack at this point is indicated by reference numeral 30. At reference numeral 22, the first 16-bit operand is expanded to 32 bits. At reference numeral 24, a second 16-bit operand is loaded and pushed onto the operand stack. At reference numeral 26, the second 16-bit operand is expanded to 32 bits. At this point, the operand stack occupies 4x16 = 64 bits. At reference numeral 28,
The two 32-bit operands are added using the 32-bit add operator.

Referring now to FIG. 3A, there is shown a flow diagram illustrating stack usage when adding two 32-bit values of type int. At reference numeral 40, the first 32-bit operand is loaded and pushed onto the operand stack. This operand stack is shown in Figure 3B. At reference numeral 42, a second 32-bit operand is loaded and pushed onto the operand stack. At reference numeral 44, the two 32-bit operands are added using the 32-bit add operator. That is, in both the 16-bit add and 32-bit add examples above, the two 32-bit operands are pushed onto the stack before they are popped from the stack and added using the 32-bit add operation.

During the course of program execution, the size of the stack is sized due to factors such as the level of nesting procedure invocation, the complexity of the calculated expression, and the number of locally represented variables. It may fluctuate. In resource limited devices such as smart cards, there is generally insufficient memory available to perform calculations such that type expansion is performed. Resource limited devices are generally considered to have relatively limited memory and / or computational power or speed when compared to typical desktop computers and the like. By way of example, other resource limited devices include cellular telephones, border scanning devices, outdoor programmable devices, personal digital assistants (PDAs).
), And pagers and other small or small satellite radio equipment.

Smart cards, also known as clever portable data carrying cards, generally
It is made of plastic or metal and has an electronic integrated circuit including an embedded microprocessor or microcontroller for executing programs and a memory for storing programs and data. Such devices, which can be approximately credit card sized, have computer integrated circuits with 8-bit or 16-bit architectures. Furthermore, these devices generally have a limited storage capacity. For example, some smart cards have less than 1 kilobyte (1K) of random access memory (RAM) as well as limited ROM (ROM) and / or non-volatile such as electrically erasable ROM (EEPROM). It has a memory.

Moreover, smart cards with 8-bit or 16-bit architectures typically have built-in 8-bit or 16-bit arithmetic operations, respectively. Therefore, smart cards are typically able to perform 8-bit or 16-bit operations more efficiently than 32-bit operations. Performing 32-bit operations on data expanded to 32 bits is particularly inefficient. That is, the limited architecture and memory of resource limited devices such as smart cards make it impractical or impossible to execute programs whose values have been extended to larger integer types.

The “Java Machine Language” instruction set forms the arithmetic instruction set for processing integer type values of byte, short, and int. Variables of type byte and short are expanded to the integer type int during editing. Conversely, "Java Card (registered trademark) (a smart card supporting the Java (registered trademark) programming language) virtual machine" adds a variable of types byte and short in addition to an instruction set that handles variables of integer type int. Form another set of instructions to process. Most of the "Java Card (R)"
The application operates on data values of type short or byte.

In the computer industry, the same program can be run on a resource limited device, thus running on a relatively memory rich desktop computer so that interoperability across vertical platforms is achieved. There is an increasing tendency to support high-level computer languages intended to be. This interoperability across vertical platforms comes into play when programs written in high-level programming languages are executed on resource-limited devices, if they were executed on relatively memory-rich devices. It is necessary to show the same results as the wax. For example,
It is necessary to support the execution of programs written in the Java programming language on various platforms, including smart card platforms, handheld devices, consumer appliances, desktop computers, and supercomputers. is there. Therefore, there is a need to change program representations so that semantically equivalent mathematical representations can be performed using less computational stack space. Moreover, there is a need in the prior art to make such modifications to increase execution speed.

DISCLOSURE OF THE INVENTION A method of arithmetic expression optimization includes receiving a first instruction formed for a first processor having a first base and including an operator and at least one operand. , For all processors with no potential overflow, or if the operator is not sensitive to overflow, for a second processor with a second base smaller than the first base. Converting the first instruction to an optimized second instruction, and if at least one operand is potential overflow and the operator is sensitive to overflow It includes converting the third source of overflow to a wider base. An arithmetic optimization device receives at least one memory having a program instruction and a first instruction formed to a first processor having a first base, and at least one of the at least one operand. Is not associated with a potential overflow, or if the operator is not sensitive to overflow, then the first instruction has a second base with a second base smaller than the first base.
To a second instruction optimized for other processors, if at least one operand is potentially overflow and the operator is sensitive to overflow. At least one processor configured to use the program instructions to translate the third instruction, which is the source of

BEST MODE FOR CARRYING OUT THE INVENTION Those skilled in the art will appreciate that the following description of the invention is merely exemplary, and would benefit from the disclosure of the invention. For, other embodiments of the invention will be readily suggested. The present invention relates to computer systems. More specifically, the present invention relates to optimization of n-base type arithmetic expressions. The invention further relates to a machine-readable medium having (1) the layout parameters of the invention and / or (2) program instructions for using the invention in performing an operation on a computer. Such media include, by way of example, magnetic tape, magnetic disk, CD / RO.
Optically readable media such as M, and semiconductor memories such as PCMCIA cards are included. The medium may also take the form of a portable item such as a small disk, diskette, or cassette. This medium may also take the form of larger or stationary items such as a hard disk drive or computer RAM.

Resource-limited devices, when compared to ordinary desktop computers,
It is generally considered to be a relatively limited memory and / or computing power or speed. Although the particular embodiments discussed below are described with respect to smart cards, the present invention can be used with other resource-limited devices, including, but not limited to, cellular telephones, border scanning. Devices, outdoor programmable devices, personal digital assistants (PDAs), and pagers,
Other small or small satellite radio devices are included. The present invention can also be used on non-resource limited devices. For the purposes of disclosing the present invention, the term "processor" may be used to mean a physical computer or virtual machine.

Referring now to FIG. 4A, there is shown a block diagram illustrating the steps of transforming an arithmetic expression for execution on a resource limited computer according to one embodiment of the invention. The compiler takes an arithmetic expression 60 written in a high level language 62, expands its operands into larger integer types, and produces larger base type instructions 64 for execution on a typical desktop computer 66. This larger base type instruction 64 is optimized into a semantically equivalent smaller base type instruction 68 for execution on resource limited computer 70. For example, a short type add instruction is used to operate on a short type operand and the result is of type short.

According to another embodiment of the invention, optimization to semantically equivalent smaller base type instructions is part of the just-in-time code generator. Shortly before the instruction set is first executed, the non-optimized instructions are optimized into smaller, semantically equivalent base type instructions for execution on a resource limited computer. Subsequent executions of the same instruction set will use that optimized instruction set. According to another embodiment of the invention, if a larger typed instruction 64 is needed to preserve the meaning of an arithmetic instruction, and the larger typed instruction is not supported by the targeted processor, the expression is , Rejected as unsupported.

Referring now to FIG. 4B, there is shown a block diagram illustrating the steps of translating instructions in accordance with one embodiment of the present invention. A Java class file 72 containing instructions with 32-bit operands is received by a "Java Card" class file converter 74. This converter 74
Generate instructions 76 optimized for execution on a resource limited device. This optimization includes, by way of example, preparing for less stack usage, smaller program size, and faster execution.

The target calculator will support n types of arithmetic operations. "Jav
"a (registered trademark) virtual machine" supports the type int operator, but "Ja
The "va Card virtual machine" supports a type short operator and optionally a type int operator. Other devices are byte
Only type arithmetic operators may be supported, or all byte, short, and int type operations may be supported. Generally, it takes a relatively small amount of time to perform 16-bit arithmetic on an 8-bit or 16-bit processor, and a relatively large amount of time to perform 32-bit arithmetic on the same processor. is necessary.

Since the actual values used for arithmetic operations are unknown during optimization, the optimization must assume the worst case value for each operand. The worst case value for the operand is determined based on the input operand type. Small type operations may have consequences that require large type representations or overflows to larger types. That is, according to the present invention, arithmetic operators are classified into operators that are affected by overflow and operators that can cause overflow. For purposes of disclosing the present invention, overflow includes negative value sub-overflow. It is said that the result of a small type operation involves a potential overflow if the operator used to produce the result belongs to a group of operators that can cause overflow to the large type display. Be seen. Intermediate values are allowed to carry a potential overflow, unless the intermediate value is used as an operand for an operator belonging to a group of operators affected by overflow.

Operators that can cause overflow include add, subtract, multiply, divide, negate, and left shift. The Java bytecodes for these operators are shown in Table 1.

(Table 1) Operations involving potential overflow

The operators that are affected by overflow are shown in Table 2. The arithmetic operators affected by carry over include divide, remainder, negate, right shift, and unsigned right shift. The non-arithmetic operators affected by the overflow include array operation, switch operation, and comparison operation.

(Table 2) Operations affected by overflow

When optimizing the operations in Table 1 for smaller types, the results may overflow into larger types. The result of an expression using one of the operators in Table 2 will lose precision if one of the operands in the expression is an intermediate value and contains potential overflow data. In order to enable optimization and preserve the meaning of the high-level source code, potential overflow causes an explicit source-level effect on the type of result when it is entered into one of the operations in Table 2. It is necessary to correct it using the pattern.

If the input operand to any of the operations in Table 2 is the result of the operation in Table 1 and there is no explicit high-level source code type, then optimization cannot occur. Such a false optimization would not guarantee semantically equivalent results. In other words, the optimized code generated to run on a resource limited device could have different results than the non-optimized code generated for a desktop computer. For example, overflow data can be stored in the operand Java (
It can be provided in a registered trademark) 32-bit representation, but not in a "Java Card (R)" 16-bit representation.

The results of operations using the operators listed in Table 1 may result in overflow when operators with smaller types are applied. Examples of these problems associated with optimizing instructions targeted for desktop computer platforms to those targeted for resource limited computer platforms are:
Given in FIGS. 5A-8B. These examples assume that the desktop computer is based on a 32-bit architecture and is relatively memory rich. Resource limited computers have relatively little memory 16
It is assumed to be based on bit architecture. Those skilled in the art will recognize that the present invention applies to computing platforms with various architectures. 5A-8B also use values with signs. Those skilled in the art will also recognize that overflow can occur with or without the sign of the value.

Referring now to FIG. 5A, two types s on a desktop computer
A code sample illustrating the addition of the value of hort is shown. The value "a" contains the maximum value that can be represented in a 16-bit signed short type. As described above, int type addition is used even if the value is a 16-bit short value. That is, there is an overflow in the resulting value from the 16-bit range to the 32-bit range, and the effect of the overflow is to produce a larger positive 32-bit number.

Referring now to FIG. 5B, a code sample illustrating the steps of adding the same values as in FIG. 5A on a resource limited computer is shown. Since the execution is on a resource limited computer and both values are 16-bit short type, the instructions are optimized with short type additions and thus use less stack space. However, because 16-bit addition is used instead of 32-bit addition, the addition causes a sign bit overflow. The desktop computer calculated the value 32,768, while the result calculated on the resource limited computer example is a negative number -32,768. This result is unacceptable because, unlike the results for desktop computers, it interferes with interoperability across diverse computer platforms.

Referring now to FIG. 6A, a code sample illustrating the addition of the values of two type shorts and the step of immediately putting the result into the type is shown. This example is similar to that of FIG. 5A, except that the result of the addition is typed into type short. Type the type into short, the most significant 16 bits are short
Rounded down to a value and the code spreads to a 32-bit value. Operations (potentially overflow)
The result of the add operation) is typed into type short, thereby eliminating any potential overflow problem. FIG. 6B illustrates adding the same values as in FIG. 6A, represented as 16-bit values on a resource limited computer. The resulting values for both desktop and resource limited computers are the same.

Referring now to FIG. 7A, three types s on a desktop computer
A code sample illustrating the addition of the value of hort is shown. In this example,
An int type addition is used to add the 16-bit short values “a” and “b” and the result to “c”. The final result is typed into the short type. Referring now to FIG. 7B, a code sample illustrating the steps for performing an operand overflow-insensitive operation caused by a potentially overflow operation on a resource limited computer is shown. All values in this example are 16
Since it is a bit short type, it is short for all intermediate additions.
Type of addition is used. As shown in Table 1, the addition operator potentially causes overflow, but is not affected by overflow. That is, adding "a" and "b" creates a value with potentially overflow. This value is added to "c" to create another value, potentially with overflow. The second add operation potentially contains one operand with overflow (the result of a + b), but the add operation is unaffected by the operand with overflow. The final result is typed into type short to remove potential overflow from the add operation. That is, the resulting values for both the desktop computer and the resource limited computer are the same.

Referring now to FIG. 8A, two types s on a desktop computer
A code sample is shown that illustrates the addition of the value of hort and the division of the result by the value of type short. Since the execution is performed on the desktop computer, the int type operation is used. The values of "a" and "b" are int
These intermediate values are added together using type add and are divided by "c]. Referring now to Figure 8B, caused by a potentially overflowing operation on a resource limited computer. A code sample illustrating the steps of performing an operation that is sensitive to operand overflow is shown.Since execution is on a resource limited computer, a short type operation is used.
And the values of "b" are added to each other using a short type add. This addition produces an intermediate value that overflows the 16-bit range. This intermediate value is divided by "c". Unlike the addition operator used in FIG. 7B, the division operator is sensitive to overflow, as shown in Table 2. This 16-bit value is considered negative because the high bits contain the value. That is, the desktop and resource limited computer examples give different results, uncorrected by the type conversions represented by the programs as in FIGS. 6A-7B.

According to the present invention, the arithmetic expression is optimized using the type of instruction that is optimal depending on the type of operand. The optimization process proceeds until a potential overflow problem is encountered. At that point, we return to the input operand of the arithmetic expression and convert it to the next larger typed instruction. This process is repeated until the appropriate type of instruction is selected such that the arithmetic expression uses the optimized instruction set to produce the same result on the desktop computer and the resource limited device.

Some relationships are maintained during the conversion process. These relationships relate to instructions and the values that will occur when the instructions execute on the targeted computer. The relational data includes the actual type and target type for the value. Relational data also includes source instructions that, once executed on the target computer, will produce a value on the target computer. Each instruction is also linked to its operand-related data. Furthermore, the relevant data about the result is linked to the instruction that consumes the result. Each relational data is also linked to the instruction (if any) that would result in a potential overflow if the instruction were executed on the target computer. This instruction is called the rollback point. Linking each of the values that is to be produced with the instruction that caused the overflow, as erroneous end results can be produced if a value with a potential overflow is consumed by an overflow-sensitive operator. This gives a way to roll back to the instruction that caused the overflow problem when the conversion process cannot proceed.

Intermediate values can be further consumed as operands in subsequent instructions. Rollback instructions are also propagated in the result if the intermediate value potentially carries overflow. This is repeated in the process of transforming the representation. This rollback action always works on intermediate values (or operands) and rolls back to the instruction at which retranslation is required. Other details of how to determine the rollback instruction and optimization are discussed below.

Referring now to FIG. 9, there is shown a flow diagram illustrating n-base type arithmetic expression optimization according to one embodiment of the present invention. At reference numeral 80, an instruction to be translated is received. At reference numeral 82, a determination is made as to whether any of the input operands carry a potential overflow. If at least one operand has a potential overflow, then a determination is made at reference numeral 84 as to whether the instruction being translated is sensitive to overflow. The Java bytecodes for these are listed in Table 2. Those skilled in the art will appreciate that the list of operators affected by overflow can vary for different high level languages, and the invention can be applied to these other languages as well.

If the instruction to be converted is overflow sensitive, the conversion process is rolled back to the instruction that is the source of the problem at reference numeral 86, and the instruction is converted using the type with the wider base. It For example, an 8-bit byte type would be expanded to a 16-bit word type, and a 16-bit word type would be expanded to a 32-bit word type. Extending an operand to a larger type requires subsequent instruction conversion of the operand to use an instruction that is bound to the larger type.

If the instruction to be translated is not overflow sensitive, or if no input operand has a potential overflow, the instruction is referenced 88 for execution on the resource limited device. Converted to the most optimal type. At reference numeral 90, a determination is made as to whether there are more instructions to be translated. If more instructions remain, the conversion of the next instruction begins at reference numeral 80. When the last instruction is converted, the conversion process ends at reference numeral 92.

Referring now to FIG. 10, there is shown a detailed flow chart illustrating n-base type arithmetic expression optimization according to one embodiment of the present invention. At reference numeral 100, an indication is made that the conversion is not complete. At reference numeral 102, an indication is made that a translation of the first instruction should be performed. At reference numeral 104, it is determined whether the instruction conversion is complete. If the instruction conversion is complete, execution ends at reference numeral 106. If the conversion is not complete, an indication that the conversion is complete is made at reference numeral 108. At reference numeral 110, a first instruction is obtained. At reference numeral 112, a determination is made whether the instruction should be translated.

If the instruction needs to be translated, an indication that the translation is incomplete and an indication that the current instruction should not be translated is made at reference numerals 114 and 116, respectively. At reference numeral 118, the instruction is translated into another instruction having a smaller base type and optimized for the target computer. At reference numeral 120, a determination is made as to whether rollback was triggered by the conversion at reference numeral 118. If a rollback has been triggered, the instruction at the rollback point is obtained at reference numeral 122 and the translation of the instruction at the rollback point is restarted at reference numeral 104. If no rollback is triggered, the result type and target type are matched at reference numeral 124. Reference number 126
Then, the conversion information is transmitted to the subsequent instruction of each control path. At reference numeral 128, a determination is made as to whether more instructions remain.
If there are more instructions remaining, the next instruction is obtained at reference numeral 130 and execution continues at reference numeral 112. The conversion process ends when the last instruction is converted.

Referring now to FIG. 11, a flowchart illustrating the steps of translating instructions according to one embodiment of the present invention is shown. At reference numeral 140, it is determined whether the current instruction is an arithmetic instruction. If the instruction is an arithmetic instruction, it is translated at reference numeral 142. Similarly, the stack manipulation instruction, the target instruction, the type conversion instruction, and the initial value conversion instruction are converted by reference numerals 146, 150, 154, and 158, respectively. Classification of instructions depending on whether the instruction is an arithmetic instruction, a stack manipulation instruction, a type conversion instruction, or an initial value instruction in FIG. 11 is shown for illustrative purposes only. Those skilled in the art will appreciate that the present invention is applicable to many other instruction types or classifications as well.

Referring now to FIG. 12A, there is shown a flow chart illustrating a method of translating a target instruction according to one embodiment of the present invention. In the “Java (registered trademark) virtual machine” instruction set, the target instructions include branch, switch, array access, array creation, and various storage / save instructions (store / put instructions), stack operation instructions, It includes type conversion instructions, initial value instructions, or any other type-sensitive non-arithmetic instructions in computer languages that are not arithmetic expressions.

At reference numeral 160, the target type for the instruction operand is determined.
At reference numeral 162, a determination is made as to whether the operand consumed by the target instruction has a type less than the target type of the target instruction. If the operand has a smaller type than the target, the conversion process is rolled back at reference numeral 164 with the smaller type operand. If the operand does not have a smaller type than the target, then a determination is made at reference numeral 166 as to whether the operand has a potential overflow. An operand may have a potential overflow if it was created by one of the operands listed in Table 1 or by an operator that propagates the overflow within the operand. Operators that propagate overflow include, by way of example, "and", "or", and exclusive "or" (xor) operators. If none of the operands have a potential overflow, the instruction is optimized at reference numeral 167. If at least one of the operands is potentially overflowed, the conversion process is rolled back at 164 with the smaller operand.

Referring now to FIG. 12B, there is shown a flow chart illustrating a method of converting an initial value instruction according to one embodiment of the present invention. Examples of initial value instructions include get / load instructions (get / load instructions) and other instructions that load variables. Initial value instructions also include method call instructions that return the results of the method. Further, the initial value instruction includes a load constant instruction. These instructions are called "initial value" instructions because the values they produce are not the result of intermediate calculations. At reference numeral 168, a variable, return value, or constant type is received. At reference numeral 169, the initial value instruction is optimized according to the type of variable or constant. For example, to load a short type local variable, the iload instruction is optimized for sload.

Referring now to FIG. 13, a flowchart illustrating a method of converting type conversion instructions according to one embodiment of the present invention is shown. A type conversion instruction may convert an operand to a larger type or a smaller type. For example, casting a 32-bit int type into a 16-bit short type converts the operand to a smaller type. Similarly, casting an 8-bit byte type into a 32-bit int type converts the operand to a larger type. In the latter case, the byte type is called the operand type and the int type is called the target type.

At reference numeral 170, an instruction is received. The operand type and target type are determined at reference numerals 172 and 174, respectively. If the operand type is greater than the target type, the operand type is reference number 178.
You can narrow down to the target type. If the operand type is less than the target type, a determination is made at reference numeral 180 as to whether the operand potentially has overflow. If the operand potentially carries overflow, the conversion process is rolled back at reference numeral 182 to correct the type. If the operand type does not involve a potential overflow, the operand is extended to the target type at reference numeral 184.

Referring now to FIG. 14, a flow chart illustrating a method of translating stack manipulation instructions according to one embodiment of the invention is shown. In the “Java (registered trademark) virtual machine” instruction set, the stack operation instructions are “dup (copy)”, “
Includes "swap" and "pop" instructions. At reference numeral 190, an instruction is received. At reference numeral 192, a determination is made as to whether the instruction is a dup instruction. If the instruction is a dup instruction, then at reference numeral 194, a determination is made as to whether there is a rollback point for the original stack entry. If the original stack entry has a rollback point, the rollback point of the duplicated stack entry is at reference numeral 196,
Set to the rollback point of the original stack entry. If the original stack entry has no rollback point, the rollback point of the duplicated stack entry is set at reference numeral 198 to the source instruction of the original stack entry. At reference numeral 200, the instruction is translated.

Referring now to FIG. 15, a flow chart illustrating a method of transforming an arithmetic expression according to one embodiment of the present invention is shown. At reference numeral 210, a determination is made as to whether the operand has a potential overflow. If the operand does not have a potential overflow, reference numeral 212 makes an indication that the operand does not have a potential overflow. Reference number 214 if the operand involves a potential overflow
Then, a decision is made as to whether the instruction is affected by overflow. If the instruction is not affected by overflow, reference numeral 216 makes an indication that the operand has a potential overflow. If the instruction is overflow sensitive, this conversion is rolled back at reference numeral 218 to the first operand with overflow. If the translation is not rolled back, the optimized instruction type is determined at reference numeral 220, the instruction is optimized at reference numeral 222, and the result type and result overflow are determined at reference numeral 224.

Referring now to FIG. 16, there is shown a flow chart illustrating a method of determining an optimized instruction type according to one embodiment of the present invention. At reference numeral 230, at least one operand is received. At reference numeral 232, the target instruction type is set to the largest type associated with that operand. Reference number 23
At 4, a determination is made as to whether any of the operands have a type that is less than the target instruction type. If at least one operand has a smaller type than the target type, the smaller operand is rolled back at 236 to correct the type.

Referring now to FIG. 17, there is shown a flow chart illustrating a method of determining result type and result overflow according to one embodiment of the invention. At reference numeral 240, the result type is set to the instruction type. The "Java Card (R)" returned result types and overflow indications are summarized in Tables 3-10 below. These tables are organized by instruction type. Each table has 1
Shows the result type and the overflow indicator based on the type of one or two operands

(Table 3) Addition, multiplication and subtraction

(Table 4) Division

(Table 5) Left shift

(Table 6) Right shift

(Table 7) Negate

(Table 8) Right shift without code

(Table 9) Remainder

(Table 10) and, or, and xor

The use of “Java Card®” result types and overflow indicators in FIG. 17 is for illustration purposes only. Those skilled in the art will recognize that the present invention is applicable to other high level languages having other types. At reference numeral 244, a determination is made as to whether the result potentially involves overflow due to the use of more optimized instructions. If the result does not involve a potential overflow, then at reference numeral 246, a determination is made as to whether any of the operands convey an overflow. If at least one operand conveys a carry, or if the result is potentially carry, a rollback point for the result is recorded at reference numeral 248, with an indication that the result has a potential carry. Made with reference numeral 250.

Referring now to FIG. 18, a flowchart illustrating a method of recording rollback points according to one embodiment of the present invention is shown. At reference numeral 260, a determination is made as to whether the first operand has a rollback point associated with it. If the first operand has a rollback point associated with it, then the rollback point of the current instruction is set at reference numeral 262 to the rollback point of the first operand. If the first operand does not have an overflow associated with it, then at reference numeral 264, a determination is made as to whether the second operand has an overflow associated with it. If the second operand has a rollback point associated with it, the rollback point of the instruction is set at reference numeral 266 to the rollback point of the second operand. If neither operand has a rollback point associated with it, the rollback point of the instruction is set at 268 to the source instruction for the first operand.

According to a particular embodiment of the invention, as shown in FIG. 18, a “first operand”
Means the first created operand. Setting the rollback point on the source instruction for the older operand can correct the type associated with the older operand, thereby correcting the type that the newer operand will subsequently use, thus adding additional space to the newer operand. It would eliminate the need to perform rollback operations.

Referring now to FIG. 19, there is shown a flow chart setting up a method for rolling back a conversion process in accordance with one embodiment of the present invention. At reference numeral 270, the translation of the current instruction is interrupted. At reference numeral 272, a determination is made as to whether the operand has a rollback point. If the operand does not have a rollback point, the rollback instruction is set at 276 to the source instruction that produced the operand. If the operand has a rollback point, the rollback instruction is set to that same rollback point at reference numeral 274. At reference numeral 278, the target type of the rollback instruction is widened. At reference numeral 280, an indication is made that the rollback instruction should be translated. The conversion process is restarted with a rollback instruction at reference numeral 282.
At reference numeral 284, the rollback instruction is translated according to the new target type.

Referring now to FIG. 20, a flowchart illustrating the steps of communicating the results of instruction optimization according to one embodiment of the invention is shown. At reference numeral 290, a subsequent instruction is obtained. A subsequent instruction is an instruction that is in the same control path as the current instruction and that occurs immediately after the current instruction. One of ordinary skill in the art will recognize that a single instruction may be part of many control paths. At reference numeral 292, a determination is made as to whether a subsequent instruction was previously visited in the conversion process. If the subsequent instruction has not been previously visited, the conversion information for the subsequent instruction is set equal to the conversion information for the current instruction at reference numeral 294, and an indication that the subsequent instruction should be converted at reference numeral 296. Made
The conversion information may include run-time state at the current conversion point. For example, current or previous instructions that have not yet been consumed produce their values.
These values will be used as operands for subsequent instructions in the control path. For each value, the type, source instruction, and rollback point are recorded. If the subsequent instruction has been previously visited, the conversion information previously recorded in the subsequent instruction is combined with the current conversion information at reference numeral 298. Reference number 30
At 0, a determination is made as to whether the values in the combined information have changed. If the value has changed, the reference number 29 indicates that the subsequent instruction should be converted.
Made in 6. This process is repeated for each subsequent instruction.

Referring now to FIG. 21, there is shown a flow diagram illustrating the steps of combining translation information from different control paths according to one embodiment of the present invention. At reference numeral 310,
The corresponding inputs of both control paths are compared. At reference numeral 312, a determination is made as to whether the corresponding input types are different. If the types are different,
Inputs with smaller types are rolled back at reference numeral 314. This process is repeated for each operand.

Referring now to FIG. 22A, a block diagram illustrating instruction conversion according to one embodiment of the present invention is shown. This shows an application method of the present invention to an arithmetic expression that can be optimized. FIG. 22A explains the conversion process for the following Java (registered trademark) representation when the values a, b, and c are of type short. short c = (short) ((short) (a + b) / c) The Java bytecode sequence for this equation is designated by reference numeral 316.

Instruction conversion begins with the iload _- a instruction. The instructions associated with the first, smaller type are used for load and add instructions. As specified in Table 1,
The add instruction causes a potential overflow, but type sh at the source level
Clear typing in the ort removes the possibility of overflow. Div 330 instructions are sensitive to overflow, as shown in Table 2. However, for clear typing,
There is no potential overflow. Therefore, the need to "roll back" to the add operation to create a larger type does not occur. To further aid the understanding of the present invention, the examples discussed above are described in further detail below in connection with FIGS. 10-21.

The iload instruction is a source instruction. At reference numeral 160, the target type for the “a” operand is type short. At reference numeral 162, the operand “a” is of type short. The operands do not carry a potential overflow at reference numeral 166 because they were loaded directly and were therefore not created by the operation that caused the overflow. Therefore, the short instruction is used to convert the iload instruction to the sload _- a instruction at reference numeral 167. Similarly, the iload _- b instruction is converted into a sload _- b instruction.

Next, the iadd instruction is processed. Because iadd is an instruction that can cause overflow, a check is made at reference numeral 210 to determine if its operands have a potential overflow. Both operands are loaded directly so that they do not have a potential overflow. Therefore, the optimized result type is determined at reference numeral 220. At reference numeral 232, the instruction type is set to the maximum operand type. In this example, this maximum operand type is of type s because both operand "a" and operand "b" are of type short.
It is a hort. At both reference numbers 238, type short is returned as the instruction type because both operands are the same type as the instruction type.

Next, at reference numeral 222, the instruction is optimized. Instruction type is type short
Since it is t, the optimized instruction is "sadd". The result type and overflow indication are then determined at reference numeral 224. At reference numeral 240, the result type is set to the instruction type type short. In addition, an indication that the result has a potential overflow is made according to Table 3. The rollback point for the (a + b) result is recorded at reference numeral 248 because the result contains a potential overflow. Since neither operand has a rollback point, the rollback point for the result is reference numeral 268 and is the operand "a" (first
Operand) of the source instruction. At reference numeral 250, an indication is made that the result has a potential overflow.

Next, the i2s instruction is processed. This i2s instruction is a type conversion instruction.
At reference numeral 176, the operand type (short) is the target type (s
hort). Since both types are the same, at 178 the type is narrowed to type short, eliminating potential overflow. Next, the iload _- c instruction is processed. Like values a and b, c is of type s
a hort, iload _- c instruction, sload _- is converted into c instruction. Next, the idiv instruction is processed. As specified in Table 2, idiv is an instruction that may be subject to overflow. The "a + b" operand does not involve a potential overflow due to explicit source level typing into short, so the optimized divide instruction type is determined at reference numeral 232 to be of type short, The result type is set to type short at reference numeral 240.

Next, the i2s instruction is processed. At reference numeral 176, the operand type (sh
ort) is compared to the target type (short). Since both types are the same, this type is narrowed down to type short at reference numeral 178, eliminating potential overflow. Finally, the store _- c instruction is processed. The target type is type sh
an ort, since operands without overflow, istore _- c instruction, at reference numeral 167, sstore _- are optimized c instruction. The converted bytecode is indicated by reference numeral 318.

Referring now to FIG. 22B, a block diagram illustrating instruction conversion according to one embodiment of the invention is shown. This shows the application of the present invention to non-optimizable arithmetic expressions. Nevertheless, the translated code retains its semantic equivalent to the untranslated code. FIG. 22B shows that values a, b, and c are of type sho
A conversion process for the following Java (registered trademark) expression when rt is described. short c = (short) ((a + b) / c) The Java bytecode sequence for this expression is reference numeral 3.
It is shown at 20.

The instruction conversion begins with the iload _- a instruction represented by reference numeral 322. The instructions associated with the first, smaller type are load322 and 324 and add326.
And used for instructions. As specified in Table 1, the add instruction 326 causes a potential overflow, but does not require the use of the second, larger type.
However, the div330 instructions are sensitive to overflow. This is shown in Table 2. That is, the instruction causing the overflow problem must be corrected. This problem is "rolled back" to reference numeral 322 and the operand "a
Is corrected by using a second large type instruction for ".

Until the instruction conversion determines that operand “b” should also be converted to a larger type and requires a second rollback, the instruction conversion is referred to by reference numeral 3.
Continue the second time at 32. The instruction conversion then proceeds to reference numeral 3 until the instruction conversion determines that the instruction for operand "c" requires the use of a larger type.
At 34, continue for the third time. The third rollback is executed and the operand "c"
Is corrected and the conversion process is complete after the fourth conversion process continues at reference numeral 336. To further aid in understanding the invention, the example of FIG. 22B discussed above is described in further detail below with reference to FIGS. 10-21.

The initial conversion of the iload _- a, iload _- b, and iadd instructions proceeds as described in the previous example. The iload _- c instruction is then converted to a sload _- c instruction at reference numeral 167. Next, the idiv instruction is processed. As specified in Table 2, idiv is an instruction that can be affected by overflow. "A
The "+ b" operand is a potential overflow because it is created by the "+" operator, which can cause overflow as shown in Table 1. Since at least one operand has a potential overflow, a rollback to the first operand with an overflow is performed at reference numeral 218.

At reference numeral 270, the translation of the current instruction is interrupted. At reference numeral 274, a rollover is associated with the a + b operand, so the rollback point is set to the rollback point for the a + b operand. Reference number 2
At 78, the target type of the rollback instruction is expanded from type short to type int. At reference numeral 280, an instruction is made to translate the destination instruction to be rolled back. At reference numeral 282, the conversion process was previously sload _- a.
It is restarted at the iload _- a instruction converted into an instruction. This iload _- a instruction is translated at reference numeral 284.

As a result of the rollback, the iload _- a instruction is processed at reference numeral 338. At reference numeral 124, the result type and the target type are matched. Since the result type is short and the target type is int, the types do not match. That is, an S2I instruction is created to raise short to int. Processing continues with the iload _- b and iadd instructions. The operand for the iadd instruction does not involve a potential overflow at 210, so the optimized result type is determined at 220. At reference numeral 234, the types of operands are compared. Since the "a" operand is now of type int and the "b" operand is still of type short, "b"
A rollback is performed on the operand. At reference numeral 276, the rollback instruction is set to the iload _- b instruction 340. Also, at reference numeral 278, the target type is set to int. At reference numeral 280, an instruction to translate the current instruction is made. At reference numbers 282 and 284, conversion resumes at the iload _- b instruction and the instruction is converted. At reference numeral 124, the result type and the target type are matched. Since the result type is short and the target type is int, the types do not match. That is, an S2I instruction is created to raise short to int.

Next, the iadd instruction is processed. After rolling back twice, neither operand has the possibility of overflow. Therefore, at reference numeral 210, an indication is made that the operand does not carry a potential overflow, and the optimized instruction type is determined at reference numeral 220. At reference numeral 232, the instruction type is set to the maximum operand type. The “a + b” operand is of type int,
The instruction type is set to int because the "c" operand is of type short. Since the type of the "c" operand is different from the instruction type, reference numeral 236
Rollback is performed on the "c" operand. At reference numeral 276, the rollback instruction is set to the iload _- c instruction. At reference numeral 278, the target type of the rollback instruction is expanded from type short to type int. The conversion process is restarted at the iload _- c instruction 342.

At reference numeral 124, the result type and the target type are matched. Since the result type is short and the target type is int, the types do not match. That is, an S2I instruction is created to raise short to int. Next, the idiv instruction is processed. At reference numeral 238, the optimized instruction type is set to int because both operands are of type int.
At reference numeral 222, a daunting int instruction (idiv) is selected. The final instruction sequence is represented by reference numeral 344 in FIG.

Although the present invention has been described in terms of integer types, those skilled in the art will appreciate that the present invention is equally applicable to floating point arithmetic expressions. Furthermore, the present invention provides
Although described with respect to "Java Card (R)" technology, those skilled in the art will recognize that the present invention is equally applicable to many other platforms. These platforms include, for example, the K virtual machine (
KVM) technology is included. KVM technology was published by Sun Microsystems, Inc. on June 8, 1999 in the "K Virtual Machine (KVM).
White Paper ”. The present invention may be implemented in software or hardware. The present invention may be implemented in other processors, as well as programmable gate array devices, "application specific integrated circuits (ASICs)", and other hardware.

A new method for adaptive optimization of arithmetic expressions has been described above. Instructions of the same type are converted to a semantically equivalent type instruction for a second, smaller (with a smaller number of bits) integer type instruction for execution on a resource limited computer, and thus relatively This results in efficient stack utilization and increased execution speed.
While embodiments and applications of the present invention have been shown and described, one of ordinary skill in the art having the benefit of the present disclosure will recognize many more than those described above without departing from the innovative concepts herein. It will be apparent that changes are possible. Accordingly, the invention is intended to be limited in the spirit of the claims, but not otherwise limited.

[Brief description of drawings]

FIG. 1 is a block diagram showing a method of compiling a program written in a high level language.

FIG. 2A is a flow chart illustrating the use of a stack to add two 16-bit operands expanded to 32 bits.

FIG. 2B is a block diagram illustrating the use of a stack to add two 16-bit operands extended to 32 bits.

FIG. 3A is a flow diagram illustrating the use of a stack to add two 32-bit operands together.

FIG. 3B is a block diagram illustrating the use of a stack to add two 32-bit operands together.

FIG. 4A is a block diagram illustrating a method of transforming an arithmetic expression for execution on a resource limited computer according to an embodiment of the present invention.

FIG. 4B is a block diagram illustrating the steps of converting a file belonging to the Java® class, according to one embodiment of the invention.

FIG. 5A is a code sample illustrating the addition of values of two types short on a desktop computer.

FIG. 5B is a code sample illustrating the addition of values of two type shorts on a resource limited computer.

FIG. 6A is a code sample illustrating the addition of the values of two type shorts and the immediate entry of the result into a type on a desktop computer.

FIG. 6B is a code sample illustrating immediate typing of the result of an operation that may introduce an overflow on a resource limited computer.

FIG. 7A is a code sample illustrating the addition of the values of three type shorts and the immediate entry of the result into a type on a desktop computer.

FIG. 7B is a code sample illustrating the execution of an operation that is unaffected by overflow on an operand due to an operation that can result in overflow on a resource limited computer.

FIG. 8A is a code sample illustrating the addition of two type short values and the division of the result by the type short value on the desktop computer.

FIG. 8B is a code sample illustrating the execution of an overflow-affected operation on an operand created by an operation that may result in a overflow on a resource-limited computer.

FIG. 9 is a flowchart illustrating a method of optimizing an n-base type arithmetic expression according to an embodiment of the present invention.

FIG. 10 is a detailed flowchart illustrating an n-base type arithmetic expression optimization method according to an embodiment of the present invention.

FIG. 11   6 is a flow chart illustrating steps of converting instructions according to an embodiment of the present invention.

FIG. 12A is a flow chart illustrating a method of converting a target instruction according to an embodiment of the present invention.

FIG. 12B   6 is a flowchart illustrating a method of converting an initial value instruction according to an exemplary embodiment of the present invention.

FIG. 13 is a flowchart illustrating a method for converting a type conversion instruction according to an exemplary embodiment of the present invention.

FIG. 14 is a flow diagram illustrating a method of converting stack manipulation instructions according to one embodiment of the invention.

FIG. 15   6 is a flowchart illustrating a method for converting an arithmetic expression according to an exemplary embodiment of the present invention.

FIG. 16 is a flow chart illustrating a method of determining an optimized instruction type according to one embodiment of the invention.

FIG. 17 is a flow chart illustrating a method of determining result type and result overflow, according to one embodiment of the invention.

FIG. 18 is a flow chart illustrating a method of recording a rollback point according to an embodiment of the present invention.

FIG. 19 is a flow chart illustrating a method of rolling back a conversion process according to an embodiment of the present invention.

FIG. 20 is a flowchart showing a step of transmitting a result of instruction optimization according to an exemplary embodiment of the present invention.

FIG. 21 is a flow chart illustrating steps of combining conversion information from different control paths according to an embodiment of the present invention.

FIG. 22A   FIG. 6 is a block diagram illustrating instruction conversion according to an exemplary embodiment of the present invention.

FIG. 22B   FIG. 6 is a block diagram illustrating instruction conversion according to an exemplary embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Schwab Judy             United States California             94303-4900 Palo Alto MS             Pal 01-521 San Antonio Law             Do 901 F-term (reference) 5B035 BB09 BC00 CA11                 5B081 AA09 DD01 [Continued summary] At least one opera converted into a second command (88) And there is a possibility of overflow (84), and If the operator is sensitive to overflow, the overflow Convert source third instruction (86) to a wider base Formed to use program instructions in order to It includes at least one processor.

Claims (35)

[Claims] 1. Formed for a first processor having a first base,
Receiving a first instruction that includes an operator and at least one operand, when the at least one operand does not involve a potential overflow beyond a second base that is less than the first base, or Converting the first instruction to a second instruction optimized for a second processor having the second base when the operator is not sensitive to overflow; and the at least one A source of potential overflow associated with the at least one operand when the operand is associated with a possibility of overflow beyond the second base, and when the operator is sensitive to overflow. Converting a third instruction that is optimized to a wider base that is greater than the second base and less than or equal to the first base. The symptom, the method of arithmetic expression optimization. 2. The step of converting to a wider base further comprises the step of discarding a previous conversion result of the third instruction before the step of converting to a wider base. The method according to Item 1. 3. The method of claim 1, further comprising rejecting expressions that cannot be optimized to a smaller base on the second processor. 4. The step of converting to a wider base further comprises rejecting the first instruction when the wider base is not supported by the second processor. The method described in. 5. The method of claim 1, wherein the first instruction is arithmetic. 6. The method of claim 1, wherein the first instruction comprises a type sensitive non-arithmetic instruction. 7. A step of returning to the step of receiving the first instruction after the step of converting the first instruction until all the instructions formed for the first processor have been converted. The method of claim 5, further comprising: 8. The method of claim 7, further comprising linking each instruction with a subsequent instruction in every control path. 9. The converting step of the first instruction comprises: linking each of the results of the instruction with all the instructions that consume the result; and, if the converting step produces a value, Linking the value to the instruction that produced the value, and linking the value to the instruction that first caused the overflow, if the value is associated with a possible overflow. The method of claim 8 characterized. 10. The first processor includes a “Java (registered trademark) virtual computer”, and the second processor includes a “Java Card (registered trademark) virtual computer”. The method according to Item 1. 11. The first base is used by the first processor to perform arithmetic operations on at least one data type having a size less than the size of the first base, Said second having a size equal to the size of at least one data type
The method of claim 1, wherein the base of is used by the second processor to perform arithmetic operations on the at least one data type. 12. The method of claim 1, wherein the first processor comprises a 32-bit processor and the second processor comprises a resource limited 16-bit processor. 13. The first base is used by the first processor to perform arithmetic operations on at least one data type having a size less than the size of the first base, The second base having a size greater than the size of at least one data type is used by the second processor to perform arithmetic operations on the at least one data type. The method according to claim 9, wherein 14. The method of claim 13, wherein the first processor comprises a 32-bit processor and the second processor comprises a resource limited 16-bit processor. 15. Receiving a first instruction formed for a first processor having a first base and including an operator and at least one operand, said at least one operand comprising said first instruction. A second processor having the second base when the first instruction is not sensitive to overflow, or when the operator is not sensitive to overflow. To a second instruction optimized for, when the at least one operand involves a possibility of overflow beyond the second base, and the operator is sensitive to overflow. At a certain time, a third instruction, which is a source of potential overflow associated with the at least one operand, has been previously optimized and is larger than the second base in the first base. And converting a wide base smaller than or equal to remote, executes arithmetic expression optimization including, characterized in that it comprises computer executable program of instructions, computer-readable program storage device. 16. The step of converting to a wider base further comprises the step of discarding a previous conversion result of the third instruction before the step of converting to a wider base. Item 16. The program storage device according to item 15. 17. The program storage device of claim 15, further comprising rejecting expressions that cannot be optimized to a smaller base on the second processor. 18. The step of converting to a wider base further comprises rejecting the first instruction when the wider base is not supported by the second processor. The program storage device according to 1. 19. The first instruction is an arithmetic operation.
5. The program storage device according to item 5. 20. The program storage device of claim 15, wherein the first instruction comprises a type-sensitive non-arithmetic instruction. 21. After the converting step of the first instruction, returning to receiving the first instruction until all instructions formed for the first processor have been converted. 20. The program storage device according to claim 19, further comprising: 22. The program storage device of claim 21, further comprising linking each instruction with a subsequent instruction in all control paths. 23. The step of converting the first instruction comprises: linking each of the results of the instruction with all the instructions that consume the result; and, if the converting step produces a value, Linking the value to the instruction that produced the value, and linking the value to the instruction that first caused the overflow, if the value is associated with a possible overflow. The program storage device according to claim 22, wherein the program storage device is a storage device. 24. The first processor includes a “Java (registered trademark) virtual computer”, and the second processor includes a “Java Card (registered trademark) virtual computer”. Item 16. The program storage device according to item 15. 25. The first base is used by the first processor to perform arithmetic operations on at least one data type having a size less than the size of the first base, Said second having a size equal to the size of at least one data type
16. The program storage device of claim 15, wherein the base of is used by the second processor to perform arithmetic operations on the at least one data type. 26. The program storage device according to claim 15, wherein the first processor includes a 32-bit processor, and the second processor includes a resource-limited 16-bit processor. . 27. The first base is used by the first processor to perform arithmetic operations on at least one data type having a size less than the size of the first base, The second base having a size greater than the size of at least one data type is used by the second processor to perform arithmetic operations on the at least one data type. 24. The program storage device according to claim 23. 28. Receiving a first instruction formed for at least one memory having a program instruction and a first processor having a first base, the first instruction including an operator and at least one operand; When the one operand does not involve a potential overflow beyond a second base that is less than the first base, or when the operator is not sensitive to overflow, the first instruction is replaced by the second instruction. Converting to a second instruction optimized for a second processor having a base of at least one operand with a possibility of overflow beyond the second base, and the operator Is sensitive to overflow, the third instruction that was the source of potential overflow associated with the at least one operand and was previously optimized is At least one processor configured to use the program instructions to convert to a wider base that is greater than a base and less than or equal to the first base; Equipment for expression optimization. 29. The at least one processor is further configured to use the program instruction to discard a previous conversion result of the third instruction prior to the step of converting to a wider base. 29. The device of claim 28, characterized by: 30. Means for receiving a first instruction formed for a first processor having a first base and including an operator and at least one operand; said at least one operand being said first A second processor having the second base when the first instruction is not sensitive to overflow, or when the operator is not sensitive to overflow. Means for converting to a second instruction optimized for, when the at least one operand involves a possibility of overflow beyond the second base, and the operator is sensitive to overflow. At a certain time, a third instruction, which is a source of potential overflow associated with the at least one operand, has been previously optimized and is larger than the second base in the first base. Characterized in that it comprises means for converting remote smaller or wider base equal to, apparatus for arithmetic expression optimization. 31. The means for converting to a wider base further comprises means for discarding a previous conversion result of the third instruction prior to the step of converting to a wider base. Item 31. The device according to item 30. 32. The apparatus of claim 30, further comprising means for linking each instruction with a subsequent instruction in every control path. 33. A method of using an application software program including at least one instruction optimization targeting a processor having a first base, the method comprising receiving the software program on a processor. Executing a sequence of instructions on the processor. 34. The method of claim 33, further comprising storing the at least one instruction on a resource limited device. 35. A virtual machine executed by a micro controller, the virtual machine executing a software application comprising a plurality of pre-optimized instructions, the virtual machine on a resource limited device. A smart card incorporating a microcontroller, comprising: means for receiving optimized instructions that have been pre-optimized for execution at: and means for executing said instructions.