A data-driven software cross-instruction set architecture porting method
By building a cross-architecture portability knowledge base and large model technology, the performance and reliability issues of software migration from X86/ARM to RISC-V were solved, achieving efficient and accurate cross-architecture software portability, especially the optimized adaptation of vector functions.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NORTHEASTERN UNIV CHINA
- Filing Date
- 2026-04-09
- Publication Date
- 2026-07-10
AI Technical Summary
Existing technologies suffer from significant performance degradation, poor reliability, and high costs when migrating software from x86/ARM architecture to RISC-V architecture, especially for architecture-specific code segments such as inline assembly and vector computing, which are difficult to adapt efficiently.
We build a cross-architecture portability knowledge base, acquire successful portability cases, perform localization and context analysis, generate target code using a large model, and conduct functional verification and performance evaluation. By combining architectural feature mapping rules and deep learning technology, we optimize vector function relationships to achieve automated code generation.
It enables efficient and accurate cross-architecture software porting, reduces the cost and error rate of manual porting, and improves performance, especially with significant adaptation effects for vector functions.
Smart Images
Figure CN122363753A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software porting technology, and in particular, it designs a data-driven method for porting software across instruction set architectures. Background Technology
[0002] Currently, mature software ecosystems are primarily built upon instruction set architectures such as x86 and ARM. However, with the rapid development of the open-source instruction set architecture RISC-V, its irreplaceable advantages are becoming increasingly apparent. On the one hand, x86 and ARM employ incremental design, requiring new processors to be compatible with all historical extensions, resulting in complex designs and a heavy historical burden. In contrast, RISC-V is based on a basic ISA (such as RV32I) and optional standard extensions, allowing for flexible hardware configuration based on needs, and features modularity, low power consumption, and scalability. On the other hand, the ARM architecture uses a licensing model, which is expensive, while x86 is completely closed-source, forcing users to purchase CPUs from specific vendors. This leaves companies relying on these architectures lacking autonomy and facing the risk of technology blockade. In contrast, the RISC-V instruction set specification is an open standard, allowing any individual, institution, or company to freely use and design chips, achieving complete openness and independent control. However, x86 and ARM are deeply tied to basic software such as operating systems, forming a vast existing software ecosystem. Developing software anew on the RISC-V platform would be time-consuming and costly. Therefore, efficiently and accurately migrating existing software to the RISC-V platform is of crucial significance to the development of the RISC-V ecosystem.
[0003] Current research on cross-architecture software porting primarily focuses on binary translation technology. Binary translation converts the binary code of software on older architecture platforms into instructions for newer architecture platforms, allowing it to run on the new platform without recompilation, thus compensating for the shortcomings of the new architecture platform's initially underdeveloped ecosystem. A smaller portion of research focuses on comprehensive adaptation to the new architecture at the source code level, modifying the source code and recompiling and running it on the new architecture platform. This mainly focuses on the cross-architecture porting of specific types of individual software, such as basic mathematical libraries and deep learning algorithm implementations.
[0004] Binary translation has unavoidable drawbacks in terms of performance and reliability. First, the execution process itself incurs overhead. Second, the poor quality of the translated instructions leads to performance degradation. Furthermore, the process is not entirely reliable and may result in incorrect results. Manually porting source code requires developers to have a deep understanding of the underlying differences between the source and target architectures, modifying code line by line, which is not only costly and inefficient but also highly prone to introducing errors. Especially for architecture-specific code segments involving inline assembly, vector calculations, etc., achieving correct and efficient adaptation is often difficult. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this invention provides a data-driven method for porting software across instruction set architectures, comprising the following steps:
[0006] Acquire several successful porting cases from source architecture to target architecture and build a cross-architecture porting knowledge base;
[0007] Obtain the source code of the project to be ported, locate and analyze the context of the source code to be ported, and obtain the code snippet to be ported and the context information corresponding to the code snippet to be ported.
[0008] Using the code snippet to be ported and context information as query criteria, similar porting examples are retrieved from the cross-architecture porting knowledge base;
[0009] Based on the code snippet to be ported, context information, and similar porting examples, structured prompts are dynamically constructed and guided to generate target code by a large model with code generation capabilities.
[0010] Perform functional verification and performance evaluation on the target code, and integrate and output the target porting code based on the verification results.
[0011] Furthermore, the successful porting cases include both source code and target code;
[0012] The specific method for building a cross-architecture portability knowledge base is as follows:
[0013] The architectural features of the source architecture are extracted from the official documentation of the source architecture in a standardized manner. The types of architectural features include assembly instructions, vector functions, predefined macros of the architecture, and compilation options and directives.
[0014] The source code and target code of each successful porting case are compared and analyzed. By constructing an abstract syntax tree, node matching is performed and regular expressions representing architectural features are constructed. The correspondence between the source architecture and target architecture features is extracted to obtain the difference code and code information description.
[0015] The types of difference codes, code information descriptions, and architectural features in successful porting cases are converted into vectors using a text embedding model to obtain a vectorized representation of the successful porting cases.
[0016] Establish architecture feature mapping rules, and build a cross-architecture portability knowledge base based on the architecture feature mapping rules and the vectorized representation of successful porting cases.
[0017] Furthermore, establishing architectural feature mapping rules includes:
[0018] Mapping rules are established for assembly instructions, vector functions, architecture predefined macros, and compiler options and directives. Specifically, the mapping rules for vector functions are established as follows:
[0019] For vector functions in the source code and target code, obtain the equivalent functions in the source code and target code respectively, extract the vector function mapping relationship, and optimize the vector function relationship by using multiplication-addition fusion, subtraction-multiplication fusion, polynomial evaluation fusion and reduction fusion strategies to obtain the vector function mapping rule.
[0020] Furthermore, the source code of the project to be ported includes multiple source code files;
[0021] The specific methods for locating and analyzing the context of the code to be ported are as follows:
[0022] Parse each source file of the project to be ported and generate an abstract syntax tree for each source file;
[0023] Traverse the abstract syntax tree of each source file to locate and extract the code snippets to be ported;
[0024] Extract all #include statements from the source code of the project to be ported, and parse the inclusion relationships between the various source code files;
[0025] Tree-sitter is used to parse the declarations in the source code of the project to be ported, query the identifier nodes of the code segment to be ported, obtain the identifier information and control flow information, and use the identifier information and control flow information as the context information of the code segment to be ported.
[0026] The specific method for querying the identifier node of the code snippet to be ported is as follows:
[0027] For each code segment to be ported, extract the identifier node of the code segment to be ported;
[0028] Check if the source file containing the code snippet to be ported contains context information. If no context information is found, continue to check if other source files contained in the source file containing the code snippet to be ported contain context information, until all other source files contained in the source file containing the code snippet to be ported are checked.
[0029] The identifier nodes include macro definition nodes, function declaration nodes, type declaration nodes, enumeration type declaration nodes, structure / union declaration nodes, class declaration nodes, variable declaration nodes, member variable declaration nodes, namespace nodes, and parameter list nodes; the control flow information includes conditional compilation, if statements, for statements, switch-case statements, while statements, functions, and data types with externally accessible members.
[0030] Furthermore, the specific method for extracting the code fragment to be ported is as follows:
[0031] For each source file in the project source code to be ported, start from the root node of the abstract syntax tree to match feature architecture. If the code segment corresponding to the root node does not match the architecture feature, proceed to the next source file to continue matching; if the code segment corresponding to the root node matches the architecture feature, start from the root node to traverse each node in the abstract syntax tree and check whether each node matches the architecture feature.
[0032] If the current node being checked does not match the architectural features, the current node is pruned, and the process moves to the next node for checking; if the current node matches the architectural features, all named child nodes of the current node are checked, including:
[0033] For the currently named child node being examined, if the current named child node is not a block node and matches an architecture feature, then backtrack the current named child node and extract the code segment corresponding to the parent node of the current named child node; if the current named child node is a block node and only the block node matches the architecture feature, then extract the code segment corresponding to the current named child node.
[0034] The block node refers to a node whose corresponding code segment can be returned as a complete code block.
[0035] Furthermore, the specific method for retrieving similar porting examples from the cross-architecture porting knowledge base is as follows:
[0036] Based on the code snippet to be ported, context information, and architecture feature mapping rules in the cross-architecture porting knowledge base, an initial target code is generated; the difference between the initial target code and the code snippet to be ported is calculated, and structural features and text features are extracted. The structural features include code modification type, file information, original code syntax structure information, and architecture feature type, while the text features include code text information and commit description information.
[0037] Weighted fusion of structural and textual features generates a query vector;
[0038] Calculate the cosine similarity between the query vector and the vectorized representations of all successful porting cases in the cross-architecture porting knowledge base. Set a similarity threshold and select successful porting cases that exceed the threshold as similar porting examples. If no successful porting case exceeds the threshold, then select the top examples with the highest similarity. One successful transplant case serves as a similar transplant example.
[0039] Furthermore, the specific method for constructing structured prompts and guiding the large model to generate target code is as follows:
[0040] Based on the architecture feature mapping rules, the code snippet to be ported, context information, and similar porting examples, structured prompt words are dynamically constructed, including role settings, task descriptions, the code snippet to be ported and its corresponding context information, architecture feature mapping rules, and similar porting examples;
[0041] The large model is guided by structured prompts to generate target code. The generated target code is then subjected to static syntax checking. If an error occurs in the target code, the error information is fed back to the large model, and the generation process is repeated several times until the generated target code passes the static syntax check.
[0042] Furthermore, the functional verification is to verify that the functionality of the target code in the target architecture is consistent with that in the source architecture;
[0043] Performance evaluation is conducted using XNNPACK as the benchmark, selecting a 32-bit floating-point neural network function for testing; comparative testing is performed in the QEMU simulation environment, using the open-source cross-architecture SIMD code conversion library SIMDe as a reference, and speedup is used as the evaluation metric; if the performance evaluation fails, failure cases are recorded, structured prompts are adjusted, and the large model is guided to regenerate the target code; if the performance evaluation passes, the target code is integrated, and a porting report is generated, including a list of code snippets to be ported, porting suggestions, and patches.
[0044] The beneficial effects of adopting the above technical solution are as follows: This invention provides a data-driven software cross-instruction set architecture porting method, which constructs a data-driven cross-architecture porting knowledge base. It transforms successful porting cases from the open-source ecosystem into reusable and searchable structured knowledge, breaking through the limitations of traditional porting methods that rely on expert experience or general tools. This enables efficient and accurate porting of C / C++ source code. This invention optimizes vector function content by deeply analyzing the differences in vector functions between architectures, combining historical porting experience, and introducing optimization strategies such as multiplication-addition fusion, subtraction-multiplication fusion, polynomial evaluation fusion, and reduction fusion to ensure the accuracy and performance of the porting. Through Tree-sitter static analysis, the code to be ported is precisely located. Simultaneously, structured prompts are constructed by combining contextual information, code examples, architectural knowledge, the code fragment to be ported, and contextual information. Combined with iterative feedback from static checking rules to generate code, this effectively automates the generation of target code, reducing the cost of manual porting. This invention significantly reduces the cost of porting C / C++ software from the x86 / ARM architecture to the RISC-V architecture by mining architecture mapping rules and similar porting examples in the history of open source software porting, and combining program analysis technology and large model technology. Attached Figure Description
[0045] Figure 1Flowchart of the data-driven software cross-instruction set architecture porting method provided in Embodiment 1 of the present invention;
[0046] Figure 2 Flowchart for locating code snippets to be ported provided in Embodiment 1 of the present invention;
[0047] Figure 3 The flowchart of similar sample retrieval based on hybrid features provided in Embodiment 1 of the present invention. Detailed Implementation
[0048] The specific implementation methods of this application will be further described in detail below with reference to the accompanying drawings and embodiments.
[0049] Example 1:
[0050] A data-driven approach to porting software across instruction set architectures, such as... Figure 1 As shown, it includes the following steps:
[0051] Step 1: Obtain several successful porting cases from the source architecture to the target architecture and build a cross-architecture porting knowledge base;
[0052] We collect architectural features from instruction set manuals and compiler official documentation, and mine the feature mapping relationship between the X86 / ARM source architecture and the RISC-V target architecture from system-level software; we construct transformation rules for complex vector functions by analyzing successful cross-architecture porting cases and integrating computational optimization strategies; we vectorize code examples from successful porting cases to form a knowledge base containing architectural features and their mapping relationships, as well as code porting examples.
[0053] Step 1.1: First, extract the architectural features of the source architecture from the official documentation of the source architecture in a standardized manner. The types of architectural features include assembly instructions, vector functions, predefined macros of the architecture, and compilation options and directives.
[0054] In this embodiment, the architectural features of the source architecture extracted from the official documentation include 3084 assembly instruction names, 11490 vector functions, 150 architecture predefined macros, and 362 features such as compilation options and compilation directives. Among them, the vector functions include data types, vector functions themselves, and vector extension header file features.
[0055] Step 1.2: Obtain several successful porting cases from the source architecture X86 / ARM to the target architecture RISC-V from GitHub open-source projects. Each successful porting case includes source code and target code. The successful porting cases in this embodiment involve multiple fields such as Linux kernel drivers, audio and video codec libraries, and encryption algorithm libraries. Use Python scripts to automatically compare and analyze the source code and target code in the successful porting cases: by constructing an Abstract Syntax Tree (AST) for node matching and constructing regular expressions representing architectural features, extract the correspondence between the features of the source architecture and the target architecture, and obtain the difference code diff and code information description.
[0056] Step 1.3: Convert the types of differing codes, code information descriptions (such as "RISC-V: Implementing… features.") and architectural features in successful porting cases into vectors using a text embedding model to obtain a vectorized representation of the successful porting cases, in order to support subsequent semantic similarity retrieval;
[0057] The text embedding model used in this embodiment is the BAAI / bge-m3 model, which has the advantage of supporting multi-vector retrieval and performing well in hybrid retrieval tasks. It can simultaneously meet the needs of code semantic matching and architectural feature keyword matching.
[0058] Step 1.4: Establish architecture feature mapping rules;
[0059] For vector functions in the source code and target code, obtain the equivalent functions in the source code and target code respectively, extract the vector function mapping relationship, and use multiplication-addition fusion, subtraction-multiplication fusion, polynomial evaluation fusion and reduction fusion strategies to optimize the vector function relationship and obtain the mapping rule of vector function;
[0060] For example, the data type naming format for a vector function in the ARM architecture is "<type><bit width>x<number of elements>_t", while the naming rule in the RISC-V architecture is "v<type> <eew> m <emul>The conversion principle of mapping "float32x4_t" to "vfloat32m4_t" can be obtained by defining "_t". Similarly, the vector function for 32-bit floating-point addition is named "vaddq_f32(a, b)" in the ARM architecture, which can be mapped to the equivalent vector function "__riscv_vadd_vv_f32m4(a, b, vl)" in the RISC-V architecture. Here, "vl" is used to configure the number of elements being processed. When the vector register width is 128 bits and the elements are 32 bits, it is usually set to 4. By analyzing successful porting cases, the vector function mapping relationship is obtained from the equivalent functions under different architecture branches. The vector function relationship is optimized by strategies such as multiplication-addition fusion, subtraction-multiplication fusion, polynomial evaluation fusion, and reduction fusion, resulting in the mapping rules of vector functions.
[0061] The types of architectural features include assembly instructions, vector functions, architecture-predefined macros, and compiler options and directives. Among them, the mapping of vector functions is more complex and has higher performance requirements. Therefore, we first perform a simple mapping between the source architecture and the target architecture for vector function data types and function naming rules. Then, we extract relatively complex mappings from successful porting cases. These complex mappings may not be directly mapped one-to-one in terms of name. Finally, we use fusion computing to optimize some mapping rules to complete the conversion. The goal is to reduce the number of instructions used on the target architecture.
[0062] Step 1.5: Construct a cross-architecture portability knowledge base based on architecture feature mapping rules and vectorized representations of successful porting cases;
[0063] The cross-architecture porting knowledge base built in this step consists of two parts. The first part is the architecture feature mapping rules, including 263 assembly instructions, 2999 vector function-related rules, 84 architecture predefined macros, and 331 compiler option-related rules. The second part is the vectorized representation of successful porting cases.
[0064] Step 2: Obtain the source code of the project to be ported, locate and analyze the context of the source code files to be ported, and obtain the code snippet to be ported and the context information corresponding to the code snippet to be ported;
[0065] Tree-sitter is used to perform static abstract syntax tree analysis on the source software code, combined with regular expression matching to locate the code segment to be ported, and the abstract syntax tree and control flow analysis are used to obtain the context information of the code segment to be ported.
[0066] Step 2.1: Obtain the source code of the project to be ported, including multiple source code files; use Python's Tree-sitter library to parse each source code file in the project source code to be ported and generate an abstract syntax tree for each source code file; build matching patterns for different types of architectural features, traverse the abstract syntax tree of each source code file to locate it, and accurately extract semantically complete code fragments to be ported through pruning and backtracking.
[0067] like Figure 2 As shown, for each source file in the project's source code to be ported, a regular expression is used to check whether the code snippet corresponding to the root node matches the architectural features. If the code snippet corresponding to the root node does not match the architectural features, the process continues to the next source file. If the code snippet corresponding to the root node matches the architectural features, the process traverses each node in the abstract syntax tree starting from the root node, checking whether the code snippet corresponding to each node matches the architectural features.
[0068] If the current node being checked does not match any architectural features, the current node is pruned, and the process moves to the next node for checking; if the current node matches any architectural features, all named child nodes of the current node are checked, including:
[0069] For the currently named child node being inspected, if the current named child node is not a block node and matches an architecture feature, then backtrack the current named child node and report the code segment corresponding to the parent node of the current named child node; if the current named child node is a block node and only the block node matches the architecture feature, then report the code segment corresponding to the current named child node, thereby achieving a balance between semantic integrity and code size.
[0070] A block node is a node whose corresponding code segment can be returned as a complete code block, such as function definitions, structs, and conditional compilation blocks wrapped by "#ifdef" and "#endif".
[0071] Step 2.2: Obtain the context of the code snippet to be ported;
[0072] First, extract all #include statements from the source code of the project to be ported, parse the inclusion relationships between the various source code files, and store them in a temporary database for use in subsequent steps.
[0073] Tree-sitter is used to parse the declarations in the source code of the project to be ported, and the identifier information and control flow information are obtained by querying the identifier node; the identifier information and control flow information are used as the context information of the code segment to be ported.
[0074] The identifier nodes include macro definition nodes, function declaration nodes, type declaration nodes, enumeration type declaration nodes, structure / union declaration nodes, class declaration nodes, variable declaration nodes, member variable declaration nodes, namespace nodes, and parameter list nodes. Control flow information includes conditional compilation, if statements, for statements, switch-case statements, while statements, functions, and data types with externally accessible members. The identifier and control flow information for all declarations are obtained by parsing the syntax tree and stored in a temporary database for subsequent steps.
[0075] The specific method for querying the identifier node of the code snippet to be ported is as follows:
[0076] For each code segment to be ported, extract the identifier of the code segment to be ported;
[0077] Querying context information in a temporary database based on an identifier, including:
[0078] Check if the source file containing the code snippet to be ported contains complete context information. If no complete context information is found, continue to check if other source files contained in the source file containing the code snippet to be ported contain complete context information, until all other source files contained in the source file containing the code snippet to be ported are checked.
[0079] Step 3: Using the code snippet to be ported and context information as query criteria, retrieve similar porting examples from the cross-architecture porting knowledge base;
[0080] like Figure 3 As shown, using the code snippet to be ported located in step 2 and its context information as query conditions, similar successful porting cases are retrieved from the cross-architecture porting knowledge base built in step 1.
[0081] Step 3.1: First, based on the code snippet to be ported and the context information obtained in Step 2, combined with the architecture feature mapping rules obtained in Step 1, an initial target code is generated, and the difference (diff) between the target code snippet and the target code snippet is calculated to extract hybrid features. The hybrid features include structural features and text features. Among them, structural features include code modification type, file information, original code syntax structure information, and architecture feature type, while text features include code text information and commit message information. The structural features and text features are then weighted and fused to form a query vector.
[0082] Step 3.2: Calculate the cosine similarity between the query vector and the vectorized representation of all successful migration cases in the cross-architecture migration knowledge base. Set the similarity threshold to 0.75 and select successful migration cases that exceed the threshold as similar migration examples. If no successful migration case exceeds the threshold, take the top 3 successful migration cases with the highest similarity as similar migration examples.
[0083] Step 4: Based on the code snippet to be ported, context information, and similar porting examples, dynamically construct structured prompts and guide a large model with code generation capabilities to generate the target code;
[0084] Based on the architecture feature mapping rules obtained in step 1, the code snippet to be ported and its context information obtained in step 2, and the similar porting examples retrieved in step 3, a structured prompt word template is dynamically constructed, input into a pre-trained large language model to generate the target architecture code, and the generated result is optimized through feedback iteration.
[0085] The structured prompt template includes role settings, task description, code snippets to be ported and corresponding context information, architectural feature mapping rules involved in the code snippets to be ported, and similar porting examples.
[0086] The target code is generated by calling the DeepSeek and ChatGPT models through the OpenAI API. The temperature parameter is set to temperature=0.2 to maintain generation stability, and max_tokens=1024.
[0087] The generated target code undergoes static syntax checking. The appropriate commands are used for automated building based on the project's build system. If an error occurs, the error message is fed back to the large model for a second iteration of generation, until the corrected target code passes the static syntax check.
[0088] Step 5: Perform functional verification and performance evaluation on the target code, and integrate and output the target porting code based on the verification results;
[0089] Perform functional verification and performance evaluation on the target code generated in step 4, and integrate and output the target porting code based on the verification results;
[0090] Functional verification: Using the test examples provided by the project, verify that the functionality of the adapted code in the target RISC-V architecture is consistent with that in the source architecture.
[0091] Performance Evaluation: Using XNNPACK (an open-source neural network computation optimization library developed by the Google team) as the benchmark, commonly used 32-bit floating-point neural network functions were selected for testing. Comparative tests were conducted in the QEMU simulation environment, using the open-source cross-architecture SIMD code conversion library SIMDe as a control, and speedup was used as the evaluation metric.
[0092] If the performance evaluation fails, the failure case is recorded, and the process returns to step 4 to adjust the structured prompts (e.g., increase the number of examples, strengthen constraints) and guide the large model to regenerate the target code. If the performance evaluation passes, the target code is integrated into the target software project, and a porting report is generated, including a list of code snippets to be ported, porting suggestions, and patches.
[0093] Example 2:
[0094] This embodiment proposes an electronic device, including: one or more processors, and a memory for storing instructions, which, when executed by the one or more processors, cause the one or more processors to perform the data-driven software cross-instruction set architecture porting method.
[0095] The electronic device may be a mobile phone, computer, or tablet computer, etc., and includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the data-driven software cross-instruction set architecture porting method as described in the embodiments. It is understood that the electronic device may also include input / output (I / O) interfaces and communication components.
[0096] The processor is used to execute all or part of the steps in the data-driven software cross-instruction set architecture porting method described in the above embodiments. The memory is used to store various types of data, which may include, for example, instructions for any application or method in the electronic device, as well as application-related data.
[0097] The processor may be implemented as an Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), controller, microcontroller, microprocessor, or other electronic components, and is used to execute the data-driven software cross-instruction set architecture porting method described in the above embodiments.
[0098] Example 3:
[0099] This embodiment proposes a computer-readable storage medium that stores executable instructions. When these instructions are executed, if they are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
[0100] The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the data-driven software cross-instruction set architecture porting method described in the various embodiments of this application.
[0101] The aforementioned storage media include: flash memory, hard disks, multimedia cards, card-type memory (e.g., SD (Secure Digital Memory Card) or DX (Memory Data Register, MDR) memory), random access memory (RAM), static random-access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, disks, optical discs, servers, APP (Application) application stores, and other media capable of storing program verification codes. These media store computer programs, and when executed by a processor, they can implement the various steps of the data-driven software cross-instruction set architecture porting method described above.
[0102] Example 4:
[0103] This embodiment proposes a computer program product, including a computer program or instructions, which, when executed by a processor, implements the data-driven software cross-instruction set architecture porting method described above.
[0104] Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a computer program product.
[0105] The various embodiments in this application are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.
[0106] The scope of protection of this application is not limited to the embodiments described above. Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from the scope and spirit of this disclosure. If such modifications and variations fall within the scope of this disclosure and its equivalents, then the intent of this disclosure also includes these modifications and variations.< / emul> < / eew>
Claims
1. A data-driven method for porting software across instruction set architectures, characterized in that, Includes the following steps: Acquire several successful porting cases from source architecture to target architecture and build a cross-architecture porting knowledge base; Obtain the source code of the project to be ported, locate and analyze the context of the source code to be ported, and obtain the code snippet to be ported and the context information corresponding to the code snippet to be ported. Using the code snippet to be ported and context information as query criteria, similar porting examples are retrieved from the cross-architecture porting knowledge base; Based on the code snippet to be ported, context information, and similar porting examples, structured prompts are dynamically constructed and guided to generate target code by a large model with code generation capabilities. Perform functional verification and performance evaluation on the target code, and integrate and output the target porting code based on the verification results.
2. The data-driven software cross-instruction set architecture porting method according to claim 1, characterized in that, The successful porting cases include source code and target code; The specific method for building a cross-architecture portability knowledge base is as follows: The architectural features of the source architecture are extracted from the official documentation of the source architecture in a standardized manner. The types of architectural features include assembly instructions, vector functions, predefined macros of the architecture, and compilation options and directives. The source code and target code of each successful porting case are compared and analyzed. By constructing an abstract syntax tree, node matching is performed and regular expressions representing architectural features are constructed. The correspondence between the source architecture and target architecture features is extracted to obtain the difference code and code information description. The types of difference codes, code information descriptions, and architectural features in successful porting cases are converted into vectors using a text embedding model to obtain a vectorized representation of the successful porting cases. Establish architecture feature mapping rules, and build a cross-architecture portability knowledge base based on the architecture feature mapping rules and the vectorized representation of successful porting cases.
3. The data-driven software cross-instruction set architecture porting method according to claim 2, characterized in that, Establishing architectural feature mapping rules includes: Mapping rules are established for assembly instructions, vector functions, architecture predefined macros, and compiler options and directives. Specifically, the mapping rules for vector functions are established as follows: For vector functions in the source code and target code, obtain the equivalent functions in the source code and target code respectively, extract the vector function mapping relationship, and optimize the vector function relationship by using multiplication-addition fusion, subtraction-multiplication fusion, polynomial evaluation fusion and reduction fusion strategies to obtain the vector function mapping rule.
4. The data-driven software cross-instruction set architecture porting method according to claim 1, characterized in that, The source code of the project to be ported includes multiple source code files; The specific methods for locating and analyzing the context of the code to be ported are as follows: Parse each source file of the project to be ported and generate an abstract syntax tree for each source file; Traverse the abstract syntax tree of each source file to locate and extract the code snippets to be ported; Extract all #include statements from the source code of the project to be ported, and parse the inclusion relationships between the various source code files; Tree-sitter is used to parse the declarations in the source code of the project to be ported, query the identifier nodes of the code segment to be ported, obtain the identifier information and control flow information, and use the identifier information and control flow information as the context information of the code segment to be ported. The specific method for querying the identifier node of the code snippet to be ported is as follows: For each code segment to be ported, extract the identifier node of the code segment to be ported; Check if the source file containing the code snippet to be ported contains context information. If no context information is found, continue to check if other source files contained in the source file containing the code snippet to be ported contain context information, until all other source files contained in the source file containing the code snippet to be ported are checked. The identifier nodes include macro definition nodes, function declaration nodes, type declaration nodes, enumeration type declaration nodes, structure / union declaration nodes, class declaration nodes, variable declaration nodes, member variable declaration nodes, namespace nodes, and parameter list nodes; the control flow information includes conditional compilation, if statements, for statements, switch-case statements, while statements, functions, and data types with externally accessible members.
5. A data-driven software cross-instruction set architecture porting method according to claim 4, characterized in that, The specific method for extracting the code fragment to be ported is as follows: For each source file in the project source code to be ported, start from the root node of the abstract syntax tree to match feature architecture. If the code segment corresponding to the root node does not match the architecture feature, proceed to the next source file to continue matching; if the code segment corresponding to the root node matches the architecture feature, start from the root node to traverse each node in the abstract syntax tree and check whether each node matches the architecture feature. If the current node being checked does not match the architecture features, the current node is pruned and the process jumps to the next node for checking. If the current node matches the architecture characteristics, then check all named child nodes of the current node, including: For the currently named child node being examined, if the current named child node is not a block node and matches an architecture feature, then backtrack the current named child node and extract the code segment corresponding to the parent node of the current named child node; if the current named child node is a block node and only the block node matches the architecture feature, then extract the code segment corresponding to the current named child node. The block node refers to a node whose corresponding code segment can be returned as a complete code block.
6. The data-driven software cross-instruction set architecture porting method according to claim 1, characterized in that, The specific method for retrieving similar porting examples from the cross-architecture porting knowledge base is as follows: Based on the code snippet to be ported, context information, and architecture feature mapping rules in the cross-architecture porting knowledge base, the initial target code is generated; The differences between the initial target code and the code segment to be ported are calculated, and structural features and text features are extracted. The structural features include code modification type, file information, original code syntax structure information, and architecture feature type. The text features include code text information and commit message information. Weighted fusion of structural and textual features generates a query vector; Calculate the cosine similarity between the query vector and the vectorized representations of all successful porting cases in the cross-architecture porting knowledge base. Set a similarity threshold and select successful porting cases that exceed the threshold as similar porting examples. If no successful porting case exceeds the threshold, then select the top examples with the highest similarity. One successful transplant case serves as a similar transplant example.
7. The data-driven software cross-instruction set architecture porting method according to claim 1, characterized in that, The specific method for constructing structured prompts and guiding the large model to generate target code is as follows: Based on the architecture feature mapping rules, the code snippet to be ported, context information, and similar porting examples, structured prompt words are dynamically constructed, including role settings, task descriptions, the code snippet to be ported and its corresponding context information, architecture feature mapping rules, and similar porting examples; The large model is guided by structured prompts to generate target code. The generated target code is then subjected to static syntax checking. If an error occurs in the target code, the error information is fed back to the large model, and the generation process is repeated several times until the generated target code passes the static syntax check.
8. The data-driven software cross-instruction set architecture porting method according to claim 1, characterized in that, The functional verification is to verify that the functionality of the target code in the target architecture is consistent with that in the source architecture. Performance evaluation was conducted using XNNPACK as the benchmark, with a 32-bit floating-point neural network function selected for testing. Comparative testing was performed in the QEMU simulation environment, with the open-source cross-architecture SIMD code conversion library SIMDe as the reference, and speedup as the evaluation metric. If the performance evaluation failed, failure cases were recorded, the structured prompts were adjusted, and the large model was guided to regenerate the target code. If the performance evaluation passes, the target code is integrated, and a porting report is generated, including a list of code snippets to be ported, porting recommendations, and patches.