Two-stage conversion compiling method and device of discrete simulation language, storage medium and electronic equipment

Abstract

The application relates to the technical field of computer language compilation, and provides a two-stage conversion and compilation method and device of a discrete simulation language, a storage medium and electronic equipment, which separate syntax structure recognition and semantic analysis, build an abstract syntax tree or an intermediate representation which completely and faithfully represents a source code form structure in a first stage, and then perform semantic binding, type derivation and type consistency checking based on complete context information in a second stage after the complete source code is scanned and a symbol table is established. In this way, the structure information of a forward reference can be retained without immediate error reporting, and delayed binding is performed after declaration information is obtained subsequently, so that the accuracy, completeness and maintainability of complex expression analysis are improved. The embodiment of the application can effectively process forward references and overcome the technical problems of limited context-sensitive syntax structure processing capability, insufficient type derivation and semantic analysis accuracy and limited generated code quality.

Description

Technical Field

[0001] This invention belongs to the field of computer language compilation technology, and particularly relates to a two-stage conversion compilation method, apparatus, storage medium and electronic device for discrete simulation languages. Background Technology

[0002] In the implementation of compiler tools for discrete event simulation languages, different technical approaches exist depending on the chosen architecture. Mainstream compilers for general-purpose programming languages ​​generally employ a multi-stage architecture, where the parser first generates a complete abstract syntax tree, followed by independent traversal for semantic analysis, type checking, and code generation. However, in the specific domain of discrete event simulation, to reduce implementation complexity, pursue rapid translation, or facilitate embedding into modeling environments, a significant number of compiler tools still adopt a single-stage processing approach. This approach simultaneously completes semantic analysis, type checking, and preliminary code generation during syntax parsing; that is, upon recognizing an identifier, array access, or function call, it attempts to immediately determine its declaration location, type, scope, semantic category, and corresponding target code form.

[0003] For simple expressions, single-stage processing can meet the transformation requirements to a certain extent. However, for discrete event simulation languages, the source code often contains a large number of context-sensitive structures and forward reference structures. A forward reference refers to a variable, function, array, or other identifier used in an expression that has not yet been declared at the current parsing point, but whose definition information is only given in subsequent statements, function definitions, model declarations, or global declarations in the source code. When traditional single-stage parsers encounter this situation, if they insist on immediately completing the semantic binding, they are prone to undefined identifier errors; if they allow temporary skipping, the lack of a unified data structure may lead to difficulties in subsequent binding.

[0004] On the other hand, the same syntactic form in discrete event simulation languages ​​may have different semantics in different contexts. If the parser only makes a judgment when it scans a string fragment, it is difficult to accurately distinguish these semantics, especially when the complete symbol table has not yet been established, which makes it easier to make misjudgments.

[0005] Furthermore, this single-stage processing approach can negatively impact type inference and code generation quality. Since type inference relies on various information, including variable types, array element types, function return types, parameter types, operator type rules, and the target type of the context, if this information is incomplete at the time of current syntax structure recognition, the compiler often has to adopt a conservative strategy to generate code. This conservative strategy can lead to redundant target code, inaccurate conversions, or runtime errors.

[0006] While existing technologies can mitigate these issues by introducing temporary placeholders, secondary scanning, or patch-based recording, these methods are typically tightly coupled with the core logic of a single-stage parser, lacking a unified and scalable abstraction mechanism. This results in high code coupling, poor maintainability, and requires modifications to the core compilation logic and a complete re-verification when adding new syntax support. On the other hand, directly adopting the heavyweight multi-stage architecture of a general-purpose compiler would introduce an overly complex compilation pipeline, which is inconsistent with the actual needs of discrete event simulation tools for lightweight embedding and rapid translation.

[0007] Therefore, there is an urgent need for a compilation mechanism that can effectively handle forward references and overcome the limitations of context-sensitive syntax structure processing, insufficient accuracy of type inference and semantic analysis, and limited quality of generated code, in order to solve the above-mentioned technical problems. Summary of the Invention

[0008] The purpose of this invention is to provide a two-stage conversion compilation method, apparatus, storage medium, and electronic device for discrete simulation languages, in order to solve the problems in the compilation process of discrete event simulation languages ​​in the prior art, such as the inability to effectively handle forward references, limited ability to handle context-sensitive syntax structures, insufficient accuracy of type inference and semantic analysis, and limited quality of generated code.

[0009] To achieve the above objectives, in a first aspect, this application provides a two-stage transformation compilation method for discrete simulation languages. This method replaces the traditional single-stage immediate binding process with two lightweight traversals, achieving delayed semantic binding while maintaining architectural simplicity. The method includes:

[0010] The first phase involves performing the first iteration.

[0011] Lexical preprocessing is performed on the input discrete event simulation language source code to identify identifiers, keywords, operators and constants in the source code and form a lexical stream;

[0012] Based on lexical flow, the expression in the source code is parsed to construct an abstract syntax tree or intermediate representation. In the first stage, only the formal structure and positional relationship of variable references, array accesses, function calls and compound expressions are recorded, without performing complete semantic analysis.

[0013] During the first traversal, variable declaration information, array definition information, function declaration information, and scope information are collected synchronously from the source code to construct a complete symbol table;

[0014] The second phase involves performing the second pass through the traversal.

[0015] Based on the abstract syntax tree or intermediate representation constructed in the first traversal and the complete symbol table, semantic binding, type inference and type consistency checks are performed to determine the actual semantic meaning of each syntax structure.

[0016] The corresponding target programming language code is generated based on the results of the semantic binding, type inference, and type consistency check.

[0017] Furthermore, in the first stage, the syntactic structure parsing of expressions in the source code based on the lexical flow includes:

[0018] Identify variable reference expressions, array access expressions, function call expressions, and compound expressions that contain at least two of the following syntax structures: variable reference, array access, and function call, and store the identified expressions in a structured form.

[0019] Furthermore, in the first stage, constructing the symbol table and collecting context information includes:

[0020] Collect variable declaration information and its type, collect the dimensions, size and element type of array definition information, collect the parameter list and return type of function declaration information, record scope information and forward reference relationships, and establish a mapping relationship between identifiers and semantic information.

[0021] Furthermore, in the second stage, semantic binding of the syntactic structure in the abstract syntax tree or intermediate representation includes:

[0022] For identifiers that were identified in the first stage but have not yet received declaration information at the current parsing location, their syntactic structure representation is preserved;

[0023] After scanning the complete source code and obtaining the declaration information of the identifier, the identifier is then deferredly bound to the corresponding semantic information based on the symbol table.

[0024] Furthermore, in the second stage, determining the actual semantic meaning of the grammatical structure includes:

[0025] Based on the symbol table and context information, determine the semantic meaning of the same syntactic form in different contexts, corresponding to variable references, array accesses, or function calls.

[0026] Furthermore, in the second phase, type inference and type consistency checks include:

[0027] Based on the variable type, array element type, function return type, and the type rules corresponding to the operators in the expression, determine the result type of the expression, and generate the corresponding type conversion information when type conversion is required.

[0028] Furthermore, in the second stage, generating the corresponding target programming language code includes:

[0029] Map discrete event simulation language variables to target programming language variables;

[0030] Convert array access expressions into array access expressions in the target programming language, and perform subscript offset processing on array indices;

[0031] Convert function call expressions into corresponding function call expressions in the target programming language;

[0032] Add a target programming language type conversion expression based on the type information;

[0033] Generate corresponding string processing code in the target programming language for string operations.

[0034] Secondly, this application provides a two-stage conversion and compilation apparatus for discrete simulation languages, comprising:

[0035] The lexical preprocessing module is used to perform lexical preprocessing on the input discrete event simulation language source code, identify identifiers, keywords, operators and constants, and form a lexical stream;

[0036] The first-stage parsing module is used to parse the syntactic structure of expressions in the source code based on the lexical flow, construct an abstract syntax tree or intermediate representation, and record the formal structure and positional relationships of variable references, array accesses, function calls, and compound expressions.

[0037] The symbol table construction module is used to scan the complete source code, build a symbol table including variable declaration information, array definition information, function declaration information, and scope information, and collect context information;

[0038] The second-stage semantic analysis module is used to perform semantic binding, type inference, and type consistency checks on the syntactic structure in the abstract syntax tree or intermediate representation based on the symbol table and context information.

[0039] The code generation module is used to generate corresponding target programming language code based on the analysis results of the second-stage semantic analysis module.

[0040] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0041] In another aspect, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0042] Compared with existing technologies, the two-stage conversion compilation method, apparatus, storage medium, and electronic device for discrete simulation languages ​​provided in this application offer the following advantages: This application separates syntax structure recognition and semantic analysis. In the first stage, it constructs a complete and faithful abstract syntax tree or intermediate representation of the source code's formal structure. After the complete source code is scanned and a symbol table is established, semantic binding, type inference, and type consistency checks are performed in the second stage based on complete context information. In this way, the structural information of forward references can be preserved without immediate error reporting, and delayed binding can be performed after obtaining subsequent declaration information, thereby improving the accuracy, completeness, and maintainability of complex expression parsing. Attached Figure Description

[0043] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0044] Figure 1 This is a schematic diagram of the overall process of a two-stage conversion compilation method for a discrete simulation language provided in an embodiment of this application;

[0045] Figure 2 This is a schematic diagram of a first-stage syntax structure parsing and abstract syntax tree or intermediate representation construction provided in an embodiment of this application;

[0046] Figure 3 This is a schematic diagram of the structure for symbol table construction and context information collection provided in an embodiment of this application;

[0047] Figure 4 This is a flowchart illustrating a second-stage semantic binding, type inference, and type consistency check provided in an embodiment of this application.

[0048] Figure 5 This is a schematic diagram of a target programming language code generation process provided in an embodiment of this application;

[0049] Figure 6 This is a schematic diagram of the structure of a two-stage conversion and compilation device for a discrete simulation language provided in an embodiment of this application;

[0050] Figure 7 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0051] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. The embodiments and technical features described herein can be combined with each other without contradiction.

[0052] The "Discrete Event Simulation Language Source Code" in this specification can be a simulation script in text form, a set of expressions derived from a graphical simulation model, a set of function definitions, a sequence of statements, or an intermediate script. It can also be a domain-specific language file with discrete event semantics. The source code may contain variable declarations, array definitions, function declarations, assignment statements, conditional statements, loop statements, jump statements, function call statements, string manipulation statements, and compound expressions formed by combining multiple syntactic elements.

[0053] In this specification, "target programming language code" refers to code snippets, function definitions, statement sequences, or source files that can be compiled, interpreted, or run in the target programming language environment. The target programming language can be C++, Java, C#, Python, JavaScript, Go, Rust, or other general-purpose programming languages ​​or dedicated runtime platform languages ​​capable of carrying discrete event simulation execution logic. The target programming language is not limited to a specific language; in specific implementations, the semantic analysis results can be adapted to the target language's variable declaration methods, array subscript rules, function call formats, type conversion formats, string processing methods, and runtime library interfaces. The target programming language can be selected based on the specific simulation runtime platform. Although some embodiments use C / C++-style assignment, array access, and type conversion expressions as examples for ease of illustration, these examples are only used to explain the two-stage parsing and semantic-driven generation techniques and do not limit the invention to any specific target programming language.

[0054] In this specification, "Phase One" refers to the parsing phase, which primarily focuses on the grammatical structure. During this phase, the system can identify the formal structure, node relationships, and positional relationships of expressions, but it does not require immediate access to the complete type information and semantic category of each identifier. "Phase Two" refers to the phase where, after the symbol table and context information have been established, semantic binding, type inference, and code generation preparation are performed on the abstract syntax tree or intermediate representation generated in Phase One.

[0055] In the implementation of compilers for discrete event simulation languages, some tools still employ a single-stage processing approach to reduce implementation complexity. This means that semantic analysis and type checking are performed simultaneously while the syntax tree is being built. For processing complex expressions, these tools often need to determine the type, scope, and semantic meaning of all variables immediately during syntax parsing. Especially when dealing with programming languages ​​containing compound expressions such as array accesses, function calls, and type conversions, these single-stage compilers typically use a one-pass scan approach, attempting a complete semantic analysis immediately after identifying the grammatical structure.

[0056] This type of expression parsing method relies heavily on predefined syntax rules, requiring all referenced variables and functions to be declared and have explicit type information during the syntax analysis phase. This method has significant limitations when dealing with forward references, dynamic type inference, or context-sensitive syntax structures common in discrete event simulation languages. Specific drawbacks include the following:

[0057] First, it cannot effectively handle forward references: In the single-phase immediate binding approach, when an expression references a variable or function that is declared later, the compiler cannot obtain complete type information and semantic context in the current resolution phase, leading to resolution failure or requiring a complex backtracking mechanism.

[0058] Second, the ability to handle context-sensitive syntax structures is limited: In discrete event simulation languages, the same grammatical form has different semantic meanings in different contexts (such as identifiers representing variables, arrays, function calls, etc.). Such methods are unable to make accurate semantic judgments in the absence of complete context information.

[0059] Third, the accuracy of type inference and semantic analysis is insufficient: due to the lack of complete program context information in the syntax structure recognition stage, such methods often cannot perform accurate type inference, resulting in excessive manual type annotation or inaccurate type conversion.

[0060] Fourth, the quality of generated code is limited: the single-phase immediate binding method has difficulty optimizing the generation of target code based on complete semantic information, especially when different target codes need to be generated according to different data types. Existing technologies often adopt a conservative strategy, which affects the execution efficiency of the final code.

[0061] On the other hand, if the heavy multi-stage architecture of a general-purpose compiler is directly adopted, it will introduce an overly complex compilation pipeline, which does not meet the actual needs of discrete event simulation tools for lightweight embedding and fast translation.

[0062] Therefore, embodiments of this application provide a two-stage transformation compilation method for discrete simulation languages. This method replaces the traditional single-stage immediate binding process with two lightweight traversals, achieving delayed semantic binding while maintaining architectural simplicity. Figure 1 As shown, it includes the following steps:

[0063] Step S110, the first stage, performs the first traversal, performs lexical preprocessing on the input discrete event simulation language source code, identifies identifiers, keywords, operators and constants in the source code, and forms a lexical stream;

[0064] Step S120: Based on the lexical flow, the expression in the source code is parsed to perform syntactic structure analysis and construct an abstract syntax tree or intermediate representation. In the first stage, only the formal structure and positional relationship of variable references, array accesses, function calls and compound expressions are recorded, without performing complete semantic analysis.

[0065] Step S130: Scan the complete source code, construct a symbol table and collect context information. The symbol table includes variable declaration information, array definition information, function declaration information and scope information.

[0066] In this embodiment, during the first traversal, variable declaration information, array definition information, function declaration information, and scope information are collected simultaneously from the source code to construct a complete symbol table.

[0067] Step S140, the second stage, performs a second traversal, based on the symbol table and context information, performs semantic binding, type inference and type consistency checks on the grammatical structure in the abstract syntax tree or intermediate representation to determine the actual semantic meaning of the grammatical structure;

[0068] This embodiment performs semantic binding, type inference, and type consistency checks based on the abstract syntax tree or intermediate representation constructed in the first traversal and the complete symbol table to determine the actual semantic meaning of each syntax structure.

[0069] Step S150: Generate the corresponding target programming language code based on the results of semantic binding, type inference, and type consistency checks.

[0070] Specifically, the lexical preprocessing in step S110 may include cleaning up comments, standardizing newline characters, identifying delimiters, identifying keywords, identifying variable names, identifying function names, identifying numerical constants, identifying string constants, identifying operators, and identifying parentheses and array subscript symbols. For words with special meanings in discrete event simulation languages, such as assignment keywords, addition, subtraction, multiplication, and division keywords, string function suffixes, simulation function suffixes, or array definition keywords, lexical preprocessing can record their original text, normalized text, row and column position, and word category in the lexical unit.

[0071] Lexical streams can be represented as lists, queues, iterators, or indexed arrays. Lexical streams do not directly determine the final semantic category of identifiers, but rather provide the basic input for constructing the syntactic structure in the first stage. That is, during the lexical preprocessing stage, even if an identifier might later be determined as a variable, array, or function, it can temporarily be identified only as an identifier type.

[0072] In the first stage, the grammatical structure parsing of expressions in the source code based on lexical flow includes: identifying variable reference expressions, array access expressions, function call expressions, and compound expressions containing at least two of the grammatical structures of variable reference, array access, and function call, and storing the identified expressions in a structured form.

[0073] The first stage of syntax structure parsing in step S120 focuses on whether the expression conforms to the grammatical form, without immediately completing the full semantic analysis. For example, when the parser reads an identifier followed by square brackets, it can construct an array access form node; when the parser reads an identifier followed by parameter brackets, it can construct a function call form node; when the parser reads multiple operands connected by operators, it can construct a binary or multivariate expression node. For these nodes, the first stage can record the node type, child node list, operators, bracket nesting relationships, and source code location, but it can temporarily not determine whether the identifier has already been declared in the symbol table.

[0074] The symbol table construction in step S130 can be performed after the first phase, or it can be performed in parallel with the first phase to collect some information. However, the completion of the symbol table depends on scanning the entire source code scope. The system can scan variable declaration statements to obtain variable names and types, scan array definition statements to obtain array names, dimensions, sizes, and element types, and scan function declarations or function definitions to obtain function names, parameter lists, and return types, and record the scope of different declarations. For identifiers that appear in the source code but cannot be immediately resolved at the current resolution location, forward references can be recorded for binding in the second phase.

[0075] Building a symbol table and collecting contextual information includes: collecting variable declaration information and its type; collecting the dimensions, size, and element types in array definition information; collecting the parameter list and return type in function declaration information; recording scope information and forward reference relationships; and establishing a mapping relationship between identifiers and semantic information.

[0076] The second-stage semantic analysis in step S140 takes the abstract syntax tree or intermediate representation from the first stage as input and relies on the complete symbol table and contextual information. The second stage can traverse each node in the abstract syntax tree, performing symbol lookup on identifier nodes, array definition binding and index type checking on array access nodes, function signature binding and parameter type checking on function call nodes, operator type deduction on compound expression nodes, and left-right type consistency checks on assignment expressions.

[0077] Semantic binding of the syntactic structure in the abstract syntax tree or intermediate representation includes: for identifiers that have been identified in the first stage but whose declaration information has not yet been obtained at the current parsing position, preserving their syntactic structure representation; and after scanning the complete source code and obtaining the declaration information of the identifier, performing delayed binding of the identifier with the corresponding semantic information based on the symbol table.

[0078] Determining the actual semantic meaning of a grammatical structure includes: judging the semantic meaning of the same grammatical form in different contexts, such as variable references, array accesses, or function calls, based on the symbol table and context information.

[0079] Type inference and type consistency checking include: determining the result type of an expression based on the variable type, array element type, function return type, and the type rules corresponding to the operators in the expression, and generating the corresponding type conversion information when type conversion is required.

[0080] The target programming language code generation in step S150 is not simply replacing the source language text with the target language text, but rather generating it based on the semantic information determined in the second stage. For ordinary variables, the system can output the target language variable name according to the mapping relationship in the symbol table; for array access, the system can output the target language array access expression according to the array subscript rules, and offset or convert the index when necessary; for function calls, the system can output the target language function call according to the function declaration information or the built-in function mapping relationship; for string operations, the system can generate corresponding code according to the string runtime library interface of the target language; for expressions that require type coordination, the system can insert type conversion expressions supported by the target language.

[0081] Generating the corresponding target programming language code may include one or more of the following steps:

[0082] Step S151: Map discrete event simulation language variables to target programming language variables;

[0083] Step S152: Convert the array access expression into an array access expression in the target programming language, and perform subscript offset processing on the array index;

[0084] Step S153: Convert the function call expression into the corresponding function call expression in the target programming language;

[0085] Step S154: Add a target programming language type conversion expression based on the type information;

[0086] Step S155: Generate the corresponding string processing code in the target programming language for the string operations.

[0087] See Figure 2In one embodiment, the first-stage grammar structure parsing includes receiving a vocabulary stream, identifying the start and end range of expressions, constructing expression nodes, establishing parent-child relationships between nodes, and outputting an abstract syntax tree or intermediate representation. The first stage can be implemented using recursive descent parsing, operator precedence parsing, Pratt parsing, stack-based expression parsing, or other parsing algorithms, as long as the formal structure in the source code can be saved as a data structure that can be traversed by subsequent stages.

[0088] In the first phase of identifying variable reference expressions, a variable reference form node can be constructed when a single identifier is read and that identifier is not directly followed by array subscript symbols or parameter parentheses. This node can contain the identifier text, normalized name, occurrence position, and position within the expression. At this point, the system does not require immediate determination of whether the identifier has already been declared in the current scope, nor does it require immediate determination of its type; instead, the system reserves this identifier as a node to be bound, so that semantic binding can be completed after querying the symbol table in the second phase.

[0089] In the first stage of recognizing array access expressions, an array access form node can be constructed when an identifier followed by square brackets is read. This node can include array name child nodes and index expression child nodes. The index expression itself can be an identifier, a constant, a function call, or a compound expression; therefore, the first stage can recursively construct subtrees of index expressions. At this point, the system does not require immediate verification of whether the array name is indeed an array, nor does it require immediate verification of whether the index expression is an integer type; it only records the formal structure of the array access.

[0090] In the first stage of function call expression recognition, a function call form node can be constructed upon reading the identifier followed by parameter brackets. This node can include the function name, parameter list, expression subtree for each parameter, and the function call's location in the source code. For parameter expressions, the first stage can also recursively construct their formal structure without immediately determining whether the parameter types match the function signature. Therefore, even if the function is declared later in the source code, the first stage can correctly preserve the function call structure.

[0091] In the first stage of recognizing compound expressions, an expression tree can be constructed based on operator precedence, associativity, and parenthesis nesting. For example, for an expression like `a[i] add f(x)`, the first stage can construct a binary expression with the addition operator as the root node, the left child node being an array access node, and the right child node being a function call node. Through this structured storage method, the syntactic elements in complex expressions will not lose their positional relationships due to a lack of semantic information.

[0092] In some embodiments, the intermediate representation generated in the first stage may retain the `sourceRange` field in the nodes to locate the source code position when semantic errors are found in the second stage; it may also retain the `rawText` field to handle special expressions during the code generation stage; and it may also retain the `nodeKind` field to distinguish between variable reference forms, array access forms, function call forms, compound expression forms, constant forms, string forms, and bracket expression forms. The above fields are specific implementations of the abstract syntax tree or intermediate representation and do not limit the scope of protection of this invention.

[0093] The fact that the first stage does not perform complete semantic analysis does not mean that no checks are performed at all. To ensure the correctness of the intermediate representation structure, the first stage can still perform basic syntactic validity checks, such as whether parentheses match, whether there are illegal consecutive operators in the expression, whether the parentheses of function call parameters are closed, whether the square brackets of array access are closed, and whether string constants end correctly. The above checks only involve syntactic form and do not require complete symbol table support, therefore they do not affect the basic idea of ​​two-stage parsing.

[0094] See Figure 3 In one embodiment, symbol table construction and context information collection include scanning the complete source code to extract all variable declarations, array definitions, function declarations, scope information, and forward references. The symbol table can be implemented using a hash table, a tree-structured scope table, a linked scope table, database records, or a collection of in-memory objects.

[0095] Variable declaration information can include the variable name, variable type, declaration location, scope, whether it is a parameter, whether it is a local variable, whether it is a global variable, and whether it has an initial value. Variable types can include integers, floating-point numbers, strings, booleans, object types, or other types supported by the source language. For target programming language code generation, variable types are used not only to determine the type of expression results but also to determine the target language's variable declaration format, assignment conversion method, and function parameter passing method.

[0096] Array definition information can include the array name, array dimensions, the size of each dimension, element type, declaration location, scope, and the array subscript rules of the source language. In discrete event simulation languages, array subscript rules may differ from those of the target programming language; for example, the source language may use subscripts starting from 1, while the target programming language may use subscripts starting from 0. The array definition information in the symbol table allows the code generation stage to accurately determine whether subscript offset processing is needed for index expressions.

[0097] Function declaration information can include the function name, parameter list, parameter types, number of parameters, return type, declaration location, scope, and whether it is a built-in function. For built-in functions, a mapping relationship can be established between source language function names and target programming language runtime library function names. For example, a string truncation function in the source language can be mapped to a corresponding string processing function in the target language. Using the function declaration information, the second stage can determine the actual semantics of the function call node and perform parameter type matching.

[0098] Scope information describes the visibility and priority of an identifier. An identifier may appear in the global scope, function scope, local block scope, or model scope. During the second phase of semantic binding, the most suitable symbol record can be found based on the node's location and the scope chain. If a variable with the same name exists in the local scope, the local variable is bound first; if it does not exist in the local scope, the search continues in the outer scope or global scope.

[0099] Forward references can be recorded during the scanning of the complete source code. For example, if an expression is found to use an identifier that has not yet been declared in the scanned portion during the first or source code scanning phase, the identifier can be recorded as a reference to be bound, along with its occurrence node, location, and expected syntax. After the complete source code scan is completed, if the declaration information of the identifier appears in the symbol table, the system can associate the reference to be bound with the corresponding symbol record in the second phase.

[0100] In some embodiments, the symbol table can be divided into a declaration symbol table and a reference record table. The declaration symbol table records all known declarations, and the reference record table records the usage locations of all identifiers. The second stage can complete the unified binding of ordinary references and forward references by traversing the reference record table to search the declaration symbol table one by one. This implementation clearly distinguishes between the two processes of "declaration information collection" and "reference information binding".

[0101] See Figure 4 In one embodiment, the second-stage semantic binding, type inference, and type consistency check includes node traversal, symbol lookup, semantic category determination, type inference, type consistency judgment, and conversion information generation. The second stage can process the abstract syntax tree using depth-first, breadth-first, or post-order traversal. For expression type inference, post-order traversal is more suitable because the type of the parent node often depends on the type of the child nodes.

[0102] For nodes that are variable references, the second phase involves querying the symbol table based on the identifier text and scope information within the node. If a variable declaration record is found, the node is bound as a regular variable reference, and the variable type is used as the expression type for that node. If no variable declaration is found in the current scope but in an outer or global scope, it is bound according to the scope rules. If no corresponding declaration is found ultimately, a semantic error can be output based on system policy, or the node can be retained as an external symbol reference.

[0103] For nodes with array access semantics, the second stage first queries the symbol record corresponding to the array name. If the symbol record indicates that the identifier is an array, the node is bound to array access semantics, and the array element type is read as a candidate result type. Then, the system performs type inference on the index expression child nodes to determine whether they can be converted to the type required for array indexing in the target programming language. If the source language array subscript rules differ from the target language, the second stage can generate subscript offset information, which will be converted into offset processing for the index expression during the code generation stage.

[0104] For function call form nodes, the second stage can query the function declaration information or built-in function mapping information corresponding to the function name. If the function has a parameter list and a return type, the system can recursively perform type deduction for each argument expression and match the argument types with the formal parameter types. If necessary type conversions exist, such as integer to floating-point, floating-point to integer, string to target language string object, etc., the second stage can generate type conversion information. The function return type serves as the expression result type of the function call node.

[0105] For compound expression nodes, the second stage can deduce the result type based on the operator type and the types of the left and right operands. For example, when two numeric types are added, the result type can be determined according to type promotion rules; when strings are concatenated with strings or strings with convertible expressions, the result type can be determined according to string processing rules; when the left and right sides of an assignment expression have different types but are convertible, conversion information can be generated; and when types are incompatible, a type inconsistency error can be output.

[0106] Delayed binding is a crucial processing mechanism in the second phase. For identifiers identified in the first phase but for which declaration information has not yet been obtained, the system does not discard the node or immediately identify an error. Instead, it re-queries the symbol table after a complete source code scan. As long as a variable, array, or function declaration for that identifier is subsequently scanned, the previously unbound node can be associated with the declaration information. This mechanism allows the compiler to handle cases where variables or functions are referenced before their declaration, improving the fault tolerance and completeness of language translation.

[0107] Context-sensitive semantic recognition is another important process in the second stage. Since the same identifier form may have different meanings in different contexts, the system can combine node structure, symbol table records, and contextual environment for judgment. For example, a standalone identifier can usually be bound to a variable reference; an identifier with indexed child nodes can be bound to an array access when an array definition exists in the symbol table; and an identifier with a parameter list can be bound to a function call when a function declaration or built-in function mapping exists in the symbol table. Through this context-based judgment method, the system can reduce ambiguity caused by semantic recognition based solely on surface-level strings.

[0108] Type consistency checks can be performed on assignment statements, function calls, arithmetic expressions, and array indices. For assignment statements, the system compares the types of lvalues ​​and rvalue expressions; for function calls, it compares the types of actual arguments and formal parameters; for array accesses, it checks whether indexed expressions can be converted to integer indices; and for compound expressions, it checks whether operators support the corresponding operand types. The results of type checks are not only used to detect errors but also to guide the insertion of necessary conversions during code generation.

[0109] See Figure 5 In one embodiment, the target programming language code generation stage generates code based on the semantic binding and type inference results of the second stage. The code generation stage can traverse the semantically annotated abstract syntax tree or intermediate representation, converting each node into an expression, statement, or function definition in the target programming language. Since the second stage has already completed symbol binding and type inference, the code generation stage does not need to guess the meaning of identifiers again and can directly output based on the semantic tags on the nodes.

[0110] For ordinary variable reference nodes, the code generation phase can look up the target name mapping in the symbol table to convert source language variable names to target programming language variable names. If the target programming language requires specific naming conventions or keyword escaping, the code generation phase can normalize the variable names. For example, when source language variable names conflict with target language reserved words, prefixes, suffixes, or mapped names can be added.

[0111] For array access nodes, the code generation phase can generate array access expressions in the target programming language. If the second phase determines that there is an offset between the source language array indices and the target language array indices, the offset processing can be added to the index expression. For example, if the source language uses indices starting from 1 while the target language uses indices starting from 0, the index expression can be converted to the target form of "index expression minus one"; if the index expression type needs to be converted to an integer type, type conversion information can be applied simultaneously.

[0112] For function call nodes, the code generation phase can generate target programming language function call expressions based on function binding results. For user-defined functions, the function name and argument list can be output based on the target name mapping; for built-in functions, the target language runtime library function name or helper function name can be output based on the built-in function mapping table; for string processing functions, code can be generated based on the calling format of the target language string library.

[0113] For compound expression nodes, the code generation phase can output operators, precedence, and bracket rules according to the target programming language. Since the operator names or textual forms may differ between the source and target languages—for example, the source language might use `add` for addition and `eq` for assignment—the code generation phase can output the `+` or assignment operator in the target language based on the operator mapping table. For scenarios where maintaining the original expression's order of operations is necessary, brackets can be added appropriately based on the abstract syntax tree structure.

[0114] For type conversion information, the code generation stage can output corresponding expressions based on the type conversion syntax of the target programming language. Different target programming languages ​​may have different type conversion syntaxes; for example, some languages ​​use explicit type conversion expressions, some use constructors or conversion functions, and some rely on runtime library functions. Since the claims specify adding target programming language type conversion expressions based on type information, the specific conversion form can be determined by the target language adapter or code generation strategy.

[0115] For string manipulation, the code generation stage can generate string processing code in the target programming language based on the string type and function semantics determined in the second stage. For example, string subtraction, string concatenation, or character index access in the source language can be mapped to string library functions, member methods, or operator expressions in the target language. If the string indexing rules of the source and target languages ​​differ, offset processing can be performed similarly to array subscripts.

[0116] The code generation phase can also utilize the function parameter list and return type information from the symbol table when generating function definitions. For each function, the system can obtain its sub-statement structure and parameter types in the first and symbol table construction phases, obtain the semantic information of its internal expressions in the second phase, and output the target programming language function header, local variable declarations, statement sequences, and return statements during the code generation phase. This enables a structured conversion from source language functions to target programming language functions.

[0117] In some embodiments, the first and second stages can be implemented using a unified statement processing function. For example, the system can set an analysis flag; when the analysis flag is true, the statement processing function performs analysis behaviors such as type inference, tag collection, declaration collection, and reference recording; when the analysis flag is false, the statement processing function performs actual code generation based on the collected semantic information. By using the same statement traversal entry point in conjunction with different running modes, duplicate code can be reduced, and the traversal scope of the analysis and generation stages can be kept consistent.

[0118] In function processing scenarios, the system can parse substatements within the function body in the first stage, collecting information about internal variables, parameter types, and return values. In the second stage, or code generation stage, the system generates the target programming language function definition based on this information. Since the first stage preserves the complete syntactic structure, the second stage can handle variable references, array accesses, and function calls within the function's complete context.

[0119] In terms of error handling, the system can report syntax errors and semantic errors in stages. The first stage reports syntax errors such as mismatched parentheses, illegal expression structures, and unknown lexical units; the second stage reports semantic errors such as undeclared identifiers, unbound forward references, mismatched parameter types, invalid array index types, and incompatible assignment types. Staged error reporting helps users locate problems more accurately.

[0120] In terms of scalability, when the source language adds new expression forms, corresponding node construction rules can be added in the first stage; when the target programming language adds new code generation rules, corresponding target language adaptation strategies can be added in the code generation module; when the source language adds new built-in functions, corresponding records can be added to the symbol table or function mapping table. Because syntax structure recognition and semantic analysis are separated, new features will not excessively impact the existing processing flow.

[0121] In terms of performance, although two-phase parsing is logically divided into a first phase and a second phase, it does not necessarily require a large number of repetitive scans of the source code. The system can simultaneously complete lexical preprocessing, preliminary syntax structure construction, and declaration information collection in the first scan, and can also save abstract syntax tree nodes and reference records simultaneously. The second phase mainly traverses the intermediate representation and queries the symbol table. Because it reduces backtracking and retries, two-phase parsing can actually improve overall stability and processing efficiency in scenarios with complex expressions and many forward references.

[0122] Here is a typical example of expression transformation:

[0123] Example 1 is an array access expression conversion. The input discrete event simulation language fragment can be: valueeq data_array[index_variable] add 10.

[0124] The parsing result (syntax structure) of step S120:

[0125] Assignment expression node:

[0126] ├── Left value: Identifier node "value"

[0127] └── Rvalue: Binary operand "+"

[0128] ├── Left operand: Accessing array nodes

[0129] │ ├── Array name: Identifier node "data_array"

[0130] │ └── Index: Identifier node "index_variable"

[0131] └── Right operand: Constant node 10

[0132] Semantic analysis results of step S140:

[0133] A lookup of the symbol table reveals that "data_array" is a DOUBLE type array.

[0134] A query of the symbol table reveals that "index_variable" is an INT type variable.

[0135] Determine the result type of the entire expression to be DOUBLE.

[0136] The C++ code generated in step S150:

[0137] value = data_array[(INT)index_variable-1] + 10.0

[0138] As can be seen, during the first stage of parsing, the system constructs assignment expression nodes. The left-hand side is the identifier node `value`, and the right-hand side is a binary expression rooted at addition. The left operand of the addition expression is an array access form node named `data_array`, and the index expression is the identifier node `index_variable`; the right operand is the constant node `10`. At this point, the system does not require immediate determination of whether `data_array` has been declared as an array, nor does it require immediate determination of the type of `index_variable`.

[0139] During the symbol table construction phase, the system scans the complete source code to obtain the array definition information of `data_array`, such as whether it is a floating-point array, and the variable declaration information of `index_variable`, such as whether it is an integer variable. In the second phase, the system binds the `data_array` node to array access semantics, binds `index_variable` to a regular variable reference, and determines that the result type of the entire rvalue expression is floating-point. If the source language array subscript rule starts from 1, while the target programming language array subscript rule starts from 0, the system generates subscript offset information. The code generation phase then outputs the target programming language array access expression based on this information, and adds integer conversions or offset processing to the index expression as necessary.

[0140] Example 2 involves function calls and string processing. The input fragment can be: result eq substr.f(source_string, start_pos, length).

[0141] The parsing result (syntax structure) of step S120:

[0142] Assignment expression node:

[0143] ├── Left value: Identifier node "result"

[0144] └── Rvalue: Function call node

[0145] ├── Function name: Identifier node "substr.f"

[0146] ├── Parameter 1: Identifier node "source_string"

[0147] ├── Parameter 2: Identifier node "start_pos"

[0148] └── Parameter 3: Identifier node "length"

[0149] Semantic analysis results of step S140:

[0150] The symbol table query identifies "substr.f" as a built-in string function.

[0151] The return type is confirmed to be STRING.

[0152] Verify parameter type matching

[0153] The C++ code generated in step S150:

[0154] result = substr(source_string, start_pos, length)

[0155] As can be seen, during the first stage of parsing, the system constructs an assignment expression node, with the right-hand side being a function call form node. The function name is substr.f, and the parameters include three expression nodes: source_string, start_pos, and length. The first stage only records the function call structure and the position of each parameter; it does not immediately require substr.f to be bound to the target runtime library function.

[0156] During the symbol table construction and context information collection phase, the system can record `substr.f` as a built-in string function, or determine its parameters and return type through function declaration information. In the second phase, after querying the function information, it determines that its return type is string and checks whether the argument types of `source_string`, `start_pos`, and `length` meet the requirements. During the code generation phase, according to the string processing rules of the target programming language, the function call is converted into the corresponding target language string function, member method, or runtime function call.

[0157] Example 3 is a forward reference processing method. The input fragment may include:

[0158] temp eq future_variable * 2.0

[0159] / / ... other code...

[0160] future_variable eq 100

[0161] Step S120 constructs the syntax structure normally without reporting an error due to "future_variable" being undefined.

[0162] Step S130 adds "future_variable" to the symbol table after scanning the complete code.

[0163] Step S140 correctly binds the identifier of the forward reference.

[0164] This ultimately generates correct C++ code, avoiding the problems of backtracking or multiple scans required by traditional methods.

[0165] As can be seen, in the first stage, the system identifies temp, future_variable, and the constant 2.0, and constructs the structures of multiplication and assignment expressions. Since the first stage does not require immediate completion of full semantic analysis, it will not be interrupted because future_variable has not yet been declared at the current parsing position.

[0166] Subsequently, the system scans the complete source code and records the declaration or semantic information of `future_variable` in the symbol table. During the second phase of traversing the abstract syntax tree, the system queries the symbol table and performs deferred binding between the `future_variable` node and its corresponding semantic information to determine the result type of the multiplication expression and generate the corresponding target programming language code. This process supports pre-declaration referencing without complex backtracking, improving the adaptability of the compilation method to actual simulation scripts.

[0167] Through the two-stage parsing technique described above, this method effectively solves the context sensitivity problem in complex expression processing and achieves accurate conversion from discrete event simulation language to C++ language.

[0168] Example 4 is context-sensitive semantic recognition. Assume that similar identifiers `data`, `data[i]`, and `data(x)` appear in the source language. In the first stage, these can be recorded as variable references, array accesses, and function calls, respectively. In the second stage, the symbol table is used for further determination: if `data` is declared as a regular variable in the current scope, then `data` is bound as a variable reference; if `data` has an array definition, then `data[i]` is bound as an array access; if `data` or its corresponding function name has a function declaration or built-in function mapping, then `data(x)` is bound as a function call. By combining the formal structure with symbol table information, ambiguity caused by relying solely on the surface form of the string can be avoided.

[0169] Example 5 describes type deduction and type conversion information generation. For the expression a[i] add f(x), the first stage constructs a compound expression structure rooted in addition; the second stage derives the types of a[i] and f(x) respectively. If a[i] is a floating-point type and f(x) is an integer type, and the target type rule requires the result to be a floating-point type, the system can determine that the entire expression result is a floating-point type and generate type conversion information for f(x) when necessary. During the code generation stage, this conversion information is converted into a conversion expression supported by the target programming language, thereby ensuring type consistency in the generated code.

[0170] Therefore, the embodiments of this application adopt a phased processing mechanism: the syntax analysis process is divided into two independent phases:

[0171] Phase 1: Pure grammatical structure recognition and abstract syntax tree construction.

[0172] Phase Two: Semantic binding and type inference based on complete context.

[0173] This application employs a forward reference processing method, using a delayed binding mechanism to address the issue of identifiers being referenced before declaration. It utilizes context-sensitive syntax structure identification and processing technology to determine different semantic meanings for the same syntactic form based on context. A symbol table-driven semantic analysis mechanism is employed to perform accurate semantic judgment based on global symbol information. Finally, a type inference and target code optimization generation method is used to generate high-quality target code based on complete type information.

[0174] Compared with the prior art, the embodiments of this application have the following advantages:

[0175] 1. Type safety guarantee: Through the complete analysis in the first phase, ensure that all variables have a clear type definition before use.

[0176] 2. Control flow integrity: Supports accurate conversion of complex control structures such as goto statements and label jumps.

[0177] 3. Modular design: The analysis and generation phases can be developed and tested independently.

[0178] 4. Scalability: New syntax features can be added simply by adding processing logic at the corresponding stage.

[0179] 5. Supports forward reference handling: This solves the problem that traditional compilers cannot handle variables or functions being referenced before their declaration. It eliminates the need for complex backtracking mechanisms or multiple scans, improving the completeness and accuracy of the resolution.

[0180] 6. Enhanced ability to handle context-sensitive syntax structures: It can accurately identify different semantic meanings of the same grammatical form (variable / array / function), make precise semantic judgments based on global context information, and reduce ambiguity parsing errors.

[0181] 7. Improved accuracy of type inference: Type analysis is performed based on the complete program context, supporting automatic type conversion and type consistency checks, which improves the reliability of code generation.

[0182] See Figure 6 In one embodiment, this application also provides a two-stage conversion and compilation apparatus for discrete simulation languages. The conversion apparatus 600 includes a lexical preprocessing module 610, a first-stage parsing module 620, a symbol table construction module 630, a second-stage semantic analysis module 640, and a code generation module 650. These modules can be deployed in a software program executed on the same processor, or implemented as multiple services, multiple threads, multiple processes, or multiple hardware units.

[0183] The lexical preprocessing module 610 is used to perform lexical preprocessing on the input discrete event simulation language source code, identifying identifiers, keywords, operators, and constants to form a lexical stream. This module can be further used to record the position of lexical units in the source code, the original text, and the normalized text, providing accurate input for subsequent abstract syntax tree construction.

[0184] The first-stage parsing module 620 is used to parse the syntax structure of expressions in the source code based on the lexical flow, construct an abstract syntax tree or intermediate representation, and record the formal structure and positional relationships of variable references, array accesses, function calls, and compound expressions. The first-stage parsing module 620 can call the expression parser, statement parser, and node builder to generate traversable intermediate data structures.

[0185] The symbol table construction module 630 is used to scan the complete source code, construct a symbol table including variable declaration information, array definition information, function declaration information, and scope information, and collect context information. The symbol table construction module 630 can also record forward references and establish a mapping relationship between identifiers and semantic information.

[0186] The second-stage semantic analysis module 640 is used to perform semantic binding, type inference, and type consistency checks on the syntactic structure in the abstract syntax tree or intermediate representation based on the symbol table and context information. This module may further include a symbol lookup unit, a delayed binding unit, a forward reference processing unit 641, a type inference unit 642, and a consistency check unit.

[0187] The code generation module 650 generates corresponding target programming language code based on the analysis results of the second-stage semantic analysis module 640. The code generation module 650 may include a variable mapping unit, an array access generation unit, a function call generation unit, a type conversion generation unit, and a string processing generation unit. Depending on the target programming language, this module can load different code generation strategies or target language adaptation rules.

[0188] The modules in the above-mentioned device can exchange data through memory objects, message queues, files, databases, or interface calls. For example, the lexical preprocessing module 610 outputs a lexical stream, the first-stage parsing module 620 outputs an abstract syntax tree or intermediate representation, the symbol table construction module 630 outputs a symbol table and context information, the second-stage semantic analysis module 640 outputs an intermediate representation with semantic and type annotations, and the code generation module 650 outputs the target programming language code.

[0189] This invention can also be implemented in the form of a computer-readable storage medium. This computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to execute the aforementioned compilation method for converting discrete event simulation language code to target programming language code based on two-stage parsing. The computer-readable storage medium may include a read-only memory, random access memory, flash memory, hard disk, solid-state drive, optical disk, magnetic disk, USB flash drive, memory card, or other media capable of storing program instructions.

[0190] See Figure 7 This application also provides an electronic device, which may include a processor 710, a memory 720, an input / output interface 730, a communication interface 740, and a display unit 750. The memory 720 is used to store computer programs, discrete event simulation language source code, lexical streams, abstract syntax trees or intermediate representations, symbol tables, context information, and generated target programming language code. The processor 710 is used to execute the computer program in the memory 720 to implement lexical preprocessing, first-stage parsing, symbol table construction, second-stage semantic analysis, and code generation.

[0191] The input / output interface 730 can be used to receive user-input source code files, model configuration files, or conversion parameters, and can also be used to output generated target programming language code files, log files, or error reports. The communication interface 740 can be used to retrieve source code from a remote server, upload generated results, or communicate with cloud-based compilation services, simulation platforms, and version management systems, displaying the results through the display unit 750. The bus connects the processor 710, memory 720, and various interfaces, enabling the transmission of data and control signals between the components.

[0192] The electronic device can be a desktop computer, laptop computer, server, cloud computing instance, embedded development device, or computing node in a simulation modeling platform. When the electronic device executes the method of this invention, it can first read the source code of the discrete event simulation language, obtain the semantic analysis result through two-stage parsing, then generate the target programming language code, and store or output the generated result to the subsequent compiler, interpreter, or simulation runtime environment.

[0193] Those skilled in the art will understand that the module division in the above embodiments is for illustrative purposes only and does not constitute a limitation on the implementation. In actual software systems, multiple modules can be merged into one module, or a module can be split into multiple sub-modules; symbol table construction and the first-stage parsing can be executed in parallel, or they can be executed uniformly after the first stage is completed; target language adaptation rules can be built into the code generation module, or they can be loaded as external configurations. As long as it adopts the two-stage processing idea of ​​separating syntax structure recognition from semantic binding and type inference based on complete context, it falls within the scope of the technical concept of this invention.

[0194] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any equivalent substitutions or obvious modifications made within the spirit and principles of the present invention to the order of steps, module names, data structure forms, target programming language types, symbol table implementation methods, and code generation strategies should be included within the scope of protection of the present invention.

Claims

1. A two-stage conversion compilation method for a discrete simulation language, characterized in that, include: In the first stage, the first traversal is performed to preprocess the input discrete event simulation language source code with lexical analysis, identifying identifiers, keywords, operators and constants in the source code to form a lexical stream. Based on the lexical flow, the expressions in the source code are parsed to construct an abstract syntax tree or intermediate representation. In the first stage, only the formal structure and positional relationship of variable references, array accesses, function calls and compound expressions are recorded, without performing complete semantic analysis. Scan the complete source code, construct a symbol table and collect context information, the symbol table including variable declaration information, array definition information, function declaration information and scope information; In the second stage, a second traversal is performed. Based on the symbol table and the context information, semantic binding, type inference, and type consistency checks are performed on the grammatical structure in the abstract syntax tree or intermediate representation to determine the actual semantic meaning of the grammatical structure. The corresponding target programming language code is generated based on the results of the semantic binding, type inference, and type consistency check.

2. The compilation method according to claim 1, characterized in that, The first stage, parsing the syntactic structure of expressions in the source code based on the lexical flow, includes: Identify variable reference expressions, array access expressions, function call expressions, and compound expressions that contain at least two of the following syntax structures: variable reference, array access, and function call, and store the identified expressions in a structured form.

3. The compilation method according to claim 1, characterized in that, The construction of the symbol table and collection of context information includes: Collect variable declaration information and its type, collect the dimensions, size and element type of array definition information, collect the parameter list and return type of function declaration information, record scope information and forward reference relationships, and establish a mapping relationship between identifiers and semantic information.

4. The compilation method according to claim 1, characterized in that, The semantic binding of the syntactic structure in the abstract syntax tree or intermediate representation includes: For identifiers that were identified in the first stage but have not yet received declaration information at the current parsing location, their syntactic structure representation is preserved; After scanning the complete source code and obtaining the declaration information of the identifier, the identifier is then delayedly bound to the corresponding semantic information based on the symbol table.

5. The compilation method according to claim 1, characterized in that, Determining the actual semantic meaning of the grammatical structure includes: Based on the symbol table and the context information, determine the semantic meaning of the same grammatical form in different contexts, corresponding to variable references, array accesses, or function calls.

6. The compilation method according to claim 1, characterized in that, The type derivation and type consistency check include: Based on the variable type, array element type, function return type, and the type rules corresponding to the operators in the expression, determine the result type of the expression, and generate the corresponding type conversion information when type conversion is required.

7. The compilation method according to claim 1, characterized in that, The generation of the corresponding target programming language code includes: Map discrete event simulation language variables to target programming language variables; Convert array access expressions into array access expressions in the target programming language, and perform subscript offset processing on array indices; Convert function call expressions into corresponding function call expressions in the target programming language; Add a target programming language type conversion expression based on the type information; Generate corresponding string processing code in the target programming language for string operations.

8. A conversion device for a discrete event simulation language, characterized in that, include: The lexical preprocessing module is used to perform lexical preprocessing on the input discrete event simulation language source code, identify identifiers, keywords, operators and constants, and form a lexical stream; The first-stage parsing module is used to parse the syntactic structure of expressions in the source code based on the vocabulary stream, construct an abstract syntax tree or intermediate representation, and record the formal structure and positional relationships of variable references, array accesses, function calls, and compound expressions. The symbol table construction module is used to scan the complete source code, build a symbol table including variable declaration information, array definition information, function declaration information, and scope information, and collect context information; The second-stage semantic analysis module is used to perform semantic binding, type inference, and type consistency checks on the grammatical structure in the abstract syntax tree or intermediate representation based on the symbol table and the context information. The code generation module is used to generate corresponding target programming language code based on the analysis results of the second-stage semantic analysis module.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

Images