U.S. patent application number 10/314179 was filed with the patent office on 2003-08-07 for condition code flag emulation for program code conversion.
Invention is credited to North, Geraint M., Sandham, John.
Application Number | 20030149963 10/314179 |
Document ID | / |
Family ID | 9930503 |
Filed Date | 2003-08-07 |
United States Patent
Application |
20030149963 |
Kind Code |
A1 |
Sandham, John ; et
al. |
August 7, 2003 |
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.
Inventors: |
Sandham, John; (Manchester,
GB) ; North, Geraint M.; (Manchester, GB) |
Correspondence
Address: |
PAUL, HASTINGS, JANOFSKY & WALKER LLP
P.O. BOX 919092
SAN DIEGO
CA
92191-9092
US
|
Family ID: |
9930503 |
Appl. No.: |
10/314179 |
Filed: |
December 5, 2002 |
Current U.S.
Class: |
717/138 ;
703/23 |
Current CPC
Class: |
G06F 9/45537
20130101 |
Class at
Publication: |
717/138 ;
703/23 |
International
Class: |
G06F 009/45; G06F
009/455 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 6, 2002 |
GB |
0202728.2 |
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.
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) .times.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 .times.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 .times.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
.times.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 .times.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 .times.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 .times.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 .times.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.sub.--1 and
inst.sub.--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
(LT.sub.n, GT.sub.n or EQ.sub.n, 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 A.sub.0-n, B.sub.0-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.
* * * * *