Method and system for translation of codes using an ai model

Abstract

A computer-implemented method for translating a first code written in a first language into a second code written in a second language using an AI model, the method comprising the steps of: preprocessing the first code; segmenting the preprocessed first code into a plurality of first units, wherein each of the plurality of first units is smaller than a unit size determined based on a context window of the AI model; and generating first prompts, wherein each of the first prompts is for translating each of the plurality of first units into the second language and includes metadata regarding context of translation from the first code to the second code; and translating the plurality of first units into a plurality of second units of the second code by providing each of the first prompts to the AI model, wherein each of the first prompts is for translating each of the plurality of first units into the second language and includes metadata regarding context of translation from the first code to the second code.

Description

METHOD AND SYSTEM FOR TRANSLATION OF CODES USING AN AI MODEL

[0001] There are cases where it is desirable to translate a first code written in a first language into a second code written in a second language. For example, the C programming language has long been widely used in existing software systems. However, it continues to suffer from memory safety vulnerabilities, which remain a significant source of critical security issues. In light of this situation, Rust has emerged as a promising alternative due to its strong memory safety guarantees and suitability for system-level programming. Accordingly, there is a growing demand to translate code written in C into Rust.

[0002] Existing translation approaches can be broadly classified into rule-based and AI model-based methods. Rule-based tools rely on hand-written transformation rules and can handle large codebases but tend to generate problematic codes. For example, C2Rust for translation from C to Rust often expands C macros before translation, relies heavily on unsafe blocks, and produces output that depends on compiler-specific behavior.

[0003] In contrast, AI Model-based approaches show potential in generating better codes by leveraging the model’s capacity to understand high-level intent and semantic structure. However, AI Model-based translation currently faces critical limitations. Prior studies have shown that AI Models can typically translate only small-scale programs, largely due to challenges in handling complex cross-references, semantic gaps between languages, and context window limitations.

[0004] To overcome these issues, the present disclosure proposes a novel AI Model-based code translation method that supports the successful compilation of large-scale programs.

[0005] Fig. 1 is a schematic diagram illustrating an overview of a translation method for translating first code written in a first language into second code written in a second language.FIG. 2 is a block diagram illustrating a schematic configuration of the translation system 100.FIG. 3A is a diagram illustrating an example of C code related to the conversion of preprocessor macro processing.FIG. 3B is a diagram illustrating an example of Rust code related to the conversion of preprocessor macro processing.FIG. 4 is a diagram illustrating an example of a translation prompt for a translation unit of C code.FIG. 5 is a diagram illustrating an example of a prompt for correcting compile errors in Rust code.FIG. 6 is a diagram illustrating an example of a mapping prompt that describes the correspondence between elements of C code and Rust code.FIG. 7 is a diagram illustrating an example of code for a feedback-driven code repair algorithm in the translation from C to Rust.FIG. 8 is a configuration diagram illustrating the relationship between the components of the translation system 100 and user devices and networks.

[0006] In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well- known features may be omitted or simplified in order not to obscure the embodiment being described.

[0007] FIG. 1 illustrates a schematic diagram of a translation method for translating a first code written in a first language into a second code written in a second language using an AI model (such as LLM). In FIG. 1, C is shown as an example of the first language, and Rust is shown as an example of the second language.

[0008] In one embodiment, the method may include preprocess of the first code written in the first language. In one embodiment, as shown as "S1: Merging" in FIG.1, the preprocess may include merging a first element of the first code with a second element of the first code that is referenced by the first element. In one embodiment, as shown as "S2: Reordering" in FIG.1, the preprocess may include reordering a plurality of elements (e.g., functions, and type definitions) of the first code in topological order. In one embodiment, as shown as "S3: Macro Handling" in FIG.1, the preprocess may include handling macros, such as removing a definition of a macro from the first code, and enabling a function corresponding to the definition in a configuration file of the second code. These preprocesses can make the definitions in the first code appear before their references, thereby aligning the first code more closely with the second language's expectations and reducing AI model misunderstanding due to fragmented contexts. Preprocessing reduces misunderstandings by the AI model and decreases compilation errors, particularly those related to name resolution and module imports, by relocating definitions in the first language closer to their references and appropriately reordering elements. This allows the first language code to align more closely with the syntax and expectations of the second language, thereby improving both the translation success rate and the quality of the generated code. Furthermore, preprocessing preserves the semantics of macros in the first language and generates contextual metadata for subsequent processing by the AI model.

[0009] In one embodiment, as shown as "S4: Segmentation" in FIG.1, the method may include segmenting the preprocessed first code into a plurality of first units. Each of the plurality of first units may be smaller than a unit size determined based on a context window of the AI model. This allows dividing the first code into logically meaningful and optimally sized translation units (first units) based on the AI model’s context window limitations. Segmentation divides the code into optimally sized translation units to accommodate the context window limitations of the AI model. This enables the AI model to process the first code more efficiently and improves translation accuracy and compilation success rate, especially for large codebases written in the first language. Additionally, it helps prevent prompts, including information such as compilation errors, from exceeding the AI model’s context window limit, thereby accelerating convergence in error repair and contributing to the generation of high-quality code in the second language.

[0010] In one embodiment, the method may include reducing the unit size when a predetermined condition is satisfied. In one embodiment, the predetermined condition may include at least one of: a size of an input prompt to the AI model reaching an upper limit, and compilation of the second code failing a predetermined number of times. By reducing the size of the translation unit based on certain conditions, such as when the input prompt to the AI model reaches its maximum limit or when compilation fails multiple times, it is possible to prevent the AI model from exceeding its context window, thereby improving translation accuracy and the success rate of compilation.

[0011] In one embodiment, as shown as "S5: Translation" in FIG.1, the method may include translating the plurality of first units into a plurality of second units of the second code using the AI model. In one embodiment, the method may include generating first prompts, wherein each of the first prompts is for translating each of the plurality of first units into the second language and includes metadata regarding context of translation from the first code to the second code. In one embodiment, the method may include providing each of the first prompts to the AI model. By using prompts that include metadata corresponding to each translation unit, the AI model can prevent loss of context across first units, thereby improving the accuracy and consistency of translation. As a result, common compilation errors such as name resolution mismatches are reduced, ultimately enhancing the quality of the second code in the second language.

[0012] In one embodiment, the metadata may include metadata regarding a definition and / or a position of an element of the first code. In one embodiment, the metadata may include metadata regarding a definition and / or a position of an element of the second code. In one embodiment, the metadata may include metadata regarding correspondence between an element of the first code and an element of the second code. Since very few AI models retain all prior context during sequential translation, these metadata will enable maintaining consistency of translation. By including contextual metadata, such as the definitions and positions of elements in the first and second languages, as well as their correspondences, in the prompt, the AI model can compensate for past context that is often lost during sequential translation. This improves the consistency and accuracy of code translation, significantly reduces common compilation errors such as name resolution mismatches and invalid module imports, and ultimately enhances both the quality of the final code in the second language and the success rate of compilation.

[0013] In one embodiment, as shown as "S6: Quality Check" in FIG.1, the method may include evaluating quality of one second unit of the plurality of second units. In one embodiment, the method may include generating a second prompt for refining the one second unit when the quality of the one second unit does not satisfy a predetermined criterion. In one embodiment, the method may include refining the one second unit by providing the second prompt to the AI model. Quality evaluation checks whether the second language code generated by the AI model meets predefined quality criteria, and if not, generates a prompt for refinement. This enables the AI model to iteratively improve the code, enhancing memory safety and semantic equivalence. Ultimately, it contributes to the production of high-quality, functionally equivalent, and safer code in the second language.

[0014] In one embodiment, as shown as "S7: Compile Error Correction" in FIG.1, the method may include correcting (repairing) compile errors. In one embodiment, the method may include performing compilation of at least one of the second units. In one embodiment, the method may include generating a third prompt for repairing a compilation error when the compilation fails. In one embodiment, the third prompt may include information regarding references among the plurality of second units, a log of the compilation error, and a code of a second unit identified in the log as having an error. In one embodiment, the method may include repairing the second unit having the error by providing the third prompt to the AI model. The compiled second language code (second unit) is executed, and in the event of failure, a detailed refinement prompt is provided to the AI model. This prompt includes the compilation error log, reference information among units, and the code of the unit identified as erroneous. This allows the AI model to accurately identify the cause of the error and efficiently resolve dependency issues, particularly those related to name resolution and module imports. Through this iterative feedback cycle, the system achieves a high success rate in generating high-quality, compilable second language code from large-scale first language code.

[0015] In one embodiment, as shown as "S8: Semantic Error Correction" in FIG.1, the method may include correcting (repairing) semantic errors. In one embodiment, the method may include running a test case both on the first code and the second code. In one embodiment, the method may include comparing results of the test case on the first code and the second code. In one embodiment, the method may include generating a fourth prompt for repairing the second code based on the results. In one embodiment, the method may include repairing the second code by providing the fourth prompt to the AI model. By executing test cases on both the first language code and the second language code and comparing the results, semantic inconsistencies and runtime errors in the translated second language code can be identified. Based on these comparison results, a prompt is generated for the AI model, including error logs and execution flow information, to guide corrections. This allows the AI model to efficiently detect and fix functional issues. Through this feedback-driven, iterative refinement process, the system ultimately achieves high-quality second language code that is functionally equivalent to the original first language code.

[0016] FIG. 2 illustrates a schematic block diagram of the translation system 100. As shown in FIG.2, the translation system 100 may include a preprocessing module 201, a segmenting module 202, a translating module 203, a quality checking module 204, a compile error correction module 205, a semantic error correction module 206, an AI Model 207, a parsing module 208, and / or a metadata database (DB) 209.

[0017] As shown in FIG. 2, the preprocessing module 201 may include a merging module 201a, a reordering module 201b, and / or a macro-handling module 201c. These components are merely illustrative examples, and the preprocessing module 201 may further include other modules as needed, depending on the characteristics of the source code and the requirements of subsequent processing stages.

[0018] The Merging Module 201a may merge multiple elements of the first code. These elements may have a reference relationship, meaning one element refers to another. Specifically, Merging Module 201a may merge a first element of the first code with a second element of the first code that is referenced by the first element. This process facilitates the generation of more accurate and compilable second code by allowing the AI Model 207 to reference both declarations and definitions within its context window. Additionally, if the target language (e.g., Rust) is designed such that definitions and declarations do not need to be in separate files, the translated code can be directly treated as the source of that language's module.

[0019] For example, in the C programming language, it is common for declarations (header files) and definitions (source files) to be separate. Header files may contain declarations of function names and types, while source files may describe the actual definitions and implementations. In contrast, for example, in the Rust programming language, modules are imported using the "use" keyword, and both declarations and definitions of functions and variables are made within a single module file. Merging Module 201a can reduce inconveniences that arise when the source language and target language differ in how functions and types are referenced and defined among code elements.

[0020] Specifically, Merging Module 201a may perform merging according to the following procedure. Firstly, Merging Module 201a may detect function and type declarations and definitions in the first code using a predetermined tool (e.g., ctags). Additionally, Merging Module 201a may detect macro variables and macro functions in the first code using a custom parser. Secondly, Merging Module 201a may copy the content of the referenced element (e.g., an included file) into the referencing element (e.g., a file containing a #include directive) and merge them. Thirdly, Merging Module 201a may adjust the namespaces of static variables and functions to be unique during the merging process, thereby avoiding conflicts.

[0021] Reordering Module 201b may reorder multiple elements of the first code in topological order. The boundaries of each element (e.g., function definitions, structure definitions, macros, conditional compilations, etc.) may be detected, for example, by prior analysis of the first code. Multiple elements subject to reordering in topological order may, for example, have a reference relationship. For example, if a first element of the first code refers to a second element, Reordering Module 201b may reorder the first and second elements such that the referenced second element appears before the referencing first element. Topological order may also be referred to as "Definition-Ordered Conversion Policy".

[0022] In translating code from a first language to a second language, AI Model 207 may infer code in the second language from declarations in the first language. This can lead to compilation errors, such as name resolution issues or attempts to import non-existent modules, because the actual definitions are not referenced. For instance, in the case of C to Rust translation, there is a challenge where AI Model 207 tends to misinterpret definitions when they are distant from their references, due to significant differences in how and where macros, functions, and modules are defined. Reordering Module 201b can reduce the number of compilation errors caused by referencing undefined or unknown elements, and it increases the likelihood of AI Model 207 correctly recognizing definitions based on the current prompt.

[0023] The Macro-Handling Module 201c may retain macro definitions and functions of the first code as they are for translation, without expanding them. Specifically, Macro-Handling Module 201c may perform predetermined processing on macros. Macro-Handling Module 201c may delete macro definitions from the first code. Furthermore, Macro-Handling Module 201c may enable functions corresponding to the deleted definitions in a configuration file of the second code.

[0024] Macro-Handling Module 201c enables AI Model 207 to semantically correctly maintain macros of the first code as translated second code. For example, C language macros have a syntax different from C itself and are processed by a preprocessor rather than a compiler. Conventional rule-based translation tools expand macros into C language before translation, which causes constants and functions defined in macros to lose their original names, reducing code readability. Additionally, if #ifdef exists, semantic differences may arise depending on the environment, and expanding all macros into C could lead to semantic discrepancies. In contrast, AI Model 207 may have the ability to interpret the meaning of macros and convert them into appropriate Rust code while preserving their original names.

[0025] In the case of C to Rust translation, Macro-Handling Module 201c may replace predetermined C language macros with predetermined Rust attributes. For instance, Macro-Handling Module 201c may replace macros like #ifdef used for conditional compilation in C code with Rust's cfg attribute. In the C language, macros are often defined within the source code using #define. In contrast, in Rust, the cfg attribute is declared within the source code, but its settings (enabled / disabled) are typically managed centrally in the Cargo.toml file, build scripts, or command-line options. Macro-Handling Module 201c may detect conditional macros such as #ifdef, #ifndef, #if defined, and #if !defined, and store them in a predetermined storage as convertible to Rust's cfg attribute. Furthermore, Macro-Handling Module 201c may delete the definitions of these conditional macros from the C code. Additionally, Macro-Handling Module 201c may enable (define) functionalities corresponding to C code macros within a build script (build.rs). Macro-Handling Module 201c may use AI Model 207 to determine where macros should be defined in Rust code (e.g., Cargo.toml, build.rs, lib.rs, or individual module files). The analysis results may be utilized in the translation process.

[0026] Referring to Figure 3(A) and Figure 3(B), an example of converting C language conditional compilation macros into Rust's cfg attributes will be explained. Figure 3(A) shows an example of typical C language conditional compilation code. In the code shown in Figure 3(A), preprocessor directives "#ifdef FEATURE_X", "#else", and "#endif" are used, indicating that different implementations of the "featureFunction()" function are selected depending on whether the macro "FEATURE_X" is defined or not. In C language, such macros are processed by a preprocessor before compilation. Figure 3(B) shows an example of Rust language code converted from the C language conditional compilation shown in Figure 3(A). As shown in Figure 3(B), the C language macro "#ifdef" is replaced with Rust's attribute #[cfg(feature="feature_x")]. Similarly, the C language macro "#else" is replaced with the attribute #[cfg(not(feature="feature_x"))]. This allows the appropriate implementation of the "feature_function()" function to be selected via Rust's build system (typically configured in the Cargo.toml file), depending on whether a specific feature is enabled. Unlike conventional rule-based approaches that simply expand C language macros, this conversion leverages AI Model 207's ability to interpret the meaning of macros and convert them into appropriate Rust code while preserving their original names. This method can improve the readability of the converted Rust code.

[0027] The conversion by Macro-Handling Module 201c enables the translated second code (Rust code, etc.) to support a single codebase without managing multiple versions for different configurations. In this way, Macro-Handling Module 201c allows the meaning and functionality of the first code's macros to be accurately preserved in the second code by not expanding macros and by leveraging the interpretive capabilities of AI Model 207 and the settings of the second code (such as Rust's cfg attributes). This can improve the compilation success rate of the second code translated from the first code.

[0028] Segmenting Module 202 may divide the first code into a plurality of first units. Here, Segmenting Module 202 may divide the first code such that each of the plurality of first units is smaller than a predetermined unit size. In this disclosure, "unit size" may be the upper limit of the size of each first unit obtained by Segmenting Module 202 dividing the first code. The unit size may be determined based on the context window of AI Model 207. For example, the unit size may be determined by multiplying the context window of AI Model 207 by a predetermined ratio. Each first unit is a unit subject to translation and may also be referred to as a "translation unit."

[0029] Segmenting Module 202 may divide the first code at logically meaningful boundaries. This can preserve the semantics (meaning) of the code and improve translation efficiency. The division boundaries may be semantically cohesive units, such as function or structure definitions, macros, or conditional compilation blocks. Specifically, for example, Segmenting Module 202 may perform division such that the entire conditional compilation block from #ifdef to #endif is included in a single translation unit. Furthermore, to prevent repeated compilation errors caused by AI Model 207 failing to find corresponding code across separate units, Segmenting Module 202 may perform division such that functions with circular dependencies are included within the same translation unit.

[0030] The optimal segment size differs depending on the type of AI Model 207 and the complexity of the first code (e.g., C language code). Therefore, Segmenting Module 202 may dynamically adjust the unit size. For example, Segmenting Module 202 may adjust the unit size based on the number of times the second code's compilation has failed. Segmenting Module 202 may, for instance, reduce the unit size if the number of compilation failures of the second code reaches a predetermined threshold (e.g., 10 times). In this case, Segmenting Module 202 may reduce the unit size by a predetermined percentage (e.g., 50%) of the current unit size. Additionally, Segmenting Module 202 may reduce the unit size if the size of the input prompt to AI Model 207 reaches its limit during the translation of the first code to the second code or during the repair of the second code. In this case, Segmenting Module 202 may reduce the unit size to a predetermined percentage (e.g., one-eighth) of the total lines of the first code.

[0031] Translating Module 203 may execute the translation by generating a prompt (translation prompt, first prompt) for translating each translation unit of the first code into the second language and providing the prompt to AI Model 207. Figure 4 shows an example of a prompt for translating each translation unit when translating C language code into Rust.

[0032] A translation prompt may include an instruction to translate the first code's translation unit into the second language. For example, in the case shown in Figure 4, the sentence "Translate the following C code into Rust by strictly following the rules below." is an instruction to translate the C code, which is a translation unit, into Rust according to predetermined rules.

[0033] A translation prompt may, for example, include contextual metadata. The contextual metadata may be extracted from Metadata DB 209. The contextual metadata may include, for example, at least one of metadata regarding the definition and / or position of an element of the first code, metadata regarding the definition and / or position of an element of the second code, and metadata regarding the correspondence between an element of the first code and an element of the second code. This enables the compensation of context that may be lost between multiple translation units of the first code when translating from the first code to the second code.

[0034] In the example shown in Figure 4, "pub fn quadtree_search(tree: &Quadtree, x: f64, y: f64) -> Option<&QuadtreePoint> (defined in crate::quadtree_0)" is the function signature of the previously translated function "quadtree_search". Similarly, "pub fn quadtree_node_isleaf(node: &QuadtreeNode) -> bool (defined in crate::quadtree_0)" is the function signature of the previously translated function "quadtree_node_isleaf". In this way, the translation prompt may include information such as function signatures and type definitions of previously compiled Rust code as contextual metadata. This helps AI Model 207 correctly recognize the definitions of functions and variables in external modules referenced by the C code to be translated, resolving common compilation errors such as name resolution issues and importing non-existent modules.

[0035] The translation prompt may include translation rules. The prompt may include the code of the translation unit to be translated. In the example shown in Figure 4, "Declare all items (structures, enums, functions, constants, etc.) using pub (public) to allow importing." indicates a translation rule to declare all elements (structures, enums, functions, constants, etc.) as pub (public). This enables the translated Rust code to be imported from other modules. Also, in the example shown in Figure 4, "Avoid unsafe in external function calls by using safe equivalents from Rust’s standard libraries or crates." indicates a translation rule to avoid the use of unsafe as much as possible in external function calls and to utilize safe equivalent functions from Rust's standard libraries or crates. AI Model 207 tends to frequently use the unsafe keyword without this rule. By applying this rule, AI Model 207 is more likely to meaningfully interpret the original C code and convert it into safer Rust code.

[0036] The translation prompt may include an instruction to split the response into multiple parts if it exceeds the specified limit (number of tokens or lines). In the example of Figure 4, "##Split Response / If the answer exceeds the token size ..." is the instruction for splitting. This instruction is to split the response into multiple parts of a predetermined size (which may be specified by the number of lines) if the response exceeds the specified number of tokens. This makes it possible to handle AI Model 207's output token size limitations.

[0037] The translation prompt may include the code of the translation unit to be translated. In the example shown in Figure 4, "##C source code:[Paste the C fragment code]" indicates the location where the C code fragment to be translated is included. Furthermore, the translation prompt may include an instruction not to add translations outside the scope of the provided translation unit, even if it recognizes at least some other parts of the first code.

[0038] Quality Checking Module 204 may perform a process to check the quality of the second units, which are the result of translating each of the plurality of first units of the first code in the first language into the second language. The quality may be evaluated from perspectives such as code safety and style.

[0039] Firstly, Quality Checking Module 204 may evaluate the quality of the second unit. For example, Quality Checking Module 204 may determine whether the second unit satisfies multiple flags. The translation and refinement process may be repeated until all of these flags are evaluated as "true". The multiple flags may include, for example, the following: -"refined_completed": Indicates that the Rust code conforms to Rust style and that adherence to safety and design principles has been achieved. -"current_block_complete": Indicates that the functionality of the original C code is fully implemented in the Rust code. -"no_omission": Indicates that the Rust code is output without omissions and can be executed independently.

[0040] Secondly, if the quality of the second unit does not satisfy a predetermined criterion, the second unit may be refined using AI Model 207. The prompt for refining the second unit may include the following: -The translated second code. -Refinement guidelines. -Self-evaluation rules.

[0041] In the case of translating from C language to Rust, the refinement guidelines may include, for example, the following rules: -Deletion of unsafe block usage. -Elimination of raw pointers. -Avoidance of static mutation for global variables.

[0042] Error Correction Module 205 may perform the correction of compilation errors for the second code, which includes at least one second unit. Compilation errors may occur when at least a part of the second code generated by AI Model 207 violates the syntax rules of the second language.

[0043] Error Correction Module 205 may attempt to compile at least one second unit translated into the second language by AI Model 207. In particular, Error Correction Module 205 may attempt to compile the code consisting of all translated second units. If compilation fails, Error Correction Module 205 may record the compilation error and include its raw compilation error log directly in the prompt to AI Model 207. AI Model 207 may be configured to understand raw messages directly. The prompt may include an instruction to interpret the error message and correct the second code. Error Correction Module 205 may repeat these processes until compilation succeeds.

[0044] Correcting an error in one second unit (e.g., a Rust file) may sometimes require corrections to previously translated second units or configuration files (e.g., Cargo.toml). Due to the limited context window size, it is difficult to repair all relevant files at once. Error Correction Module 205 may include information regarding references among the plurality of second units (e.g., the pathname of each second unit) in the prompt. Error Correction Module 205 may identify the file with the error from the error log and request AI Model 207 to identify the files that need correction. Subsequently, Error Correction Module 205 may also correct past second units and configuration files by inputting a correction request prompt, including the content of each second unit requiring correction, to AI Model 207.

[0045] FIG. 5 is an example of a prompt given to AI Model 207 to correct compilation errors when translating from C language to Rust.

[0046] The prompt shown in FIG. 5 includes the sentence "Please repair the following code in a Rust program." as an instruction for correcting compilation errors.

[0047] As shown in FIG. 5, the prompt includes the explanation "The definitions of the elements used have been provided in other modules as follows." Following this explanation, the prompt also includes signatures of elements defined in other modules (units) (e.g., pub fn quadtree_search(tree: &Quadtree, x: f64, y: f64) -> Option<&QuadtreePoint>). This enables AI Model 207 to repair previously translated units and configuration files in order to correct errors in the current translation unit. Since AI Model 207 has a limited context window size, it is difficult to repair all relevant files at once. By including the pathname of the Rust file as metadata in this section, AI Model 207 can identify which files need to be repaired based on the path information of the erroneous files included in the compilation error log. This allows AI Model 207 to send repair requests for individual files, including the contents of those files, thereby ensuring the overall consistency of the program while repairing past translation units and configuration files.

[0048] During the correction of compilation errors, only the context metadata of the translated Rust code may be provided to AI Model 207, and the provision of C code metadata may be omitted. This is because if AI Model 207 knows that the Rust code was translated from C, it tends to revert to using unsafe C functions or external C function calls. By providing only the context metadata of the translated Rust code and not the C code metadata, AI Model 207 can focus on performing the repair entirely within the Rust ecosystem.

[0049] "##Rust code:" shown in FIG. 5 indicates that the entire content of the Rust code file to be repaired is included in the prompt. "##Compilation Error:" shown in FIG. 5 indicates that the raw, unprocessed compilation error log is included in the prompt.

[0050] Furthermore, the prompt may include the instruction "please resolve this error." This enables AI Model 207 to provide a more comprehensive solution that leads to successful compilation, rather than just superficially correcting the line indicated by the error log. By using this prompt, AI Model 207 is instructed to provide the start and end lines that need repair, along with the new code, in JSON format, which enables programmatic repair processing. This repair process may be repeated until compilation succeeds. Additionally, past repair conversations may be retained as memory to prevent repeating the same errors, and memory may be cleared between translation units.

[0051] The Semantic Correction Module 206 may repair semantic errors in the second code. Semantic errors may occur even if the second code compiles successfully, if its behavior differs from the original code or if it causes issues like panics during runtime.

[0052] The Semantic Correction Module 206 may perform repairs by following these steps: -First, the Semantic Correction Module 206 may generate and execute test cases based on the first code and the corresponding second code, obtaining their respective program outputs. -At this time, the Semantic Correction Module 206 may individually build the first code and the second code, and use a set of shell scripts (e.g., a build script for the second code, a build script for the first code, a test script, an integration script) to automate the execution of each program. -Additionally, the Foreign Function Interface (FFI) may be used to call functions of the second code from the program of the first code.

[0053] The Semantic Correction Module 206 may compare function call stacks, input values, and output values obtained from each test case, and determine that a semantic mismatch exists if there are differences. The Semantic Correction Module 206 may, in particular, use the consistency of input and output as a criterion for semantic equivalence, focusing on the program's entry point function rather than all functions. This may be done considering that the function structures in the first and second languages do not necessarily have a one-to-one correspondence. For standalone programs, end-to-end operational verification may also be performed.

[0054] If a semantic discrepancy is identified, the Semantic Correction Module 206 may provide a prompt to AI Model 207 (or LLM) that includes the code snippet where the discrepancy occurred and information about the differences in execution results. This prompt may also include information regarding the function execution flow and the corresponding part of the original code (first code). Based on this information, AI Model 207 may generate step-by-step correction proposals for each test case, while also presenting the reasons for the corrections. The Semantic Correction Module 206 may then modify the second code according to these correction proposals.

[0055] The AI Model 207 forms the core of the process for translating code written in a first language into code written in a second language, and has the following functions. The AI Model 207 may be a Large Language Model (LLM). The type of LLM is not particularly limited, but may include, for example, Claude, ChatGPT, and Gemini.

[0056] The AI Model 207 may have the function of translating the first code written in the first language (e.g., C language) into the second code written in the second language (e.g., Rust). The AI Model 207 may have the function of translating each of the plurality of first units obtained by segmenting the first code into the second code. Additionally, the AI Model 207 may have the function of determining whether the translated second language code conforms to the grammar, safety, and design principles of that language (e.g., Rust) and faithfully reproduces the functionality of the original first language code (e.g., C), and iteratively refining it until it meets quality standards. Furthermore, if the compilation of the second language code fails, the AI Model 207 may have the function of directly interpreting the output compilation error log and generating correction proposals. The AI Model 207 also includes a function to retain past repair history to prevent the recurrence of the same errors. Moreover, even if the second language code successfully compiles, if it does not perform the equivalent function to the original first language code, the AI Model 207 may have the function of identifying and repairing semantic mismatches. The AI Model 207 may also generate and, if necessary, update contextual metadata regarding the definitions and positional information of elements contained in each code unit of the first and second languages, as well as the correspondence between both languages.

[0057] Figure 6 shows an example of a prompt for mapping the correspondence between elements of C code and elements of Rust code when translating from C language to Rust.

[0058] Each time a Rust translation unit is successfully compiled, AI Model 207 may use this prompt to generate and update the correspondence between the original C translation unit and the translated Rust translation unit. This allows for continuous recording of which specific parts of the C code (e.g., functions, variables) have been translated into which parts of the Rust code. This mapping is also used to keep the overall translation context of the program up to date. This enables subsequent translation units to recognize definitions from previously compiled Rust code.

[0059] In Rust, naming conventions such as snake_case are used for function and variable names, and AI Model 207 may change the original C names to match these naming conventions when translating C code to Rust. Tracking such name changes has been difficult with conventional static analysis. However, in this embodiment, by having the AI Model 207 itself generate this correspondence (as part of the translation process), accurate mapping becomes possible.

[0060] The prompt in Figure 6 may provide the following information and instructions to AI Model 207. The prompt in Figure 6 includes the instruction: "The following Rust code has been converted from the original C code. The original C code has the following JSON-formatted metadata for each element named the value in "element" enclosed by the start line (start_line) and end line (end_line).". The prompt in Figure 6 also includes the specific instruction: "Compare the original C code with the converted Rust code, add a new key "rust_code" to the metadata of each element block in the JSON format of the original C code, and insert the converted code for each element.".

[0061] In the prompt of Figure 6, "## Rust code:" is the field where fragments of the converted Rust code can be pasted. "## Original C code:" is the field where fragments of the original C code can be pasted. In "## JSON-formatted metadata for the C code" within Figure 6's prompt, JSON data including C code elements (e.g., quadtree_walk, node_contains) along with their start_line and end_line is provided. Each element has a placeholder, "rust_code": "(Please insert here)," where the AI Model 207 is prompted to insert the corresponding Rust code.

[0062] Parsing Module 208 may extract contextual metadata by parsing multiple translation units (first units) generated by the segmentation of the first code by Segmenting Module 202. As contextual metadata, Parsing Module 208 may extract definitions and call sites of code elements in the first code. Additionally, Parsing Module 208 may classify the code elements contained in each translation unit. For example, in the case of C language, the classification may include at least one of functions, macro functions, type definitions, macro variables, variables, and others. This allows the AI Model to supplement context between translation units that would otherwise be lost when the first code is segmented into translation units. Parsing Module 208 may store the contextual metadata in a predetermined format in Metadata DB 209, for example, in JSON format.

[0063] Parsing Module 208 may extract metadata by parsing the Rust code (second code) after it has been compiled. As metadata, Parsing Module 208 may extract code elements contained in the Rust code, such as function signatures and type definitions. The extracted code elements may include functions, macro functions, type definitions, macro variables, and variables. Additionally, Parsing Module 208 may identify information regarding the definition locations and source files of elements used in each Rust module file. Such Rust code metadata may be generated after each translation unit of C code has been translated into Rust code and successfully compiled. The generated metadata may be utilized as supplementary context during the translation of subsequent translation units or during the repair of compilation errors. In particular, Parsing Module 208 may incrementally update the metadata so that subsequent translation units can recognize elements defined in previously compiled units. Furthermore, Parsing Module 208 may store the generated metadata in a predetermined format in Metadata DB 209, for example, in JSON format. Additionally, if a compilation error occurs, Parsing Module 208 can include this metadata in the repair prompt, along with reference information and the code of the erroneous translation unit.

[0064] Metadata DB 209 is a database that stores metadata related to the first code (C language) and the second code (Rust), and may include at least one of the following pieces of information: -Metadata regarding the definition and / or position of elements of the first code. -Metadata regarding the definition and / or position of elements of the second code. -Metadata regarding the correspondence between elements of the first code and elements of the second code.

[0065] Metadata regarding the definition and / or position of elements of the first code may be generated, for example, by parsing the first units into which the first code was segmented. This metadata may record, in JSON format, the definition and location (e.g., start_line, end_line) within the source code for each code element (functions, macro functions, type definitions, macro variables, variables, and other elements).

[0066] Metadata regarding the definition and / or position of elements of the second code may be generated by parsing the successfully compiled second code. This metadata may be used as supplementary information, especially to enable elements like functions defined in other modules to be referenced in subsequent translation units. Additionally, this metadata may include path information for the Rust files to be repaired during compilation error correction.

[0067] Metadata regarding the correspondence between elements of the first code and elements of the second code may be mapping information generated and updated upon successful compilation of the second unit. It may record which element in the second code each element (e.g., function names, variable names) in the first code corresponds to. This mapping may be used to maintain consistent references even when AI Model 207 renames elements based on naming conventions (e.g., snake_case).

[0068] Translation System 100 may iteratively correct compilation errors and semantic errors during the translation process from the first code to the second code, ultimately generating successfully compiled and functionally equivalent second code. This process by Translation System 100 may be referred to as a feedback-driven code repair algorithm.

[0069] Figure 7 illustrates an example of the code for the feedback-driven code repair algorithm in C-to-Rust translation. In this code, "C_UNIT1, C_UNIT2, ..., C_UNITn" represents a list of C code translation units, and "DepC:" refers to the C code's metadata. Additionally, "S = {R_UNIT0, R_UNIT1, R_UNIT2, ..., R_UNITn+α}" is the set of translated and successfully compiled Rust programs.

[0070] Lines 1-3 constitute the initialization process. During this initialization, S is initialized as an empty set, which will hold the entire translated Rust program. Furthermore, the maximum number of compilation attempts, "COMPILE_MAX," is set to "N," and the maximum number of repair attempts, "REPAIR_MAX," is set to "N′".

[0071] Lines 4-28 represent the main loop for sequential processing of C translation units. This main loop sequentially processes each C translation unit (C_UNITi), performing conversion to Rust code, quality checking, and compilation error repair.

[0072] Lines 5-6 describe the build script generation process. For the first unit (i = 0), R_UNIT0 (the Rust build script) is generated based on the C metadata (DepC).

[0073] Lines 7-8 outline the process of translating C code to Rust. Each C unit (C_UNITi) other than the initial unit is passed to AI Model 207 (LLM) for translation into Rust code (R_UNITi). During this process, C metadata (DepC) is provided as context. The translation prompt includes translation rules (e.g., declaring all elements as pub and avoiding the use of unsafe), contextual metadata, and instructions for splitting the response.

[0074] Lines 9-11 detail the quality check and refinement process. The translated Rust code undergoes iterative refinement (refine_quality) by AI Model 207 (LLM) until all specific quality evaluation flags are set to true. These flags include: -"refined_completed": Indicates that the Rust code has been refined to proper Rust style, achieving compliance with safety and design principles. -"current_block_complete": Indicates that the functionality of the original C segment is fully implemented in the Rust code. -"no_omission": Indicates that there are no omissions in the output Rust code, making it executable independently.

[0075] Lines 13-24 represent the compilation and repair loop. In this loop, the repair process is repeated as long as compilation errors (compile_error) exist and the number of compilation attempts (compile_count) has not reached the maximum allowed (COMPILE_MAX). First, in Line 17, S (the current Rust program) is parsed, and Rust metadata (DepR) is generated; this metadata is subsequently used as dependency information in repair prompts. Next, in Line 18, AI Model 207 (LLM) is requested to perform repairs, and a modification set (M) is obtained. The prompt provided to AI Model 207 includes the entire Rust code, the compilation error log, directory structure, and dependencies (definitions of elements in other modules). AI Model 207 can directly interpret the error messages to make corrections. Subsequently, in Lines 19 to 21, the modifications proposed by AI Model 207 are applied to the Rust program (S). This method supports modifications spanning multiple files and configuration files (e.g., Cargo.toml). Finally, in Line 22, the modified Rust program is recompiled, and the presence of errors is checked.

[0076] Lines 25 to 27 describe the C code to Rust code mapping process. When each Rust translation unit successfully compiles, the AI Model 207 generates the correspondence between that Rust unit and the original C unit, updating the C metadata (DepC). This process maintains an up-to-date conversion context between the C and Rust code.

[0077] Lines 29 to 37 detail the semantic repair loop. This iterative process continues as long as compilation or semantic errors exist and the maximum repair attempts (REPAIR_MAX) have not been reached. At Line 30, AI Model 207 is prompted for repair, and a modification set (M) is obtained. This prompt includes semantic errors derived from test case execution results (e.g., function execution flow information for both C and Rust code), in addition to compilation errors. At Lines 31 to 33, the modifications proposed by AI Model 207 are applied to the Rust program (S). At Lines 34 to 35, the modified program is re-compiled, and test cases are executed to check for semantic errors. The method validates semantic correctness by running tests on both the C and Rust programs and comparing their results. Through this iterative feedback process, AI Model 207 progressively corrects the test cases, aiming to achieve a test pass rate at or above a predefined threshold (e.g., 100%).

[0078] Finally, at Line 38, the successfully compiled Rust program (S) that has passed all test cases is returned.

[0079] FIG. 8 illustrates components of a translation system 100 according to a particular embodiment. In system 100, one or more user(s) may utilize a user device (e.g., a user device of a collection of user device(s) 204 to access a user interface accessible through an application 206 running on the user device(s) 204 via one or more network(s) 208. In some aspects, the application 206 operating on the user device(s) 204 may be hosted, managed, and / or provided by a computing resources service or service provider, such as by utilizing one or more service provider computer(s) 210.

[0080] In some examples, the network(s) 208 may include any one or a combination of many different types of networks, such as cable networks, the Internet, wireless networks, cellular networks, and other private and / or public networks. While the illustrated example represents the user(s) accessing application functionality over the network(s) 208, the described techniques may equally apply in instances where the user(s) interact with the service provider computer(s) 210 via the one or more user device(s) 204 over a landline phone, via a kiosk, or in any other suitable manner. It should be appreciated that the described techniques may apply in other client / server arrangements, as well as in non-client / server arrangements (e.g., locally stored applications, etc.). Additionally, in some embodiments, the translation engine 244, discussed further below in more detail, may operate in whole or in part on the user device(s) 204. Thus, in some embodiments, the user(s) may access the functionality of the translation engine 244 directly through the user device(s) 204 and / or the service provider computer(s) 210 via user interfaces provided by the translation engine 244.

[0081] The service provider computer(s) 210, perhaps arranged in a cluster of servers or as a server farm, may host the application 206 operating on the user device(s) 204 and / or cloud-based software services. Other server architectures may also be used to host the application 206 and / or cloud-based software services. The application 206 operating on the user device(s) 204 may be capable of handling requests from the user(s) and serving, in response, various user interfaces that can be rendered at the user device(s) 204. The application 206 operating on the user device(s) 204 can present any suitable type of website that supports user interaction. The described techniques can similarly be implemented outside of the application 206, such as with other applications running on the user device(s) 204.

[0082] The user device(s) 204 may be any suitable type of computing device such as, but not limited to, a mobile phone, a hand-held scanner, a touch screen device, a smartphone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a thin-client device, a tablet PC, an electronic book (e-book) reader, etc. In some examples, the user device(s) 204 may be in communication with the service provider computer(s) 210 via the network(s) 208, or via other network connections.

[0083] In one illustrative configuration, the user device(s) 204 may include at least one memory 212 and one or more processing units (or processor(s)) 214. The processor(s) 214 may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) 214 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.

[0084] The memory 212 may store program instructions that are loadable and executable on the processor(s) 214, as well as data generated during the execution of these programs. Depending on the configuration and type of user computing device, the memory 212 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). The user device(s) 204 may also include additional removable storage and / or non-removable storage including, but not limited to, magnetic storage, optical disks, and / or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some implementations, the memory 212 may include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM.

[0085] Turning to the contents of the memory 212 in more detail, the memory 212 may include an operating system 216, one or more data stores 215, and one or more application programs, modules, or services provided via the application 206 (e.g., a web browser application, a shopping application associated with an online retailer, etc.). The application 206 may be configured to receive, store, and / or display a network page or other interfaces for interacting with the service provider computer(s) 210. The application 206 may include any suitable functionality related to code translations and / or any suitable functionality provided by the service provider computer(s) 210. Additionally, the memory 212 may store access credentials and / or other user information such as, but not limited to, user IDs, passwords, and / or other user information. In some examples, the user information may include information for authenticating an account access request such as, but not limited to, a device ID, a cookie, an IP address, a location, or the like.

[0086] The user device(s) 204 may also contain communications connection(s) 218 that allow the user device(s) 204 to communicate with a stored database, another computing device or server (e.g., the service provider computer(s) 210), user terminals and / or other devices on the network(s) 208. The user device(s) 204 may also include I / O device(s) 220, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.

[0087] In some aspects, the service provider computer(s) 210 may also be any suitable type of computing devices such as, but not limited to, a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a thin-client device, a tablet PC, etc. Additionally, it should be noted that in some embodiments, the service provider computer(s) 210 are executed by one more virtual machines implemented in a hosted computing environment. The hosted computing environment may include one or more rapidly provisioned and released computing resources, which computing resources may include computing, networking and / or storage devices. A hosted computing environment may also be referred to as a cloud-computing environment. In some examples, the service provider computer(s) 210 may be in communication with the user device(s) 204 and / or other service providers via the network(s) 208 or via other network connections. The service provider computer(s) 210 may include one or more servers, perhaps arranged in a cluster, as a server farm, or as individual servers not associated with one another. These servers may be configured to implement the functionality described herein as part of an integrated, distributed computing environment.

[0088] In one illustrative configuration, the service provider computer(s) 210 may include at least one memory 228 and one or more processing units (or processor(s)) 230. The processor(s) 230 may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) 230 may include computer-executable or machine-executable instructions written in any suitable programming language to perform the various functions described.

[0089] The memory 228 may store program instructions that are loadable and executable on the processor(s) 230, as well as data generated during the execution of these programs. Depending on the configuration and type of service provider computer(s) 210, the memory 228 may be volatile (such as RAM) and / or non-volatile (such as ROM, flash memory, etc.). The service provider computer(s) 210 or servers may also include additional storage 232, which may include removable storage and / or non-removable storage. The additional storage 232 may include, but is not limited to, magnetic storage, optical disks and / or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some implementations, the memory 228 may include multiple different types of memory, such as SRAM, DRAM, or ROM.

[0090] The memory 228, the additional storage 232, both removable and non-removable, are all examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. The memory 228 and the additional storage 232 are all examples of computer storage media. Additional types of computer storage media that may be present in the service provider computer(s) 210 may include, but are not limited to, PRAM, SRAM, DRAM, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the service provider computer(s) 210. Combinations of any of the above should also be included within the scope of computer-readable media.

[0091] Alternatively, computer-readable communication media may include computer-readable instructions, program modules, or other data transmitted within a data signal, such as a carrier wave, or other transmission. However, as used herein, computer-readable storage media does not include computer-readable communication media.

[0092] The service provider computer(s) 210 may also contain communications connection(s) 634 that allow the service provider computer(s) 210 to communicate with a stored database, another computing device or server, user terminals and / or other devices on the network(s) 208. The service provider computer(s) 210 may also include I / O device(s) 236, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc.

[0093] Turning to the contents of the memory 228 in more detail, the memory 228 may include an operating system 240, one or more data stores 242, and / or one or more application programs, modules, or services for implementing the features disclosed herein, such as the features provided by the translation engine 244. The translation engine 244 may be configured to perform the operations discussed above in connection with FIGS. 1-7.

[0094] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the disclosure as set forth in the claims.

[0095] Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the disclosure to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure, as defined in the appended claims.

[0096] The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein and each separate value is incorporated into the specification as if it were individually recited herein. All Methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments of the disclosure and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0097] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

[0098] Preferred embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the disclosure. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate and the inventors intend for the disclosure to be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0099] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. A computer-implemented method for translating a first code written in a first language into a second code written in a second language using an AI model, the method comprising the steps of: preprocessing the first code; segmenting the preprocessed first code into a plurality of first units, wherein each of the plurality of first units is smaller than a unit size determined based on a context window of the AI model; and translating the plurality of first units into a plurality of second units of the second code by providing each of first prompts to the AI model, wherein each of the first prompts is for translating each of the plurality of first units into the second language and includes metadata regarding context of translation from the first code to the second code.

2. The metadata includes at least one of the following: metadata regarding a definition and / or a position of an element of the first code; metadata regarding a definition and / or a position of an element of the second code; and metadata regarding correspondence between an element of the first code and an element of the second code.

3. The method according to claim 1, further comprising the steps of: evaluating quality of one second unit of the plurality of second units; and refining the one second unit by providing a second prompt to the LLM, wherein the second prompt is for refining the one second unit when the quality of the one second unit does not satisfy a predetermined criterion.

4. The method according to claim 3, further comprising the steps of: performing compilation of at least one of the second units; and repairing the second unit having the error by providing a third prompt to the LLM, wherein the third prompt includes: information regarding references among the plurality of second units, a log of the compilation error, and a code of a second unit identified in the log as having an error.

5. The method according to claim 1, further comprising the steps of: running a test case both on the first code and the second code; comparing results of the test case on the first code and the second code; and repairing the second code by providing a fourth prompt to the AI model, wherein the fourth prompt is for repairing the second code based on the results.

6. The method according to claim 1, wherein the preprocessing step includes the step of merging a first element of the first code with a second element of the first code that is referenced by the first element.

7. The method according to claim 1, wherein the preprocessing step includes the step of reordering a plurality of elements of the first code in topological order.

8. The method according to claim 1, wherein the preprocessing step includes the step of removing a definition of a macro from the first code, and further comprises the step of enabling a function corresponding to the definition in a configuration file of the second code.

9. The method according to claim 1, further comprising the step of reducing the unit size when a predetermined condition is satisfied.

10. The method according to claim 8, wherein the predetermined condition includes at least one of: a size of input prompt to the LLM reaching an upper limit; and compilation of the second code failing a predetermined number of times.

11. A system for translating a first code written in a first language into a second code written in a second language using an AI model, the system comprising: a preprocessing module for preprocessing the first code; a segmenting module for segmenting the preprocessed first code into a plurality of first units, wherein each of the plurality of first units is smaller than a unit size determined based on a context window of the AI model; and translating the plurality of first units into a plurality of second units of the second code by providing each of first prompts to the AI model, wherein each of the first prompts is for translating each of the plurality of first units into the second language and includes metadata regarding context of translation from the first code to the second code.

Images