Condition code flag emulation for program code conversion

Abstract

An emulator (30) allows subject code (10) written for a subject processor (12) having subject processor registers (14) and condition code flags (16) to run in a non-compatible computing environment (2). The emulator (3) identifies and records parameters of instructions in the subject code (10) that affect status of the subject condition code flags (16). Then, when an instruction in the subject code (10) is encountered, such as a branch or jump, that uses the flag status to make a decision, the flag status is resolved from the recorded instruction parameters. Advantageously, emulation overhead is substantially reduced.

Description

[0001] The present invention relates in general to the field of program code conversion. In particular, the invention relates to a method and apparatus for emulation of condition code flags.

[0002] In the field of computer processing, it is often desired to run program code written for a computer processor of a first type (a “subject” processor) on a processor of a second type (a “target” processor). Here, an emulator is used to perform program code translation, such that the subject program is able to run on the target processor. The emulator provides a virtual environment, as if the subject program were running natively on a subject processor, by emulating the subject processor.

[0003] Most conventional computer processors comprise a set of registers, which are a small number of high-speed memory locations closely associated with the processor. The registers can be contrasted with general random access memory provided remote from the processor, which is slower but has a much larger capacity. Typically, a modern processor includes of the order of 32 to 144 registers. The limited size and high speed of the registers make them one of the most critical resources in almost all computer architectures.

[0004] The registers are usually augmented with a set of condition code flags. The condition code flags are set or cleared such as in response to the execution of instructions in the processor and are used to represent the outcome of various operations. The value of one or more of the condition code flags is often used as the basis for a decision during execution of a sequence of instructions. Hence, in the context of program code conversion, it is critical to accurately emulate the condition code flags.

[0005] Whilst there tends to be some overlap between the set of condition code flags of a subject processor and the set of condition code flags of a target processor, in almost all cases there is not an exact correspondence between the two sets of flags. Therefore, accurately emulating the subject condition code flags can be an expensive operation. The degree to which flag emulation impacts upon the efficiency of the conversion process varies according to compatibility of the subject processor architecture with the target processor architecture, but in general the emulation of subject condition code flags amounts to a significant proportion of overall performance.

[0006] A further problem arises in that some processor architectures are inherently highly incompatible. Some processors are strongly reliant on the use of condition code flags, whereas some other processors do not provide any condition code flags at all. For example, it is very expensive to provide an emulator able to convert subject code written for a subject processor which does use condition code flags to run on a target processor without any condition code flags.

[0007] An aim of the present invention is to provide a method for emulating condition code flags that addresses the problems of the prior art, particularly those problems set out above.

[0008] A preferred aim of the present invention is to provide a method for emulating condition code flags that is efficient and reduces overall cost of program code conversion.

[0009] According to a first aspect of the present invention there is provided a method for emulating condition code flags during program code conversion, comprising the steps of: (a) identifying a flag-affecting instruction in a sequence of subject code instructions; (b) recording parameters of the identified flag-affecting instruction; (c) detecting a flag-usage instruction in the sequence of subject code instructions; and (d) resolving a flag status with respect to the recorded parameters.

[0010] In a first preferred embodiment, preferably the step (d) comprises explicitly calculating a flag status by emulating effects of the identified flag-affecting instruction on one or more subject condition code flags. Preferably, the step (b) comprises setting a flag status indicator to a pending state to indicate that parameters have been recorded, and the step (d) comprises setting the flag status indicator to a normalised state to indicate that a flag status has been explicitly calculated.

[0011] In a second preferred embodiment, preferably the step (d) comprises implicitly determining flag status with reference to the recorded parameters.

[0012] The first and second preferred embodiments can be used in combination. Preferably, the step (c) comprises determining a flag usage type with reference to a type of the detected flag-usage instruction, and the step (d) comprises resolving flag status either by explicitly calculating a flag status or by implicitly determining a flag status, according to the determined flag usage type.

[0013] Preferably, the step (a) comprises identifying a second flag-identifying instruction in the sequence of subject code instructions, and the step (b) comprises replacing the recorded parameters with parameters of the second flag-affecting instruction. Here, the recorded parameters are replaced as each new flag-affecting instruction is encountered. Alternatively, parameters are recorded for a plurality of instructions.

[0014] Preferably, the step (a) comprises identifying a type of flag-affecting instruction as one of a plurality of predetermined types, and the step (b) comprises recording parameters for each type of flag-affecting instruction.

[0015] In one embodiment, preferably, the predetermined types include a first type instruction affecting a full set of condition code flags, and a second type instruction affecting a subset of the full set of condition code flags. Preferably, the step (d) comprises resolving flag status for a full set of condition code flags with respect to the recorded first-type parameters, and resolving flag status with respect to the subset of the condition code flags with respect to the recorded second-type parameters. Preferably, the step (d) comprises explicitly determining flag status from the recorded first-type parameters, and modifying the explicitly determined flag status from the recorded second-type parameters.

[0016] In a second embodiment, preferably the predetermined types include instruction types each affecting a condition code flag set amongst a plurality of condition code flag sets.

[0017] Preferably, the recorded parameters include an instruction type parameter and one or more instruction operand parameters. In one embodiment, the parameters are recorded in dedicated storage locations, such as predetermined locations in a main memory. The parameters are suitably copied to such location. However, recording an instruction operand parameter may comprise storing a reference to a location containing an operand. Here, recording an instruction operand parameter comprises determining that an operand remains available unmodified at an original location and storing a reference to the original location as the instruction operand parameter, or else copying the operand from the original location to a dedicated operand parameter storage location. Preferably, the method comprises providing a plurality of abstract registers representing registers of a subject processor, and supplementing the abstract registers with one or more additional abstract registers each for storing an operand as an instruction operand parameter.

[0018] According to a second aspect of the present invention there is provided a method for emulating condition code flags during program code conversion, comprising: selecting a sequence of subject code instructions; identifying a flag-affecting instruction in the sequence of subject code instructions, the flag-affecting instruction specifying an operation that affects subject condition code flags of a subject processor; recording parameters of the identified flag-affecting instruction including an instruction type parameter and one or more operand parameters; detecting a flag-usage instruction in the sequence of subject code instructions, the flag-usage instruction specifying an operation with reference to a flag status of one or more of the subject condition code flags; and in response to detecting a flag-usage instruction, resolving a flag status of one or more of the subject condition code flags with respect to the recorded parameters.

[0019] The method preferably comprises updating the recorded parameters when a new flag-affecting instruction is encountered in the sequence of subject code instructions. Parameters may be recorded for a plurality of flag-affecting instructions. In one embodiment the plurality of instructions are each associated with differing sets of subject condition code flags.

[0020] Preferably, the method comprises resolving flag status by at least one of (a) explicitly calculating a status for one or more subject condition code flags by emulating an effect of the recorded flag-affecting instruction, or (b) implicitly representing the flag-usage instruction using the recorded parameters, or (c) selecting between options (a) and (b) according to a type of the flag-usage instruction.

[0021] Preferably, the recorded parameters include at least one instruction operand parameter, and wherein recording the instruction operand parameter comprises at least one of (a) copying an operand to a predetermined storage location, or (b) storing a reference to an original location containing the operand, or (c) selectively performing (a) or (b).

[0022] According to a third aspect of the present invention there is provided an emulator apparatus for use in a target computing environment for emulating a subject processor of a subject computing environment when translating subject code appropriate to the subject computing environment to produce target code appropriate to the target computing environment, the emulator apparatus comprising: means for identifying a flag-affecting instruction in a sequence of subject code instructions; an instruction parameter store for recording parameters of the identified flag-affecting instruction; means for detecting a flag-usage instruction in the sequence of subject code instructions; and means for resolving a flag status with respect to the instruction parameters recorded in the instruction parameter store.

[0023] The invention also extends to a computing platform embodying the emulator apparatus and/or arranged to perform the methods defined herein. The computing platform may take any suitable form including, for example, a networked computing system, a server computer, a desktop computer, or a portable computing device. The invention also extends to a computer readable recording medium containing program code instructions for performing any of the methods defined herein.

[0024] For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which:

[0025] FIG. 1 shows an example computing environment including subject and target computing environments;

[0026] FIG. 2 outlines a preferred method for emulating condition code flags;

[0027] FIG. 3 shows two examples of subject program code;

[0028] FIG. 4 shows a preferred emulator;

[0029] FIG. 5 shows an example of subject program code together with recorded instruction parameters;

[0030] FIG. 6 shows program code during translation from a subject environment to a target environment;

[0031] FIG. 7 shows a preferred arrangement for storing instruction parameters;

[0032] FIG. 8 shows an example of subject program code;

[0033] FIG. 9 shows a condition register of condition code flags in an example subject processor;

[0034] FIG. 10 shows a preferred arrangement for storing instruction parameters; and

[0035] FIG. 11 shows another preferred arrangement for storing instruction parameters.

[0036] Referring to FIG. 1, an example computing environment is shown including a subject computing environment 1 and a target computing environment 2. In the subject environment 1, subject code 10 is executable natively on a subject processor 12. The subject processor 12 includes a set of subject registers 14 and a set of subject condition code flags 16. Here, the subject code 10 may be represented in any suitable language with intermediate layers (e.g. compilers) between the subject code 10 and the subject processor 12, as will be familiar to the skilled person.

[0037] It is desired to run the subject code 10 in the target computing environment 2, which provides a target processor 22 using a set of target registers 24 and a set of target condition code flags 26. As a typical example, the subject processor 12 is a member of the Intel (rtm) ×86 family of processors, whilst the target processor 22 is a member of the PowerPC (rtm) processor family. These two processors are inherently non-compatible. Firstly, these two processors use different instruction sets. Secondly, an ×86 processor uses two flags (the auxiliary flag and the parity flag) which are unique to that family and are not provided in the PowerPC (rtm) architecture. Hence, an emulator 30 is provided in the target computing environment 2, in order to run the subject code 10 in that non-compatible environment.

[0038] The emulator 30 performs a translation process on the subject code 10 and provides a translated target code 20 to the target processor 22. Suitably, the emulator 30 performs binary translation, wherein subject code 10 in the form of executable binary code appropriate to the subject processor 12 is translated into executable binary code appropriate to the target processor 22.

[0039] Translation can be performed statically, or dynamically. In static translation, an entire program is translated prior to execution of the translated program on the target processor. This involves a significant delay. Therefore, emulators have been developed which dynamically translate small sections of the subject code 10 for execution immediately on the target processor 22. This is much more efficient, because large sections of the subject code 10 will not be used in practice, or will be used only rarely. The preferred embodiment of the present invention is particularly intended for use with an emulator 30 that performs dynamic binary translation of the subject code 10 into target code 20 executable on the target processor 22.

[0040] In executable form, the subject code 10 provides instructions that directly or indirectly make use of the subject registers 14 and the subject condition code flags 16. Hence, it is desired to emulate the effects of those instructions, in order to provide an accurate translation of the subject code 10. However, since the target condition code flags 26 are not directly compatible with the subject condition code flags 16, emulation of the subject condition code flags 16 in the target computing environment is expensive in terms of both time and resources.

[0041] It is desired to provide emulation of condition code flags in a manner which is cost efficient in the target processor. Further, it is desired that the emulation method can be performed efficiently in many different types of target processor. Ideally, it is desired to allow efficient emulation even in a target processor which does not provide any condition code flags.

[0042] FIG. 2 shows a first preferred embodiment of a method for emulating condition code flags. In step 210, parameters of a flag-setting instruction are recorded. Conveniently, certain instructions are known to affect one or more of the condition code flags, whilst other instructions are known to have no affect on the condition code flags. Hence, when translating a sequence of instructions in the subject code 10, an instruction which potentially affects flag settings is identified. Parameters of that flag-affecting instruction are then stored, to be available later.

[0043] In step 220, a flag usage is detected. That is, it is known that some instructions in the instruction set of the subject code 10 make use of one or more of the subject condition code flags 16, such as to make a branch or jump decision based on the value of a condition code flag. At this point, it is desired to know the real values of those flags.

[0044] Step 230 comprises resolving a value for the condition code flags, at least for the one or more flags where a usage has been detected, from the recorded parameters of the flag-affecting instruction.

[0045] In this method, flag emulation is deferred until the last possible moment. Instruction parameters are recorded for a potentially flag-affecting instruction. Then, when it is necessary to emulate the flag, such as when the flags are used as the basis for a decision, the recorded instruction parameters are used to resolve the necessary flag or flags at that point. Here, the flag-affecting instruction is emulated including explicit emulation of the effect of that instruction on the subject condition code flags. However, since full flag emulation is only performed when a flag-using instruction is encountered, overhead associated with flag emulation is significantly reduced and emulator performance is substantially enhanced.

[0046] Once the flag values have been resolved, they remain valid until a new flag-affecting instruction is encountered. At that point, the parameters of the flag-affecting instruction are again recorded, as in step 210. Conveniently, the emulated condition code flags are marked as either being in a normalised, explicitly calculated state, or else in a pending state to be resolved with reference to a recorded flag-affecting instruction.

[0047] FIG. 3 shows two example instruction sequences to illustrate the method of FIG. 2. In a simple first example, the instruction at line 1 affects the subject condition code flags “z”, “s” and “o”, with the “z” flag subsequently utilised by the conditional branch instruction at line 2. In this example, the first instruction (Sub) subtracts the value of register R2 from the value in register R1, and the branch (Bez) is effected if the result is equal to zero. The parameters of the instruction on line 1 are recorded, and are then used to determine the value of the flag “z” for the instruction on line 2. In the second more complex example, the instruction (Ble) on line 2 branches if the result of the subtraction is less than or equal to zero, this decision being made with reference to the example condition code flags “z”, “s” and “o”.

[0048] As an enhancement of this first method, it has been found that for most flag-using instructions it is not necessary to explicitly calculate the value of each flag. That is, the value of a- flag can be determined implicitly, with reference to the stored parameters of the flag-affecting instruction.

[0049] Referring to the code examples of FIG. 3, the branch decision in line 2 can be made simply based upon the parameters of the preceding flag-affecting instruction in line 1. That is, the flag value “z” can be determined implicitly based upon the recorded instruction parameters and there is no need to explicitly determine the value of the flag “z”. Hence, the step 220 advantageously comprises determining a flag usage, and determining a flag usage type. The step 230 then comprises either explicitly determining flag values, or else implicitly determining flag values from recorded instruction parameters, based upon the determined flag usage type.

[0050] Instruction combinations similar to those shown in FIG. 3 occur very frequently. Hence, this optimisation has a significant impact.

[0051] The example instruction sequences shown in FIG. 3 provide a flag-affecting instruction (Sub) followed immediately by a flag-using instruction (Bez or Ble) However, it is also possible that one or more intervening sterile instructions are present between example lines 1 and 2, which do not affect or use the relevant flag or flags.

[0052] Referring now to FIG. 4, the emulator 30 of the preferred embodiment is illustrated in more detail, comprising a front end 31, a core 32 and a back end 33.

[0053] The front end 31 is configured specific to the subject processor 12 being emulated. The front end 31 takes a predetermined section of the subject code 10 and provides a block of a generic intermediate representation (an “IR block”).

[0054] The core 32 optimises each IR block generated by the front end 31 by employing optimisation techniques, such as dead code elimination, which need not be described here in detail.

[0055] The back end 33 takes optimised IR blocks from the core 32 and produces target code 20 executable by the target processor 22.

[0056] Suitably, the front end 31 divides the subject code 10 into basic blocks, where each basic block is a sequential set of instructions between a first instruction at a unique entry point and a last instruction at a unique exit point (such as a jump, call or branch instruction). The core 32 may select a group block comprising two or more basic blocks which are to be treated together as a single unit. Further, the front end 31 may form iso-blocks representing the same basic block of subject code under different entry conditions.

[0057] In use, a first predetermined section of the subject code 10 is identified, such as a basic block, and is translated by the emulator 30 running on the target processor 22 in a translation mode. The target processor 22 then executes the corresponding optimised and translated block of target code 20.

[0058] The preferred emulator 30 includes a plurality of abstract registers 320, suitably provided in the core 32, which represent the physical subject registers 14 that would be used within the subject processor 12 to execute the subject code 10. The abstract registers define the state of the subject processor 12 being emulated by representing the expected effects of the subject code instructions on the subject processor registers.

[0059] FIG. 4 also shows a preferred implementation of the flag emulation method, suitable for use in the general emulator architecture described above. When a flag-affecting instruction is identified in the subject code 10, parameters of that instruction are recorded in an instruction parameter store 200. Most conveniently, the stored instruction parameters include an instruction type 201, and one or more instruction operands 202. For example, in a ×86 type processor each instruction can operate on a maximum of two operands, and therefore two operand parameters 202a, and 202b are recorded. The instruction type parameter 201 together with the one or more operand parameters 202 provide sufficient information for each of the emulated subject condition code flags 16 to be resolved either explicitly, or implicitly.

[0060] The one or more operand parameters 202 are suitably represented as one or more abstract registers additional to the emulated set of subject registers 14. That is, the emulator 30 of target computing environment 2 emulates the set of subject registers 14, by using abstract registers, and supplements this set of abstract registers with one or more additional registers to store the instruction operand parameters. Hence, the operand parameters 202, which are dynamic quantities, are available in the target processor 12 in a high speed memory location and the values of the subject condition code flags 16 are resolvable quickly and cheaply, such as via suitable dynamic target code. The instruction type parameter 201, which is a statically determinable quantity, is suitably stored in a slower or more remote location in the target computing environment 2, such as in main memory, and is associated with a corresponding section of code such as a basic block.

[0061] As shown in FIG. 4, in this first preferred embodiment only the most recent flag-affecting instruction is recorded. As each new flag-affecting instruction is encountered in the sequence of instructions in the subject code 10, then the recorded parameters are replaced with those of the latest encountered flag-affecting instruction. That is, as each new flag-affecting instruction is encountered, the instruction parameters are replaced with those of that new flag-affecting instruction.

[0062] To further illustrate the preferred embodiments of the present invention, FIG. 5 shows six lines of example subject code. Some of the instructions (Sub) affect the full set of condition code flags o,s,z,a,p & c, whilst other instructions (Inc) affect only a subset of the condition code flags. The third column records the instruction type, whilst the fourth and the final columns record the two operands A & B referenced by that instruction. In this example, “Normalised” refers to the normalised status of the flag values, while “SubLong” refers to an instruction type, namely a long (32 bit) subtraction operation in an example ×86 processor. EAX, EBX, ECX and EDX are example subject registers.

[0063] In use, the emulator forms predetermined sections of subject code such as basic blocks, and records entry conditions giving the status of the emulation when passing from one basic block into another. That is, the emulator records entry conditions which are used to define the current status of the emulation at entry into a new basic block. These entry conditions include, for example, the status of each abstract register, and the status of the condition code flags. In FIG. 5, the “Inc” instructions in lines 2 and 4 which affect a subset of the flags require the flags to be explicitly determined and the status is shown as normalised. The “Sub” instructions on the other hand put the flags into the pending state and the parameters of that flag-affecting instruction are recorded. When it comes to the jump “JA” instruction in line 6, the condition code flags are emulated indirectly derived from the recorded parameters of the “Sub” instruction in line 5.

[0064] FIG. 6 illustrates the preferred emulation method during translation of the subject code into target code In the first column an example pair of instructions are shown, in this case a compare (Cmp) instruction and a jump if not equal to zero (Jne) instruction. The front end 31 of the emulator 30 determines that these instructions form a basic block. The second column shows the same instructions, set out as standardised intermediate representation in the core 32. The third column shows the resulting target code produced by the back end 33. This example shows subject code appropriate to an ×86 processor being emulated by an MIPS processor. The architecture of a MIPS processor does not provide any target condition code flags. This example illustrates a worst case practical situation, because traditionally the condition code flags of the ×86 processor are very expensive to emulate in the flagless MIPS processor. The fourth column of FIG. 6 shows that two lines of target code produced from the intermediate representation can be removed by global dead code elimination during an optimisation phase performed by the emulator. Hence, the two lines of subject code in the first column result in a single line of target code in the third column.

[0065] As illustrated by the simple example in FIG. 6, the emulation method described herein can be efficiently implemented even for highly non-compatible environments. Flag emulation is not required at all for a large percentage of instructions, i.e. for sterile instructions. Further, in many instances flag status can be derived implicitly from the recorded instruction parameters. Only a small percentage of the instructions in the source code require full normalised emulation of the subject condition code flags. As practical examples, instructions such as subtraction (Sub) or compare (Cmp) or test (Tst) which occur frequently in source code written such as for ×86 subject processors can be emulated without any need for explicit resolution of the subject condition code flags.

[0066] In the implementation described above, the last flag-affecting instruction is recorded simply and easily by using additional abstract registers to represent each operand. In this architecture, an additional abstract register is provided for each potential operand. In the example of an ×86 processor, each instruction can act on at most two operands, and therefore two additional operand parameter registers are employed. Sometimes, however, it is advantageous to record additional instruction parameters, as will now, be described below.

[0067] FIG. 7 shows a preferred implementation for recording multiple sets of instruction parameters. In this example, two sets of instruction parameters are provided, namely inst—1 and inst—2.

[0068] For some types of processor, there are instructions which affect only a subset of the subject condition code flags, whilst other instructions affect the full set of subject condition code flags. As one option, this problem is overcome by explicitly determining the full set of flag values from the last full set flag-affecting instruction, and then explicitly determining the flag values of the subset affected by the subset-affecting instruction. The full set of flag values can then be determined by combining the explicitly determined flag values of the last full-set flag affecting instruction with those of the newly encountered subset affecting instruction.

[0069] FIG. 8 shows four lines of subject code to illustrate the use of the first and second recorded instruction parameters of FIG. 7. The add instruction (add) at line 1 affects the complete flag set, whereas the decrement instruction (dec) at line 3 affects only a subset of the flags. The embodiment described above would require an explicit definition of the flags at line 3, by first normalising the flags with reference to the instruction parameters recorded for line 1. However, by providing two sets of instruction parameters as shown in FIG. 7, it is now possible to record both instructions, from lines 1 and 3, without needing to normalise the flags at either point. When the flag-using jump instruction is encountered at line 4, the values of the condition code flags are resolved explicitly or implicitly from the two sets of stored instruction parameters.

[0070] FIGS. 9 and 10 illustrate another preferred implementation of the emulation method for use with processors such as the PowerPC (rtm) family which make use of a number of identical flag sets.

[0071] FIG. 9 shows the condition register used in a typical PowerPC processor using eight 4-bit condition fields (CF) which each contain four flags, namely less than (LT), greater than (GT), equal to (EQ) and summary overflow (SO). In this processor architecture, a flag-setting operation is allowed to selectively modify one of the eight sets of flags. Further, although most instructions will set every flag in the specified flag set, some operations exist which affect the status of specific flags. Hence, in traditional emulation systems, it is relatively expensive to emulate a processor of this nature.

[0072] A majority of modifications to the condition code flags in the condition register are initiated by compare instructions, which perform a signed or unsigned comparison of two values. One of the three comparison flags within the specified condition field (LTn, GTn or EQn, where n=0 . . . 7) is set, while the other two are cleared. In order to emulate this relatively complex set of subject condition code flags, it is convenient to provide a set of recorded instructions such that instruction parameters are recorded for each of the condition fields. In this example, as shown in FIG. 10, instruction parameters are recorded for each of “n” instructions, such that the last flag-affecting instruction can be recorded for each of the condition fields. If necessary, the embodiment of FIG. 10 can be combined with the embodiment of FIG. 8, to provide a plurality of recorded instructions for each of the condition fields.

[0073] FIG. 11 shows a further preferred option to improve efficiency of emulation. In the embodiments discussed above, the operands of a flag affecting instruction are copied to operand registers so as to be available when it is necessary to resolve the flag status. However, in some circumstances it is possible to avoid this copying operation by referring instead to the original source location of that operand. That is, the operand value is validly recorded, for example, in an emulated subject register. Provided the value in that subject register remains unchanged, then the subject register itself can be used as the source of the value of that operand.

[0074] FIG. 11 in this example is adapted for the architecture of a PowerPC processor. For each operand A0-n, B0-n, two control fields are recorded. The first control field denotes whether the operand value has been copied to the dedicated operand register 202, or else denotes that the second field specifies the location which contains the value of this operand. That is, the second control field is used as a reference to a subject register (i.e. one of the abstract registers held by the emulator) which contains the value of the desired operand parameter. Here, the first control field is a single bit in length, while the second field is five bits in length, which is sufficient to address the available subject registers of this example processor.

[0075] In another preferred embodiment, the recorded operand parameters are only a subset of the operand parameters employed by the flag-affecting instruction. Firstly, when the flag-affecting instruction performs a reversible transformation and the result of the operation is still available when it is desired to resolve flag status, then the result together with a first operand can be used to infer a second operand. Secondly, if the flag-affecting operation has duplicate parameters, then it is sufficient to record just one of those parameters. These special-case flag-affecting instructions allow increased optimisation of the target code and further reduce overhead associated with emulation of condition code flags.

[0076] The preferred embodiments of the invention have been described in the context of an emulator performing program code conversion for the purposes of translation between non-compatible computing environments. However, the principles of the invention are also applicable to fields such as program code conversion for the purposes of optimisation, wherein a subject processor and a target processor have a compatible architecture.:

[0077] The emulation method described herein is apt to be recorded on a computer readable recording medium as a computing program for performing the method. The invention also extends to an emulator apparatus, and to a computing platform, for performing the emulation method.

[0078] The present invention has many advantages as will be apparent from the description above, and as will be apparent to the skilled person through practice of the invention. In particular, flag emulation is performed efficiently and cost effectively, even for highly non-compatible subject and target processor environments.

Claims

1. A method for emulating condition code flags during program code conversion, comprising the steps of:

(a) identifying a flag-affecting instruction in a sequence of subject code instructions;

(b) recording parameters of the identified flag-affecting instruction;

(c) detecting a flag-usage instruction in the sequence of subject code instructions; and

(d) resolving a flag status with respect to the recorded parameters.

2. The method of claim 1, wherein the step (d) comprises explicitly calculating a flag status by emulating effects of the identified flag-affecting instruction on one or more subject condition code flags.

3. The method of claim 2, wherein the step (b) comprises setting a flag status indicator to a pending state to indicate that parameters have been recorded, and the step (d) comprises setting the flag status indicator to a normalised state to indicate that a flag status has been explicitly calculated.

4. The method of claim 1, wherein the step (d) comprises implicitly determining flag status with reference to the recorded parameters.

5. The method of claim 1, wherein the step (c) comprises determining a flag usage type with reference to a type of the detected flag-usage instruction, and the step (d) comprises resolving flag status either by explicitly calculating a flag status or by implicitly determining a flag status, according to the determined flag usage type.

6. The method of claim 1, wherein the step (a) comprises identifying a second flag-identifying instruction in the sequence of subject code instructions, and the step (b) comprises replacing the recorded parameters with parameters of the second flag-affecting instruction.

7. The method of claim 1, wherein the step (a) comprises identifying a type of flag-affecting instruction as one of a plurality of predetermined types, and the step (b) comprises recording parameters for each type of flag-affecting instruction.

8. The method of claim 7, wherein the predetermined types include a first type instruction affecting a full set of condition code flags, and a second type instruction affecting a subset of the full set of condition code flags.

9. The method of claim 8, wherein the step (d) comprises resolving flag status for a full set of condition code flags with respect to the recorded first-type parameters, and resolving flag status with respect to the subset of the condition code flags with respect to the recorded second-type parameters.

10. The method of claim 9, wherein the step (d) comprises explicitly determining flag status from the recorded first-type parameters, and modifying the explicitly determined flag status from the- recorded second-type parameters.

11. The method of claim 7, wherein the predetermined types include instruction types each affecting a condition code flag set amongst a plurality of condition code flag sets.

12. The method of claim 1, wherein the recorded parameters include an instruction type parameter and one or more instruction operand parameters.

13. The method of claim 12, wherein recording an instruction operand parameter comprises storing a reference to a location containing an operand.

14. The method of claim 12, wherein recording an instruction operand parameter comprises determining that an operand remains available unmodified at an original location and storing a reference to the original location as the instruction operand parameter, or else copying the operand from the original location to a dedicated operand parameter storage location.

15. The method of claim 12, comprising providing a plurality of abstract registers representing registers of a subject processor, and supplementing the abstract registers with one or more additional abstract registers each for storing an operand as an instruction operand parameter.

16. A method for emulating condition code flags during program code conversion, comprising:

selecting a sequence of subject code instructions;

identifying a flag-affecting instruction in the sequence of subject code instructions, the flag-affecting instruction specifying an operation that affects subject condition code flags of a subject processor;

recording parameters of the identified flag-affecting instruction including an instruction type parameter and one or more operand parameters;

detecting a flag-usage instruction in the sequence of subject code instructions, the flag-usage instruction specifying an operation with reference to a flag status of one or more of the subject condition code flags; and

in response to detecting a flag-usage instruction, resolving a flag status of one or more of the subject condition code flags with respect to the recorded parameters.

17. The method of claim 16, comprising updating the recorded parameters when a new flag-affecting instruction is encountered in the sequence of subject code instructions.

18. The method of claim 16, comprising recording parameters for a plurality of flag-affecting instructions.

19. The method of claim 18, wherein the plurality of flag-affecting instructions are each associated with differing sets of subject condition code flags.

20. The method of claim 16, comprising resolving flag status by at least one of (a) explicitly calculating a status for one or more subject condition code flags by emulating an effect of the recorded flag-affecting instruction, or (b) implicitly representing the flag-usage instruction using the recorded parameters, or (c) selecting between options (a) and (b) according to a type of the flag-usage instruction.

21. The method of claim 16, wherein the recorded parameters include at least one instruction operand parameter, and wherein recording the instruction operand parameter comprises.at least one of (a) copying an operand to a predetermined storage location, or (b) storing a reference to an original location containing the operand, or (c) selectively performing (a) or (b).

22. An emulator apparatus for use in a target computing environment for emulating a subject processor of a subject computing environment when translating subject code appropriate to the subject computing environment to produce target code appropriate to the target computing environment, the emulator apparatus comprising:

means for identifying a flag-affecting instruction in a sequence of subject code instructions;

an instruction parameter store for recording parameters of the identified flag-affecting instruction;

means for detecting a flag-usage instruction in the sequence of subject code instructions; and

means for resolving a flag status with respect to the instruction parameters recorded in the instruction parameter store.

23. A computing platform comprising the emulator apparatus of claim 22.

24. A computer-readable recording medium containing program code constructions for performing the method of claim 1.

25. A computer-readable recording medium containing program code constructions for performing the method of claim 16.