Dynamic binary translation optimization method and system based on regional granularity

Abstract

The invention provides a dynamic binary translation optimization method and system based on regional granularity. The method comprises the following steps: S1, initializing a program entry; s2, acquiring and analyzing an instruction; s3, performing cache query; s4, hot spot judgment; s5, performing interpretive execution; s6, initiating a compiling request; s7, compiling mode selection; s8, compiling and caching the code blocks; s9, skipping to a local code for execution; and S10, returning to the main cycle. According to the invention, the technical problems of limited optimization space, high context switching overhead and high code expansion rate are solved.

Description

Technical Field

[0001] The present invention relates to the field of binary translation, and in particular to a dynamic binary translation optimization method and system based on region granularity. Background Art

[0002] Detailed description of the problems existing in existing commercial dynamic binary translation software: Current commercial dynamic binary translation software divides the binary code to be translated into basic blocks, and compiles the executed blocks on the fly as the program executes. If a block that has not been compiled before is encountered, the compilation operation will be performed first. If the block is found in the cache to have been compiled before, the previous compilation result will be reused. The current mainstream dynamic binary translation system (such as QEMU) uses basic blocks as the compilation unit. This is a method that truncates the binary code into blocks when a jump instruction is encountered. This method is simple to implement, but has the following problems:

[0003] Limited optimization space: The basic block division method is used, and each block contains a small number of instructions. The subsequent optimization capability when the block is further translated into binary instructions of the target structure by the compiler is limited, and global optimization (such as loop unrolling and register allocation) cannot be performed.

[0004] High context switching overhead: When using compilation and execution to accelerate program execution, it is necessary to switch between the main process and the process executing the compiled code blocks. Compilation units divided using basic blocks contain fewer instructions per block, resulting in high context switching overhead. Frequent jumps between blocks require saving and restoring register states (prologue / epilogue operations), increasing memory accesses and CPU pipeline interruptions, leading to performance degradation.

[0005] High code expansion rate: The target code size increases significantly after translation, increasing cache pressure and reducing hit rate.

[0006] Due to differences in instruction set design, operating mechanisms, and hardware characteristics, software usually needs to be recompiled and rebuilt for the target architecture to achieve compatibility. However, this process not only relies on a complete tool chain and a complex compilation environment, but may also be impossible to implement due to reasons such as source code loss, seriously affecting the portability and operational efficiency of the software. Binary translation technology is an important transitional means to achieve rapid expansion of software applications in the early stages of a new platform. It has extremely important research significance in the current context of diversified chip scenarios and localization of chips. Binary translation technology can directly translate the binary execution code of the source program without source code, translating programs on one ISA to execute on another ISA, thereby achieving cross-architecture porting of programs. The advantage of this technology is that it achieves code compatibility between different hardware architectures, allowing programs written for a specific architecture to run seamlessly on another architecture without modification or recompilation.

[0007] Binary translation implementation classification:

[0008] Static translation reduces runtime translation overhead by translating binary code from the source ISA into code for the target ISA before the program runs. However, static translation technology has limitations when dealing with complex hardware characteristics and dynamic runtime environments. For example, because static translation cannot perceive the program's runtime behavior in real time, the generated target code is often difficult to fully optimize, resulting in performance losses. Furthermore, static translation lacks adaptability to heterogeneous platforms, especially in scenarios that require dynamic loading, branch prediction, or other runtime features. Dynamic binary translation (DBT) has emerged to further improve the performance and adaptability of instruction set translation. Unlike static translation, dynamic binary translation translates and optimizes binary code during program runtime, adjusting translation strategies in real time based on the program's actual runtime behavior. This dynamic nature makes DBT technology not only more adaptable to complex hardware characteristics, but also significantly improves program performance through runtime optimization. Furthermore, dynamic binary translation offers greater flexibility, enabling better support for heterogeneous platforms and dynamic runtime environments, making it a key research area in instruction set simulation and cross-architecture compatibility.

[0009] like Figure 1As shown in Figure 1, the dynamic binary translation process can be roughly divided into three core phases: analysis, translation, and optimization. In the analysis phase, the dynamic binary translation system first reads the source architecture's machine code and performs comprehensive static and dynamic analysis. Static analysis involves decoding the code to understand the function and operands of each instruction, while dynamic analysis focuses on collecting runtime data to gain insight into the program's behavior and performance characteristics. The goal of this phase is to build an accurate source code model, which is challenging because many key information (such as data dependencies and control flow) must be revealed at runtime. In the actual translation phase, the dynamic binary translation system converts the source code model into machine code for the target architecture. This process is divided into two sub-phases: intermediate code generation and target code generation. Intermediate code generation converts the source code model into an intermediate representation (IR), a hardware-independent abstract code form that provides a foundation for subsequent optimization. The target code generation sub-phase involves converting the IR into machine code for the target architecture, taking into account the specific characteristics of the target architecture. In the optimization phase of dynamic binary translation technology, the system performs a series of optimization operations on the IR to improve the efficiency of the resulting target code. These optimizations involve common compiler optimization techniques, such as constant folding, dead code elimination, and loop unrolling. They also include optimization strategies specifically tailored to dynamic translation, such as cross-block optimization and cross-procedure optimization. Cross-block optimization relies on the program's control flow information. By analyzing and optimizing the control flow relationships between code blocks, it helps eliminate unnecessary jumps and function calls, thereby improving code fluency and locality. Cross-procedure optimization, on the other hand, relies on the program's call relationships. It aims to reduce procedure switching overhead and enhance code parallelism and reusability by analyzing and optimizing the calling relationships between procedures. Handling dynamic behavior and system state changes is one of the main challenges facing dynamic binary translation technology. To ensure correct and efficient code translation and execution, the system must be able to perceive and handle the program's dynamic behavior in real time, such as changes in data dependencies, control flow jumps, exceptions, and interrupts. Furthermore, it must handle system state changes, such as changes in memory layout, device state, and operating system scheduling. Dynamic binary translation systems typically combine static translation and dynamic optimization strategies to address these issues. Static translation addresses the program's static behavior and stable state, while dynamic optimization targets the program's changing behavior and state. A typical dynamic binary translator consists of a translation module and an execution module. The translation module is responsible for receiving program code instructions from the source architecture and converting them into machine code for the target architecture. The converted machine code is then loaded by the execution module. When a program instruction from the source architecture is triggered for execution, the corresponding translation process is simultaneously initiated. The source instruction is loaded into the translation module, and the translation process begins.After translation is complete, the execution module addresses and executes the target machine instruction according to its address. During runtime, the execution module collects dynamic information about the instructions. If it identifies a frequently executed code path, it returns control to the translation module for further translation or optimization. This inter-module collaboration ensures the continuity and effectiveness of dynamic binary translation. The basic storage logic of the dynamic binary translation process is based on code pages, which consist of occupied and free pages. Occupied pages store the translated target architecture instructions. Once the number of stored pages exceeds a preset threshold, the DBT system's memory cache cleanup mechanism is triggered. Because complex cache cleanup strategies can impose additional resource burdens, DBT typically employs a simpler cache cleanup approach. It's worth noting that the cache cleanup mechanism in DBT systems shares similarities with page replacement algorithms in operating systems, employing different eviction strategies such as first-in-first-out, least recently used, and all-at-once eviction. In the early stages of translation, identifying and reclaiming pages that will not be executed in the near future generally improves translation efficiency. However, as the translation process progresses and code block activity continues to evolve, different cache cleanup strategies may be necessary to maintain efficient translation.

[0010] Translation method:

[0011] In dynamic binary translation, interpreted execution and compiled execution are the two main execution methods. Interpreted execution runs the program by extracting source instructions one by one, parsing them, and executing them immediately without generating target code. It is characterized by fast startup and simple implementation, but because each instruction needs to be re-parsed, the running overhead is relatively high, making it suitable for processing cold code. In contrast, compiled execution translates source instructions into target machine code to generate directly executable code blocks, improving execution efficiency through caching and optimization. It is suitable for hot code. Although there is initial translation overhead, the overall performance is much higher than interpreted execution. The two form a typical trade-off between startup speed and execution efficiency. Dynamic binary translation systems usually dynamically switch between interpretation and compilation based on the execution heat of the code to balance response speed and execution performance.

[0012] Description of problems with existing technical solutions:

[0013] The existing mainstream commercial dynamic binary translation software QEMU implements the translation module by dividing the original binary code into basic blocks and translating them block by block. QEMU has the following problems:

[0014] Regardless of the unit's execution count, all units are compiled and executed. Many units, such as those implementing initialization functions, are only executed once in their entire lifecycle. Compiled execution requires a compiler to convert the code, which incurs significant overhead and does not offset the benefits of improved execution efficiency.

[0015] The use of basic blocks for unit partitioning results in low software execution efficiency. While simple to implement, the small granularity of basic blocks limits the scope for subsequent target code optimization, making global optimization difficult. Frequent inter-block jumps increase context switching overhead, disrupting register states and instruction pipelines, further degrading performance. Furthermore, the generated target code after translation significantly expands in size, exacerbating cache pressure and reducing hit rates.

[0016] The existing invention patent application document, "A System-Wide Dynamic Binary Translation Method Based on Translation Rules," with publication number CN114610325A, includes the following steps: first, during the client instruction parsing phase, instructions that may affect system-level implementation are identified and isolated for identification and monitoring; then, during the translation rule application phase, instructions that may be involved in system-level instruction issues, memory management issues, and exception / interrupt issues are inspected and processed; finally, by analyzing instruction stream information, two conditional code optimization schemes are proposed to improve translation efficiency. The aforementioned prior art focuses on system-level translation and emphasizes the correct simulation of system states, such as registers, memory, and exceptions. It identifies special instructions through translation rules and performs state save and restore before and after translation to ensure correctness in complex scenarios such as interrupts and exceptions. The scheme also proposes optimization strategies for conditional codes such as EFLAGS, such as delayed writeback and dependency graph analysis.

[0017] However, the aforementioned prior art does not explicitly specify any specific modifications to the granularity of the translation unit. The prior art adopts the default basic block granularity. This prior art emphasizes the safety and controllability of translation behavior and is suitable for system-level simulation. It focuses on providing a comprehensive supplement to the implementation of automatically learned translation rules and is focused on improving the performance of dynamic binary translation software. Furthermore, the instruction set architecture implemented in this prior art is ARM. This prior art is difficult to directly apply to user-mode applications with high performance requirements, and the prior art still has shortcomings in execution efficiency.

[0018] Furthermore, current mainstream dynamic binary translation systems (such as QEMU) generally use basic blocks as compilation units. A basic block is a sequentially executed code segment with a single entry and exit point. It is truncated upon encountering control instructions such as jumps and calls. While this division method is simple to implement and has a clear structure, it also introduces several structural issues.

[0019] The excessively small granularity of basic blocks directly limits optimization opportunities. During compilation and optimization, a larger code scope typically means more global information can be analyzed and utilized. Basic blocks, by their very nature, are frequently interrupted by control flow, making it difficult for the compiler to perform in-depth analysis of cross-block behavior, such as advanced optimization operations like function inlining, loop unrolling, and vectorized instruction replacement. This not only limits the execution efficiency of the generated code but also wastes a significant amount of potential optimization opportunities. Furthermore, frequent inter-block jumps incur high context switching overhead. Before and after each basic block execution, the system must perform operations such as register state saving and restoration, stack frame creation and destruction, involving significant memory reads and writes and control transfers. These operations themselves do not provide computational benefits, but they severely undermine the processor's pipeline efficiency, increase the risk of CPU cache failures, and slow overall program execution.

[0020] In a dynamic binary translation system, compilation and execution typically involves a certain amount of initial overhead. This overhead includes instruction parsing, control flow construction, intermediate representation generation, and target code generation and caching. While compilation and execution can significantly improve target code execution efficiency, this does not mean that all code deserves the same optimization resources. The distribution of hotspots during program runtime is distinctly phased and uneven: some code segments are frequently accessed throughout the program's lifecycle, forming the backbone path, while other code segments may only be executed once under specific conditions or never be triggered. If the system treats all code equally, regardless of its popularity, using the same deep compilation process, this will not only lead to the resource waste mentioned above, but also increase the mismatch between optimization strategies and runtime requirements. For example, for short-lived or infrequently called code, complex optimization processes may prevent execution before they can take effect. Furthermore, for high-frequency critical paths, failure to schedule optimizations in a timely manner can lead to performance bottlenecks due to interpreted execution. This "hot and cold" compilation strategy directly violates the fundamental principle that optimization resources should be balanced with performance gains.

[0021] In summary, existing technologies have technical problems such as limited optimization space, high context switching overhead, high code expansion rate, difficulty in global optimization, increased cache pressure and reduced hit rate. Summary of the Invention

[0022] The technical problem to be solved by the present invention is how to solve the technical problems of limited optimization space, high context switching overhead and high code expansion rate in the prior art.

[0023] The present invention solves the above technical problems by adopting the following technical solutions: a dynamic binary translation optimization method based on regional granularity includes:

[0024] S1. Initialize the program entry; load the binary file to be executed, obtain the starting entry address of the program, and initialize the program counter PC; the control flow jumps to the main execution loop and prepares for instruction-level execution;

[0025] S2. Read the instruction content from the current address of the program counter PC, identify the instruction format, operation code and operand through parsing operation, and construct instruction meta information for use by subsequent processing modules;

[0026] S3. Perform cache query: search the code block to which the current instruction belongs in the local compilation cache;

[0027] S4, performing hotspot determination; submitting the instruction block that does not hit the cache to the hotspot monitoring module, and determining whether the current code block is a hotspot code based on a predefined heat threshold condition;

[0028] S5. Perform interpretation and execution operations; the non-hotspot instruction blocks are handed over to the interpreter module for interpretation and execution one by one;

[0029] S6. Initiate a compilation request, select a compilation mode, construct a compilation unit, compile and cache the code block; when a code block is identified as a hotspot, construct context information for the code block and submit it to the compilation manager; the compilation manager receives the compilation request and evaluates the compilation urgency of the code block to obtain a heat level; the compilation manager selects to enter a lightweight compilation path or a deep optimization compilation path based on the heat level and historical behavior of the code block and determines the compilation strategy; the compilation manager generates optimized target code based on the compilation strategy, establishes a mapping relationship between the optimized target code and the original block address, and writes it into the local compilation cache for subsequent reuse operations;

[0030] S7. Use the generated local machine code segment to perform program control, skipping the interpreter to perform local code execution;

[0031] S8. When the current instruction block is executed, jump to S2 to start a new round of execution process until the program terminates.

[0032] The present invention dynamically expands the boundaries of compilation units through control flow analysis to construct regional compilation units with larger granularity and stronger internal correlation, thereby improving the overall optimization space. On this basis, combined with the heat perception mechanism, different levels of optimization strategies are dynamically selected according to the execution frequency of the code block, lightweight optimization is adopted for short-life cycle code blocks, and deep optimization is applied to high-frequency hot spot code blocks, such as function inlining, loop expansion and vectorization processing. Finally, the constructed regional intermediate representation is submitted to the LLVM backend, and different optimization levels (such as -O0, -O2, -O3) are selected according to the heat level to generate efficient target machine code, so as to take into account the translation overhead and execution performance, and improve the overall operation efficiency of the system.

[0033] In a more specific technical solution, in S3, if the code block has been compiled outdated and it is determined to hit the cache, it will directly jump to S9 and reuse the generated target code for execution;

[0034] If the cache is not hit, the hotspot analysis operation in S4 is performed.

[0035] In a more specific technical solution, in S4, if the heat threshold condition is not met, the interpretation and execution operation in S5 is performed;

[0036] If the heat threshold condition is met, the process proceeds to S6 to initiate compilation.

[0037] In a more specific technical solution, in S5, the heat statistics information is updated, the program counter is advanced, and the next address fetch cycle is entered.

[0038] In a more specific technical solution, in S6, the execution environment is initialized;

[0039] Get the starting address and build the initial state;

[0040] Use the stack structure driven depth-first traversal mechanism to perform stack driven depth-first search and basic block traversal operations;

[0041] Through the depth-first traversal mechanism driven by the stack structure, the top element of the stack is continuously popped up as the PC address currently being processed; wherein, it is determined whether the popped PC address already exists in the access set; if so, a skip operation is performed; if not, the instruction content in the corresponding memory is continued to be read, and the instruction decoding operation is completed to obtain the parsing information, and the intermediate representation structure RV_IR and the control flow graph CFG are updated for regional path expansion.

[0042] Perform control flow expansion processing according to the jump type of the jump instruction;

[0043] When the current instruction is a normal sequential execution instruction, the next instruction address is calculated based on the instruction length and pushed into the stack to continue advancing. When calculating the next instruction address, the offset is dynamically adjusted according to the instruction type to continuously capture the linear code sequence.

[0044] Perform boundary detection. During the expansion process, after each basic block is built, check whether the size of the current region exceeds the preset instruction number threshold, or if there are special control flow instructions, terminate the expansion operation of the current region.

[0045] Generate intermediate representation structure RV_IR;

[0046] Perform loop control and termination judgment according to the status of the stack;

[0047] Submit the intermediate representation structure RV_IR to the LLVM backend for compilation, generate and save the corresponding machine code to the code repository for subsequent execution.

[0048] The present invention sets a regional maximum instruction number threshold to control the scale of the construction unit, thereby preventing excessive expansion from causing excessive compilation overhead.

[0049] The present invention only needs to add the jump target address to the stack for unconditional jump instructions as a node for further expansion. In this way, the region construction can fully cover various possible control paths and ensure the correctness and coverage of the translated code.

[0050] When the present invention calculates the address of the next instruction, it is necessary to dynamically adjust the offset according to the instruction type to ensure that the program counter is correctly updated, thereby achieving continuous capture of the linear code sequence.

[0051] The present invention immediately terminates the expansion operation of the current region when encountering a special control flow instruction. This design can effectively avoid compilation delays caused by overly large region units and ensure the correct processing of special semantic instructions at runtime.

[0052] In a more specific technical solution, in the operation of obtaining the starting address and constructing the initial state, the starting address is extracted from the program entry; the starting address is pushed into the working stack as the starting point of the depth-first search DFS traversal; the starting address is added to the visited set; the starting address is used to initialize the basic control flow graph node as the starting point for area expansion, preparing to enter the area construction phase.

[0053] In a more specific technical solution, in the operation of performing control flow expansion processing according to the jump type of the jump instruction, for a conditional jump instruction, the jump target address is pushed into a stack, the jump path is explored, and the fall-through path of the next sequential instruction address is pushed into the stack to cover all control flow branches;

[0054] For unconditional jump instructions, the jump target address is added to the stack as the next expansion node.

[0055] In a more specific technical solution, in the operation of generating the intermediate representation structure RV_IR, when the region construction is completed, the region is organized as a whole to construct a region-level intermediate representation.

[0056] In a more specific technical solution, the region-granularity-based dynamic binary translation optimization system includes:

[0057] The program loading module is used to initialize the program entry; load the binary file to be executed, obtain the starting entry address of the program, and initialize the program counter PC; the control flow jumps to the main execution loop to prepare for instruction-level execution;

[0058] The addressing module is used to read the instruction content from the current address of the program counter PC, identify the instruction format, operation code and operand through parsing operations, and construct instruction meta-information for use by subsequent processing modules. The addressing module is connected to the program loading module;

[0059] The cache query module is used to perform cache query; the code block to which the current instruction belongs is searched in the local compilation cache, and the cache query module is connected to the addressing module;

[0060] Hotspot monitoring module, used to determine hotspots; submit instruction blocks that do not hit the cache to the hotspot monitoring module, and determine whether the current code block is a hotspot code based on predefined heat threshold conditions. The hotspot monitoring module is connected to the cache query module;

[0061] The interpreter module is used to perform interpretation and execution operations; the non-hotspot instruction blocks are handed over to the interpreter module for interpretation and execution one by one, and the interpreter module is connected to the hotspot monitoring module;

[0062] The compilation cache module is used to initiate compilation requests, select compilation methods, build compilation units, and compile and cache code blocks. When a code block is identified as a hotspot, the context information of the code block is built and submitted to the compilation manager. The compilation manager receives the compilation request and evaluates the compilation urgency of the code block to obtain a heat level. The compilation manager selects to enter a lightweight compilation path or a deep optimization compilation path based on the heat level and historical behavior of the code block and determines the compilation strategy. The compilation manager generates optimized target code based on the compilation strategy, establishes a mapping relationship between the optimized target code and the original block address, and writes it to the local compilation cache for subsequent reuse operations. The compilation cache module is connected to the interpreter module.

[0063] Jump to the local execution module to use the generated local machine code segment to perform program control, skip the interpreter to perform local code execution, and jump to the local execution module to connect with the compilation cache module;

[0064] The main loop return module is used to jump to the addressing module to start a new round of execution process when the current instruction block is executed, until the program terminates. The main loop return module is connected to the jump local execution module and the addressing module.

[0065] Compared with the prior art, the present invention has the following advantages:

[0066] The present invention dynamically expands the boundaries of compilation units through control flow analysis to construct regional compilation units with larger granularity and stronger internal correlation, thereby improving the overall optimization space. On this basis, combined with the heat perception mechanism, different levels of optimization strategies are dynamically selected according to the execution frequency of the code block, lightweight optimization is adopted for short-life cycle code blocks, and deep optimization is applied to high-frequency hot spot code blocks, such as function inlining, loop expansion and vectorization processing. Finally, the constructed regional intermediate representation is submitted to the LLVM backend, and different optimization levels (such as -O0, -O2, -O3) are selected according to the heat level to generate efficient target machine code, so as to take into account the translation overhead and execution performance, and improve the overall operation efficiency of the system.

[0067] The present invention sets a regional maximum instruction number threshold to control the scale of the construction unit, thereby preventing excessive expansion from causing excessive compilation overhead.

[0068] The present invention only needs to add the jump target address to the stack for unconditional jump instructions as a node for further expansion. In this way, the region construction can fully cover various possible control paths and ensure the correctness and coverage of the translated code.

[0069] When the present invention calculates the address of the next instruction, it is necessary to dynamically adjust the offset according to the instruction type to ensure that the program counter is correctly updated, thereby achieving continuous capture of the linear code sequence.

[0070] The present invention immediately terminates the expansion operation of the current region when encountering a special control flow instruction. This design can effectively avoid compilation delays caused by overly large region units and ensure the correct processing of special semantic instructions at runtime.

[0071] This paper focuses on improving the user-mode execution efficiency and optimization capabilities of dynamic binary translation software. It uses "region granularity" to partition code blocks and constructs larger, more coherent translation units through control flow analysis. The system dynamically determines whether to compile code based on its popularity during runtime, selecting more advanced optimization strategies such as function inlining and loop unrolling when the popularity is high. Ultimately, LLVM is used to generate efficient target code, balancing translation overhead and performance.

[0072] This invention utilizes dynamic heat sensing and a hybrid execution mechanism of interpretation and compilation, resulting in high translation granularity and a wide optimization space, suitable for efficient execution. Furthermore, because the invention implements user-mode simulation, it eliminates the need for system-level register adaptation. The instruction set architecture implemented in this invention is RISC-V, which differs from the ARM instruction set architecture implemented in existing solutions.

[0073] The present invention is more suitable for user-mode applications with high performance requirements and has higher execution efficiency.

[0074] The present invention solves the technical problems existing in the prior art of limited optimization space, high context switching overhead and high code expansion rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 A schematic diagram of the basic framework of a dynamic binary translator in the background technology;

[0076] Figure 2 Schematic diagram of basic steps of the dynamic binary translation optimization method based on region granularity according to Example 1 of the present invention;

[0077] Figure 3 This is a schematic diagram of the specific steps of constructing a mutation unit in Example 1 of the present invention;

[0078] Figure 4 This is a comparison diagram of the number of coding units at four heat thresholds using different coding granularities according to Example 2 of the present invention;

[0079] Figure 5 This is a comparison chart of the number of context switch operations at four heat thresholds using different compilation granularities according to Example 2 of the present invention;

[0080] Figure 6 This is a comparison diagram of memory usage after compilation at four heat thresholds using different compilation granularities according to Example 2 of the present invention;

[0081] Figure 7 This is a schematic diagram of relative compile time values ​​at four heat thresholds using different compilation granularities according to Example 2 of the present invention;

[0082] Figure 8 This is an analysis diagram of the number of instructions within a basic block of a compilation unit using the regional compilation and basic block compilation methods according to Example 2 of the present invention;

[0083] Figure 9 This is an expansion rate analysis diagram of the second embodiment of the present invention using the regional compilation and basic block compilation methods;

[0084] Figure 10 This is a performance comparison chart of the improved simulator of Example 2 of the present invention and QEMU on nbench. DETAILED DESCRIPTION

[0085] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0086] Example 1

[0087] like Figure 2 As shown, the region-granularity-based dynamic binary translation optimization method provided by the present invention includes the following basic steps:

[0088] S1. Load ELF file;

[0089] In this embodiment, the program entry is initialized; specifically, the program loading module loads the binary file to be executed, obtains the program's starting entry address, and initializes the program counter (PC). The control flow jumps to the main execution loop to prepare for instruction-level execution.

[0090] S2, addressing;

[0091] In this embodiment, instruction acquisition and parsing are performed; specifically, the addressing module reads the instruction content from the current PC address, the parsing module identifies the instruction format, operation code and operand, and constructs instruction meta-information for use by the subsequent processing module.

[0092] S3, query cache;

[0093] In this embodiment, the code block to which the current instruction belongs is searched in the local compilation cache. If the cache is hit (i.e., the block has been compiled), the generated target code is directly reused for execution. If the cache is not hit, hotspot analysis continues.

[0094] S4. When a cache hit occurs, the compiled result is obtained from the cache.

[0095] S5. Execution;

[0096] S6. When there is a cache miss, determine the heat information;

[0097] In this embodiment, hotspot determination is performed. Specifically, instruction blocks that miss the cache are submitted to the hotspot monitoring module, which determines whether the current block is a hotspot based on predefined hotness thresholds (such as access frequency and backedge count). If the threshold is not reached, the program proceeds to step 5 for interpretation and execution. If the threshold is reached, the program proceeds to step 6 for compilation.

[0098] S7. When the heat information is lower than the compilation threshold, interpret the execution engine; and execute the aforementioned step S5.

[0099] In this embodiment, an interpret-execute operation is performed; specifically, non-hot instruction blocks are interpreted and executed one by one by the interpreter module. During the interpret-execution process, heat statistics are updated and the program counter is advanced to enter the next address fetch cycle.

[0100] S8. For potential hot blocks, use T1 compilation level;

[0101] S9, for hot fast, use T2 translation level;

[0102] S10, building a compilation unit;

[0103] In this embodiment, a compilation request is initiated; specifically, when a code block is identified as a hotspot, the system constructs context information for the block and submits it to the compilation manager. The compilation manager receives the compilation request and evaluates its compilation urgency.

[0104] In the compilation mode selection process of this embodiment, the compilation manager chooses to enter the lightweight compilation path or the deep optimization compilation path based on the heat level and historical behavior of the code block; if the strategy determines that the heat is still unstable, submission is postponed.

[0105] like Figure 3 As shown, in this embodiment, step S10 of constructing a mutation unit further includes the following specific steps:

[0106] S101, initialize PC, stack, set, configuration unit contains instruction threshold;

[0107] In this embodiment, before constructing the compilation unit, it is necessary to first complete the initialization of the basic environment. Specifically, it is necessary to set the program counter (PC), the working stack (stack), and the visited address set (set) to record the status during the traversal process. At the same time, the intermediate representation structure (RV_IR) is initialized to save the regional instruction sequence constructed subsequently, a register tracer is established to track register usage, and a control flow graph (CFG) is prepared to support dynamic path expansion. In addition, a threshold for the maximum number of instructions in the region is set to control the scale of the construction unit, thereby preventing excessive expansion from causing excessive compilation overhead.

[0108] S102, obtain the starting address, add the current address to the stack and set;

[0109] In this embodiment, the starting address is obtained and the initial state is constructed. Specifically, after the environment is initialized, the starting address is first extracted from the program entry. This address needs to be pushed into the working stack as the starting point for the depth-first search (DFS) traversal and added to the visited set to ensure that the location is not repeatedly processed later. Subsequently, the starting address is used to initialize the basic control flow graph node as the starting point for region expansion, preparing to officially enter the region construction phase.

[0110] S103, determine whether the stack is empty; if so, end the compilation unit construction operation;

[0111] S104. If not, pop the top element of the stack;

[0112] In this embodiment, a stack-driven depth-first search traverses basic blocks. Specifically, through a stack-driven depth-first traversal mechanism, the top element of the stack is continuously popped as the current PC address. For each popped address, it is first determined whether it already exists in the access set. If so, it is skipped to avoid circular traversal. If it has not been accessed, the corresponding instruction content in memory is read and the instruction decoding operation is completed. The parsed information is used to update the intermediate representation structure (RV_IR) and control flow graph (CFG), providing a basis for subsequent region path expansion.

[0113] S105, parse the top element instruction of the stack and convert it into an intermediate representation according to the rules;

[0114] S106, determining whether it is a jump instruction;

[0115] S107: If it is a jump instruction, determine whether it is a conditional jump;

[0116] S108. If yes, then if the jump address is not in the set, add the jump address to the stack;

[0117] In the jump instruction and control flow expansion of this embodiment, when processing instructions, if a jump instruction is encountered, it is necessary to perform detailed processing based on the jump type. For conditional jump instructions, it is necessary to push the jump target address into the stack to explore the jump path, and also to push the next sequential instruction address (fall-through path) into the stack to ensure that all possible control flow branches are covered. For unconditional jump instructions, it is only necessary to add its jump target address to the stack as a node for the next expansion. In this way, regional construction can fully cover various possible control paths, ensuring the correctness and coverage of the translated code.

[0118] S109. If not, if the next instruction address is not in the set, add the next instruction address to the stack;

[0119] In this embodiment, normal instructions are processed and pushed forward; specifically, when the current instruction is a normal sequential instruction, the address of the next instruction is directly calculated based on the instruction length and pushed onto the stack to continue the process. It should be noted that the RISC-V architecture distinguishes between standard instructions (4 bytes) and compressed instructions (2 bytes). Therefore, when calculating the address of the next instruction, the offset needs to be dynamically adjusted based on the instruction type to ensure that the program counter is correctly updated, thereby achieving continuous capture of linear code sequences.

[0120] S1010, add the elements in the stack to the set; execute S1014;

[0121] S1011, if it is not a jump instruction, update PC;

[0122] S1012, determining whether the current PC already exists in the set;

[0123] S1013. When the current instruction does not exist in the set, add the instruction corresponding to the current PC to the queue;

[0124] S1014. When the current instruction already exists in the set, obtain the top element of the stack;

[0125] In this embodiment, during loop control and termination determination, after a region build is complete, a check is performed to determine whether the stack contains any unprocessed nodes. If the stack is not empty, the process returns to step 3 and pops the next node for processing. If the stack is empty, the region build is complete, the current compilation unit is officially finished, and the subsequent optimization and translation phases can begin.

[0126] S1015. Determine whether the number of instructions included in the compilation unit reaches a threshold; if so, end the compilation unit construction operation; if not, jump to step S103.

[0127] In this embodiment, boundary detection and construction termination are implemented. Specifically, during the expansion process, after each basic block is built, it is necessary to promptly check whether the size of the current region has exceeded a preset instruction count threshold. If the limit is exceeded, or if a special control flow instruction such as a system call (ecall) or indirect jump is encountered, the expansion operation of the current region is immediately terminated. This design effectively avoids compilation delays caused by overly large region units and ensures that special semantic instructions are correctly processed at runtime.

[0128] Generate the intermediate representation structure RV_IR; after the region is built, the region needs to be organized as a whole. First, the region's prologue code block is generated to switch from the interpreter to the compiler execution mode. At the same time, register mapping instructions are generated based on the results of the register tracer to complete the context state synchronization. Subsequently, the previously collected instruction body is written as a whole into the intermediate representation (RV_IR) as the region body. Finally, the region epilogue is added to safely return to the interpreter environment after executing the region, thereby achieving a complete region-level intermediate representation construction.

[0129] S11, compile and store in cache; execute the above step S5;

[0130] During the code block compilation and caching process in this embodiment, the compiler generates optimized target code according to the strategy, establishes a mapping relationship between the target code and the original block address, and writes it into the local compilation cache for subsequent rapid reuse.

[0131] S12. Update popularity information.

[0132] In this embodiment, when the cache hits or the compilation is completed, the program control is transferred to the generated local machine code segment, skipping the interpreter and executing directly, thereby improving the operation efficiency.

[0133] In this embodiment, the main loop is returned; after the current instruction block is executed, the program counter is updated to the next instruction address, and a new round of execution process is restarted until the program terminates.

[0134] Submit it to the LLVM backend for compilation and save it to the code repository; after the regional intermediate representation (RV_IR) is built, it is submitted to the LLVM backend for compilation, generating the corresponding machine code and saving it to the translator's code repository for subsequent execution.

[0135] In this embodiment, a zero-dependency user-mode binary translation platform is built. Specifically, during register and memory simulation, the simulator constructs independent data structures for general-purpose registers (x0–x31) and floating-point registers (f0–f31) to achieve accurate architecture simulation. The x0 register is always set to 0 to meet the semantic constraints of the RISC-V instruction set on register zero. The remaining general-purpose registers support full read and write operations. The floating-point registers can flexibly store single- and double-precision floating-point data to meet floating-point computation requirements. Regarding memory management, the simulator virtualizes guest memory using an address mapping approach. Using the mmap system call, a contiguous physical memory region is allocated on the host machine and mapped into a guest-visible virtual address space. This mechanism not only supports conventional instruction and data access but also features dynamic address remapping, enabling flexible adaptation to various runtime scenarios. This design ensures that virtual memory accesses by guest programs are accurately mapped to the host machine's physical memory region, effectively simulating the target architecture's memory layout and access behavior. Based on this mechanism, the simulator has good scalability and cross-platform portability, which can meet the needs of collaborative testing of heterogeneous architectures and accurate modeling in complex operating environments.

[0136] During the instruction simulation implementation process of this embodiment, an interpreted instruction set simulator based on the RISC-V 64-bit architecture was designed to support multiple extended subsets, including common integer operations, floating-point operations, compressed instructions, and atomic operations. The simulator currently supports a total of 124 instructions, covering multiple functional categories. The I-set (basic integer instruction set) includes 41 general operation instructions such as load, arithmetic logic, jump, and control. The M-set (multiplication and division extension) contains 8 instructions, mainly involving integer multiplication and division operations. The F-set (single-precision floating-point extension) covers 31 instructions, involving functions such as load and store, arithmetic operations, type conversion, and comparison. The D-set (double-precision floating-point extension) corresponds to the double-precision version of the F-set, totaling 34 instructions. In addition, it also supports system control instructions such as ecall and access operations to the control and status register (CSR), totaling 7 instructions. By fully covering these various instructions, the simulator can provide stable and accurate instruction-level execution support for upper-level binary translation and simulation systems.

[0137] In this embodiment, a simulator module is provided; specifically, the dynamic binary translator system as a whole is composed of an analysis module, a translation module, an execution module, and a storage management module.

[0138] The analysis module executes in real time during program execution, collecting behavioral data such as hotspot paths and execution heat, providing guidance for subsequent translation and optimization. The analysis results are then passed to the translation module to assist in the scheduling of instruction conversion and code generation processes.

[0139] The translation module is responsible for converting binary instructions into intermediate representation and then into target code. It first translates the original instructions into intermediate code (IR) expressed in C language based on the analysis information, and then further optimizes and compiles the intermediate code using LLVM to generate machine code that can run on the target platform. The translation module will use different compilation optimization options based on the unit heat information. For example, for units with low execution times, only the mapping between local variables and registers is used, while for units whose execution tests reach a pre-configured threshold, additional optimization options such as function inlining, loop unrolling, loop vectorization, dead code removal, and tail call optimization are used.

[0140] The execution module actually runs the translated code, continuously collecting dynamic information during this process. The system executes the machine instructions generated by the translation module and collects key data such as hotspot paths, jump patterns, and memory behavior during program execution in real time, feeding this information back to the analysis module.

[0141] The memory management module is primarily responsible for managing the translated code cache and metadata. It maintains two core areas: occupied pages, which store translated machine code, instruction metadata, jump maps, and function call tables, while free pages are dynamically allocated to meet memory allocation and deallocation requests from various modules during translation, optimization, and execution.

[0142] Example 2

[0143] In this example, we conducted an experimental evaluation by building our own user-mode dynamic binary translation software, RV64-EMU. We implemented both the basic block-based approach and our proposed approach in the RV64-EMU environment. We executed the same benchmark program to compare metrics such as the number of compilation units, the number of context switches, the size of the compiled cache, the compilation time, and the expansion rate. We also analyzed the time it took for RV64-EMU and QEMU to execute the same benchmark program.

[0144] In this embodiment, the experimental environment setting includes:

[0145] Hardware Configuration

[0146]

[0147] Simulator Configuration

[0148] The RV64-EMU simulator used in the experiment supports the simulation execution of the RISC-V 64-bit instruction set architecture (RISCV_64_IMFDC). The instruction set module extensions implemented and enabled by the simulator in this experiment are shown in Table 1:

[0149] Table 1 RISCV instruction set module extension

[0150]

[0151] Because the simulator runs on an x86-64 host machine and the simulation target is a RISC-V64 platform, all experimental applications are statically cross-compiled using the RV64 Newlib toolchain to generate target executables for RISC-VISA. The cross-compilation toolchain prefix is ​​riscv64-unknown. The specific simulator configuration parameters are shown in Table 2.

[0152] Table 2 Simulator parameter configuration

[0153]

[0154] During simulation execution, the simulator uses basic blocks and regions as compilation units, and Clang acts as the just-in-time compiler for dynamic compilation optimization. To improve code execution efficiency, the just-in-time compiler uses a -O3 optimization strategy to fully utilize hardware resources, improve instruction parallelism, and enhance execution performance.

[0155] In this embodiment, a benchmark program is set. In the experiment, nbench is used to evaluate the overall performance of the RISC-V user-level simulator. The test scope covers key computing tasks such as integer operations, floating-point operations, and memory operations. This experiment analyzes the execution efficiency of the RISC-V simulator under different computing tasks by running multiple test programs of nbench. The specific description of each test item is shown in Table 3:

[0156] Table 3 nbench benchmark program

[0157]

[0158] Through the above tests, the experimental system comprehensively evaluated the performance of the RISC-V simulator in integer computing, floating-point operations, memory management, data compression and encryption, and provided data support for system optimization and performance analysis.

[0159] In this embodiment, the experimental results are analyzed; specifically, in the dynamic binary translation system for analyzing the number of compilation units, the choice of compilation unit granularity has an important impact on the overall system performance and resource consumption. This section compares and analyzes the performance of two different compilation unit construction methods (basic blocks and regional blocks) in terms of the number of compilation units, focusing on the RV64-EMU simulator. The experiment uses different compilation thresholds (i.e., the number of executions for determining a code block as a "hot block") for testing, and analyzes the behavioral trends of each as the threshold changes. The results of the comparison are as follows: Figure 4 shown.

[0160] Experimental results show that the regional granularity compilation method reduces the number of compilation units by an average of about 63.86% compared to the basic block granularity compilation method, and the reduction for some programs exceeds 80%, effectively reducing translation frequency and memory usage, while improving cross-block optimization capabilities.

[0161] In this embodiment, the number of context switches is analyzed. In a dynamic binary translation system, frequent context switch operations will significantly increase the operating overhead of the system, thereby reducing the overall execution efficiency. Context switch operations usually occur when the translator switches between different translation blocks, or switches between interpreted execution mode and compiled execution mode. Each switch requires saving and restoring the running state of the program, resulting in additional performance loss. Therefore, optimizing the frequency and cost of context switch operations is of great significance for improving the execution efficiency of the DBT system. This section focuses on analyzing the impact of different compilation unit granularities (basic blocks and regional blocks) on the number of context switch operations. The experiment was conducted on the RV64-EMU simulator based on different compilation heat thresholds (50, 100, 150, 200) to compare the number of context switches under the two compilation methods. The experimental results are as follows: Figure 5 shown.

[0162] Experimental results show that regional granularity compilation can significantly reduce the number of context switches compared to basic block compilation. The average reduction increases with the compilation threshold. In some programs with good locality, the number of switches can be reduced by an average of about 61.25%, effectively reducing the overall system overhead. The optimization effect is affected by the locality and control flow complexity of the application.

[0163] In this embodiment, the size of the compiled code cache is analyzed; specifically, the impact of different compilation unit granularity on the memory usage of the compiled code cache is analyzed. By comparing the memory usage of regional compilation and basic block compilation at different compilation heat thresholds (50, 100, 150, 200), the difference in memory resource utilization between the two compilation strategies is evaluated. The experimental results are shown in Figure 2. Figure 6 shown.

[0164] Regional granularity compilation effectively reduces code cache memory usage by reducing the number of translation blocks. The overall memory overhead is reduced by an average of about 37.6% compared to basic block compilation. The optimization effect becomes more significant as the compilation threshold increases. It is especially suitable for applications with good locality and concentrated hot paths.

[0165] In this embodiment, a compile time analysis is performed; specifically, the focus is on analyzing the impact of different compilation granularities and heat thresholds on the compilation time of the dynamic binary translation system. Compilation time plays a key role in the overall performance of the dynamic binary translator. It directly determines the program startup delay and translation overhead, and has a significant impact on the performance of both short-term tasks and long-term execution programs. A shorter compile time can effectively shorten the program startup phase and improve the system response speed, but it may limit runtime performance due to insufficient optimization; while a longer compile time can generate high-quality target code and improve execution efficiency, it will increase system latency, especially introducing additional overhead in short-life programs. Therefore, the dynamic binary translation system needs to achieve a balance between compilation overhead and runtime performance. To ensure the stability and repeatability of the experimental data, all test data were performed under the same hardware and software environment, and each group of experiments was performed 10 times to take the average value. Compilation time comparison results Figure 7 shown.

[0166] Compared with basic block compilation, regional granularity compilation reduces compilation time by an average of about 42.66%, and the optimization effect increases with the increase of heat threshold. However, in programs with strong locality or complex control flow, the regional division needs to be reasonably adjusted to avoid performance fluctuations.

[0167] In this embodiment, the number of instructions and the expansion ratio of the region are analyzed; specifically, the distribution of the number of instructions within the compilation unit and the change pattern of the code expansion ratio (Code Expansion Ratio) under different compilation granularity strategies are analyzed. The number of instructions and the expansion ratio of the compilation unit directly affect the storage overhead and runtime performance of the dynamic binary translation system, and are therefore important indicators for measuring the optimization effect of the system. The results of the comparison of the number of instructions within the compilation unit generated by the two methods of regional compilation and basic block compilation are shown in Figure 2. Figure 8 shown.

[0168] Experimental results show that compilation units using region granularity contain significantly more instructions than basic block units, exhibiting a distinct long-tail distribution. Statistics show that the average number of instructions in a region compilation unit is 108.58, approximately ten times that of a basic block compilation unit. Larger compilation units enhance cross-block optimization capabilities, reduce the frequency of control flow switches, and thus improve overall execution efficiency.

[0169] In this embodiment, the code expansion rate is an important indicator to measure the volume growth of the target code generated after translation relative to the original code. Its calculation formula is shown in (1-1):

[0170]

[0171] Here, len(src_insn) represents the number of instructions in the unit before translation, and len(trans_insn) represents the number of instructions in the unit after translation. In the field of dynamic binary translation, the code expansion rate is often greater than 1, generally due to the introduction of instruction overhead such as additional metadata, control flow expansion, or decoding operations during the translation process. A higher expansion rate means greater pressure on the system code cache, which may negatively impact runtime performance. Therefore, properly controlling the code expansion rate is crucial to improving overall system efficiency.

[0172] like Figure 9 The figure shows the distribution of code expansion rates at different compilation granularities. Experiments show that region-granular compilation significantly reduces code expansion rate compared to basic block compilation, with an average expansion rate of only 0.68 times, while basic block compilation can reach as high as 12.45 times. Region compilation effectively alleviates code cache pressure and improves system efficiency.

[0173] In this embodiment, the impact analysis of tiered compilation is performed; specifically, the execution effect of the tiered compilation strategy in the dynamic binary translation system is analyzed, focusing on evaluating the usage distribution of different compilation levels in the program life cycle and its impact on the overall execution efficiency. First, for typical benchmark test programs, the proportion of each level execution mode (interpreted execution, T1 compilation, T2 compilation) under the tiered compilation strategy is counted. All test programs are run 2000 times, and the final execution distribution is shown in Table 4.

[0174] Table 4 Distribution of the three modes in different benchmark programs

[0175]

[0176] As shown in the table, T2 compilation optimization dominates in most compute-intensive programs (such as Numericsort, Stringsort, and Emfloat), while interpreted execution and T1 compilation phases account for a very low percentage. This demonstrates that these programs can fully leverage the performance advantages of deep optimization under the tiered compilation strategy. In contrast, programs with complex control flow or poor locality (such as Four and Bitfield) have a higher proportion of interpreted execution and T1 compilation phases, indicating that their hotspots are more difficult to reliably identify and optimize.

[0177] In further analysis of the effectiveness of the tiered compilation strategy, this experiment evaluated the compilation time and overall execution time under different compilation modes. The specific results are shown in Table 5:

[0178] Table 5 The impact of different compiler optimization methods

[0179]

[0180] Experimental results show that when using only the T1 compiler, while compilation time is shorter, the inability to perform deep optimizations results in an overall execution time of 626.4 seconds, a 19.8% increase over the baseline. Using only the T2 compiler, on the other hand, while compilation time is longer, its optimization capabilities are significant, reducing overall execution time to 542.1 seconds. Tiered compilation combines the advantages of both compilers, with execution times of 1.04 seconds for T1 and 5.9 seconds for T2, for a total execution time of 522.8 seconds. This approach maintains the code quality of T2 without significantly increasing latency, achieving a balance between performance and compilation efficiency.

[0181] In this embodiment, an overall operating performance analysis is performed; specifically, the overall performance of the proposed RV64-EMU optimization simulator and the mainstream dynamic binary translation simulator QEMU in the nbench benchmark test is compared and analyzed. As a currently widely used open source dynamic binary translation framework, QEMU supports instruction simulation and translation between multiple architectures and has strong versatility and scalability. Therefore, selecting QEMU as a comparison object can fully verify the effectiveness of the optimization scheme of this study. In order to quantify the optimization effect, the speedup (Speedup, S) indicator is introduced, and its calculation formula is shown in (3-2):

[0182]

[0183] Among them, iterations_per_sec_new represents the number of iterations executed per second by the optimized benchmark program, and iterations_per_sec_old represents the number of iterations executed per second by the original benchmark program. The comparison results are as follows: Figure 10 shown.

[0184] As can be seen from the figure, on multiple standard benchmark programs, our optimization solution (RV64) significantly outperforms QEMU, with an average performance improvement of 2.88 times. The performance improvement of some test items even exceeds 5 times, demonstrating the effectiveness of the optimization strategy.

[0185] To address the issue of selecting compilation unit granularity, this paper performs dynamic compilation optimization based on region granularity. The core concept of this invention is to dynamically analyze the control flow graph during program execution and construct larger, more contextually complete compilation units (Regions) based on regions. These "regions" can span multiple basic blocks and expand according to the control flow path, providing higher code locality and structural integrity, providing a broader semantic perspective for subsequent deep optimization.

[0186] In response to the heat classification problem, the present invention introduces a heat perception mechanism and a hierarchical compilation strategy. Specifically, the system monitors the execution frequency of each code block during the interpretation and execution phase, and determines blocks with high "heat" as hot codes. For such hot areas, we adopt a deep optimization path and enable advanced compilation strategies, such as LLVM backend optimization at -O2 and -O3 levels, to maximize execution performance. For low-frequency or short-lifecycle code blocks, lightweight compilation or interpretation execution is adopted to avoid unnecessary waste of compilation resources. Through the combination of regional granularity and heat stratification mechanism, the present invention achieves a dynamic balance between optimization capability and execution efficiency.

[0187] In summary, the present invention dynamically expands the boundaries of compilation units through control flow analysis to construct regional compilation units with larger granularity and stronger internal correlation, thereby improving the overall optimization space. On this basis, combined with the heat perception mechanism, different levels of optimization strategies are dynamically selected according to the execution frequency of the code block, lightweight optimization is used for short-life cycle code blocks, and deep optimization is applied to high-frequency hot spot code blocks, such as function inlining, loop expansion and vectorization processing. Finally, the constructed regional intermediate representation is submitted to the LLVM backend, and different optimization levels (such as -O0, -O2, -O3) are selected according to the heat level to generate efficient target machine code, so as to take into account the translation overhead and execution performance, and improve the overall operation efficiency of the system.

[0188] The present invention sets a regional maximum instruction number threshold to control the scale of the construction unit, thereby preventing excessive expansion from causing excessive compilation overhead.

[0189] The present invention only needs to add the jump target address to the stack for unconditional jump instructions as a node for further expansion. In this way, the region construction can fully cover various possible control paths and ensure the correctness and coverage of the translated code.

[0190] When the present invention calculates the address of the next instruction, it is necessary to dynamically adjust the offset according to the instruction type to ensure that the program counter is correctly updated, thereby achieving continuous capture of the linear code sequence.

[0191] The present invention immediately terminates the expansion operation of the current region when encountering a special control flow instruction. This design can effectively avoid compilation delays caused by overly large region units and ensure the correct processing of special semantic instructions at runtime.

[0192] The present invention solves the technical problems existing in the prior art of limited optimization space, high context switching overhead and high code expansion rate.

[0193] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A dynamic binary translation optimization method based on region granularity, characterized in that: The method comprises: S1. Initialize the program entry; load the binary file to be executed, obtain the starting entry address of the program, and initialize the program counter PC; the control flow jumps to the main execution loop and prepares for instruction-level execution; S2. Read the instruction content from the current address of the program counter PC, identify the instruction format, operation code and operand through parsing operation, and construct instruction meta information for use by subsequent processing modules; S3. Perform cache query: search the code block to which the current instruction belongs in the local compilation cache; S4, performing hotspot determination; submitting the instruction block that does not hit the cache to the hotspot monitoring module, and determining whether the current code block is a hotspot code based on a predefined heat threshold condition; S5. Perform interpretation and execution operations; the non-hotspot instruction blocks are handed over to the interpreter module for interpretation and execution one by one; S6. Initiate a compilation request, select a compilation mode, construct a compilation unit, and compile and cache the code block; wherein, when the code block is identified as a hotspot, construct context information of the code block and submit it to the compilation manager; the compilation manager receives the compilation request and evaluates the compilation urgency of the code block to obtain a heat level; the compilation manager selects to enter a lightweight compilation path or a deep optimization compilation path based on the heat level and historical behavior of the code block, and determines a compilation strategy; the compilation manager generates optimized target code according to the compilation strategy, establishes a mapping relationship between the optimized target code and the original block address, and writes the optimized target code into a local compilation cache for subsequent reuse operations; S7. Use the generated local machine code segment to perform program control, skipping the interpreter to perform local code execution; S8. When the current instruction block is executed, jump to S2 to start a new round of execution process until the program terminates.

2. The method for optimizing dynamic binary translation based on regional granularity according to claim 1, characterized in that: In S3, if the code block has been compiled outdated and is determined to have hit the cache, the process directly jumps to S9 and reuses the generated target code for execution; If the cache is not hit, the hotspot analysis operation in S4 is performed.

3. The method for optimizing dynamic binary translation based on regional granularity according to claim 1, wherein: In S4, if the heat threshold condition is not met, the interpretation and execution operation in S5 is performed; If the heat threshold condition is met, the process proceeds to S6 to initiate compilation.

4. The method for optimizing dynamic binary translation based on regional granularity according to claim 1, wherein: In S5, the heat statistics information is updated, the program counter is advanced, and the next address fetch cycle is entered.

5. The method for optimizing dynamic binary translation based on regional granularity according to claim 1, wherein: In S6, the execution environment is initialized; Get the starting address and build the initial state; Use the stack structure driven depth-first traversal mechanism to perform stack driven depth-first search and basic block traversal operations; Through the depth-first traversal mechanism driven by the stack structure, the top element of the stack is continuously popped up as the PC address currently being processed; wherein, it is determined whether the popped PC address already exists in the access set; if so, a skip operation is performed; if not, the instruction content in the corresponding memory is continued to be read, and the instruction decoding operation is completed to obtain the parsing information, and the intermediate representation structure RV_IR and the control flow graph CFG are updated for regional path expansion. Performing control flow expansion processing according to the jump type of the jump instruction; When the current instruction is a normal sequential execution instruction, the next instruction address is calculated based on the instruction length, and the next instruction address is pushed into the stack to continue advancing; wherein, when calculating the next instruction address, the offset is dynamically adjusted according to the instruction type to continuously capture the linear code sequence; Perform boundary detection. During the expansion process, after each basic block is built, check whether the size of the current area exceeds the preset instruction number threshold, or if there are special control flow instructions, terminate the expansion operation of the current area. Generate intermediate representation structure RV_IR; Perform loop control and termination judgment according to the status of the stack; Submit the intermediate representation structure RV_IR to the LLVM backend for compilation, generate and save the corresponding machine code to the code repository for subsequent execution.

6. The method for optimizing dynamic binary translation based on regional granularity according to claim 5, characterized in that: In the operation of obtaining the starting address and constructing the initial state, the starting address is extracted from the program entry; the starting address is pushed into the working stack as the starting point of the depth-first search DFS traversal; the starting address is added to the visited set; the basic control flow graph node is initialized using the starting address as the starting point for area expansion, preparing to enter the area construction phase.

7. The method for optimizing dynamic binary translation based on regional granularity according to claim 1, wherein: In the operation of performing control flow expansion processing according to the jump type of the jump instruction, for a conditional jump instruction, a jump target address is pushed into a stack, a jump path is explored, and a fall-through path of a next sequential instruction address is pushed into the stack to cover all control flow branches; For unconditional jump instructions, the jump target address is added to the stack as the next expansion node.

8. The method for optimizing dynamic binary translation based on region granularity according to claim 1, wherein: In the operation of generating the intermediate representation structure RV_IR, when the region construction is completed, the region is organized as a whole to construct a region-level intermediate representation.

9. A dynamic binary translation optimization system based on regional granularity, characterized in that: The system comprises: The program loading module is used to initialize the program entry; load the binary file to be executed, obtain the starting entry address of the program, and initialize the program counter PC; the control flow jumps to the main execution loop to prepare for instruction-level execution; An addressing module is used to read instruction content from the current address of the program counter PC, identify the instruction format, operation code and operand through parsing operations, and construct instruction meta-information for use by subsequent processing modules. The addressing module is connected to the program loading module; A cache query module is used to perform cache query; the code block to which the current instruction belongs is searched in the local compilation cache, and the cache query module is connected to the addressing module; A hotspot monitoring module is used to determine hotspots; the instruction block that does not hit the cache is submitted to the hotspot monitoring module, and the hotspot monitoring module is connected to the cache query module to determine whether the current code block is a hotspot code based on a predefined heat threshold condition; The interpreter module is used to perform interpretation and execution operations; the non-hotspot instruction blocks are handed over to the interpreter module for interpretation and execution one by one, and the interpreter module is connected to the hotspot monitoring module; A compilation cache module is used to initiate a compilation request, select a compilation method, construct a compilation unit, and compile and cache the code block; wherein, when the code block is identified as a hotspot, context information of the code block is constructed and submitted to the compilation manager; the compilation manager receives the compilation request and evaluates the compilation urgency of the code block to obtain a heat level; the compilation manager selects to enter a lightweight compilation path or a deep optimization compilation path based on the heat level and historical behavior of the code block and determines the compilation strategy; the compilation manager generates optimized target code according to the compilation strategy, establishes a mapping relationship between the optimized target code and the original block address, and writes it into the local compilation cache area for subsequent reuse operations. The compilation cache module is connected to the interpreter module; A jump local execution module is used to use the generated local machine code segment to perform program control and skip the interpreter to perform local code execution operations, and the jump local execution module is connected to the compilation cache module; The main loop return module is used to jump to the addressing module to start a new round of execution process when the current instruction block is executed, until the program terminates. The main loop return module is connected to the jump local execution module and the addressing module.

Images