Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/40—Transformation of program code
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
  • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
  • G06F9/45516—Runtime code conversion or optimisation
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

• the present invention relates in general to the field of computers and computer software and, more particularly, to program code conversion methods and apparatus useful, for example, in code translators, emulators and accelerators which convert program code.
• a translator to perform program code conversion inevitably brings overheads associated with operation of the translator.
• dynamic translation requires the translator to operate inline with the translated program code, such that execution of a host CPU switches between the translator program and the translated code. Performing this switch involves significant work and causes a time delay.
• the present invention improves performance of a translator when undertaking program code conversion.
• Preferred embodiments of the present invention reduce overhead associated with performing context switches between execution of a translator and execution of translated code, particularly during dynamic translation.
• the inventors have developed an optimization technique directed at expediting program code conversion, and which is particularly useful in connection with a run-time translator which employs translation of subject program code into target code.
• a method of execution control when converting subject code into target code including providing a translator trampoline function which is called from a translator run loop and which in turn calls either to a translator code generator to generate additional target code, or else calls previously generated target code for execution. Control then returns to the translator trampoline function to make a new call, or returns to the translator run loop through the trampoline function.
• first and second calling conventions are applied either side of the trampoline function. Altering the calling convention allows parameters to be passed such as between the translator code generator function and the executed target code, particularly by using target processor registers.
• the parameters preferably include block identifiers referring to a current block of subject code ' and/or parameters concerning a subject processor state.
• the trampoline function also performs a processor mode switch of the target processor, such as between first and second modes.
• the first mode is applied when calling the translator generator function
• the second, different, mode is applied for execution of the generated target code .
• the method includes generating each target code block with tail instructions to provide a linking parameter.
• the linking parameter links to the subsequent block, such as by linking to a memory address where the subsequent block is stored, or where a block object is stored representing the subsequent block.
• the linking parameter is used an operand in a jump instruction.
• the preferred method includes providing a second translator trampoline function nested within a first translator trampoline function.
• the second trampoline function is called from an executing target code block, which in turn calls a nested translator function to generate additional target code.
• the preferred method includes performing a profiling check to determine whether execution control will remain with the target code, or return to the translator run loop.
• the profiling check is applied particularly when jumping between target code blocks.
• the profiling check includes maintaining a counter value for executions of a target code block and comparing the counter value against a predetermined threshold. Once the target code has repeated a predetermined number of times, execution control is forced back to the translator run loop.
• the present invention also extends to a computer- readable storage medium having recorded thereon program software to execute the methods described herein. Further, the present invention extends to a computer processor in combination with such software, such as in a translator apparatus or other computing machine.
• a computer processor in combination with such software, such as in a translator apparatus or other computing machine.
• Figure 1 is a schematic diagram of an illustrative computing environment illustrating translation of subject code to target code
• Figure 2 is a schematic flow diagram illustrating an example method of execution control during program code conversion
• Figure 3 is a schematic representation showing an example of a subject program
• Figure 4 is a schematic representation of execution control in a target architecture
• Figure 5 illustrates workload distribution of the execution control method of Figures 2, 3 & 4;
• Figure 6 is an overview of a preferred method of execution control during program code conversion
• FIG. 7 illustrates workload distribution in the preferred method
• Figure 8 illustrates a preferred method employing first and second calling conventions during program code conversion
• Figure 9 illustrates another preferred method of execution control during program code conversion
• Figure 10 shows an example stored block object as employed in preferred embodiments of the present invention
• Figure 11 illustrates yet another preferred method of execution control during program code conversion
• Figure 12 shows a preferred execution control method including a lightweight profiling check
• Figure 13 shows another preferred execution control method including a lightweight profiling check
• Figure 14 shows another preferred method of execution control during program code conversion, employing nested control loops .
• a subject program is intended to execute on a subject computing platform including a subject processor.
• a target computing platform including a target processor is used to execute the subject program, through a translator which performs dynamic program code conversion.
• the translator performs code conversion from subject code to target code, such that the target code is executable on the target computing platform.
• Figure 1 illustrates a target computing platform comprising a target processor 13 having a plurality of target registers 15, and a memory 18 to store a plurality of software components 17, 19, 20, 21, and 27.
• the software components include an operating system 20, subject code 17, translator code 19, and translated target code 21.
• the translator code 19 is an emulator to translate subject code of a subject ISA into translated target code of another ISA, with or without optimisations.
• the translator code functions as an accelerator for translating subject code into target code, each of the same ISA.
• the translator 19, i.e., the compiled version of source code implementing the translator, and the translated code 21, i.e., the translation of the subject code 17 produced by the translator 19, run in conjunction with the operating system 20 running on the target processor 13, which is typically a microprocessor or other suitable computer.
• FIG. 1 is exemplary only and that, for example, software, methods and processes according to the invention may be implemented in code residing within or beneath an operating system.
• the subject code 17, translator code 19, operating system 20, and storage mechanisms of the memory 18 may be any of a wide variety of types, as known to those skilled in the art.
• program code conversion is preferably performed dynamically, at runtime, while the target code 21 is running.
• the translator 19 runs inline with the translated program 21.
• the translator 19 is preferably employed as an application compiled for the target architecture.
• the subject program 17 is translated by the translator 19 at run-time to execute on the target architecture.
• Running the subject program 17 through the translator 19 involves two different types of code that execute in an interleaved manner: the translator code 19; and the target code 21.
• the translator code 19 is generated such as by a compiler, prior to run-time, based on a high-level source code implementation of the translator 19.
• the target code 21 is generated by the translator code 19, throughout run-time, based on the stored subject code 17 of the program being translated.
• the subject program 17 is intended to run on a subject processor (not shown) .
• the translator 19 functions as an emulator. That is, the translator 19 emulates the subject processor, whilst actually executing the subject program 17 as target code 21 on the target processor 13.
• at least one global register store 27 is provided (also referred to as the subject register bank 27) .
• optionally more than one abstract register bank 27 is provided according to the architecture of the subject processor.
• a representation of a subject processor state is provided by components of the translator 19 and the target code 21. That is, the translator 19 stores the subject processor state in a variety of explicit programming language devices such as variables and/or objects; the compiler used to compile the translator determines how the state and operations are implemented in target code.
• the target code 21, by comparison, provides subject processor state implicitly in the target registers 15 and in memory locations 18, which are manipulated by the target instructions of the target code 21.
• the low-level representation of the global register store 27 is simply a region of allocated memory.
• the global register store 27 is a data array or an object which can be accessed and manipulated at a higher level.
• Figure 2 is a schematic flow diagram illustrating an example method of execution control during program code conversion.
• control initially resides with a translator control loop 190.
• the control loop 190 calls a code generation function 192 of the translator code 19, which translates a block of the subject code 17 into a corresponding block of translated code 21.
• that block of translated code 21 is executed on the target processor 13.
• the end of each block of translated code 21 contains instructions to return control back to the control loop 190.
• the steps of translating and executing the subject code are interlaced, such that portions of the subject program 17 are translated and then executed in turn.
• basic block will be familiar to those skilled in the art.
• a basic block is defined as a section of code with exactly one entry point and exactly one exit point, which limits the block code to a single control path. For this reason, basic blocks are a useful fundamental unit of control flow.
• the translator 19 divides the subject code 17 into a plurality of 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 translator may select just one of these basic blocks (block mode) or select a group of the basic blocks (group block mode) .
• a group block suitably comprises two or more basic blocks which are to be treated together as a single unit. Further, the translator may form iso-blocks representing the same basic block of subject code but under different entry conditions .
• IR trees are generated based on a subject instruction sequence, as part of the process of generating the target code 21 from the original subject program 17.
• IR trees are abstract representations of the expressions calculated and operations performed by the subject program. Later, the target code 21 is generated based on the IR trees. Collections of IR nodes are actually directed acyclic graphs (DAGs) , but are referred to colloquially as "trees".
• DAGs acyclic graphs
• the translator 19 is implemented using an object-oriented programming language such as C++.
• an IR node is implemented as a C++ object, and references to other nodes are implemented as C++ references to the C++ objects corresponding to those other nodes.
• An IR tree is therefore implemented as a collection of IR node objects, containing various references to each other.
• IR generation uses a set of abstract register definitions which correspond to specific features of the subject architecture upon which the subject program 17 is intended to run. For example, there is a unique abstract register definition for each physical register on the subject architecture ("subject register").
• abstract register definitions in the translator may be implemented as a C++ object which contains a reference to an IR node object (i.e., an IR tree) .
• the aggregate of all IR trees referred to by the set of abstract register definitions is referred to as the working IR forest ("forest" because it contains multiple abstract register roots, each of which refers to an IR tree) .
• IR trees and other processes form part of the translator code generation function 192.
• Figure 3 is a schematic representation showing functional sections 300 of a subject program 17.
• the sections are labelled as blocks A, B & C with arrows therebetween representing subject program flow.
• block B comprises a looping structure involving a decision either to loop back within block B or else continue to block C.
• Figure 4 is a schematic representation of execution control in the target architecture. Program flow runs down the diagram, whilst the columns show execution control passing between execution of the translator 19 and execution of the translated code 21.
• the translator 19 suitably includes a run loop 190 to control operation of the translator and target code execution.
• the run loop 190 calls either to previously translated target code 21 (e.g. TC A , TC B or TC C ) stored in the memory 18, or else calls a translator code generator function 192 to generate such translated target code from the corresponding block of subject code A, B or C stored in the memory 18.
• One or more parameters 400 are passed between these functions during execution, in particular denoting the current block under consideration (A, B or C) and information about the subject processor state.
• each switch between translation and target code execution involves significant work.
• a context switch typically includes saving or restoring of registers such as into the global register store 27 in order to meet predetermined conditions and achieve a settled state.
• the context switch requires execution of ten or more instructions by the target processor 13.
• a basic block A, B, or C might itself only contain five to ten instructions, and so it will be appreciated that each context switch adds significantly to the work required of the target architecture.
• Each block of target code 21 is executed based on a set of assumptions as to the state of the target processor 13 and the memory 18. Similarly, execution of the translator 19 adheres to assumptions as to the state of the target machine. In particular, a calling convention is defined to determine attributes such as register roles and/or register preservation.
• register roles particular registers are commonly allocated specific roles.
• Various general purpose registers may also be provided.
• a register ESP is defined as the stack pointer
• a register EBP is defined as the frame/base pointer.
• Register preservation defines which register contents should be preserved (e.g. by saving to a stack and then restoring) and which can be safely ignored (e.g. scratch or temporary registers) when moving through execution of different sections of program code on the target machine.
• x8 ⁇ processors have eight registers.
• the registers EAX, ECX and EDX are scratch and do not need to be preserved across a function call, i.e. these are caller preserved.
• EBX, ESP, EBP, ESI & EDI are callee preserved. That is, these registers must be pushed to the stack upon entry into a called block of code and then popped from the stack upon exit, in order to save and restore their contents across a call.
• the callee preserved registers add overhead both to storage and to execution of each block of target code 21. That is, the translator 19 adds extra instructions at the beginning and at the end of each generated block of target code 21, to perform the register save and restore operations required by the calling convention. This is in addition to the useful instructions of the target block which replicate the equivalent block of subject code.
• processors have 16, 32, 64 or more registers, and hence involve increased workload particularly for callee preserved registers .
• each context switch requires significant work by the target architecture and inevitably introduces a time delay, thus slowing execution of the subject program 17 through the translator 19.
• Figure 5 illustrates workload distribution of the example execution control method discussed above with reference to Figures 2, 3 & 4.
• the translator run loop 190 is in the left hand column, and execution of the target code 21 is in the right hand column.
• Work done by the run loop 190 is denoted by X.
• Work within each block (TC A , TC B , TC C ) of target code 21 is denoted by Y as the overhead of the calling convention, such as register preservation and the passing of parameters, whereas Z represents the useful work of the relevant target code block (corresponding to the work of block A, B or C in the original subject program 17) .
• block B is repeatedly executed, but, as shown in Figure 5, each execution of block B requires a context switch between the translator and the target execution, thus incurring significant overhead.
• the preferred embodiments of the present invention provide an improved method of execution control during program code conversion, in particular by making context switching more efficient, by reducing overhead associated with context switching, and by reducing the occurrence of context switching.
• Figure 6 shows an overview of a method of controlling execution during program code conversion according to a first preferred aspect of the present invention.
• the translator run loop 190 makes calls into an assembly trampoline function 191, which in turn calls execution of a stored previously translated target code block 212 (TC A , TC B , TC C ) .
• the trampoline function 191 calls the translator code generator function 192 to generate the target code 21 from the stored subject program 17.
• Figure 7 illustrates workload distribution during program code conversion according to the first preferred aspect of the present invention.
• workload is distributed between the translator 19 and the target code 21.
• Work done by the run loop 190 is denoted by X
• work by the trampoline function 191 is shown as Y'
• work by the target code block 212 is shown as Z.
• the main task of the trampoline function 191 is to perform the context switch between the translator context and the target code context.
• the variable block_identifier is loaded into a register, and the register value then used as an address to call directly or indirectly and execute code stored at that address.
• the executed code can either be the previously translated target code 212, or the translator code generator function 192.
• each target code block 212 stored in memory. That is, each block contains the useful instructions and minimal overhead. Further, each block is smaller and faster to produce, thus reducing work during translation.
• Figure 8 illustrates a preferred method employing first and second calling conventions during program code conversion .
• the method comprises the steps of applying a first calling convention 71 during execution of the translator 19, and applying a second calling convention 72 during execution of the target code 21.
• a first calling convention 71 a register is allocated a first predetermined role and assumes certain properties.
• the second calling convention 72 the register is allocated a second, different role and assumes a different, second set of properties .
• the trampoline function 191 comprises instructions to perform the calling convention switch from the first calling convention to the second calling convention.
• a pseudo-code example of the trampoline with calling convention switch instructions is shown below:
• the first calling convention 71 is observed appropriate to the instruction set architecture (ISA) of the target processor 13.
• This first calling convention defines one or more registers 15 which are callee preserved, and one or more registers which are caller preserved (scratch registers).
• the translator 19 itself operates according to the first calling convention appropriate to the instruction set architecture of the target processor 13. However, the target code 21 is generated by the translator 19 according to the second calling convention, and thereby takes advantage of the alternate register roles and register preservations defined by the second calling convention.
• the trampoline function 191 also provides a convenient mechanism to pass parameters into and out of each target code block TC A , TC B , TC C during execution thereof.
• a parameter is passed into and/or out of each target code block using a register 15 of the target processor 13. This is achieved by selectively adhering to the first and second calling conventions 71, 72 at appropriate times, in order to pass the parameter values stored in these one or more registers 15.
• register ebp stores the stack base pointer.
• ebp instead stores a pointer to the abstract register bank 27, which is contrary to the assumptions for that register in the first calling convention 71.
• Passing a parameter in one of the target registers 15 has a number of advantages. Firstly, save/restore operations are avoided. Secondly, it is generally much faster for a processor to retrieve a value from a register compared with a memory access to a stack, cache or long- term memory.
• a processor mode switch is performed during each context switch. That is, the trampoline function 191 preferably further comprises instructions to perform the processor mode switch. As an example, some processors are able to operate in either a little-endian or a big-endian byte ordering mode. A processor mode switch is performed during the context switch to set the little- or big-endian mode appropriate for the target code execution, and a contrary mode is set for the translator execution.
• processor mode switch there are practical advantages in performing a processor mode switch, particularly where the target processor provides an alternate operating mode which better reflects the needs of a subject program which has been written for a particular subject processor mode.
• changing processor mode is accomplished with a set of instructions that will set a mode flag, or other processor control arrangement, as appropriate to the specific target processor .
• Figure 9 shows a further preferred embodiment of a method of execution control during program code conversion.
• each block of target code 212 terminates with an instruction or instructions passing control back to the trampoline function 191.
• a further enhancement allows a current block of target code 212 (e.g. TC B ) to indirectly reference a subsequent block of target code (e.g. TC B or TC C ) through the trampoline function 191.
• TC B current block of target code 212
• TC C subsequent block of target code
• each block of target code 212 is generated with a tail which provides a linking parameter (such as a variable "block_identifier") which links to a stored block object containing code of a subsequent target code block or containing a link to a stored subsequent target code block.
• the trampoline function 191 receives this block linking parameter and thereby calls the subsequent block of target code.
• Each block object 100 comprises a block label 101 (e.g. "A”, "B” or “C"), a subject address 102 of a corresponding block of source code 17, and a target address 103.
• the target address 103 refers either to the target code block (TC A , TC B , TC C ) if available, or else refers to the target code generator 192.
• a jump to the stored target address 103 allows execution either of the target code or the code generator function as appropriate.
• Figure 11 shows a further preferred embodiment of a method of execution control during program code conversion.
• each block 212 of target code terminates with a tail instruction or instructions which link from the current block (TC B ) to a subsequent block (TC B or TC 0 ) , without reverting to the trampoline function
• the tail preferably comprises a jump instruction which performs an indirect jump based upon a value loaded from memory.
• a pseudo-code example of the target code tail is shown below:
• a jump is performed according to a value of a stored linking parameter, here called "block_identifier".
• the stored variable points to a memory address storing a subsequent block object to be executed next.
• the block object stores the translated target code, or contains an address pointer for the target code.
• the linking parameter is provided in one of the target registers 15.
• an example tail instruction is shown below:
• variable block_identifier is stored the register EAX of an x86 processor.
• the tail instruction is modified to reference the register EAX, which contains the linking parameter. Jumping to the memory address contained in the register EAX links to a stored object representing a block of code to be executed next. Also, the value in the register EAX is retained in order to denote the current block of the subject program under consideration. That is, the linking parameter preferably denotes block A, B, or C of the subject program, which is useful during execution of the corresponding target code .
• Figure 12 shows yet another preferred aspect -of the execution control method, by providing a lightweight profiling check.
• a particularly preferred mechanism allocates an execution limit to each target code block 212. That is, each target code block is executed no more than N times before returning control to the run loop, where N is an integer. Conveniently, a counter counts up to the threshold value N, which is set by the translator 19 upon creation of the target code block 212. A further cost saving is achieved by instead counting down to zero from the threshold value N. This allows a "jump less than or equal to zero" type instruction which is more efficient to execute in many processor architectures.
• each block 100 of target code is generated including a profile count 104 to store the current value of the counter N.
• the lightweight profiling check is provided in the trampoline function 191 as illustrated by the follow pseudo-code example:
• the jz (jump if equal to zero) instruction bypasses the call, if the counter has already reached zero.
• FIG 13 shows yet another preferred aspect of the lightweight profiling check, appropriate to the embodiment discussed above with reference to Figure 11.
• the profiling check is performed within the target code block 191.
• a threshold is set and reduced to zero over subsequent iterations.
• the check is performed upon entry into the target code block with instructions such as in the following example: dec offset (block identifier) jnz 1 : ret 1:
• control returns to the trampoline function 191 to perform appropriate actions, such as a context switch back to the translator run loop 190.
• Figure 14 shows another preferred method of execution control during program code conversion, which employs nested control loops.
• a nested form of execution control provides a convenient mechanism to call the translator code generator function 192.
• block jumping is performed as discussed above in Figures 9 and 11.
• the tail of target code block TC B tries to jump to block TCc, which has not yet been generated.
• the block object C contains a redirection such that execution passes to a second trampoline function 193, which calls the translator generator function 192.
• the target code block TC C is then generated from the corresponding subject code block C.
• control returns to the run loop 190.
• the target code block TC 0 is then called through the first trampoline function 191.
• the first and second trampoline functions 191, 193 are very similar and may share the same code, but have been shown separately in Figure 14 for clarity.
• Figure 14 also shows context switching between the translator context and the target code context.
• the trampoline functions 191, 193 each perform the context switch into and out of the target code context, including changing between the first and second calling conventions 71, 72.
• the trampolines 191, 193 are each shown straddling the first and second contexts.
• the second trampoline function 193 nests the context switches into and out of the translator context 71 to run the code generator 192.
• the first trampoline function then unpicks the original context switch to return to the top- level of run loop 190.
• the double bounce through the first and second trampolines 191, 193 allows parameters and other data to be stored to the stack and then properly restored in the correct order.
• each context switch requires register save or restore operations, conveniently using a push or pop of a LIFO stack.
• the subject program 17 requires small areas of code to be executed repeatedly, whilst major portions are executed rarely if at all.
• the subject program is a spreadsheet or word processor program where only relatively few of the many available functions or commands are used frequently.
• target code execution occurs much more frequently than translation.
• the preferred execution control method of Figure 14 adds overhead in the second trampoline function 193, but is optimised for execution of the translated code 21.

Applications Claiming Priority (3)

Publications (1)

Family

ID=36282585

Family Applications (1)

Country Status (3)

Families Citing this family (4)

Family Cites Families (5)

• 2006
  • 2006-03-06 WO PCT/GB2006/000799 patent/WO2006095155A1/en not_active Application Discontinuation
  • 2006-03-06 KR KR1020077022472A patent/KR101244063B1/ko active IP Right Grant
  • 2006-03-06 EP EP06710015A patent/EP1866761A1/de not_active Withdrawn

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events