Code cross-language generation method, device, equipment and product

CN123011206APending Publication Date: 2026-10-30SUZHOU TONGYUAN SOFT CONTROL INFORMATION TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611158105.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-31
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0005]本申请的主要目的在于提供一种代码跨语言生成方法、装置、设备以及产品,旨在解决现有人工迁移成本高、复用性差,且大模型迁移缺乏约束校验,无法满足科学计算可靠性需求的技术问题

Benefits of technology

本申请实施例提出的一种代码跨语言生成方法、装置、设备以及产品,通过接收源代码信息,对所述源代码信息中的待迁移函数进行解析得到迁移对象描述表;根据所述迁移对象描述表生成行为特征向量以及候选迁移规则集;计算所述候选迁移规则集的置信度,并根据所述置信度,通过所述候选迁移规则集以及行为特征向量构建得到函数映射数据库;通过所述函数映射数据库生成目标语言代码。由此,先解析待迁移函数生成迁移对象描述表,随后依靠迁移对象描述表生成行为特征向量约束大模型输出候选规则,避免数值差异遗漏,对规则加权计算置信度筛选有效规则并建库,实现规则复用,降低人工迁移成本,根据映射库生成目标代码,配套数值校验闭环,补齐大模型缺失的约束校验,保障科学计算数值可靠性,解决了现有人工迁移成本高、复用性差,且大模型迁移缺乏约束校验,无法满足科学计算可靠性需求的问题,提高了代码跨语言生成的效率。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123011206A_ABST
    Figure CN123011206A_ABST
Patent Text Reader

Abstract

The application discloses a code cross-language generation method and device, equipment and products, and relates to the technical field of software engineering automation. The method comprises the following steps: receiving source code information, analyzing a to-be-migrated function in the source code information to obtain a migration object description table; generating a behavior feature vector and a candidate migration rule set according to the migration object description table; calculating the confidence of the candidate migration rule set, and constructing a function mapping database through the candidate migration rule set and the behavior feature vector according to the confidence; and generating target language code through the function mapping database. Thus, the problem that the current manual migration has high cost, poor reusability, and lacks constraint verification in large model migration, and cannot meet the reliability requirements of scientific calculation is solved, and the efficiency of code cross-language generation is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of software engineering automation technology, and in particular to a method, apparatus, device, and product for cross-language code generation. Background Technology

[0002] In fields such as scientific computing, engineering simulation, data analysis, optimization, and statistical modeling, algorithm functions often need to be migrated between different programming languages ​​and scientific computing libraries. Existing cross-language migration mainly includes two types of implementation methods. One is manual migration, which involves manually reviewing function documentation, writing adaptation code, constructing test cases, and analyzing execution results to complete the migration. The other is code generation based on large models, which uses the semantic understanding capabilities of large models of function documentation and source code fragments to generate candidate migration code, thereby achieving cross-language conversion at the syntax and interface levels.

[0003] However, existing technologies have significant drawbacks. First, manual migration is only applicable to simple scalar functions. When faced with complex functions such as linear algebra, matrix factorization, and sparse matrix computation, there are problems such as high migration costs, insufficient scenario coverage, and difficulty in error localization. Furthermore, it is difficult to accumulate reusable function mapping rules. Second, the large model generation method has uncertain results and lacks numerical behavior feature constraints, mapping confidence assessment, execution-level numerical verification, and closed-loop correction mechanisms. This can easily lead to problems where the code can run but the numerical behavior is inconsistent. It often overlooks differences such as default parameters, index benchmarks, memory layout, exception handling, and special value propagation, and cannot guarantee that the numerical behavior after migration remains consistent within the engineering tolerance range, making it difficult to meet the high reliability requirements of scientific computing scenarios.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, device and product for cross-language code generation, which aims to solve the technical problems of high cost and poor reusability of existing manual migration, and lack of constraint verification for large model migration, which cannot meet the reliability requirements of scientific computing.

[0006] To achieve the above objectives, this application proposes a cross-language code generation method, which includes: Receive source code information, parse the functions to be migrated in the source code information to obtain a migration object description table; Generate behavioral feature vectors and a set of candidate migration rules based on the migration object description table; Calculate the confidence level of the candidate migration rule set, and construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors; The target language code is generated using the function mapping database.

[0007] In one embodiment, the step of parsing the function to be migrated in the source code information to obtain the migration object description table includes: Perform multi-dimensional static code analysis on the source code information to obtain the function call nodes of the function to be migrated; Semantic parsing is performed on the context semantics of the function call node to obtain the interface definition information, call chain dependency relationship and runtime environment constraint information of the function to be migrated; The interface definition information, call chain dependencies, and runtime environment constraint information are structurally integrated; After the structured integration is completed, the interface definition information, call chain dependencies, and runtime environment constraint information are standardized and mapped to obtain the migration object description table.

[0008] In one embodiment, the step of generating behavioral feature vectors and candidate migration rule sets based on the migration object description table includes: Based on the function attributes and calling context information in the migration object description table, the computational logic, data organization, and runtime behavior of the function to be migrated are analyzed in layers to obtain several function characteristics; The aforementioned functional features are categorized and summarized to obtain a multi-dimensional behavioral feature set, and the multi-dimensional behavioral feature set is standardized and encoded to obtain a behavioral feature vector. Based on the behavioral feature vectors and the environmental specifications of the target language computing library, a set of candidate transfer rules is obtained through semantic reasoning using a semantic understanding model.

[0009] In one embodiment, the step of calculating the confidence level of the candidate migration rule set includes: The candidate migration rule set is scored individually according to the preset migration scoring dimensions to obtain the scoring results; The migration scoring dimensions are weighted according to the function category of the function to be migrated, and the scoring weights are obtained. The scoring results are weighted and fused according to the scoring weights to obtain the confidence levels of several migration rules in the candidate migration rule set.

[0010] In one embodiment, the step of constructing a function mapping database based on the confidence level, the candidate migration rules, and the behavioral feature vectors includes: The confidence levels of the several migration rules are compared using a confidence threshold to obtain the comparison results; Based on the comparison results, effective mapping rules are selected from the several migration rules, and the effective mapping rules are classified by mapping type to obtain the classification results. Based on the classification results, the effective mapping rules are bound to behavioral feature vectors, applicable conditions, and state identifiers to obtain binding results. A function mapping database is constructed using the classification and binding results.

[0011] In one embodiment, the step of generating target language code through the function mapping database includes: Based on the migration object description table, the target mapping rules of the function to be migrated are matched through the function mapping database; Based on the target mapping rules, the function to be migrated is subjected to interface adaptation, data structure conversion, and runtime compatibility processing to obtain the initial target language code; The initial target language code is subjected to compliance verification, and the target language code is generated if the verification result is satisfactory.

[0012] In one embodiment, the step of generating target language code through the function mapping database further includes: Generate test cases based on the function to be migrated; The test case set is executed in the source language runtime environment and the target language runtime environment respectively to obtain the source end runtime result and the target end runtime result. The consistency of the source end runtime result and the target end runtime result is verified to obtain the consistency verification result. If the consistency check result is successful, then the cross-language code generation is considered complete. If the consistency check result is a failure, the source of the difference is determined based on the consistency check result, a correction rule is generated based on the source of the difference, the correction rule is updated to the function mapping database, and iterative verification is performed through the function mapping database until the check passes.

[0013] Furthermore, to achieve the above objectives, this application also proposes a cross-language code generation apparatus, which includes: The receiving module is used to receive source code information and parse the functions to be migrated in the source code information to obtain a migration object description table; The first generation module is used to generate behavioral feature vectors and a set of candidate migration rules based on the migration object description table. A construction module is used to calculate the confidence level of the candidate migration rule set, and to construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors. The second generation module is used to generate target language code through the function mapping database.

[0014] In addition, to achieve the above objectives, this application also proposes a cross-language code generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the cross-language code generation method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the code cross-language generation method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the code cross-language generation method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a method, apparatus, device, and product for cross-language code generation. It receives source code information, parses the functions to be transferred in the source code information to obtain a migration object description table; generates behavioral feature vectors and a candidate migration rule set based on the migration object description table; calculates the confidence level of the candidate migration rule set; and constructs a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors. Finally, it generates target language code using the function mapping database. Thus, by first parsing the functions to be transferred to generate a migration object description table, then using the migration object description table to generate behavioral feature vectors to constrain the output of candidate rules for a large model, avoiding the omission of numerical differences, weighting the rules to calculate confidence levels to filter effective rules and build a database, achieving rule reuse and reducing manual migration costs, and generating target code based on the mapping database, a corresponding numerical verification closed loop is provided to supplement the missing constraint verification of the large model, ensuring the reliability of scientific computing numerical values. This solves the problems of high cost and poor reusability of existing manual migration methods, and the lack of constraint verification in large model migration, which cannot meet the reliability requirements of scientific computing, thereby improving the efficiency of cross-language code generation. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the cross-language code generation method of this application. Figure 2 This is a schematic diagram illustrating the cross-language transfer system involved in the cross-language code generation method of this application; Figure 3 This is a schematic diagram illustrating the mapping rules involved in the cross-language code generation method of this application. Figure 4 This is a flowchart illustrating Embodiment 2 of the method for cross-language code generation in this application. Figure 5 A simplified flowchart illustrating the cross-language code generation method provided in Embodiment 2 of this application; Figure 6 This is a schematic diagram of the module structure of the code cross-language generation device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the code cross-language generation method in the embodiments of this application.

[0021] Figure 8 This is a flowchart illustrating the candidate migration rule scoring, weight allocation, and confidence determination in an embodiment of this application. Figure 9 This is a schematic diagram of the process for attributing and automatically correcting differences based on the operating errors at both ends in this application embodiment.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: Perform multi-dimensional static code analysis on the source code information to obtain the function call nodes of the function to be migrated; perform semantic parsing on the context semantics of the function call nodes to obtain the interface definition information, call chain dependencies, and runtime environment constraint information of the function to be migrated; perform structured integration on the interface definition information, call chain dependencies, and runtime environment constraint information; after structured integration, perform standardized mapping on the interface definition information, call chain dependencies, and runtime environment constraint information to obtain a migration object description table. Based on the function attributes and call context information in the migration object description table, perform hierarchical analysis on the computational logic, data organization, and runtime behavior of the function to be migrated to obtain several function features; classify and summarize the several function features to obtain a multi-dimensional behavioral feature set, and perform standardized encoding on the multi-dimensional behavioral feature set to obtain a behavioral feature vector; based on the behavioral feature vector and the environment specifications of the target language computing library, perform semantic reasoning through a semantic understanding model to obtain a candidate migration rule set. The candidate migration rule set is individually scored according to preset migration scoring dimensions to obtain scoring results. Weights are assigned to the migration scoring dimensions based on the function category of the function to be migrated to obtain scoring weights. The scoring results are then weighted and fused according to the scoring weights to obtain the confidence levels of several migration rules in the candidate migration rule set. The confidence levels of the several migration rules are compared using a confidence threshold to obtain comparison results. Effective mapping rules are selected from the several migration rules based on the comparison results, and these effective mapping rules are classified by mapping type to obtain classification results. Based on the classification results, the effective mapping rules are bound to behavioral feature vectors, applicable conditions, and status identifiers to obtain binding results. A function mapping database is constructed using the classification results and binding results. The target mapping rules for the function to be migrated are matched against the migration object description table using the function mapping database. The function to be migrated is then subjected to interface adaptation, data structure conversion, and runtime compatibility processing according to the target mapping rules to obtain initial target language code. The initial target language code is then subjected to compliance verification, and if the verification result is satisfactory, the target language code is generated.Test cases are generated based on the function to be migrated. These test cases are executed in both the source and target language runtime environments to obtain source and target execution results. A consistency check is performed on these results to obtain a consistency check result. If the consistency check passes, the cross-language code generation is considered complete. If the consistency check fails, the source of the discrepancy is determined, correction rules are generated based on these discrepancy sources, and these rules are updated in the function mapping database. Iterative verification is then performed using the function mapping database until the check passes. This solves the problems of high cost, poor reusability, and lack of constraint verification in large model migration, which fails to meet the reliability requirements of scientific computing. It achieves cross-language code generation and improves the efficiency of cross-language code generation. Based on the solution of this invention, addressing the issues of uncertainty in the generation of large models in reality, the lack of numerical behavior feature constraints, mapping confidence assessment, execution-level numerical verification, and closed-loop correction mechanisms, which easily lead to problems such as code being runnable but numerical behavior being inconsistent, often overlooking differences in default parameters, index benchmarks, memory layout, exception handling, and special value propagation, making it impossible to guarantee that the numerical behavior after migration remains consistent within the engineering tolerance range, and failing to meet the high reliability requirements of scientific computing scenarios, thus resulting in low efficiency, this invention designs a cross-language code generation method. The effectiveness of the cross-language code generation method of this invention is verified when generating code in cross-language environments. Finally, the efficiency of cross-language code generation using the method of this invention is significantly improved.

[0026] In this embodiment, for ease of description, the following description will focus on the cross-language code generation device as the execution subject.

[0027] Due to inherent shortcomings in existing cross-language migration methods for scientific computing functions, the reliability of numerical values ​​generated across languages ​​is difficult to guarantee. One issue is manual migration: migrating complex numerical functions relies on manual adaptation, resulting in high costs, limited coverage, and difficulty in establishing reusable mapping rules. This leads to a significant decrease in migration efficiency in complex scientific computing scenarios. Another issue is the lack of constraints in large model generation: models can only perform syntax conversion, lacking numerical behavior constraints, confidence assessment, and numerical verification mechanisms. This easily overlooks underlying differences such as indexes, memory, and exceptions, resulting in code that runs but with inconsistent numerical results. Furthermore, there is the lack of a closed-loop correction mechanism. Without error attribution and automatic correction iteration processes, numerical deviations can only be investigated and repaired manually, which severely reduces migration reliability. Therefore, current engineering simulation and numerical modeling scenarios also face challenges in numerical consistency adaptation. Since various scientific computing libraries have specific computational rules for indices, matrices, floating-point numbers, and sparse matrices, if the cross-language migration process lacks a corresponding closed-loop numerical verification system, the numerical accuracy of the migrated code cannot meet engineering tolerance requirements.

[0028] This application provides a solution that first parses the function to be transferred to generate a transfer object description table, then uses the transfer object description table to generate behavioral feature vectors to constrain the output candidate rules of the large model, avoiding the omission of numerical differences. The confidence scores of the rules are weighted and used to filter effective rules and build a library to achieve rule reuse and reduce the cost of manual transfer. The target code is generated based on the mapping library, and a numerical verification closed loop is provided to fill the missing constraint verification of the large model, ensuring the reliability of scientific computing numerical values. This solves the problems of high cost and poor reusability of existing manual transfer methods, as well as the lack of constraint verification in large model transfer, which cannot meet the reliability requirements of scientific computing, and improves the efficiency of cross-language code generation.

[0029] Based on this, embodiments of this application provide a method for cross-language code generation, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the cross-language code generation method of this application.

[0030] In this embodiment, the cross-language code generation method includes steps S01 to S04: Step S01: Receive source code information, and parse the functions to be migrated in the source code information to obtain a migration object description table; Before the implementation of this embodiment, it should be clear that the large model generation method has uncertainty in the results, lacks numerical behavior feature constraints, mapping confidence assessment, execution-level numerical verification and closed-loop correction mechanisms, and is prone to problems such as code that can run but numerical behavior that is inconsistent. It often overlooks differences such as default parameters, index benchmarks, memory layout, exception handling and special value propagation, and cannot guarantee that the numerical behavior after migration is consistent within the engineering tolerance range, making it difficult to meet the high reliability requirements of scientific computing scenarios.

[0031] Therefore, in order to solve the above problems, this embodiment receives source code information containing various scientific computing scenarios and performs multi-dimensional static analysis of the source code, including lexical analysis, syntax analysis, and call graph analysis, to accurately locate the call nodes of all functions to be migrated within the code.

[0032] The core raw information of the function to be migrated, such as interface parameters, call chain, and runtime environment, is collected in a comprehensive manner. The scattered raw data is classified, integrated, and standardized and mapped, and then organized into a unified structured format. Finally, a standardized migration object description table is generated that can support subsequent feature extraction and rule generation.

[0033] Step S02: Generate behavioral feature vectors and candidate migration rule sets based on the migration object description table; Based on the generated standardized migration object description table, the inherent attributes and program call context information of the function to be migrated are extracted. The core features of the function are decomposed from multiple dimensions such as computational logic, data organization, and runtime behavior, and summarized to form a complete set of multi-dimensional behavioral features.

[0034] Perform standardized encoding on the feature set to construct behavioral feature vectors that include numerical precision, array dimension, broadcast rules, index baseline, memory layout, and handling of anomalies and special values.

[0035] Using this feature vector as a rigid constraint, and combining the target language and the environment specifications of the corresponding computing library, deep semantic reasoning is carried out through the large model semantic understanding module to intelligently generate a complete set of candidate migration rules covering multiple adaptation scenarios.

[0036] Step S03: Calculate the confidence level of the candidate migration rule set, and construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors; Based on the pre-set multi-dimensional migration scoring system, each migration rule in the candidate migration rule set is given a comprehensive single-item quantitative score to objectively characterize the basic adaptation performance of each rule.

[0037] Based on the specific category of the function to be transferred, the weight parameters of each scoring dimension are configured differently to adapt to the evaluation emphasis of different scientific computing scenarios such as linear algebra, statistical modeling, and optimization.

[0038] By integrating all individual score data through a weighted fusion algorithm, the comprehensive fit reliability of each candidate migration rule is accurately calculated.

[0039] The confidence scores of each rule are compared with preset thresholds to select effective rules. The rules are then classified, information is bound, and structured archiving is completed by combining behavioral feature vectors. Finally, a dedicated function mapping database adapted for cross-language migration of scientific computing functions is built.

[0040] Step S04: Generate target language code through the function mapping database.

[0041] Based on the pre-built function mapping database and the migration object description table corresponding to the function to be migrated, the optimal target mapping rule is accurately retrieved and matched. According to the matching rule, multi-dimensional compatibility optimizations are performed in a targeted manner, including function interface adaptation, parameter adjustment, data structure conversion, memory layout adaptation, and handling of exceptions and special values, and the initial target language code is generated.

[0042] The initial code undergoes comprehensive verification for syntax compliance, runtime compatibility, and numerical precision consistency. Adaptation vulnerabilities and syntax errors are eliminated. After passing the verification, the final target language code that can run stably and whose numerical behavior accurately matches the source function is output.

[0043] Figure 2 This is a schematic diagram of the cross-language migration system involved in the code cross-language generation of this application. The overall implementation adopts a modular and collaborative closed-loop architecture. Each functional module has a clear division of labor and links up and down, fully covering the entire process of cross-language migration, intelligent generation, numerical verification, error correction, and rule iteration of scientific computing functions. It can be adapted to migration scenarios of various scientific computing languages ​​and function libraries such as NumPy, SciPy, MATLAB, R, Fortran, C, C++, and Julia.

[0044] The system core comprises twelve major functional modules, among which the code parsing module serves as the core of the front-end input, responsible for receiving source code, function documentation, and calling context, and completing the parsing of function information and outputting the object description table.

[0045] The numerical behavior feature extraction module deeply mines the multi-dimensional numerical characteristics of functions, standardizes and generates behavior feature vectors and behavior constraint lists, and provides accurate constraint basis for subsequent rule generation.

[0046] The large-scale model semantic understanding module relies on structured parsing data and feature vectors to intelligently infer and generate multiple types of candidate transfer rules and adaptation code templates.

[0047] The transformation rule generation module combines numerical constraints to standardize various mapping and adaptation rules, providing a standardized basis for code generation.

[0048] The function mapping library building module classifies, archives, binds, and maintains versions of compliance rules, building a full-dimensional rule library that includes basic mapping, combination matching, exception handling, numerical tolerance, and historical correction.

[0049] The test case generation module generates full-scenario test cases covering normal, boundary, ill-conditioned matrices, sparse matrices, complex numbers, special values, and abnormal triggers based on behavioral characteristics.

[0050] The multi-language execution module is compatible with multiple language runtime environments, enabling dual-end execution of source and target language code and collecting complete runtime behavior data.

[0051] The numerical behavior verification module completes the accurate verification of the results from both ends through multi-dimensional error indicators and consistency judgment criteria.

[0052] The error attribution module accurately locates the core sources of various migration biases and distinguishes between problems such as mapping errors, adaptation omissions, and numerical deviations.

[0053] The automatic correction module generates various compensation and adaptation correction rules and updates them to the rule base simultaneously.

[0054] The closed-loop re-verification module iteratively completes code regeneration, secondary verification, and rule updates, forming a continuously optimized closed-loop mechanism.

[0055] The output module ultimately summarizes and outputs migration code, verification data, correction records, and rule update results. Each module is interconnected and iterates in a closed loop, completely solving the industry pain points of low efficiency, poor numerical reliability, and unusable rules in traditional migration methods.

[0056] Specifically, step S01 above, which involves parsing the function to be migrated in the source code information to obtain the migration object description table, includes: Step S011: Perform multi-dimensional static code analysis on the source code information to obtain the function call nodes of the function to be migrated; Step S012: Semantic parsing is performed on the context semantics of the function call node to obtain the interface definition information, call chain dependency relationship and runtime environment constraint information of the function to be migrated; Step S013: The interface definition information, call chain dependency relationship and runtime environment constraint information are structurally integrated; Step S014: After the structured integration is completed, the interface definition information, call chain dependency relationship and runtime environment constraint information are standardized and mapped to obtain the migration object description table.

[0057] We conduct comprehensive, multi-dimensional static code analysis on the acquired source code information, covering lexical analysis, syntax analysis, and program call chain analysis. We accurately traverse the overall structure of the source code, accurately identify and locate all function call nodes involved in the operation and call, and lock the core objects for subsequent migration processing.

[0058] For each identified function call node to be migrated, deep semantic analysis is performed in conjunction with the contextual semantics of its upstream and downstream code to comprehensively extract the complete interface definition parameters of the function, the dependencies of the program call chain, and the environmental constraints adapted to different running scenarios, thus fully capturing the basic information of the function to be migrated in all dimensions.

[0059] The extracted interface definition information, call chain dependencies, and runtime environment constraint information are classified, sorted, and integrated. Redundant data is removed, and missing related information is supplemented to form a structured set of original function information.

[0060] The integrated structured information is subjected to unified and standardized mapping processing. The information is organized according to the preset field specifications, data formats and storage standards, and the scattered unstructured data is transformed into a unified, standardized, identifiable migration object description table that can be used for subsequent feature extraction and rule generation.

[0061] More specifically, step S02 above, which involves generating behavioral feature vectors and candidate migration rule sets based on the migration object description table, includes: Step S021: Based on the function attributes and calling context information in the migration object description table, perform hierarchical analysis on the computation logic, data organization, and running behavior of the function to be migrated to obtain several function features; Step S022: Classify and summarize the several function features to obtain a multi-dimensional behavioral feature set, and standardize and encode the multi-dimensional behavioral feature set to obtain a behavioral feature vector; Step S023: Based on the behavioral feature vector and the environmental specifications of the target language computing library, a set of candidate transfer rules is obtained through semantic reasoning using a semantic understanding model.

[0062] The generated migration object description table is retrieved, and core data such as the inherent attributes of the function to be migrated, program call context, and runtime adaptation constraints are extracted from the internal records. The function is then disassembled and analyzed layer by layer from three dimensions: the core computational logic operation rules, the multi-dimensional data structure organization form, and the real-time performance of the program. All inherent characteristics of the function in scenarios such as numerical operation, data processing, state response, exception triggering, and special value propagation are comprehensively explored, and a large number of scattered and refined individual function features are summarized.

[0063] All the single function features obtained from mining are categorized, summarized, deduplicated, and integrated to form a multi-dimensional behavioral feature set covering function category, data structure, numerical precision, array dimension, matrix direction, broadcasting rules, index benchmark, memory layout, sparse matrix structure, complex number representation, randomness, abnormal behavior, NaN and Inf propagation, and overflow / underflow handling.

[0064] A unified and standardized coding process is carried out on the integrated multi-dimensional behavioral feature set to transform unstructured feature information into structured, quantified, constrained, and matchable vector data, generating behavioral feature vectors that can accurately represent all numerical behavioral characteristics of the transfer function.

[0065] Based on the constructed behavioral feature vector as a rigid constraint for numerical consistency, and combined with the target language and its supporting computing library's environment adaptation specifications, syntax rules, numerical processing mechanisms, and anomaly handling logic, the semantic understanding model is input to carry out cross-language deep semantic reasoning. It intelligently generates a full-scenario candidate migration rule set that includes direct mapping, substitution functions, combination matching, wrapping matching, special value handling, and anomaly matching, adapting to the cross-language migration needs of various complex scientific computing functions.

[0066] Further, step S03 above, the step of calculating the confidence level of the candidate migration rule set, includes: Step S031: Score each item of the candidate migration rule set according to the preset migration scoring dimensions to obtain the scoring results; Step S032: Assign weights to the migration scoring dimensions according to the function category of the function to be migrated, and obtain the scoring weights; Step S033: Perform a weighted fusion calculation on the scoring results according to the scoring weights to obtain the confidence levels of several migration rules in the candidate migration rule set.

[0067] A multi-dimensional comprehensive scoring system adapted to cross-language transfer scenarios of scientific computing functions is pre-built. The scoring dimensions comprehensively cover eight core dimensions: function name similarity, function signature matching degree, parameter constraint adaptability, return value structure matching degree, numerical behavior feature matching degree, strength of official documentation evidence support, historical transfer rule hit rate, and large model inference self-consistency. It can comprehensively evaluate the adaptability and reliability of transfer rules, and its calculation form can be expressed as:

[0068] Where C is the total confidence of the candidate rule, Cn is the function name matching score, Cs is the function signature matching score, Cp is the parameter constraint matching score, Cr is the return value structure matching score, Cb is the numerical behavior feature matching score, Cd is the document evidence score, Ch is the historical rule hit score, Cl is the large model self-consistency score, and w1 to w8 are weight parameters.

[0069] Specifically, the eight individual scores of the candidate rules are all normalized to [0, 1]. Among them, the function name matching score Cn is determined based on the name edit distance and semantic similarity; the function signature matching score Cs is determined based on the proportion of consistent items in the number, order and type of input parameters; the parameter constraint matching score Cp is determined based on the proportion of consistent items in the range, default value, optional parameters and unit constraints; the return value structure matching score Cr is determined based on the proportion of consistent items in the number, type, dimension and arrangement order of return values; the numerical behavior feature matching score Cb is determined based on the proportion of test cases in the stratified test cases that meet the absolute error, relative error, ULP error and structural constraints; the document evidence score Cd is determined based on the degree of explicit support for the mapping relationship in the official documents of the source and target languages; the historical rule hit score Ch is determined based on the pass rate of similar verified rules; and the large model self-consistency score Cl is determined based on the proportion of consistent results of multiple rounds of independent inference.

[0070] When assigning weights, first retrieve the category-based weight vector Bk=(bk1,…,bk8) based on the function category identifier k in the behavioral feature vector. Then, count the number of validated samples Nki and the number of valid samples Pki of the same category and scoring dimension from the historical migration rule base to calculate the reliability coefficient.

[0071] When there are no historical samples, let rki=1.

[0072] Then press:

[0073] Normalization is performed to ensure that all weights are non-negative and their sum is 1. Thus, the function category determines the emphasis of the basic evaluation, and historical validation results are used to correct the actual reliability of the judgments in each dimension.

[0074] In an optional implementation, the eight components correspond sequentially to Cn, Cs, Cp, Cr, Cb, Cd, Ch, and Cl. The basic weights for the linear algebra class are (0.05, 0.10, 0.15, 0.15, 0.30, 0.10, 0.10, 0.05), for the statistical class they are (0.05, 0.10, 0.25, 0.10, 0.25, 0.10, 0.10, 0.05), for the optimization class they are (0.05, 0.10, 0.20, 0.10, 0.30, 0.10, 0.10, 0.05), and for the general numerical class they are (0.10, 0.15, 0.15, 0.10, 0.20, 0.10, 0.10, 0.10). These values ​​can be recalibrated using a historical validation set, but the normalization step is performed during each calibration.

[0075] The confidence level is determined by combining a comprehensive threshold with the lower limit of key dimensions: When C ≥ 0.80 and Cs, Cp, Cr, and Cb are all not less than 0.70, the candidate rule is marked as valid; When 0.65≤C<0.80 or any key dimension is below 0.70, proceed with the supplementary documentation evidence and two-way review process. This rule is eliminated when C < 0.65.

[0076] This key dimension lower bound is used to prevent name similarity or high self-consistency of large models from masking mismatches in parameters, return structure, or numerical behavior.

[0077] The candidate rule scoring, weighting, and judgment process is as follows: Figure 8 As shown, for example, for a linear algebra candidate rule, without historical correction, the basic weights are (0.05, 0.10, 0.15, 0.15, 0.30, 0.10, 0.10, 0.05), and the eight-dimensional scores are (0.90, 0.95, 0.80, 0.90, 0.85, 1.00, 0.80, 0.90), then C=0.875, and all four key dimensions meet the lower bound, so the rule is marked as valid. If only Cp is changed to 0.60, the overall value is still 0.845, but because Cp is lower than 0.70, it enters the review process, thus avoiding the overall score masking the differences in key parameter constraints.

[0078] Through the standardized scoring system described above, each independent migration rule in the candidate migration rule set is given a refined, single-item quantitative score. The performance of each rule in different adaptation dimensions is objectively collected, resulting in a complete and refined multi-dimensional scoring result.

[0079] Based on the specific business category and computational attributes of the function to be migrated, the device sequentially performs function category identification, basic weight retrieval, historical reliability correction, and normalization processing to obtain the scoring weight corresponding to the current migration scenario.

[0080] Among them, the linear algebra class strengthens the constraints on dimension, matrix direction and memory layout by increasing the basic weights of Cb and Cr; the statistics class strengthens the constraints on default normalization parameters, stochastic properties and distribution parameters by increasing the basic weights of Cp and Cb; and the optimization solution class strengthens the constraints on stopping conditions, convergence state and numerical behavior by increasing the basic weights of Cp and Cb.

[0081] The eight individual scores are weighted and fused according to the normalized weight parameters, and the lower limit of the key dimensions is checked at the same time to obtain the comprehensive confidence and validity, review or elimination status of each candidate migration rule, so as to provide repeatable evaluation results for subsequent rule screening and database construction.

[0082] Furthermore, step S03 above, the step of constructing a function mapping database based on the confidence level, using the candidate migration rules and behavioral feature vectors, includes: Step S034: The confidence levels of the several migration rules are compared using a confidence threshold to obtain the comparison results; Step S035: Based on the comparison results, select the effective mapping rules from the plurality of migration rules, classify the effective mapping rules by mapping type, and obtain the classification results; Step S036: Based on the classification result, bind the effective mapping rule to the behavior feature vector, the applicable condition, and the state identifier to obtain the binding result; Step S037: Construct a function mapping database using the classification results and binding results.

[0083] The mapping rules in this embodiment are as follows: Figure 3 As shown, the confidence value of each migration rule is calculated and compared with the system's preset confidence threshold one by one to clearly distinguish between rules that meet the adaptability standard and those that do not, thus obtaining a complete rule screening and comparison result and accurately eliminating invalid rules with poor adaptability, high risk of numerical deviation, and insufficient reliability.

[0084] Based on the comparison results, all valid mapping rules that meet the confidence threshold requirements are selected and retained. At the same time, according to the implementation form and adaptation logic of the rules, the valid mapping rules are divided into four types: direct mapping rules, substitution function rules, combination function rules, and wrapping adaptation rules. The standardized classification and archiving of rules are completed, resulting in a clear rule classification result.

[0085] For each of the various valid mapping rules that have been classified, a multi-dimensional information binding operation is carried out one by one. The behavioral feature vectors that accurately represent the inherent characteristics of the function, the applicable calculation scenarios and input conditions of the rule, and the rule operation verification status identifier are accurately bound to the corresponding rule entries. This achieves the completeness and structured supplementation of information for a single rule, resulting in standardized rule binding results.

[0086] Based on the rule classification results and information binding results, refer to Figure 3 The rule-based structured architecture uses source language function identifiers and target language function identifiers as the core associations, integrating full-dimensional information such as function name mapping, signature mapping, parameter adaptation, return value rearrangement, data structure transformation, sparse matrix and complex number adaptation, anomaly and special value handling, adaptation code templates, confidence parameters, verification status and version number. Finally, it builds a full-dimensional function mapping database including a basic mapping library, a combined mapping library, a wrapper adaptation library, an anomaly mapping library, a numerical tolerance library, and a historical correction rule library, realizing structured storage, reusable calls, and continuous iterative updates of migration rules.

[0087] This embodiment, through the above-described scheme, specifically receives source code information, parses the function to be transferred in the source code information to obtain a migration object description table; generates behavioral feature vectors and a candidate migration rule set based on the migration object description table; calculates the confidence level of the candidate migration rule set, and constructs a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors; and generates target language code using the function mapping database. Thus, by first parsing the function to be transferred to generate a migration object description table, then using the migration object description table to generate behavioral feature vectors to constrain the output candidate rules of the large model, avoiding the omission of numerical differences, weighting the rules to calculate confidence levels to filter effective rules and build a database, achieving rule reuse, reducing manual migration costs, generating target code based on the mapping database, and providing a corresponding numerical verification closed loop to supplement the missing constraint verification of the large model, ensuring the reliability of scientific computing numerical values, this embodiment solves the problems of high cost and poor reusability of existing manual migration methods, and the lack of constraint verification in large model migration, which cannot meet the reliability requirements of scientific computing, thus improving the efficiency of cross-language code generation.

[0088] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 In step S04, the step of generating target language code through the function mapping database, the cross-language code generation method further includes steps S041 to S043: Step S041: Based on the migration object description table, match the target mapping rule of the function to be migrated through the function mapping database; Step S042: According to the target mapping rules, the function to be migrated is subjected to interface adaptation, data structure conversion and runtime compatibility processing to obtain the initial target language code; Step S043: Perform compliance verification on the initial target language code, and generate the target language code if the verification result is satisfactory.

[0089] The migration object description table corresponding to the function to be migrated is retrieved, and the core information such as the function's interface parameters, data structure, computational characteristics, and runtime constraints are extracted. A precise search and matching is performed in the pre-built function mapping database to select the target mapping rule with the highest fit and the best confidence level to the current function to be migrated.

[0090] Strictly adhering to the matched target mapping rules, comprehensive code adaptation and compatibility optimization are carried out. For differences in function interfaces, parameter rearrangement, default parameter completion, and parameter type conversion are performed. For differences in arrays, matrices, and tensors, dimension conversion, matrix transposition, broadcast rule adaptation, and memory layout adjustment are performed. For sparse matrix scenarios, compression format conversion and non-zero structure preservation are performed. For complex number operations, real and imaginary parts are split and recombined, and amplitude and phase are adapted. For abnormal and special value scenarios, exception handling, error code mapping, NaN and Inf standardization, and overflow and underflow adaptation are performed. All these measures comprehensively eliminate adaptation biases caused by differences in multiple languages, generating initial target language code that is structurally complete and logically coherent.

[0091] A comprehensive compliance check is performed on the generated initial target language code, covering syntax standardization check, runtime compatibility check, numerical adaptation check, and abnormal response compliance check. This accurately identifies various issues such as syntax errors, adaptation vulnerabilities, numerical deviations, and runtime anomalies. Non-compliant content is corrected and optimized. After all checks pass, standard target language code that can run stably in the target language environment, whose numerical behavior perfectly matches the source function, and meets engineering tolerance requirements is generated.

[0092] Specifically, after step S04 above, which involves generating the target language code through the function mapping database, the method further includes: Step S05: Generate test cases based on the function to be migrated; Step S06: Execute the test case set in the source language runtime environment and the target language runtime environment respectively to obtain the source end runtime result and the target end runtime result, and perform consistency verification on the source end runtime result and the target end runtime result to obtain the consistency verification result; Step S07: If the consistency verification result is successful, then the cross-language code generation is considered complete. Step S08: If the consistency verification result is that the verification fails, then the source of the difference is determined according to the consistency verification result, a correction rule is generated based on the source of the difference, the correction rule is updated to the function mapping database, and iterative verification is performed through the function mapping database until the verification passes.

[0093] Based on the numerical behavior feature vector and inherent computational characteristics of the function to be transferred, a layered test case set is generated in batches, covering regular operations, boundary extrema, dimensional degradation, ill-conditioned matrices, singular matrices, sparse matrices, complex number operations, maximum and minimum values, special values ​​of NaN and Inf, overflow and underflow, random seeds, anomaly triggers, and typical engineering scenarios. Each test case set is bound to input labels, expected output structure, engineering tolerance strategy, anomaly expectations, and error attribution observation points to ensure the comprehensiveness and accuracy of test coverage.

[0094] The same set of standardized test cases is generated and deployed and run in the dedicated runtime environments of the source language and the target language respectively. All runtime data, including output values, data dimensions, data types, symbol characteristics, sparse structure, complex real and virtual parameters, exception types, error codes, special value markers, overflow and underflow states, and iteration counts, are collected after the two ends run. These data form complete source language behavior records and target language behavior records respectively.

[0095] Multi-dimensional consistency verification is performed on the behavior records at both ends. The core indicators such as absolute error, relative error, ULP error, sign consistency, dimension consistency, sparse structure consistency, complex amplitude and phase consistency, broadcast result consistency, index result consistency, anomaly and error code consistency, NaN and Inf propagation consistency, and overflow and underflow handling consistency are compared and matched with function category-differentiated verification indicator combinations to obtain accurate consistency verification results.

[0096] If all core indicators meet the engineering tolerance standards, the migration result is deemed qualified.

[0097] If there is a deviation, then execute. Figure 9 The difference attribution process shown involves merging the source result Ys, target result Yt, input label, and behavioral feature vector into an error feature signature D for each failed test case. D includes at least the maximum absolute error Eabs, maximum relative error Erel, maximum ULP error Eulp, output shape difference Δshape, data type difference Δtype, sign difference Δsign, element position correlation feature Rpos, sparse structure difference Δsparse, complex amplitude difference Δcomplex, anomaly type difference Δexc, and special value propagation difference Δspecial.

[0098] The device first filters candidate sources based on non-numerical features: different shapes or ranks correspond to dimension preservation or return value rearrangement; consistent elements after transposition correspond to matrix direction differences; consistent elements after fixed position offset correspond to index baseline differences; different anomaly types or NaN / Inf masks correspond to anomaly and special value handling differences. For cases where only numerical errors are present or multiple candidate sources exist simultaneously, the device uses a controlled variable probe for back-inference. The absolute error, relative error, and ULP error are divided by their respective tolerances and the maximum value is taken to obtain the original target end normalized scalar error E0. Only one adaptation factor q is replaced each time, and the following tests are performed sequentially: default parameter explicitness, parameter order adjustment, dimension preservation, matrix transposition, broadcast wrapping, index ±1, row and column master order conversion, sparse format conversion, complex number representation conversion, computational accuracy improvement, and anomaly standardization, to obtain the probe error Eq, and the error reduction rate is calculated. .

[0099] When ρq≥0.80 and at least two test cases with the same error attribution label reach the same conclusion, q is identified as the source of difference. If multiple q meet the conditions at the same time, the single-factor source with the largest ρq is selected first, and then joint probes are performed on the remaining factors until the remaining error no longer exceeds the engineering tolerance.

[0100] After determining the source of the difference, the device generates correction rules according to the preset mapping: difference in default value or parameter order corresponds to parameter completion or rearrangement; difference in dimension or transpose corresponds to reshape, squeeze, or transpose adaptation; difference in broadcast corresponds to explicit dimension expansion; difference in index baseline corresponds to fixed offset; difference in memory layout corresponds to row and column master order conversion; difference in sparsity or complex number corresponds to storage format or representation conversion; difference in precision corresponds to data type enhancement or high-precision algorithm replacement; difference in anomalies and special values ​​corresponds to anomaly type, NaN, and Inf propagation standardization.

[0101] After correction, the target language code is regenerated and the original failed test cases, same-label boundary test cases, and regression test cases are executed; only if the structural metrics are completely consistent and the numerical error meets the requirements... Only when the condition is met will the corrected rule be written into the function mapping database and marked as verified; otherwise, the next round of attribution will continue.

[0102] Example 1 of difference verification: Calculate the standard deviation of vector [1, 2, 3]. The default result of the source MATLAB is 1. When the target NumPy uses the default ddof=0, the result is about 0.81649658. The device recognizes that the output shape, type and sign are consistent, and only the numerical value has a stable proportional deviation. After changing the target to ddof=1, the result becomes 1, ρ=1. Therefore, it is attributed to the difference of default parameters, and the parameter compensation rule "explicitly set ddof=1 on the target std" is generated.

[0103] Example 2 of difference verification: Rearrange [1, 2, 3, 4, 5, 6] into a 2×3 matrix. The source MATLAB result is [[1, 3, 5], [2, 4, 6]], and the target NumPy default C order result is [[1, 2, 3], [4, 5, 6]]. The two ends have the same shape but different element position patterns. After changing the target end to order='F', the elements are consistent, and ρ=1. Therefore, the difference is attributed to the difference in row and column order or rearrangement order, and a column order conversion rule is generated.

[0104] Example 3 of difference verification: When inputting A=[10, 20, 30] and reading the first element of the source end, MATLAB's A(1) is 10, while the target end directly generates NumPy's A[1] as 20. After changing the index to A[1-1] separately, the error returns to zero and all similar boundary test cases pass. Therefore, the error is attributed to the difference in the index baseline, and the index minus 1 rule is generated.

[0105] This embodiment, through the above-described scheme, specifically matches the target mapping rules of the function to be migrated to the migration object description table through the function mapping database; performs interface adaptation, data structure conversion, and runtime compatibility processing on the function to be migrated according to the target mapping rules to obtain initial target language code; performs compliance verification on the initial target language code, and generates the target language code if the verification result is satisfactory. Thus, the migration object description table is first generated by parsing the function to be migrated, and then behavioral feature vectors are generated based on the migration object description table to constrain the output candidate rules of the large model, avoiding the omission of numerical differences. The confidence scores of the rules are weighted and used to filter effective rules and build a library, achieving rule reuse and reducing manual migration costs. Target code is generated based on the mapping library, with a corresponding numerical verification closed loop to supplement the missing constraint verification of the large model, ensuring the reliability of scientific computing numerical values. This solves the problems of high cost and poor reusability of existing manual migration methods, and the lack of constraint verification in large model migration, which cannot meet the reliability requirements of scientific computing, thus improving the efficiency of cross-language code generation.

[0106] For example, to help understand the implementation process of the cross-language code generation method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 5 , Figure 5 A simplified flowchart illustrating a method for cross-language code generation is provided, specifically: This embodiment implements a fully automated, high-precision, iterative closed-loop scientific computing function cross-language transfer system, which fully covers the entire chain of code parsing, feature extraction, rule generation, confidence assessment, rule library construction, code generation, testing and verification, error correction, and closed-loop iteration.

[0107] First, various scientific computing source code information is received. Through multi-dimensional static analysis and standardization processing, a migration object description table that accurately represents the function attributes is generated, and the standardized identification and sorting of migration objects are completed.

[0108] Based on the deep mining of multi-dimensional numerical behavioral features of functions using the transfer object description table, behavioral feature vectors are constructed through standardized encoding. Using these vectors as rigid constraints and relying on the semantic reasoning capabilities of large models, a candidate transfer rule set covering multiple adaptation scenarios is generated.

[0109] The algorithm employs an eight-dimensional weighted fusion method to accurately calculate the confidence level of each rule. Combined with preset thresholds, it completes the effective rule selection, classification, and multi-dimensional information binding, building a standardized and reusable function mapping database. Based on the standardized adaptation rules of the mapping database, it completes comprehensive cross-language adaptation and compliance verification of the functions to be migrated, generating high-precision and stable target language code.

[0110] Subsequently, full-scenario layered test cases were used to complete the execution of dual-end environments and multi-dimensional numerical consistency verification, accurately identify migration adaptation deviations, locate the specific source of the problem through multi-dimensional error attribution, automatically generate adaptation correction rules and update them to the rule base simultaneously.

[0111] Ultimately, relying on the updated rule base, the code is regenerated and re-verified iteratively. Multiple termination conditions are used as the basis for iteration, forming a complete closed loop of transformation, verification, attribution, correction, and re-verification. This completely solves the technical defects of high cost of manual migration, insufficient scenario coverage, difficulty in reusing rules, poor numerical reliability of pure large model migration, and easy occurrence of adaptation omissions. It significantly improves the automation, numerical accuracy, scenario adaptability, and reusability of cross-language migration of scientific computing functions.

[0112] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the cross-language code generation method of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0113] This application also provides a cross-language code generation device; please refer to [reference needed]. Figure 6 The cross-language code generation device includes: The receiving module 10 is used to receive source code information and parse the functions to be migrated in the source code information to obtain a migration object description table; The first generation module 20 is used to generate behavioral feature vectors and candidate migration rule sets based on the migration object description table. The construction module 30 is used to calculate the confidence level of the candidate migration rule set, and to construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors. The second generation module 40 is used to generate target language code through the function mapping database.

[0114] The cross-language code generation apparatus provided in this application, employing the cross-language code generation method described in the above embodiments, can solve the technical problems of high cost and poor reusability of existing manual migration methods, as well as the lack of constraint verification in large model migration, which fails to meet the reliability requirements of scientific computing. Compared with the prior art, the beneficial effects of the cross-language code generation apparatus provided in this application are the same as those of the cross-language code generation method provided in the above embodiments, and other technical features in the cross-language code generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0115] This application provides a cross-language code generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the cross-language code generation method in Embodiment 1 above.

[0116] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing cross-language code generation devices in the embodiments of this application. The cross-language code generation devices in the embodiments of this application may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The code shown for cross-language generation devices is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0117] like Figure 7 As shown, the cross-language code generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the cross-language code generation device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the cross-language code generation device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows cross-language code generation devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0118] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0119] The cross-language code generation device provided in this application, employing the cross-language code generation method described in the above embodiments, can solve the technical problems of high cost and poor reusability of existing manual migration methods, as well as the lack of constraint verification in large model migration, which fails to meet the reliability requirements of scientific computing. Compared with the prior art, the beneficial effects of the cross-language code generation device provided in this application are the same as those of the cross-language code generation method provided in the above embodiments, and other technical features of this cross-language code generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0120] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0122] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the code cross-language generation method in the above embodiments.

[0123] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0124] The aforementioned computer-readable storage medium may be included in a cross-language code generation device; or it may exist independently and not be assembled into a cross-language code generation device.

[0125] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a cross-language code generation device, the cross-language code generation device: receives source code information; parses the functions to be migrated in the source code information to obtain a migration object description table; generates behavioral feature vectors and a candidate migration rule set based on the migration object description table; calculates the confidence level of the candidate migration rule set; and constructs a function mapping database based on the confidence level, using the candidate migration rule set and the behavioral feature vectors; and generates target language code using the function mapping database.

[0126] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0129] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described cross-language code generation method. This solves the technical problems of high cost and poor reusability in existing manual migration methods, and the lack of constraint verification in large model migration, which fails to meet the reliability requirements of scientific computing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the cross-language code generation method provided in the above embodiments, and will not be repeated here.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the cross-language code generation method described above.

[0131] The computer program product provided in this application can solve the technical problems of high cost and poor reusability of existing manual migration methods, as well as the lack of constraint verification in large model migration, which fails to meet the reliability requirements of scientific computing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the code cross-language generation method provided in the above embodiments, and will not be repeated here.

[0132] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for cross-language code generation, characterized in that, The cross-language code generation method includes: Receive source code information, parse the functions to be migrated in the source code information to obtain a migration object description table; Generate behavioral feature vectors and a set of candidate migration rules based on the migration object description table; Calculate the confidence level of the candidate migration rule set, and construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors; The target language code is generated using the function mapping database.

2. The code cross-language generation method as described in claim 1, characterized in that, The step of parsing the function to be migrated in the source code information to obtain the migration object description table includes: Perform multi-dimensional static code analysis on the source code information to obtain the function call nodes of the function to be migrated; Semantic parsing is performed on the context semantics of the function call node to obtain the interface definition information, call chain dependency relationship and runtime environment constraint information of the function to be migrated; The interface definition information, call chain dependencies, and runtime environment constraint information are structurally integrated; After the structured integration is completed, the interface definition information, call chain dependencies, and runtime environment constraint information are standardized and mapped to obtain the migration object description table.

3. The cross-language code generation method as described in claim 1, characterized in that, The step of generating behavioral feature vectors and candidate migration rule sets based on the migration object description table includes: Based on the function attributes and calling context information in the migration object description table, the computational logic, data organization, and runtime behavior of the function to be migrated are analyzed in layers to obtain several function characteristics; The aforementioned functional features are categorized and summarized to obtain a multi-dimensional behavioral feature set, and the multi-dimensional behavioral feature set is standardized and encoded to obtain a behavioral feature vector. Based on the behavioral feature vectors and the environmental specifications of the target language computing library, a set of candidate transfer rules is obtained through semantic reasoning using a semantic understanding model.

4. The code cross-language generation method as described in claim 1, characterized in that, The step of calculating the confidence level of the candidate migration rule set includes: The candidate migration rule set is scored individually according to the preset migration scoring dimensions to obtain the scoring results; The migration scoring dimensions are weighted according to the function category of the function to be migrated, and the scoring weights are obtained. The scoring results are weighted and fused according to the scoring weights to obtain the confidence levels of several migration rules in the candidate migration rule set.

5. The cross-language code generation method as described in claim 4, characterized in that, The step of constructing a function mapping database based on the confidence level, the candidate migration rules, and the behavioral feature vectors includes: The confidence levels of the several migration rules are compared using a confidence threshold to obtain the comparison results; Based on the comparison results, valid mapping rules are selected from the several migration rules, and the valid mapping rules are classified by mapping type to obtain the classification results. Based on the classification results, the effective mapping rules are bound to behavioral feature vectors, applicable conditions, and state identifiers to obtain binding results. A function mapping database is constructed using the classification and binding results.

6. The cross-language code generation method as described in claim 1, characterized in that, The step of generating target language code through the function mapping database includes: Based on the migration object description table, the target mapping rules of the function to be migrated are matched through the function mapping database; Based on the target mapping rules, the function to be migrated is subjected to interface adaptation, data structure conversion, and runtime compatibility processing to obtain the initial target language code; The initial target language code is subjected to compliance verification, and the target language code is generated if the verification result is satisfactory.

7. The code cross-language generation method as described in claim 1, characterized in that, The step of generating target language code through the function mapping database is followed by: Generate test cases based on the function to be migrated; The test case set is executed in the source language runtime environment and the target language runtime environment respectively to obtain the source end runtime result and the target end runtime result. The consistency of the source end runtime result and the target end runtime result is verified to obtain the consistency verification result. If the consistency check result is successful, then the cross-language code generation is considered complete. If the consistency check result is a failure, the source of the difference is determined based on the consistency check result, a correction rule is generated based on the source of the difference, the correction rule is updated to the function mapping database, and iterative verification is performed through the function mapping database until the check passes.

8. A cross-language code generation device, characterized in that, The cross-language code generation device includes: The receiving module is used to receive source code information and parse the functions to be migrated in the source code information to obtain a migration object description table; The first generation module is used to generate behavioral feature vectors and a set of candidate migration rules based on the migration object description table. A construction module is used to calculate the confidence level of the candidate migration rule set, and to construct a function mapping database based on the confidence level, using the candidate migration rule set and behavioral feature vectors. The second generation module is used to generate target language code through the function mapping database.

9. A cross-language code generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the code cross-language generation method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the code cross-language generation method as described in any one of claims 1 to 7.