Cross-architecture code automatic migration method, system and equipment based on large language model agent and medium

Abstract

The invention relates to a cross-architecture code automatic migration method, system and device based on a large language model agent and a medium. The method comprises the following steps: acquiring a source code, a construction script and an architecture related header file of a target project; based on a pre-constructed transplantation target system architecture knowledge base, analyzing system architecture differences in combination with construction scripts and positioning architecture related positions needing to be modified in source codes to obtain a preliminary modification scheme; constructing scripts through static analysis and carrying out abstract syntax tree analysis on source codes to obtain a global dependency directed graph; based on a transplantation target system architecture knowledge base, performing migration code semantic matching on the source code according to the preliminary modification scheme and the global dependency directed graph, and generating a semantic equivalent replacement code to obtain a patch list; and sequentially executing incremental compiling, function consistency testing and performance regression verification on the migration project copy after the patch list is applied to generate verification information and a verification result. By adopting the method, cross-architecture code automatic migration can be realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of code migration, and particularly relates to a cross-architecture code automatic migration method, system, device and medium based on a large language model agent. BACKGROUND

[0002] With the diversification of computer architecture and the rapid advancement of domestic processor ecological construction, cross-architecture code migration technology has emerged, which adapts to heterogeneous hardware platforms through compiler backend recompilation, binary translation, script replacement and compatible layer encapsulation.

[0003] In the traditional technology, compiler recompilation relies on cross-tool chains to recompile the source code, binary translation realizes the runnability through instruction-level translation, and script replacement relies on regular tools to modify conditional compilation fragments in batches.

[0004] However, the above methods, compiler recompilation cannot automatically solve the problems of inline assembly, SIMD (Single Instruction Multiple Data) instructions and ABI (Application Binary Interface) incompatibility, which need to be manually modified and take weeks; binary translation has serious performance loss, only reaching 5%-20% of the original performance, and does not support source code debugging; script replacement is prone to missed detection and misrepair in large-scale projects with millions of lines, and the maintenance cost increases sharply with the expansion of the project scale. At the same time, the existing solutions generally lack joint semantic support of global dependency analysis and system architecture specification documents, and the verification mechanism is imperfect, which is difficult to meet the migration efficiency and stability requirements of large-scale projects. SUMMARY

[0005] Therefore, it is necessary to provide a cross-architecture code automatic migration method, system, device and medium based on a large language model agent, which can meet the efficiency and stability of large-scale projects.

[0006] In a first aspect, the application provides a cross-architecture code automatic migration method based on a large language model agent, comprising:

[0007] Obtaining a migration project copy corresponding to a target project, and extracting a requirement file from the migration project copy to obtain source code, a build script and an architecture-related header file;

[0008] Based on a pre-built transplantation target system architecture knowledge base, analyzing the system architecture difference in combination with the build script, and locating the architecture-related positions in the source code that need to be modified to obtain a preliminary modification scheme;

[0009] With the architecture-related header file as a hierarchical guide, the build script is parsed recursively layer by layer, and through static analysis, explicit dependencies, subdirectory inclusion relationships and conditional compilation options are extracted, combined with abstract syntax tree analysis of the source code, to obtain a global dependency directed graph; the global dependency directed graph includes source file path nodes, file dependency relationship directed edges and semantic metadata node attributes;

[0010] Based on the transplantation target system architecture knowledge base, the source code is migrated according to the preliminary modification scheme and the global dependency directed graph to match the code semantics, and the semantic equivalent replacement code is generated to obtain a patch list; the patch list includes the target position of each patch, the replacement code and the corresponding build condition change;

[0011] The migrated engineering copy after applying the patch list is sequentially executed for incremental compilation, functional consistency testing and performance regression verification to generate verification information and verification results, and when the verification result is verification failure, at least one of patch regeneration, rollback or manual review is triggered based on the verification information.

[0012] In one of the embodiments, the transplantation target system architecture knowledge base is constructed by the following method:

[0013] Obtain the description information and historical engineering migration records of the transplantation target system; the description information includes hardware manuals containing instruction definitions, register parameters and application binary interfaces; the historical engineering migration records include the original build script, source code, source code comments, API call specification and historical migration patches of the migrated engineering;

[0014] Convert the description information and historical engineering migration records into standardized parseable text, and use a pre-trained large language model to perform semantic analysis, cross-dimension semantic matching and associated structured description on the parseable text to obtain semantic independent text segments; the associated structured description includes but is not limited to instruction-register-application binary interface triple structured description and cross-architecture equivalent semantic structured association;

[0015] Perform vectorization processing on the semantic independent text segments by searching the enhanced vector encoder, and construct a vector search index to obtain a vector database; the vector search index is used to match the semantic association degree based on the vector similarity; the vector database stores each semantic independent text segment and its corresponding vector features and unique identifier;

[0016] The vector database is labeled and classified by function category and persistently stored to obtain the transplantation target system architecture knowledge base; the transplantation target system architecture knowledge base includes a hardware base library, a code mapping library, a build rule library and a verification rule library.

[0017] In one of the embodiments, the method further includes:

[0018] In response to the verification result being a verification pass, it is checked whether the target engineering migrated generated semantic equivalent patch exists in the transplant target system architecture knowledge base, and if not, the semantic equivalent patch is supplemented as corpus;

[0019] The pre-trained large language model is used for semantic analysis, semantic matching and associated structured description of the supplemented corpus, and the structured description of the supplemented corpus is vectorized after being merged into the transplant target system architecture knowledge base through retrieval of the enhanced vector encoder.

[0020] In one embodiment, the construction script is parsed recursively layer by layer with the architecture-related header file as a hierarchical guide, and explicit dependencies, subdirectory inclusion relationships and conditional compilation options are extracted through static analysis, combined with abstract syntax tree analysis of the source code to obtain a global dependency directed graph, including:

[0021] The explicit sub-projects, targets, compilation options and conditional branch relationships are extracted by parsing the construction script, and the symbol references, function calls and type dependency relationships between files are extracted by abstract syntax tree analysis of the source code, and the extracted results are used to construct an initial dependency directed graph; the initial dependency directed graph includes source file path nodes and file dependency relationship directed edges;

[0022] Based on the transplant target system architecture knowledge base, architecture-related metadata is labeled on the source file path nodes that need to be migrated;

[0023] Based on the file dependency relationship directed edges and the hierarchical dependency logic of the architecture-related header files, the migration execution order of each source file path node is determined to obtain a migration order list;

[0024] The migration order list and the labeled architecture-related metadata are used as semantic metadata node attributes of the source file path nodes, and the global dependency directed graph is generated by combining the source file path nodes and the file dependency relationship directed edges.

[0025] In one embodiment, based on the transplant target system architecture knowledge base, the source code is migrated according to the preliminary modification scheme and the global dependency directed graph, and the semantic equivalent replacement code is generated to obtain a patch list, including:

[0026] According to the migration order list, the source file path nodes that need to be migrated are extracted from the global dependency directed graph, and the corresponding to-be-migrated source code segments of each node are located to obtain a to-be-migrated code list; the to-be-migrated code list includes a plurality of to-be-migrated source code segments arranged in the migration order;

[0027] The source code fragments to be migrated are converted into vector features by a retrieval-enhanced vector encoder, and vector feature semantic matching retrieval is performed in the transplantation target system architecture knowledge base according to a vector retrieval index to obtain a candidate semantic equivalence set;

[0028] Based on the interface compatibility and the functional semantic invariance principle, replacement code and corresponding construction condition changes are generated according to the candidate semantic equivalence set to obtain a patch list; the replacement code is at least one of syntax-level replacement, auxiliary adaptation code, conditional compilation and interface adaptation code.

[0029] In one of the embodiments, the method further comprises:

[0030] According to the patch list, all source file path nodes and file dependency directed edges thereof that depend on the generated replacement code are identified in the global dependency directed graph to obtain an affected dependency subgraph;

[0031] A synchronous adaptation patch corresponding to the replacement code is generated for each source file path node in the affected dependency subgraph to obtain an updated patch list.

[0032] In one of the embodiments, the migrated engineering copy after application of the patch list is sequentially subjected to incremental compilation, functional consistency testing and performance regression verification to generate verification information and verification results, including:

[0033] The migrated engineering copy after application of the patch list is subjected to incremental compilation to generate a compilation report; the compilation report includes a compilation success state, compilation error information and error positioning identification;

[0034] Based on preset functional test cases, the migrated engineering copy after application of the patch list is subjected to automatic functional consistency testing to generate a functional consistency report; the functional consistency report contains a comparison result of functional outputs before and after migration and an identification of abnormal functional modules;

[0035] The migrated engineering copy after application of the patch list is executed on the transplantation target system, and performance regression testing is performed to verify performance indicators and resource usage, to generate a performance indicator comparison report before and after migration; the performance indicators include throughput, delay and resource utilization;

[0036] The compilation report, the functional consistency report and the performance indicator comparison report before and after migration are integrated to generate verification information;

[0037] According to the verification information, it is determined whether the migrated engineering satisfies preset compilation passing thresholds, functional consistency thresholds and performance indicator thresholds to obtain verification results; the verification results include verification pass and verification fail.

[0038] In a second aspect, the present application further provides a cross-architecture code automatic migration system based on a large language model intelligent agent, comprising:

[0039] a target engineering metadata module, configured to obtain a migration engineering copy corresponding to a target engineering, and perform requirement file extraction on the migration engineering copy to obtain source code, a build script, and an architecture-related header file;

[0040] a preliminary positioning module, configured to position a position in the source code that needs to be modified due to system architecture differences according to the build script based on a pre-built porting target system architecture knowledge base, to obtain a preliminary modification scheme;

[0041] a code relationship construction module, configured to recursively parse and layer-by-layer scan the build script according to the architecture-related header file, and extract explicit dependencies, subdirectory inclusion relationships, and conditional compilation options through static analysis to obtain a global dependency directed graph; the global dependency directed graph includes a source file path node, a file dependency relationship directed edge, and a semantic metadata node attribute;

[0042] a patch generation module, configured to perform migration code semantic matching and generate semantically equivalent code based on the preliminary modification scheme and the global dependency directed graph according to a porting target system architecture knowledge base to obtain a patch list; the patch list includes a target position, replacement code, and corresponding build condition changes of each patch;

[0043] a verification module, configured to perform incremental compilation, functional consistency testing, and performance regression verification on the migration engineering copy after the patch list is applied to obtain verification information and a verification result, and trigger at least one of re-generation, rollback, and manual review of the patch based on the verification information when the verification result is a verification failure.

[0044] In a third aspect, the present application also provides a computer device, including a memory and a processor, the memory stores a computer program, and the processor implements the steps of any of the above-mentioned cross-architecture code automatic migration methods based on a large language model agent when executing the computer program.

[0045] In a fourth aspect, the present application also provides a computer-readable storage medium, which stores a computer program, and the computer program implements the steps of any of the above-mentioned cross-architecture code automatic migration methods based on a large language model agent when executed by a processor.

[0046] The cross-architecture code automatic migration method, system, device and medium based on the large language model agent can realize the pipelining and repeatable execution of the migration task by connecting the target engineering acquisition, difference positioning, dependency analysis, semantic replacement and verification into a closed loop process and reducing the manual intervention points. By using the pre-constructed transplantation target system architecture knowledge base and combining the system architecture difference analysis of the constructed script, the modification position related to the architecture in the source code can be accurately positioned, and blind rewriting is avoided. By constructing a global dependency directed graph containing semantic metadata, the topological consistency of the rewriting can be ensured in the cross-file and cross-module scenarios, and the risk of global inconsistency caused by local changes is reduced. The knowledge base is used as the semantic source to generate the replacement code and patch list with semantic equivalence, the interface and external behavior are kept unchanged, thereby reducing the function regression, and the automatic positioning and semantic replacement reduce the error probability of manual rewriting. After the incremental compilation, function consistency test and performance regression verification, if the verification fails, the patch regeneration, rollback or manual review can be triggered, and the migration result is controllable and correctable. BRIEF DESCRIPTION OF DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the embodiments or the related art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0048] Figure 1 A flowchart of the cross-architecture code automatic migration method based on the large language model agent of the present application;

[0049] Figure 2 A construction flowchart of the transplantation target system architecture knowledge base of the present application;

[0050] Figure 3 A sub-step flowchart of step S103;

[0051] Figure 4 A composition structure diagram of the cross-architecture code automatic migration system based on the large language model agent of the present application. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0053] In one embodiment, as Figure 1As shown, a cross-architecture code automatic migration method based on a large language model agent is provided. In this embodiment, the method is applied to a terminal. It should be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and can be implemented through the interaction of the terminal and the server. In this embodiment, the method includes the following steps:

[0054] S101, obtain the migration engineering copy corresponding to the target engineering, and extract the demand file from the migration engineering copy to obtain the source code, the build script and the architecture related header file.

[0055] The migration engineering copy refers to an independent copy created to avoid polluting the original code of the target engineering, ensuring the integrity of the original engineering is not affected. For example, if the target engineering is a compressed package, it is released to the specified working directory through the decompression tool and a copy is automatically created. If the target engineering is stored in a code repository, a copy of an independent branch is generated through a cloning operation. Further, the migration agent will perform a comprehensive scan on the copy directory, filter out redundant files unrelated to migration, such as binary files, image resources, log documents, etc., and only keep the core file types supporting engineering compilation and running. Among them, the source code refers to the core implementation file written in C / C++ language in the engineering, usually with.c,.cpp,.h as the suffix, containing business logic, function implementation and architecture related underlying code; the build script is a configuration file used to guide the engineering compilation and construction, such as meson.build of Meson and CMakeLists.txt of CMake, which defines the compilation options, dependency library association, conditional compilation branch and other key information; the architecture related header file refers to the header file containing the definition of the hardware architecture, such as rte_arch_x86_64.h of x86 architecture, which contains architecture macro definition, special function declaration, register parameter and other hardware related semantic information, which is an important basis for identifying architecture differences.

[0056] S102, based on the pre-built transplantation target system architecture knowledge base, analyze the system architecture difference combined with the build script, and locate the architecture related position in the source code that needs to be modified to obtain a preliminary modification scheme.

[0057] A pre-built target system architecture knowledge base serves as the core knowledge carrier supporting migration decisions. By pre-integrating structured knowledge sets related to the target system, including hardware characteristics, compilation rules, and historical migration experience, it provides a unified semantic reference standard for architecture difference analysis, ensuring the accuracy and consistency of difference identification. Specifically, the migration agent parses key configuration items in the build script, including compiler type, compilation options (such as -mxsave for x86 architecture), architecture-specific conditional branches (such as if host_machine.cpu_family()=='x86'), and dependency library versions. For example, if the target system architecture is a Shenwei processor, it compares it one by one with the Shenwei architecture build rules stored in the target system architecture knowledge base, such as the compiler SWCC, compilation option -msw64, and conditional branch if host_machine.cpu_family()=='sw_64', thereby accurately identifying incompatible configurations caused by architecture differences.

[0058] Furthermore, based on the x86-specific configurations identified in the build script, the agent associates them with the corresponding implementation logic in the source code. For example, for x86 SIMD compilation options in the build script, it locates functions in the source code that use the SSE instruction set; for x86 ABI-related compilation configurations, it locates functions that depend on x86 register calling conventions. Through this configuration-code association mapping, the agent can initially mark the code locations that need modification and, combined with the basic adaptation logic in the knowledge base, form a preliminary modification plan.

[0059] S103. Using architecture-related header files as hierarchical guides, the build script is recursively parsed layer by layer. Explicit dependencies, subdirectory inclusion relationships, and conditional compilation options are extracted through static analysis. Combined with the abstract syntax tree analysis of the source code, a global dependency directed graph is obtained. The global dependency directed graph includes source file path nodes, directed edges of file dependency relationships, and semantic metadata node attributes.

[0060] As an illustration, architecture-related header files naturally possess hierarchical dependency characteristics. Using this as a guide can avoid logical confusion during the build script parsing process, ensuring that the parsing covers all related modules. The process of recursively parsing the build script layer by layer begins with the core build script in the project root directory. The agent will then parse the subdirectory build scripts and subproject scripts referenced in this script in turn, until it traverses all configuration files related to the project build, ensuring that no hidden dependencies and compilation rules are missed.

[0061] Furthermore, the agent constructs scripts through static scanning, extracting explicit dependencies such as third-party library dependencies and internal module dependencies, subdirectory inclusion relationships, and conditional compilation options. Simultaneously, it performs Abstract Syntax Tree (AST) analysis on the source code to extract implicit dependency information such as symbolic references between files, function call relationships, and type dependencies. By combining explicit and implicit dependencies and supplementing them with semantic metadata node attributes, a global dependency directed graph can be constructed.

[0062] S104. Based on the target system architecture knowledge base, perform migration code semantic matching on the source code according to the preliminary modification plan and the global dependency directed graph, and generate semantically equivalent replacement code to obtain a patch list; the patch list includes the target location of each patch, the replacement code, and the corresponding build condition changes.

[0063] Indicatively, the agent will combine the locations to be modified marked in the initial modification scheme with the engineering structure presented in the global dependency directed graph, and process the code to be migrated one by one according to the migration priority. Specifically, it will extract the code fragments to be migrated, such as functions containing x86 SIMD instructions and inline assembly blocks, and convert them into searchable semantic features. Then, it will search the target system architecture knowledge base for semantically similar target architecture implementation cases, instruction mapping rules, code adaptation templates, etc., to form a candidate semantically equivalent set.

[0064] Furthermore, the generation of semantically equivalent replacement code must strictly adhere to two core principles: interface compatibility and functional semantic immutability. Interface compatibility ensures that the replaced code does not alter the input / output parameters, return type, or calling method of the original function, avoiding any destructive impact on upper-level calling logic. Functional semantic immutability requires that the replacement code be completely consistent with the original code's business logic and execution results, adapting only to the underlying implementation of the target architecture. The agent will generate specific replacement code based on the candidate semantically equivalent set, combined with the code generation capabilities of a large language model. The patch list is a structured integration of all replacement code; each patch record includes the target location, accurate to the filename and line number, as well as the replacement code and corresponding build condition changes, such as modifying conditional compilation branches in the build script or adjusting compilation options.

[0065] S105. Perform incremental compilation, functional consistency testing and performance regression verification sequentially on the migration project copy after the application patch list, generate verification information and verification results. When the verification result is that the verification fails, trigger at least one of the following based on the verification information: patch regeneration, rollback or manual review.

[0066] Incremental compilation, as an illustration, refers to compiling only files modified after the application patch manifest, significantly shortening compilation time and improving verification efficiency. During compilation, a detailed compilation report is generated, recording the compilation success status, error messages, and error location identifiers, providing direct clues for problem troubleshooting. Functional consistency testing, based on pre-defined automated test cases, verifies the functional correctness of the migrated code by comparing the functional output results of the project before and after migration. During testing, the agent executes the project's built-in unit tests and integration test cases, recording output data, status codes, log information, etc., before and after migration, and generating a functional consistency report. If the output results after migration are completely consistent with the original results, the function is considered normal; if differences occur, they are marked as abnormal functional modules, providing direction for subsequent patch optimization. Performance regression verification requires executing the migrated project on the target system, testing core performance indicators, and comparing them with the performance data of the original project on the original platform or the performance benchmark threshold of the target architecture, generating a performance indicator comparison report.

[0067] Optionally, the verification information is an integrated result of the compilation report, functional consistency report, and performance indicator comparison report, containing key data and anomaly identifiers from all verification processes. The verification result is a binary judgment based on the verification information: verification passed or failed. The judgment criteria are whether the project meets the preset compilation pass threshold, functional consistency threshold, and performance indicator threshold. When the verification result is failed, the agent will take targeted measures based on the verification information. For example, if it is a compilation error, the code will be adjusted and replaced based on the error information, triggering a patch regeneration; if it is a functional anomaly or performance failure that cannot be automatically repaired, the system will automatically roll back to the state before the patch was applied to prevent the error from spreading; if it is a complex architecture adaptation problem, manual review will be prompted for developer intervention and optimization.

[0068] The aforementioned cross-architecture code migration method based on large language model agents combines a pre-built target system architecture knowledge base with build script analysis results for localization. This allows localization to be based on dual constraints of semantic knowledge and build information, reducing misjudgments from pattern matching or human experience alone, thus lowering the probability of erroneous modifications. A global dependency directed graph jointly represents file paths, dependencies, and semantic metadata, and performs migration based on topological order, ensuring synchronous consideration of upstream / downstream dependencies and avoiding interface / call semantic mismatches caused by partial replacements. A patch manifest records each modification and its impact in a structured manner, facilitating automated replay, manual review, and problem localization, improving verification efficiency and auditing capabilities. Incremental compilation and multi-dimensional verification are performed on the migrated project, enabling early detection of compilation errors, functional deviations, or performance anomalies. Based on verification information, decisions are made regarding patch regeneration or rollback, thereby reducing regression risks before release. After identifying and explicitly representing conditional compilation and subdirectory inclusion relationships in the global dependency directed graph, the migration agent can selectively generate corresponding patches according to conditions and record the changes in build conditions in the patch list. This enables fine-grained control over code branches and minimal rewriting. After automatically generating most semantically equivalent replacements, only the positions that cannot be automatically and safely handled are marked as requiring manual processing. This allows manual review to focus on high-risk or high-complexity points, improving the efficiency of manual review and reducing the overall workload.

[0069] In one embodiment, such as Figure 2 As shown, the target system architecture knowledge base for porting is constructed using the following methods:

[0070] S201. Obtain the description information and historical project migration records of the target system for porting; the description information includes the hardware manual containing instruction definitions, register parameters, and application binary interfaces; the historical project migration records include the original build script, source code, source code comments, API call specifications, and historical migration patches of the project being migrated.

[0071] Indicatively, the information for porting the target system is primarily conveyed through the hardware manual. The hardware manual is an authoritative technical document published by the chip manufacturer, covering the underlying technical details of the target architecture. Taking the Shenwei processor as an example, the instruction definitions clearly state all instructions supported by the Shenwei processor and the disabled instructions. Register parameters detail the address, function, and data width of each register. The Application Programming Interface (ABI) defines key compatibility information such as function calling conventions and data type endianness. The hardware manual serves as the underlying basis for subsequent semantic equivalence mapping of code. Historical project migration records are the accumulated experience from similar cross-architecture migration projects. Specifically, they include the original build scripts, source code, source code comments, API calling specifications, and historical migration patches of the project being migrated. These historical migration patches are verified and effective code replacement solutions, such as the Shenwei adaptation patch for x86 SIMD instructions in the OpenBLAS project.

[0072] S202. Transform the explanatory information and historical engineering migration records into standardized parsable text, and use a pre-trained large language model to perform semantic parsing, cross-dimensional semantic matching, and associated structured description on the parsable text to obtain semantically independent text fragments; the associated structured description includes, but is not limited to, instruction-register-application binary interface triplet structured description and cross-architecture equivalent semantic structured association.

[0073] As an illustration, the original data consists mostly of hardware manuals in PDF format, build scripts in plain text code, and source code comments in semi-structured text. Optionally, for hardware manuals, OCR technology should be used to extract table content and formula conversion, and irrelevant formatting information should be filtered out; for build scripts and source code, redundant blank lines and debugging comments should be removed, while retaining core configurations and code logic; for historical migration patches, structured fields of original code, replacement code, and adaptation instructions should be extracted. Finally, all data should be converted to UTF-8 encoded plain text format to ensure that subsequent large language models can parse it uniformly.

[0074] Furthermore, a pre-trained large language model is used to process the parsable text. Specifically, through semantic parsing, the large language model can understand the technical meaning of the text. For example, it can identify that the sw64_nop_4 instruction in the hardware manual is used for no operation, which is equivalent to the PAUSE instruction of x86. Optionally, through cross-dimensional semantic matching, the model can break the data source barrier and establish associations between the hardware manual, source code, and historical patches. For example, in a practical case where x86_mm_pause in the historical patch is replaced by sw64_nop_4, it is associated with the instruction definition of sw64_nop_4 in the hardware manual to form a complete semantic chain of instruction function - practical application. Further, through associated structured descriptions, the model converts the abstract semantic associations into a machine-recognizable structured format, typically such as the instruction - register - ABI triple, such as <Instruction: sw64_cpuinfo, Register: EAX, ABI: The function return value is stored in the R0 register>, and cross-architecture equivalent semantic associations, such as <x86 code: _mm_loadu_si128, ShenWei equivalent semantics: Scalar loop byte-by-byte loading, Association basis: Both achieve 128-bit data reading>.

[0075] S203. Vectorize the semantically independent text fragments through a retrieval-enhanced vector encoder, and construct a vector retrieval index to obtain a vector database; the vector retrieval index is used to match the semantic association degree based on vector similarity; the vector database stores each semantically independent text fragment and its corresponding vector features and unique identifiers.

[0076] Illustratively, the retrieval-enhanced (RAG) vector encoder can be Sentence-BERT, LangChain vector module. The encoder will convert each semantically independent text fragment into a fixed-dimensional vector feature based on a pre-trained code and hardware hybrid domain model. Each dimension of the vector corresponds to a semantic attribute of the fragment, such as instruction type, function description, architecture adaptation scenario. The more similar the semantics of the fragments, the closer the distance between the vectors in the high-dimensional space. Exemplarily, the vector of the x86_mm_pause instruction (no operation) has a very small distance from the vector of the ShenWei sw64_nop_4 instruction (no operation), while the distance from the vector of the ShenWei addition instruction sw64_add is significantly larger.

[0077] Furthermore, based on vector generation, a vector retrieval index needs to be constructed, such as FAISS index, Milvus index. The index optimizes the vector storage structure through algorithms such as clustering and dimensionality reduction to form a vector database, further improving the retrieval speed. Exemplarily, when retrieving alternative solutions for x86 SIMD instructions during subsequent migration, the index can quickly locate all ShenWei scalar loop / multi-int simulation related fragments with similar vectors, avoiding full-library traversal.

[0078] S204. Label and classify the vector database according to functional categories and persist it to obtain the target system architecture knowledge base for porting. The target system architecture knowledge base for porting includes a hardware base library, a code mapping library, a build rule library, and a verification rule library.

[0079] Optionally, the annotation classification is based on knowledge function and migration scenario matching. The hardware base library focuses on the underlying hardware characteristics of the target architecture, storing instruction definitions, register parameters, ABI specifications, and other knowledge extracted from hardware manuals, primarily used for hardware feasibility assessment during code semantic matching. The code mapping library stores the equivalent mapping relationship between the original code and the target system adaptation code, directly providing code replacement templates for patch generation. The construction rule base integrates the compilation configuration knowledge of the target architecture for script adaptation and compilation verification. The verification rule base includes functional testing standards and performance benchmark thresholds for the target architecture, supporting result determination in subsequent verification stages. During the annotation process, each semantic fragment in the vector database is tagged with the corresponding functional library, and the relationships between fragments are recorded.

[0080] Optionally, persistent storage is the foundation for ensuring the long-term reusability and updating of the knowledge base. A hybrid storage architecture of vector database and relational database can be adopted. The vector database stores the vector features and text content of semantic fragments to support fast semantic retrieval; the relational database stores the unique identifiers of fragments, function library tags, and structured metadata such as relationships to support accurate classification queries and knowledge association.

[0081] In one embodiment, the method further includes:

[0082] S11. In response to the verification result being successful, check whether the semantically equivalent patch generated by the migration of the target project exists in the target system architecture knowledge base. If it does not exist in the target system architecture knowledge base, use the semantically equivalent patch as supplementary corpus.

[0083] Indicatively, successful verification means that the migrated project copy after applying the patch has met the preset compilation pass threshold, functional consistency threshold, and performance indicator threshold. The semantic equivalent logic corresponding to the patch has been proven reliable and has value for inclusion in the knowledge base. Furthermore, through a dual mechanism of semantic matching and metadata comparison, redundant knowledge in the knowledge base is avoided. Specifically, the agent locates the semantically equivalent patches generated by the migration of the target project, including instruction replacement patches at the source code level, compilation configuration patches at the build script level, and definition supplement patches at the architecture-related header file level. For each type of patch, the agent transforms it into retrieval features consistent with semantically independent text fragments in the knowledge base. For example, for code patches, the core semantics are extracted; for configuration patches, key configuration items are extracted. By transplanting the vector retrieval index of the target system architecture knowledge base, the vector similarity between the semantic features of the patch and the existing knowledge base fragments is calculated. At the same time, the metadata of the patch is compared with the unique identifier association information of the knowledge base fragments. If the vector similarity is lower than the threshold and the metadata does not overlap, it is determined that the patch does not exist in the knowledge base and is used as supplementary corpus. If there are highly similar fragments or overlapping metadata, it is determined that the knowledge already exists and there is no need to include it again, thus avoiding the expansion of the knowledge base and the resulting decrease in retrieval efficiency.

[0084] S12. Use a pre-trained large language model to perform semantic parsing, semantic matching, and associated structured description of the supplementary corpus. Then, use a retrieval-enhanced vector encoder to vectorize the structured description of the supplementary corpus and merge it into the target system architecture knowledge base.

[0085] This example illustrates how a pre-trained large language model processes supplementary corpora, transforming engineered patch results into structured knowledge fragments compatible with the knowledge base. Specifically, the large language model decomposes the complete logic of the supplementary corpora. For instance, replacing the x86 SSE instruction in `rte_memcpy` with a Shenwei scalar loop patch resolves the corpora into a complete semantic chain encompassing the original instruction's function, target architecture limitations, alternative solutions, and interface preservation, ensuring knowledge integrity. Furthermore, the large language model establishes logical connections between the supplementary corpora and existing related knowledge in the knowledge base. For example, it matches the aforementioned scalar loop patch with knowledge in the hardware foundation library, such as the Shenwei processor's scalar instruction execution efficiency and Shenwei memory access rules, forming a connection between code implementation and hardware characteristics, preventing the supplementary corpora from becoming isolated knowledge. Finally, the large language model transforms the supplementary corpora into structured entries according to the knowledge base's established format specifications, including code patch generation, target code, adaptation scenarios, build script patch generation, target configuration, adaptation projects, and verification results. Similarly, the encoder transforms the structured description into fixed-dimensional vector features, with each dimension of the vector corresponding to the semantic attributes of the supplementary corpus, ensuring that the vector features of the supplementary corpus can be applied to the next transfer.

[0086] In one embodiment, such as Figure 3 As shown, the build script is recursively parsed layer by layer, guided by architecture-related header files. Explicit dependencies, subdirectory inclusion relationships, and conditional compilation options are extracted through static analysis. Combined with abstract syntax tree analysis of the source code, a global dependency directed graph is obtained, including:

[0087] S301. Extract explicit sub-projects, targets, compilation options, and conditional branch relationships by parsing the build script, and perform abstract syntax tree analysis on the source code to extract symbolic references, function calls, and type dependencies between files. Use the extraction results to construct an initial dependency directed graph; the initial dependency directed graph includes source file path nodes and directed edges of file dependencies.

[0088] To illustrate, the migration agent starts with the core build script in the project root directory, recursively parsing all related scripts layer by layer, extracting explicit dependencies, such as the third-party library dpdk-lib that the project depends on, and the internal module dependency lib / eal; extracting sub-project call relationships, such as the sub-project path corresponding to subproject('drivers / net'); extracting compilation targets, such as the generated executable file test-pmd, the static library librte_base.a; and extracting conditional compilation options, such as the x86-specific compilation branch corresponding to if host_machine.cpu_family()=='x86'.

[0089] Simultaneously, the source code is analyzed using Abstract Syntax Tree (AST) to uncover implicit dependencies. AST is a tree-like representation of the source code's syntactic structure, clearly showing the symbol definitions and reference relationships. Specifically, the agent uses compiler front-end tools such as Clang to convert C / C++ source code into AST, traversing the tree structure to extract three types of implicit dependencies: symbolic references, such as file A referencing the structure rte_ring defined in file B; function calls, such as file C calling the rte_memcpy function implemented in file D; and type dependencies, such as file E using the enumeration type rte_cpu_flag_t declared in file F.

[0090] Furthermore, by integrating explicit and implicit dependencies, an initial directed dependency graph can be constructed. This graph uses source file paths as core nodes and dependency relationships as directed edges.

[0091] S302. Based on the target system architecture knowledge base, mark the architecture-related attributes to be migrated on the source file path nodes to obtain the marked architecture-related metadata.

[0092] As an example, by annotating architecture-related metadata, core nodes requiring modification can be filtered from a massive amount of files. This avoids inefficiency and the risk of accidental modifications caused by indiscriminate migration, while ensuring the integrity of the migration scope and ensuring no architecture-related code is missed. Specifically, the annotation is based on a pre-built target system architecture knowledge base. This knowledge base stores an architecture-specific feature library for the target architecture, including disabled instructions for x86 architecture, proprietary macro definitions, inline assembly templates, ABI-related interfaces, etc., serving as the authoritative standard for determining whether files need to be migrated. For example, the agent reads the file content corresponding to each source file path node in the initial dependency directed graph, and performs semantic matching between the file content and the architecture-specific features in the knowledge base. For example, when scanning lib / rte_pause.c, it finds that it contains x86 inline assembly asm("pause"), which matches the x86-specific inline assembly feature that needs to be migrated in the knowledge base. The node is then labeled with architecture-related metadata. The core content of the metadata includes the architecture dependency type, such as SIMD instruction dependency, inline assembly dependency, or ABI dependency, as well as the unique identifier and priority weight of the associated knowledge base features. For example, the core module lib / eal has a higher priority than the test module test, and the labeling weights are 1.0 and 0.5, respectively.

[0093] S303. Based on the directed edges of file dependencies and the hierarchical dependency logic of architecture-related header files, determine the migration execution order of each source file path node and obtain a migration order list.

[0094] Indicatively, global architecture header files are typically referenced by all modules and represent the top-level dependencies. Module-level architecture header files are referenced only by their respective modules and represent mid-level dependencies. Hardware-specific header files are referenced only by specific hardware drivers and represent low-level dependencies. This hierarchical relationship is highly consistent with the module dependency hierarchy of the project and can serve as a guiding benchmark for migration order planning. Specifically, based on the directed edges of file dependencies in the initial dependency directed graph, the in-degree of each node (i.e., how many other nodes depend on it) and the out-degree of each node (i.e., how many other nodes it depends on) are analyzed. A topological sort is then performed on the initial dependency directed graph. Topological sorting is the sorting of nodes in a directed acyclic graph (DAG), ensuring that for each directed edge, such as A pointing to B, node A is always before node B in the sort, thus avoiding order conflicts caused by circular dependencies. Furthermore, the topological sorting result is fine-tuned by combining the hierarchical logic of architecture-related header files and the priority weights of nodes. The final generated migration order list is a list of nodes to be migrated, sorted by dependency level and importance. Each entry in the list contains the source file path, node migration priority, and associated architecture-related header files.

[0095] S304. Use the migration order list and annotation architecture-related metadata as semantic metadata node attributes of the source file path nodes, and combine the source file path nodes and directed edges of file dependencies to generate a global dependency directed graph.

[0096] Optionally, to ensure the semantic consistency of the globally dependent directed graph, the agent will check the logical matching of node attributes and dependent edges to avoid attribute conflicts. For example, if node A is labeled with an architecture dependency type of "no migration required," but its dependent node B is labeled with an architecture dependency type of "ABI related, requiring migration," then the file content of node A needs to be re-verified to confirm whether the attribute mislabeling is due to a missed check. If node C's migration sequence number is 10, but its dependent node D's migration sequence number is 15, then the migration order needs to be adjusted to ensure that node D migrates before node C. For example, taking the DPDK23.07 project as an example, the final generated globally dependent directed graph contains 115 nodes and 118 edges. Each node is labeled with its migration order and architecture attributes. The agent implements a top-down iterative migration based on this graph, covering all architecture-related nodes without encountering compilation failures due to dependency conflicts.

[0097] In one embodiment, based on the target system architecture knowledge base, the source code is subjected to migration code semantic matching according to the preliminary modification plan and the global dependency directed graph, and semantically equivalent replacement code is generated to obtain a patch list, including:

[0098] S21. According to the migration order list, extract the source file path nodes to be migrated one by one from the global dependency directed graph, and locate the source code fragments to be migrated corresponding to each node to obtain the code list to be migrated; the code list to be migrated includes multiple source code fragments to be migrated arranged in migration order.

[0099] Indicatively, a migration order list serves as the execution guide, clearly defining the migration priority and associated architectural attributes of each source file path node. The agent extracts the source file path nodes to be migrated one by one according to the migration order in the list. During extraction, the agent skips nodes marked as non-architecture related, focusing only on the core objects that need modification. Furthermore, precise positioning is achieved based on labeled architecture-related metadata. The metadata clearly defines the architectural dependency type and unique identifier of the associated knowledge base features of each node. The agent scans for matching code snippets in the source files accordingly. For example, if the metadata is marked as a SIMD dependency, functions or code blocks containing x86 SIMD intrinsics are retrieved; if marked as an inline assembly dependency, assembly code blocks starting with the keyword "asm" are located; if marked as an ABI dependency, functions dependent on x86 register calling conventions are found. The final list of code to be migrated is a structured collection of code snippets arranged in migration order. Each list entry includes the source file path, code snippet location, architectural dependency type, and associated knowledge base features.

[0100] S22. The source code fragments to be migrated are transformed into vector features by a retrieval-enhanced vector encoder, and the vector feature semantic matching retrieval is performed in the target system architecture knowledge base based on the vector retrieval index to obtain a candidate semantic equivalent set.

[0101] In a schematic manner, the agent transforms each code segment to be transferred into high-dimensional vector features by retrieving an enhanced vector encoder. It then searches for the target architecture implementation scheme with the closest semantics in the target system architecture knowledge base. In other words, the agent inputs the vector features of the code segment to be transferred into the index, sorts them by vector cosine similarity, and filters out knowledge segments with similarity higher than a preset threshold to form a candidate semantically equivalent set.

[0102] For example, the _mm_loadu_si128 code snippet to be migrated may yield three candidates after vector search. Candidate 1 is the description of Shenwei's lack of SSE instructions in the hardware base library, which suggests implementing it with a scalar loop; Candidate 2 is a historical patch of the OpenBLAS project in the code mapping library, which replaces _mm_loadu_si128 with a for loop for byte-by-byte loading; Candidate 3 is a performance optimization suggestion for Shenwei's scalar loop in the verification rule base.

[0103] S23. Based on the principles of interface compatibility and functional semantic invariance, generate replacement code and corresponding build condition changes according to the candidate semantic equivalence set to obtain a patch list; the replacement code is at least one of syntax-level replacement, auxiliary adaptation code, conditional compilation, and interface adaptation code.

[0104] Furthermore, the agent selects the optimal adaptation solution from the candidate set. Optionally, if there are historically validated patches, they are reused first; if only hardware manual suggestions exist, the LLM generates code based on hardware rules; if performance optimization suggestions exist, they are integrated into the code to improve runtime efficiency. The final patch list is a collection of migration solutions that can be directly applied in batches. Its structure is clear and traceable, supporting both automatic application by the agent and easy manual review.

[0105] In one embodiment, the method further includes:

[0106] S31. Based on the patch list, identify all source file path nodes and their file dependency directed edges that depend on the source code of the generated replacement code in the global dependency directed graph, and obtain the affected dependency subgraph.

[0107] Specifically, the system relies on both the patch manifest and the global dependency directed graph to precisely pinpoint the scope of impact. The patch manifest extracts key information about the source code for which replacement code has been generated, including file paths, core modifications, and exposed interfaces. Then, the global dependency directed graph undergoes both reverse and forward searches to locate affected source file path nodes and their associated directed edges. Reverse search identifies all nodes that depend on the source code, while forward search further retrieves downstream dependent nodes of the nodes found in the reverse search, extracting all directed edges connecting these nodes to represent dependency propagation paths. Integrating the retrieved affected source file path nodes with their associated directed edges forms an affected dependency subgraph. This subgraph is a local subset of the global dependency directed graph but focuses on the cascading impact of the patches.

[0108] S32. Generate a synchronous adaptation patch for each source file path node in the affected dependency subgraph, corresponding to the replacement code, to obtain the updated patch list.

[0109] As an illustration, the generation of synchronous adaptation patches must strictly adhere to the semantic alignment principle of the main patch. This means the modification logic of the synchronous patch must be consistent with the core adaptation scheme of the main patch, and no new semantic deviations should be introduced. The agent will generate corresponding synchronous adaptation code based on the dependency types of nodes in the affected dependency subgraph. For example, for function call dependency nodes, if the subgraph node directly calls the interface modified by the main patch, it needs to check whether the call parameters and return value handling are compatible with the new implementation of the main patch. If the main patch has adjusted the interface parameters, the synchronous patch needs to supplement the parameters at the call site to ensure the call format matches. For header file reference dependency nodes, if the subgraph node references architecture-related header files modified by the main patch, it needs to check whether the macro definitions and type declarations in the header files are synchronized with the main patch to avoid compilation errors caused by undefined macros. For macro definition dependency nodes, if the subgraph node depends on global macros modified by the main patch, the synchronous patch needs to replace the macro with the macro corresponding to the target system, or supplement the conditional branches of the target system to ensure that the macro definition is consistent with the architecture adaptation logic of the main patch. Optionally, the generated synchronization adaptation patches can be integrated into the original patch list to form an updated patch list. Simultaneously, the application order of the synchronization patches is arranged according to the migration order of the affected dependency subgraphs, ensuring that the main patch is applied first, followed by the downstream synchronization patches, to avoid synchronization failures caused by dependency inversion.

[0110] In one embodiment, incremental compilation, functional consistency testing, and performance regression verification are sequentially performed on the migration project copy after applying the patch manifest, generating verification information and verification results, including:

[0111] S41. Perform incremental compilation on the migration project copy after applying the patch list and generate a compilation report; the compilation report includes the compilation success status, compilation error information and error location identifier.

[0112] For example, taking the migrated project copy after applying the patch list as the processing object, the migration agent first identifies the source files modified by the patches and their direct dependencies through version control tools or file hash comparison, forming an incremental compilation file list. Then, it calls a compilation toolchain adapted to the Shenwei architecture, such as the SWCC compiler, loads the adapted build script, and executes the incremental compilation instructions. During compilation, the agent captures the compiler's output log information in real time and organizes it into a compilation report according to compilation status, error type, and location information. The compilation success status records the successfully generated target files, while compilation error information categorizes and records syntax errors, linking errors, and compilation option errors. Error location identifiers mark each error message with a precise file path, line number, and associated patch ID, ensuring that the root cause of the problem can be quickly located when subsequent patches are applied.

[0113] S42. Based on preset functional test cases, perform automated functional consistency testing on the migration project copy after applying the patch list and generate a functional consistency report; the functional consistency report includes the comparison results of functional output before and after migration and the identification of abnormal functional modules.

[0114] For example, based on the pre-set functional test cases of authoritative verification standards that come with the project itself or are customized before migration, the core business logic, edge scenarios, and exception handling are covered. A copy of the migrated project with application patches is deployed in the same software environment as the original project to ensure that the difference in test results is only caused by the architecture migration, rather than environmental interference. Test cases are executed in batches through the automated testing framework that comes with the project, and the execution process of each test case is recorded. The output results of the migrated test cases are compared with the benchmark results of the original project on the x86 platform field by field. If they are completely consistent, they are marked as functionally normal; if there are differences, they are marked as functionally abnormal, and the name of the abnormal module, the test case, and the details of the difference are recorded, and finally a functional consistency report is generated.

[0115] S43. Execute the migration project copy after applying the patch list on the target system and perform performance regression testing to verify performance indicators and resource usage, and generate a performance indicator comparison report before and after migration; performance indicators include throughput, latency and resource utilization.

[0116] For example, after deploying the application patch on the target system, a copy of the migration project is configured with the same hardware resources and software parameters as the original platform to eliminate the impact of resource configuration differences on performance. For core performance indicators of the project, such as DPDK packet throughput and latency, OpenBLAS floating-point operation efficiency, and PostgreSQL query response time and transaction volume, multiple rounds of data collection are performed using professional performance testing tools. Simultaneously, resource usage data such as CPU utilization, memory bandwidth, and IO throughput are recorded. The collected target system performance data is compared with two benchmarks: the performance data of the original project on the original platform and the performance benchmark threshold of the target system. If the target system performance reaches more than 80% of the original platform and exceeds the benchmark threshold, the performance is considered satisfactory; otherwise, bottlenecks are analyzed, and a performance comparison report before and after the migration is generated.

[0117] S44. Generate verification information by integrating compilation reports, functional consistency reports, and performance metric comparison reports before and after migration.

[0118] To illustrate, the method extracts the number of successfully compiled targets, the number of compilation failures, and the main error types, and associates them with the test cases that could not be executed due to compilation failures in functional testing. It also extracts the test case pass rate, the number of abnormal modules, and the high-frequency exception types, and associates them with the performance of abnormal modules in performance testing. Furthermore, it extracts the core indicator compliance rate, the performance bottleneck module, and the peak resource usage, and associates them with the compilation options of that module in the compilation report to obtain integrated verification information, which is presented in the form of a structured document.

[0119] S45. Based on the verification information, determine whether the migration project meets the preset compilation pass threshold, functional consistency threshold, and performance index threshold, and obtain the verification result; the verification result includes verification pass and verification fail.

[0120] For illustration, the compilation pass threshold is such as a first-time compilation pass rate of ≥90%. If the proportion of successfully compiled targets to the total number of targets exceeds this threshold, the compilation dimension is considered successful. The functional consistency threshold is such as a functional test case pass rate of ≥99%. If the proportion of successful test cases to the total number of test cases exceeds this threshold, and there are no core module functional abnormalities, the functional dimension is considered successful. The performance indicator threshold is such as core performance indicators being no less than 80% of the original platform or reaching 90% of the target system's native performance. If all core indicators exceed this threshold, the performance dimension is considered successful. Optionally, if all three dimensions—compilation, functionality, and performance—are successful, the verification is considered passed, and the migration project can proceed to the subsequent deployment stage; if any dimension fails to meet the standard, the verification is considered unsuccessful.

[0121] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0122] Based on the same inventive concept, this application also provides a cross-architecture code automation migration system based on a large language model agent for implementing the aforementioned cross-architecture code automation migration method based on a large language model agent. The solution provided by this system is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the cross-architecture code automation migration system based on a large language model agent provided below can be found in the limitations of the cross-architecture code automation migration method based on a large language model agent described above, and will not be repeated here.

[0123] In one exemplary embodiment, such as Figure 4 As shown, a cross-architecture code automation migration system based on a large language model intelligent agent is provided, including:

[0124] The target project metadata module 401 is used to obtain a copy of the migration project corresponding to the target project, and to extract the requirement files from the migration project copy to obtain the source code, build script and architecture-related header files;

[0125] The preliminary positioning module 402 is used to locate the parts of the source code that need to be modified due to differences in system architecture based on the pre-built target system architecture knowledge base and the build script, and obtain a preliminary modification plan.

[0126] The code relationship building module 403 is used to recursively parse the architecture-related header files and scan the build script layer by layer. It also extracts explicit dependencies, subdirectory inclusion relationships, and conditional compilation options through static analysis to obtain a global dependency directed graph. The global dependency directed graph includes source file path nodes, directed edges of file dependency relationships, and semantic metadata node attributes.

[0127] The patch generation module 404 is used to perform migration code semantic matching based on the target system architecture knowledge base, the preliminary modification plan and the global dependency directed graph, and generate semantically equivalent code to obtain a patch list. The patch list includes the target location of each patch, the replacement code and the corresponding build condition changes.

[0128] The verification module 405 is used to perform incremental compilation, functional consistency testing and performance regression verification on the migration project copy after the application patch list to obtain verification information and verification results. When the verification result is that the verification fails, at least one of the following is triggered based on the verification information: patch regeneration, rollback and manual review.

[0129] In one embodiment, a knowledge base building module is also included, for:

[0130] Obtain the description information and historical project migration records of the target system for porting; the description information includes the hardware manual containing instruction definitions, register parameters, and application binary interfaces; the historical project migration records include the original build scripts, source code, source code comments, API call specifications, and historical migration patches of the project being migrated;

[0131] The explanatory information and historical engineering migration records are transformed into standardized parsable text. A pre-trained large language model is used to perform semantic parsing, cross-dimensional semantic matching, and associated structured description on the parsable text to obtain semantically independent text fragments. The associated structured description includes, but is not limited to, the instruction-register-application binary interface triplet structured description and cross-architecture equivalent semantic structured association.

[0132] A retrieval-enhanced vector encoder is used to vectorize semantically independent text fragments and construct a vector retrieval index to obtain a vector database. The vector retrieval index is used to match semantic relevance based on vector similarity. The vector database stores each semantically independent text fragment and its corresponding vector features and unique identifiers.

[0133] The vector database is labeled and categorized according to functional categories and stored persistently to obtain the target system architecture knowledge base for porting. The target system architecture knowledge base for porting includes a hardware base library, a code mapping library, a build rule library, and a verification rule library.

[0134] In one embodiment, a knowledge base update module is also included, for:

[0135] In response to a successful verification result, check whether the semantically equivalent patch generated by the migration of the target project exists in the target system architecture knowledge base. If it does not exist in the target system architecture knowledge base, use the semantically equivalent patch as supplementary corpus.

[0136] A pre-trained large language model is used to perform semantic parsing, semantic matching, and structured description of the supplementary corpus. The structured description of the supplementary corpus is then vectorized and merged into the target system architecture knowledge base through a retrieval-enhanced vector encoder.

[0137] In one embodiment, the code relationship construction module 403 is further configured to:

[0138] By parsing the build script, explicit sub-projects, targets, compilation options, and conditional branch relationships are extracted. Abstract syntax tree analysis is performed on the source code to extract symbolic references, function calls, and type dependencies between files. The extraction results are used to construct an initial dependency directed graph, which includes source file path nodes and directed edges of file dependencies.

[0139] Based on the target system architecture knowledge base, the architecture-related attributes to be migrated are marked on the source file path nodes to obtain the marked architecture-related metadata.

[0140] Based on the directed edges of file dependencies and the hierarchical dependency logic of architecture-related header files, the migration execution order of each source file path node is determined, and a migration order list is obtained.

[0141] The migration order list and metadata related to the annotation architecture are used as semantic metadata node attributes of the source file path nodes. Combined with the source file path nodes and directed edges of file dependencies, a global dependency directed graph is generated.

[0142] In one embodiment, the patch generation module 404 is further configured to:

[0143] According to the migration order list, the source file path nodes that need to be migrated are extracted one by one from the global dependency directed graph, and the source code fragments to be migrated corresponding to each node are located to obtain the migration code list; the migration code list includes multiple source code fragments to be migrated arranged in migration order.

[0144] The enhanced vector encoder transforms each source code fragment to be migrated into vector features, and performs semantic matching retrieval of vector features in the target system architecture knowledge base based on the vector retrieval index to obtain a candidate semantic equivalent set.

[0145] Based on the principles of interface compatibility and functional semantic invariance, replacement code and corresponding build condition changes are generated according to the candidate semantic equivalence set to obtain a patch list; the replacement code is at least one of syntax-level replacement, auxiliary adaptation code, conditional compilation, and interface adaptation code.

[0146] In one embodiment, a collaborative patching module is also included for:

[0147] Based on the patch list, identify all source file path nodes and their file dependency directed edges that depend on the source code that has generated replacement code in the global dependency directed graph, and obtain the affected dependency subgraph;

[0148] Generate a synchronous adaptation patch for each source file path node in the affected dependency subgraph, corresponding to the replacement code, to obtain the updated patch list.

[0149] In one embodiment, the verification module 405 is further configured to:

[0150] Perform incremental compilation on the migration project copy after applying the patch list and generate a compilation report; the compilation report includes the compilation success status, compilation error information and error location indicators;

[0151] Based on preset functional test cases, automated functional consistency tests are performed on the migration project copy after the application patch list, and a functional consistency report is generated. The functional consistency report includes a comparison of functional output before and after migration and an identifier of abnormal functional modules.

[0152] Run the migration project copy after applying the patch list on the target system, and perform performance regression testing to verify performance metrics and resource usage, generating a performance metric comparison report before and after migration; performance metrics include throughput, latency, and resource utilization.

[0153] The compilation report, functional consistency report, and performance metric comparison report before and after migration are integrated to generate verification information;

[0154] Based on the verification information, determine whether the migration project meets the preset compilation pass threshold, functional consistency threshold, and performance index threshold, and obtain the verification result; the verification result includes verification pass and verification fail.

[0155] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above method embodiments.

[0156] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0157] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0158] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A cross-architecture code automation migration method based on a large language model agent, characterized in that, The method comprises: acquiring a migration engineering copy corresponding to a target engineering, and extracting a requirement file from the migration engineering copy to obtain source code, a build script, and an architecture-related header file; based on a pre-built transplantation target system architecture knowledge base, analyzing system architecture differences in combination with the build script, and locating architecture-related positions in the source code that need to be modified to obtain a preliminary modification scheme; recursively parsing the build script layer by layer based on the architecture-related header file as a hierarchical guide, and extracting explicit dependencies, subdirectory inclusion relationships, and conditional compilation options through static analysis, in combination with abstract syntax tree analysis of the source code to obtain a global dependency directed graph; the global dependency directed graph comprises a source file path node, a file dependency relationship directed edge, and a semantic metadata node attribute; based on the transplantation target system architecture knowledge base, performing migration code semantic matching on the source code according to the preliminary modification scheme and the global dependency directed graph, and generating semantically equivalent replacement code to obtain a patch list; the patch list comprises a target position, replacement code, and corresponding build condition changes of each patch; sequentially performing incremental compilation, functional consistency testing, and performance regression verification on the migration engineering copy after the patch list is applied to generate verification information and verification results, and when the verification results are not passed, triggering at least one of patch regeneration, rollback, or manual review based on the verification information.

2. The method of claim 1, wherein, The transplantation target system architecture knowledge base is constructed by the following method: acquiring specification information and historical engineering migration records of a transplantation target system; the specification information comprises a hardware manual containing instruction definitions, register parameters, and application binary interfaces; and the historical engineering migration records comprise original build scripts, source code, source code annotations, API call specifications, and historical migration patches of the migrated engineering; transforming the specification information and the historical engineering migration records into standardized parseable texts, and utilizing a pre-trained large language model to perform semantic parsing, cross-dimension semantic matching, and associated structured description on the parseable texts to obtain semantically independent text segments; the associated structured description comprises, but is not limited to, instruction-register-application binary interface triple structured description and cross-architecture equivalent semantic structured association; performing vectorization processing on the semantically independent text segments by a retrieval-enhanced vector encoder, and constructing a vector retrieval index to obtain a vector database; the vector retrieval index is used for matching semantic association degrees based on vector similarity; and the vector database stores each of the semantically independent text segments, corresponding vector features, and unique identifiers thereof; annotating and classifying the vector database according to functional categories and persistently storing the vector database to obtain the transplantation target system architecture knowledge base; the transplantation target system architecture knowledge base comprises a hardware base library, a code mapping library, a build rule library, and a verification rule library.

3. The method of claim 2, wherein, The method further comprises: In response to the verification result being a verification pass, it is checked whether a target engineering migrated generated semantically equivalent patch exists in the transplantation target system architecture knowledge base, and if not, the semantically equivalent patch is supplemented as corpus; The pre-trained large language model is used to perform semantic analysis, semantic matching and associated structured description on the supplemented corpus, and the structured description supplemented corpus is vectorized after being merged into the transplantation target system architecture knowledge base by searching an enhanced vector encoder.

4. The method of claim 2, wherein, The construction script is recursively parsed layer by layer with the architecture-related header file as a hierarchical guide, and explicit dependencies, subdirectory inclusion relationships and conditional compilation options are extracted through static analysis, combined with abstract syntax tree analysis of the source code to obtain a global dependency directed graph, including: Explicit sub-projects, targets, compilation options and conditional branch relationships are extracted by parsing the construction script, and symbol references, function calls and type dependency relationships between files are extracted by abstract syntax tree analysis of the source code to construct an initial dependency directed graph; the initial dependency directed graph includes the source file path node and the file dependency relationship directed edge; Based on the transplantation target system architecture knowledge base, architecture-related attributes that need to be migrated are labeled on the source file path node to obtain labeled architecture-related metadata; Based on the file dependency relationship directed edge and the hierarchical dependency logic of the architecture-related header file, the migration execution order of each source file path node is determined to obtain a migration order list; The migration order list and the labeled architecture-related metadata are taken as the semantic metadata node attributes of the source file path node, and the global dependency directed graph is generated in combination with the source file path node and the file dependency relationship directed edge.

5. The method of claim 4, wherein, Based on the transplantation target system architecture knowledge base, the source code is migrated for code semantic matching according to the preliminary modification scheme and the global dependency directed graph, and semantically equivalent replacement code is generated to obtain a patch list, including: According to the migration order list, the source file path node that needs to be migrated is extracted from the global dependency directed graph, and the corresponding to-be-migrated source code segment of each node is located to obtain a to-be-migrated code list; the to-be-migrated code list includes a plurality of to-be-migrated source code segments arranged in migration order; Each to-be-migrated source code segment is converted into a vector feature by searching an enhanced vector encoder, and vector feature semantic matching retrieval is performed in the transplantation target system architecture knowledge base according to the vector search index to obtain a candidate semantically equivalent set; Based on the interface compatibility and the functional semantic invariance principle, replacement code and corresponding build condition changes are generated according to the candidate semantically equivalent set to obtain the patch list; the replacement code is at least one of syntax-level replacement, auxiliary adaptation code, conditional compilation and interface adaptation code.

6. The method of claim 5, wherein, The method further comprises: According to the patch list, all source file path nodes and file dependency relationship directed edges dependent on the source code of the generated replacement code are identified in a global dependency directed graph, to obtain an affected dependency subgraph; A synchronization adaptation patch corresponding to the replacement code is generated for each source file path node in the affected dependency subgraph, to obtain an updated patch list.

7. The method of claim 6, wherein, The migration engineering copy after applying the patch list is sequentially executed for incremental compilation, functional consistency testing and performance regression verification, to generate verification information and verification results, including: The migration engineering copy after applying the patch list is subjected to incremental compilation, to generate a compilation report; the compilation report includes a compilation success state, compilation error information and error positioning identification; Based on preset functional test cases, the migration engineering copy after applying the patch list is executed for automatic functional consistency testing, to generate a functional consistency report; the functional consistency report contains a comparison result of functional outputs before and after migration and an abnormal functional module identification; The migration engineering copy after applying the patch list is executed on a transplantation target system, and performance regression testing is performed on performance indicators and resource usage, to generate a performance indicator comparison report before and after migration; the performance indicators include throughput, delay and resource utilization; The compilation report, the functional consistency report and the performance indicator comparison report before and after migration are integrated to generate the verification information; According to the verification information, it is judged whether the migration engineering meets preset compilation passing thresholds, functional consistency thresholds and performance indicator thresholds, to obtain the verification results; the verification results include verification pass and verification fail.

8. A cross-architecture code automation migration system based on a large language model agent, characterized in that, The system comprises: A target engineering metadata module configured to obtain a migration engineering copy corresponding to a target engineering, and to extract a requirement file from the migration engineering copy to obtain source code, a build script and an architecture-related header file; A preliminary positioning module configured to locate, based on a pre-built transplantation target system architecture knowledge base, a position in the source code that needs to be modified due to system architecture differences according to the build script, to obtain a preliminary modification scheme; A code relationship construction module configured to recursively parse and scan the build script layer by layer according to the architecture-related header file, and to extract explicit dependencies, subdirectory inclusion relationships and conditional compilation options through static analysis to obtain a global dependency directed graph; the global dependency directed graph includes source file path nodes, file dependency relationship directed edges and semantic metadata node attributes; A patch generation module configured to perform migration code semantic matching and generate semantically equivalent code based on the transplantation target system architecture knowledge base, the preliminary modification scheme and the global dependency directed graph, to obtain a patch list; the patch list includes a target position of each patch, replacement code and corresponding build condition changes; A verification module configured to perform incremental compilation, functional consistency testing and performance regression verification on the migration engineering copy after applying the patch list to obtain verification information and verification results, and to trigger at least one of patch regeneration, rollback and manual review based on the verification information when the verification results are verification fail. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8 when the computer program is executed by the processor. The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

Images