Semantic-aware type conversion compiling method, device, medium and equipment

Abstract

A type conversion compiling method, device, medium and equipment based on semantic perception are disclosed, wherein the method comprises: setting a second entity type and required components of a general programming language for each syntax rule set for each entity type of a simulation modeling language; establishing a decision tree according to each first entity type of the simulation modeling language, a first semantic feature of each syntax rule, the second entity type and the required components; determining a first entity type and a second semantic feature corresponding to an entity-based statement in a simulation modeling language program, and performing decision processing on the first entity type and the second semantic feature according to the decision tree to determine a leaf node corresponding to the entity-based statement; and generating target program code based on the general programming language for the entity-based statement according to the second entity type and the required components contained in the above leaf node. The technical solution provided by the disclosure is conducive to improving the accuracy and efficiency of the compiling result.

Description

Technical Field

[0001] This disclosure relates to the field of simulation modeling technology, and in particular to a semantically aware type conversion compilation method, a semantically aware type conversion compilation device, a storage medium, and an electronic device. Background Technology

[0002] Simulation modeling languages ​​(such as SimScript) are programming languages ​​specifically designed for simulation modeling. Because they have built-in core simulation concepts (such as entities, events, resources, and time), syntax that fits business scenarios, and a focus on model description, simulation modeling languages ​​offer advantages such as high modeling efficiency, low learning curve (allowing even non-professional programmers to quickly build simulation models), and clear simulation logic.

[0003] However, since simulation modeling languages ​​are usually interpreted simulation languages, meaning they are parsed and run simultaneously without a pre-compilation process to convert the program into machine code, the running speed of simulation modeling language programs is usually lower than that of general programming languages ​​(such as C++). This is especially true when the simulation model is large in scale, where the slow running speed of simulation modeling language programs becomes particularly noticeable and may even cause stuttering.

[0004] To improve the execution speed of simulation modeling language programs, a technique can be employed that first translates the simulation modeling language program into a general-purpose programming language (such as C++), and then compiles the converted general-purpose programming language program into machine code. This allows the compiled code to be executed directly at runtime. How to improve simulation speed while ensuring the accuracy of simulation results is a technically important issue. Summary of the Invention

[0005] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a semantically aware type conversion compilation method, a semantically aware type conversion compilation apparatus, a storage medium, and an electronic device.

[0006] According to a first aspect of the present disclosure, a semantically aware type conversion compilation method is provided, the method comprising: a decision tree generation stage and a code generation stage of a general programming language; the decision tree generation stage comprising the steps of: obtaining first semantic features of each syntax rule set by a simulation modeling language for each first entity type; setting a corresponding second entity type and required components based on the general programming language for each syntax rule set by the simulation modeling language for each first entity type; establishing a decision tree based on the first entity type, the first semantic features, the second entity type, and the required components; wherein the second entity type and the required components are used as leaf nodes of the decision tree; the code generation stage of the general programming language comprising the steps of: identifying entity-based statements in a simulation modeling language program to determine the first entity type and second semantic features corresponding to the entity-based statements; performing decision processing on the first entity type and second semantic features corresponding to the entity-based statements according to the decision tree to determine the leaf nodes corresponding to the entity-based statements; and generating target program code based on the general programming language for the entity-based statements based on the second entity type and required components contained in the leaf nodes corresponding to the entity-based statements.

[0007] According to a second aspect of the present disclosure, a semantically aware type conversion compilation apparatus is provided, comprising: a decision tree generation sub-apparatus and a code generation sub-apparatus for a general-purpose programming language; the decision tree generation sub-apparatus comprises: a semantic feature acquisition module, configured to acquire first semantic features of each syntax rule set by a simulation modeling language for each first entity type; a type component setting module, configured to set a corresponding second entity type and required components based on a general-purpose programming language for each syntax rule set by the simulation modeling language for each first entity type; and a decision tree building module, configured to build a decision tree based on the first entity type, the first semantic features, the second entity type, and the required components; wherein... The second entity type and the required components are used as leaf nodes of the decision tree; the code generation sub-device of the general programming language includes: a statement recognition module, used to recognize entity-based statements in the simulation modeling language program to determine the first entity type and second semantic feature corresponding to the entity-based statement; a decision processing module, used to perform decision processing on the first entity type and second semantic feature corresponding to the entity-based statement according to the decision tree to determine the leaf node corresponding to the entity-based statement; and a translation module, used to generate target program code based on the general programming language for the entity-based statement according to the second entity type and the required components contained in the leaf node corresponding to the entity-based statement.

[0008] According to a third aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for implementing any of the methods described above.

[0009] According to a fourth aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement any of the methods described above.

[0010] Based on an embodiment of this disclosure, a semantically aware type conversion compilation method, apparatus, storage medium, and electronic device are provided. By extracting semantic features from the syntax rules set for each entity type in the simulation modeling language, it is beneficial to accurately and comprehensively extract the actual meaning from all entity-specific syntax rules in the simulation modeling language, thereby ensuring the semantic integrity of the syntax rules for each entity type. By setting the corresponding entity type and required components based on a general programming language for each entity type-based syntax rule, it is beneficial to accurately construct an appropriate translation framework for each syntax rule. By using the entity type of the simulation modeling language, the extracted semantic features, the entity type of the general programming language, and the required components to build a decision tree, not only can the translation rules of the program code be completely extracted from the translated program code, but also, regardless of whether it is for simulation... Whether adding new syntax rules, deleting or modifying existing syntax rules, or adjusting required components (such as adding new components) in a true modeling language, all can be achieved by modifying the decision tree, thus effectively avoiding intrusive modifications to the translated program code. Extracting entity types and semantic features from entity-based statements in simulation modeling language programs helps obtain the complete semantics of the statements, avoiding semantic incompleteness. By using the decision tree to process the extracted entity types and semantic features, the entity types and required components that should be used in general programming languages ​​can be quickly and accurately obtained. This not only avoids translation deviations caused by the loss of semantics such as priority in statements, but also helps eliminate the uncertainty of manual translation, facilitating standardized and accurate translation of entity-based statements in simulation modeling language programs. Therefore, the technical solution provided in this disclosure improves the accuracy, efficiency, and scalability of compilation results, ultimately increasing simulation speed while ensuring the accuracy of simulation results.

[0011] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 This is a flowchart of an embodiment of the semantically aware type conversion compilation method disclosed herein;

[0014] Figure 2 This is a schematic diagram of an embodiment of the semantically aware type conversion compilation device disclosed herein.

[0015] Figure 3 This is a structural diagram of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation

[0016] Example embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. It is obvious that the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure, and it should be understood that this disclosure is not limited to the example embodiments described herein.

[0017] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0018] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0019] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0020] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0022] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0024] The embodiments of this disclosure can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, or servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems, etc.

[0025] This disclosure outlines

[0026] In implementing this disclosure, the inventors discovered that current compilers typically translate statements based on entity types in simulation modeling languages. For example, they pre-establish a mapping between entity types in simulation modeling languages ​​and entity types in general-purpose programming languages. Then, for statements in a simulation modeling language program that contain entities, they determine the type of the entity in the statement and translate the statement into a statement in a general-purpose programming language program according to the aforementioned mapping. However, the actual usage of entities in simulation modeling languages ​​is very flexible. For example, the `wait eventpriority` statement and the `wait event` statement correspond to completely different queues. If both statements are mapped to `std::queue` in a general-purpose programming language based on the entity type... <event>This will cause errors in the subsequent event scheduling order, resulting in inaccurate simulation results.

[0027] If, during the translation of entities in a simulation modeling language program, the semantics of the statements containing entities are fully understood, and even the semantics of the context of those statements are fully understood, then a more appropriate translation method can be adopted, thereby improving the consistency between the translation results and the source code.

[0028] Exemplary methods

[0029] Figure 1 This is a flowchart of an embodiment of the semantically aware type conversion compilation method provided in this disclosure. Figure 1 The method described mainly consists of two parts: the first part is the decision tree generation stage, and the second part is the code generation stage of the general-purpose programming language. The decision tree generation stage is primarily used to generate decision trees for all entity-specific syntax rules in the simulation modeling language. The code generation stage of the general-purpose programming language is mainly used to translate source code into target code using the decision trees.

[0030] like Figure 1 The illustrated embodiment mainly includes the following steps: S100, S101, S102, S103, S104, and S105. S100, S101, and S102 belong to the decision tree generation stage, while S103, S104, and S105 belong to the code generation stage of a general-purpose programming language. The steps within each of these two stages are described in detail below.

[0031] S100. Obtain the first semantic features of each syntax rule set by the simulation modeling language for each first entity type.

[0032] The simulation modeling language in this disclosure can be SimScript or similar languages ​​used in discrete event simulation. Entities in the simulation modeling language of this disclosure are the fundamental core elements of the simulation system, possessing independent identities, states, and behaviors. They are the basic units for constructing simulation models, and entities in the simulation modeling language typically have lifecycles.

[0033] In one example, the entity type in the simulation modeling language of this disclosure (referred to as the first entity type to distinguish it from entity types in general programming languages) may include at least one of: events, resources, queues, lists, and variables. Alternatively, the first entity type in the simulation modeling language may also be other entity types besides those listed above. This disclosure does not limit the specific representation of the first entity type in the simulation modeling language. By including one or more of events, resources, queues, lists, and variables in the first entity type, appropriate translation strategies can be provided for corresponding types of entities according to actual needs, and the compilation technology of this disclosure can cover all entities in the simulation modeling language as comprehensively as possible.

[0034] The syntax rules set for the first entity type in the simulation modeling language of this disclosure can be considered as unified syntax specifications and format conventions predefined at the language level for declaring, identifying, distinguishing, and constraining various simulation entities. For example, the syntax rules can specify entity declaration keywords, writing formats, legal combination methods, and usage constraints. The syntax rules set separately for each first entity type in the simulation modeling language can ensure that all types of entities can be correctly identified and processed during simulation operation.

[0035] In one example, this disclosure can obtain all the syntax rules set by the simulation modeling language for each first entity type from the syntax manual provided by the simulation modeling language. The syntax manual of the simulation modeling language usually refers to the officially released technical document (such as the syntax manual provided by the SimScript official website), and this technical document can usually completely and standardly define all the syntax structures, keywords, statement formats, semantic rules, and usage constraints of the simulation modeling language.

[0036] In one example, this disclosure can first perform syntactic analysis on all the syntactic rules in the syntax manual of the simulation modeling language to determine the syntactic rules for each first entity type in the syntax manual, that is, to select the syntactic rules set by the simulation modeling language for each first entity type from the syntax manual. Then, this disclosure can perform semantic analysis on each selected syntactic rule to obtain the semantic features of each syntactic rule for each first entity type (to distinguish it from the semantic features extracted from statements containing entities in general programming language programs, it is called the first semantic feature). Thus, this disclosure can form the correspondence information between the first entity type and the first semantic feature of the simulation modeling language. For example, assuming that a first entity type has N (N is an integer greater than 1) ways of use, and each way of use corresponds to a syntactic rule, then this disclosure can obtain N records by performing semantic analysis on these N syntactic rules, and each record includes the first entity type and the corresponding first semantic feature. In addition, this disclosure can pre-set a type semantic knowledge base, and the type semantic knowledge base includes at least the first entity type and the first semantic feature of the simulation modeling language. Thus, this disclosure can store all the correspondence information of the first entity type and the first semantic feature obtained above in the type semantic knowledge base.

[0037] By obtaining the first semantic features of each syntax rule set by the simulation modeling language for each first entity type from the syntax manual of the simulation modeling language, the correspondence information between the first entity type and the first semantic feature obtained in this disclosure is characterized by standardization, authority, accuracy, and comprehensiveness. Storing the correspondence information between the first entity type and the first semantic feature using a type semantic knowledge base facilitates the formation of structured and reusable basic knowledge information. For example, it allows for convenient grouping, organization, and maintenance of the correspondence information between the first entity type and the first semantic feature by entity type, thus facilitating the subsequent generation of decision trees.

[0038] In one example, for an entity of the type of event, the first semantic features obtained by this disclosure from different syntactic rules for events may include: support for priority, waiting queues (such as entering a queue waiting for an event), and blocking wake-up (such as resuming execution when an event is triggered).

[0039] In one example, for an entity of the type of resource, the first semantic features obtained from different syntactic rules for resources in this disclosure may include: support for resource request / release (e.g., acquiring the right to use a resource through a request operation and returning the resource through a release operation), support for concurrent access (e.g., allowing multiple processes to request, occupy, and release the same resource simultaneously), and support for priority queuing (e.g., allowing waiting processes to be sorted by priority when resources are insufficient, so that processes with higher priority are allocated resources first).

[0040] In one example, for an entity of the type queue, the first semantic features obtained from different syntactic rules for queues in this disclosure may include: support for first-in, first-out (i.e., support for entities that enter the queue first to leave the queue) and support for priority ordering (i.e., support for entities to be queued in the queue according to their priority, so that entities with higher priority are placed before entities with lower priority, and ensuring that the entity dequeued is always the entity with the highest priority).

[0041] In one example, for entities of the type list, the first semantic features obtained by this disclosure from different syntax rules for lists may include: support for insertion operations (such as supporting adding an entity to a list at any time), support for deletion operations (such as supporting removing an entity from a list at any time), and support for frequent insertion / deletion operations (such as supporting a large number of repeated dynamic insertion / deletion operations).

[0042] In one example, for entities of the type variable, the first semantic features obtained from different syntax rules for variables in this disclosure may include: supporting dynamic assignment (such as supporting the value of a variable to be modified or reset multiple times during simulation) and supporting the possibility of being null (such as supporting the variable to be in an empty state during simulation, i.e., allowing the variable to not point to any valid object or not contain a valid value during simulation).

[0043] It should be noted that the above is merely an illustrative example of the first entity type and the extracted first semantic features. The first entity type may also include user-defined entity types (such as distributed_queue), and the syntax rules set by the simulation modeling language for each first entity type may also include user-defined syntax rules. This disclosure does not limit the specific manifestation of the first entity type and syntax rules in the simulation modeling language. Furthermore, this disclosure can employ existing semantic analysis processes to perform semantic analysis on the corresponding syntax rules to extract their semantic features; the specific process will not be described in detail here.

[0044] S101. For each syntax rule set by the simulation modeling language for each first entity type, set the corresponding second entity type and required components based on the general programming language.

[0045] The general programming language used in this disclosure can be an object-oriented programming language (such as C++).

[0046] In one example, the second entity type of the general-purpose programming language in this disclosure may include: a pointer type to an event object (such as a shared smart pointer type to an event object), a pointer type to a resource object (such as a shared smart pointer type to a resource object), a queue type (such as a first-in-first-out queue type or a priority queue type), a list container type (such as a doubly linked list type or a dynamic array type), and an optional value type (such as a nullable value type or a basic data type). This disclosure does not limit the specific manifestation of the second entity type of the general-purpose programming language.

[0047] In one example, the required components of this disclosure refer to the auxiliary mechanisms, data structures, and library components that must be introduced into the general-purpose programming language program to fully reproduce the behavior of the syntax rules in the simulation modeling language during simulation runtime. Furthermore, the required components of this disclosure can be categorized as follows: required components for event types, required components for resource types, required components for queue types, required components for list types, and required components for variable types, etc.

[0048] The required components for the above event types may include: a priority comparator, a wait queue, and a condition variable (such as std::condition_variable). The priority comparator is used to sort the events by priority. The wait queue is used to store processes waiting to be woken up by the event. The condition variable is used to implement the blocking-wake synchronization mechanism.

[0049] The required components for the aforementioned resource types may include: shared smart pointers, mutexes (such as std::mutex), and request queues. The mutexes can be encapsulated using a RAII (Resource Acquisition Is Initialization) mechanism. RAII binds the resource lifecycle to the object, automatically completing resource allocation and release, avoiding resource leaks and manual management errors. The shared smart pointer automatically manages the lifecycle of resource objects, working with a custom deleter to ensure safe resource release, preventing content leaks and dangling pointers. This shared smart pointer can be considered a pointer encapsulated using RAII; by binding the pointer resource to its lifecycle, it automatically releases the resource during destruction, thus achieving safe pointer management. The mutex ensures thread safety during concurrent access, preventing data races caused by multi-threaded resource contention. The request queue stores processes waiting for resource allocation when resources are insufficient, and sorts them by priority to implement a scheduling strategy that prioritizes resource allocation for higher-priority processes.

[0050] The required components for the above queue types may include an optional comparator. This optional comparator is used to provide custom priority comparison rules when processes in the queue need to be sorted according to priority. If the queue is a first-in, first-out queue, then an optional comparator is not required.

[0051] The required components for the above list type may include an access pattern auto-selector. This access pattern auto-selector is used to automatically select a doubly linked list or a dynamic array based on the actual use case of the list (such as frequent insertion / deletion operations or random access).

[0052] The required components for the above variable types may include a variable type inference engine. This variable type inference engine is used to determine whether to use a nullable type or a basic data type based on the variable's assignment state.

[0053] This disclosure utilizes decompilation techniques and trial-and-error experience accumulated during debugging to set up entity types (referred to as second entity types to distinguish them from entity types in the simulation modeling language) and required components in a general programming language for each syntax rule set for each first entity type in the simulation modeling language. This disclosure does not limit the specific implementation method of setting up the second entity type and required components in the general programming language.

[0054] In one example, this disclosure can utilize a type semantic knowledge base to store the correspondence information between the first entity type and the first semantic feature of the simulation modeling language, the second entity type of the general programming language, and the required components. That is, the type semantic knowledge base includes four parts: the first entity type of the simulation modeling language, the first semantic feature, the second entity type of the general programming language, and the required components. When the simulation modeling language is SimScript and the general programming language is C++, an example of the type semantic knowledge base is shown in Table 1 below:

[0055] Table 1

[0056]

[0057] S102. Based on the first entity type, first semantic feature, second entity type and required components mentioned above, establish a decision tree.

[0058] The decision tree disclosed herein is a tree-structured decision model. The decision tree continuously divides the dataset represented by the decision tree into smaller subsets through layer-by-layer binary or multi-branch classification judgments, ultimately outputting the classification result at the leaf nodes. Since the leaf nodes of the decision tree established in this disclosure represent the second entity type and required components for a general-purpose programming language, the decision tree established in this disclosure is used to represent the entity types and required components of the general-purpose programming language needed in the decision translation process.

[0059] In one example, during the process of building a decision tree using a type semantic knowledge base, this disclosure first organizes all records in the type semantic knowledge base into a type semantic graph, and then uses the type semantic graph to build the decision tree. The type semantic graph in this disclosure can be considered a structured, hierarchical, and reasonable knowledge system. For example, a node in the type semantic graph represents a specific item in the type semantic knowledge base, and the connection between nodes indicates that two nodes belong to the same record in the type semantic knowledge base. Forming a type semantic graph helps improve the efficiency of decision tree generation.

[0060] In one example, the process of constructing a type semantic graph based on all records in the type semantic knowledge base can be as follows: For any first entity type, all records containing that first entity type can be selected from the type semantic knowledge base, and the type semantic graph corresponding to that first entity type can be constructed by merging and organizing the same items in all the selected records. This disclosure can set up a separate type semantic graph for each first entity type, meaning different first entity types correspond to different type semantic graphs.

[0061] In a more specific example, this disclosure can organize all records in the type semantic knowledge base according to the first entity type of the simulation modeling language, thereby forming multiple categories of records. That is, all records with the same first entity type are grouped together to form multiple record sets. For example, all records of the event type in the type semantic knowledge base are grouped into a first record set, all records of the resource type are grouped into a second record set, all records of the queue type are grouped into a third record set, all records of the list type are grouped into a fourth record set, and all records of the variable type are grouped into a fifth record set. Then, this disclosure can treat each item in a record in the type semantic knowledge base as a node, that is, the first entity type in the record is the first node, the first semantic feature in the record is the second node, the second entity type in the record is the third node, and the required component in the record is the fourth node. Thus, each record in the type semantic knowledge base can form a type semantic graph formed by sequentially connecting the four nodes. And the type semantic graphs corresponding to all records in a record set can be aggregated to form a type semantic graph spectrum. For example, by merging nodes with the same content, multiple type semantic graphs can be aggregated to form a type semantic graph spectrum. Specifically, the type semantic graphs formed by all records in the first record set are aggregated to form an event-based type semantic graph; the type semantic graphs formed by all records in the second record set are aggregated to form a resource-based type semantic graph; the type semantic graphs formed by all records in the third record set are aggregated to form a queue-based type semantic graph; the type semantic graphs formed by all records in the fourth record set are aggregated to form a list-based type semantic graph; and the type semantic graphs formed by all records in the fifth record set are aggregated to form a variable-based type semantic graph.

[0062] In one example, this disclosure can construct a decision tree in a top-down manner, and this disclosure can build a decision tree based on all types of semantic graphs, or build a decision tree separately for each type of semantic graph.

[0063] In one example, this disclosure first sets the root node of the decision tree (i.e., the first-level node), then sets multiple child nodes (i.e., the second-level nodes, for example, setting five child nodes for the five first entity types as the root node) based on the first entity type as the root node. After that, it sets the third-level nodes of the decision tree based on all nodes representing the first semantic features in the semantic graph of each type. Finally, it sets the leaf nodes of the decision tree based on the nodes of the corresponding second entity types and the nodes of the corresponding required components in the semantic graph of each type, thereby constructing a decision tree using all the semantic graphs of each type.

[0064] In another example, for any type of semantic graph, this disclosure first uses the nodes corresponding to the first entity type in the semantic graph to set the root node of a decision tree. Then, according to the nodes corresponding to the first semantic features in the semantic graph, multiple child nodes are set for the root node of the decision tree (different first semantic features correspond to different child nodes). After that, according to all the nodes corresponding to the second entity type and all the nodes corresponding to the required components in the semantic graph, the leaf nodes of the decision tree are set, thereby constructing a decision tree for the semantic graph. Thus, this disclosure can construct event decision trees, resource decision trees, queue decision trees, list decision trees, and variable decision trees, etc.

[0065] By organizing the records in the type semantic knowledge base and forming a type semantic graph, not only can the scattered semantic knowledge be structured, which is beneficial for the structural reasoning in the subsequent decision tree building process, but the process of generating the decision tree can also be isolated from the structural changes of the semantic knowledge base. This helps to reduce the coupling of the system, thereby facilitating the generation of decision trees and improving the system's scalability and maintainability. This disclosure generates a type semantic graph for each entity type in the simulation modeling language and a decision tree for each type semantic graph. This not only reduces the complexity of the decision tree, thus reducing its computational and storage overhead, but also, when adding or deleting the first entity type, only the type semantic graph and decision tree need to be set for the newly added first entity type, or the corresponding type semantic graph and decision tree need to be deleted, without affecting other type semantic graphs or other decision trees. This further improves the system's scalability and maintainability.

[0066] In one example, during the aggregation process to form a type semantic graph, this disclosure can perform anomaly detection on the type semantic graph to filter out abnormal type semantic graphs, thereby preventing abnormal type semantic graphs from affecting the subsequent decision tree construction process. For example, if the contents of the first node and the second node of two type semantic graphs are exactly the same, but the contents of the third node or the fourth node are different, then an abnormal type semantic graph can be detected. When an abnormal type semantic graph is detected, the user can be notified of the anomaly in the type semantic knowledge base by outputting anomaly information or automatically rolling back, thereby ensuring the accuracy of the basic information in the type semantic knowledge base.

[0067] S103. Identify entity-based statements in the simulation modeling language program to determine the first entity type and second semantic feature corresponding to the entity-based statement.

[0068] This disclosure performs sentence-by-sentence syntactic analysis on simulation modeling language programs to filter out entity-based statements (i.e., statements containing entities), and then performs semantic analysis on the filtered entity-based statements to determine the specific type of the entity in the statement (i.e., the first entity type, such as event, resource, queue, list, or variable, etc.) and the second semantic feature (i.e., the semantic feature of the statement, such as priority support, waiting queue, or blocking wake-up, etc. in S100 above). This disclosure does not limit the specific implementation process of the syntactic and semantic analysis in this step.

[0069] In one example, after obtaining the first entity type and second semantic features corresponding to the entity-based statement, this disclosure can further perform a rationality check on the lifecycle behavior of each entity in the simulation modeling language program to determine whether there are any abnormalities in the entity behavior. The lifecycle behavior of an entity in the simulation modeling language program refers to a set of time-constrained behaviors performed by the entity from its creation until its destruction / recycling. That is, the lifecycle behavior of an entity typically includes multiple entity behaviors, and all entity behaviors included in the lifecycle behavior of an entity are time-sequential, which is usually determined by the simulation modeling language program. The specific implementation process of the rationality check in this disclosure can be as follows:

[0070] First, based on the recognition results of S103, the entity behaviors corresponding to each entity-based statement in the simulation modeling language program are obtained.

[0071] For events, entity behaviors can include creating an event, waiting for an event, activating an event, resetting an event, canceling an event, destroying an event, or querying the event status.

[0072] For resources, entity behaviors can include creating resources, requesting resources, releasing resources, or destroying resources.

[0073] For queues, entity behaviors can include creating a queue, enqueuing, dequeuing, querying the queue status, or destroying the queue.

[0074] For lists, entity behaviors can include creating a list, inserting elements, deleting elements, searching for elements, traversing a list, querying the list's status, or destroying a list.

[0075] For variables, entity behaviors can include creating variables, assigning values, retrieving values, modifying variables, querying variable status, or destroying variables.

[0076] Secondly, based on the entity behaviors corresponding to each of the above entity-based statements, the lifecycle behaviors of each entity are determined.

[0077] For any given entity, this disclosure sorts all entity behaviors of that entity to obtain the entity's lifecycle behaviors. For example, for any given entity, this disclosure can sort all entity behaviors of that entity according to the order of their positions in the simulation modeling language program (such as line number order) to obtain the entity's lifecycle behaviors. As another example, for any given entity, this disclosure can sort all entity behaviors of that entity according to the execution order of its statements (such as when the execution order differs from the order of their positions due to calling phenomena) to obtain the entity's lifecycle behaviors.

[0078] In one example, this disclosure can generate a lifecycle behavior graph for each entity based on its lifecycle behavior, thereby facilitating more convenient anomaly detection. The lifecycle behavior graph in this disclosure refers to a semantic model that represents entity states, entity behaviors, and the transitions in entity states caused by entity behaviors in a graph format. For example, for any entity, the nodes in its lifecycle behavior graph can be entity states (such as uncreated, idle, occupied, waiting, active, and destroyed states), and the edges in the graph represent entity behaviors (such as creation, request, yes / no, waiting, activation, and destruction behaviors). The edges in the graph are directed, and the nodes pointed to by the edges represent the transitions in entity states caused by the corresponding entity behaviors. This disclosure typically pre-sets constraint rules; for example, a set of constraint rules is set for each first entity type. These constraint rules can include: constraint rules for entity state transitions, constraint rules for the execution order of entity behaviors, and constraint rules for entity behavior dependencies. These constraint rules are used to detect anomalies in the lifecycle behavior graph.

[0079] Finally, abnormal behavior detection is performed on the lifecycle behavior of each entity, and when abnormal entity behavior is detected, the corresponding abnormal information is output according to the statement corresponding to the abnormal entity behavior.

[0080] The abnormal behavior detection in this disclosure may include: detection of missing preceding behaviors, detection of abnormal execution order of entity behaviors, detection of redundancy of entity behaviors, detection of mismatch of entity behaviors, detection of illegal transition of entity state, and detection of abnormal entity behavior context.

[0081] The detection of missing preceding behaviors refers to situations where an entity's behavior depends on the existence of a preceding behavior, but the preceding behavior does not precede the entity's behavior. For example, an activating event behavior should be preceded by a waiting event behavior. If the lifecycle behavior of event A does not include WAIT EVENT A, then WAIT EVENT A will not appear in the upstream edge of ACTIVATE EVENT A in the lifecycle behavior graph. Detecting missing preceding behaviors can identify ACTIVATE EVENT A as an abnormal entity behavior in the lifecycle behavior of event A. As another example, a requesting resource behavior should be preceded by a creating resource behavior. If the lifecycle behavior of resource B does not include CREATE RESOURCE B, then CREATE RESOURCE B will not appear in the upstream edge of REQUEST RESOURCE B in the lifecycle behavior graph. Detecting missing preceding behaviors can identify REQUEST RESOURCE B as an abnormal entity behavior in the lifecycle behavior of resource B.

[0082] The entity behavior execution order anomaly detection refers to detecting whether the execution order of entity behaviors violates the legal timing constraints specified by the simulation modeling language. For example, the upstream edge of an activation event behavior should contain a waiting event behavior. If the lifecycle behavior of event A includes WAIT EVENT A, but WAIT EVENT A in the lifecycle behavior graph is a downstream edge of ACTIVATE EVENT A, then WAIT EVENT A can be detected as an abnormal entity behavior through entity behavior execution order anomaly detection. As another example, the upstream edge of a request resource behavior should contain a create resource behavior. If the lifecycle behavior of resource B includes CREATE RESOURCE B, but CREATE RESOURCE B in the lifecycle behavior graph is a downstream edge of REQUEST RESOURCE B, then CREATE RESOURCE B can be detected as an abnormal entity behavior through entity behavior execution order anomaly detection.

[0083] Entity behavior redundancy detection refers to detecting whether the same entity behavior is executed repeatedly or whether entity behaviors are mutually exclusive. For example, the creation behavior of an event should not be repeated. If the lifecycle behavior of event A contains two consecutive ACTIVATE EVENT A, entity behavior redundancy detection can detect the existence of two starting edges (two starting nodes) in the lifecycle behavior graph, and the latter ACTIVATE EVENT A can be considered an abnormal entity behavior. As another example, the activation event behavior should generally not be executed again on an already activated event. If the lifecycle behavior of event A contains two consecutive ACTIVATE EVENT A, entity behavior redundancy detection can detect two identical edges in the lifecycle behavior graph pointing to the same node, and the latter ACTIVATE EVENT A can be considered an abnormal entity behavior.

[0084] The entity behavior mismatch detection refers to detecting whether an entity behavior matches its entity type. For example, a wait behavior should not be performed on a variable, an activation behavior should not be performed on a queue, and a request behavior should not be performed on a list. If WAIT C appears in the lifecycle behavior of variable C, the entity behavior mismatch detection can detect that the node pointed to by WAIT C in the lifecycle behavior graph is in an abnormal state, thus identifying WAIT C as an abnormal entity behavior. Similarly, if ACTIVATE D appears in the lifecycle behavior of queue D, the entity behavior mismatch detection can detect that the node pointed to by ACTIVATE D in the lifecycle behavior graph is in an abnormal state, thus identifying ACTIVATE D as an abnormal entity behavior. Likewise, if REQUEST E appears in the lifecycle behavior of list E, the entity behavior mismatch detection can detect that the node pointed to by REQUEST E in the lifecycle behavior graph is in an abnormal state, thus identifying REQUEST E as an abnormal entity behavior.

[0085] The illegal state transition detection of an entity refers to detecting whether the state transitions caused by subsequent actions conform to the legal state transition rules specified by the simulation modeling language, based on the current state of the entity. For example, when a resource is in a destroyed state, subsequent actions should not cause the resource's state to change to an occupied state. If the lifecycle behavior of resource B includes DESTROYRESOURCE B, and there is a REQUESTRESOURCE B downstream edge of DESTROYRESOURCE B in the lifecycle behavior graph, then the illegal state transition detection can detect REQUESTRESOURCE B as an abnormal entity behavior.

[0086] Entity behavior context anomaly detection refers to detecting whether entity behavior is within a valid scope, lifecycle stage, or execution environment. For example, if WAIT EVENT A appears in the lifecycle behavior of event A, and the context of WAIT EVENT A determines that it appears in the main program, initialization module, or ordinary subroutine, then entity behavior context anomaly detection can identify WAIT EVENT A as an abnormal entity behavior.

[0087] As described above, the basic information for abnormal behavior detection in this disclosure may include a lifecycle behavior graph. That is, when detecting whether an entity's behavior is abnormal, this disclosure can determine the context entity behavior based on the entity's lifecycle behavior graph, and then combine the entity behavior, its context entity behavior, and corresponding constraint rules to determine whether it is an abnormal behavior. For example, it can determine whether there is a preceding behavior in the context entity behavior, or whether the directed edges between the state transitions caused by the context entity behaviors and the state transitions caused by the entity behavior match preset directed edges. This disclosure does not limit the specific form of the constraint rules, nor does it limit the specific implementation process of using the lifecycle behavior graph for abnormal behavior detection.

[0088] By assigning lifecycle behaviors to each entity in a simulation modeling language program, and ensuring that these behaviors reflect the execution sequence of the entity's actions throughout its lifecycle, it's equivalent to extracting the entity's various usage points from the simulation modeling language program. This allows for a higher-level examination of the rationality of entity behavior during execution, enabling a context-aware assessment of the rationality of entity behavior. This facilitates the comprehensive and accurate detection of abnormal entity behavior. Furthermore, by generating corresponding lifecycle behavior maps for each entity's lifecycle behaviors, which reflect the entity's state transitions and the entity behaviors that trigger these transitions, the use of lifecycle behavior maps facilitates more accurate, convenient, and comprehensive detection of abnormal entity behavior. This helps to avoid compilation errors caused by abnormal entity behavior, thereby improving the reliability of compilation results.

[0089] S104. Based on the decision tree described above, perform decision processing on the first entity type and second semantic features corresponding to the entity-based statement to determine the leaf node corresponding to the entity-based statement.

[0090] The decision processing disclosed herein refers to a process based on a pre-established decision tree model, using the first entity type and second semantic features corresponding to entity-based statements as decision features, judging layer by layer according to the branching conditions of the decision tree, and finally outputting the corresponding decision result. This decision result may include: decision anomalies (such as no corresponding leaf node), or the finally determined leaf node, etc.

[0091] In one example, if a decision tree is set up for each entity type, this disclosure can first use the first entity type corresponding to the entity-based statement to determine the decision tree corresponding to the entity-based statement, and then use the decision tree determined above to perform decision processing on the second semantic feature corresponding to the entity-based statement (such as selecting the corresponding branch path according to the corresponding second semantic feature) to determine the leaf node corresponding to the entity-based statement.

[0092] In another example, when setting up a decision tree for all entity types, this disclosure can directly use the first entity type and second semantic feature corresponding to the entity-based statement and the decision tree to perform decision processing. For example, firstly, the child nodes of the root node corresponding to the entity-based statement are determined using the first entity type corresponding to the entity-based statement. Then, the decision processing continues from the child nodes of the root node (such as selecting the corresponding branch path according to the corresponding semantic feature) to determine the leaf nodes corresponding to the entity-based statement using the second semantic feature corresponding to the entity-based statement.

[0093] In one example, where this disclosure includes abnormal behavior detection, statements corresponding to abnormal entity behaviors can be removed first, while statements corresponding to detected normal entity behaviors can be retained. Then, a decision tree can be used to process the first entity type and second semantic features of each retained statement to determine the leaf node corresponding to each retained statement. This avoids unnecessary decision-making processes and improves decision-making efficiency.

[0094] S105. Based on the second entity type and required components contained in the leaf node corresponding to the above entity-based statement, generate target program code based on a general programming language for the above entity-based statement.

[0095] This disclosure allows for the pre-setting of corresponding functions (such as functions providing APIs) for each leaf node. Thus, when the leaf node corresponding to the entity-based statement is determined, the function to be used can be identified. By using relevant information from the entity-based statement (such as entity name and priority) as input parameters to the function and calling the function, the target program code based on a general programming language can be generated for the entity-based statement, thereby achieving standardized and accurate translation of entity-based statements.

[0096] In one example, for entities of event type or resource type, this disclosure, in the process of translating entity-based statements into target program code, can, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement, translate the entity-based statement into target program code encapsulated with RAII mechanisms, such as the destructor automatically calling the resource release operation `release` or the event triggering operation `signal`. For example, this disclosure can use shared smart pointers (such as `std::shared_ptr`) in the target program code, and the shared smart pointer can be wrapped in a safe function. This safe function will perform null checks and other operations on the shared smart pointer before accessing it to ensure the safe use of the pointer; as another example, this disclosure can use mutex locks encapsulated in RAII manner in the target program code to ensure concurrency safety.

[0097] In one example, this disclosure can add debug assertions to the translated general-purpose programming language program. For example, add assertion statements for debug mode (such as assert(ptr!= nullptr)) to the corresponding translated statements. In this way, during debug execution, if the condition in the assertion statement is met (such as detecting that the pointer is null), the program will automatically stop running, so as to quickly locate the runtime exception (such as null pointer access exception).

[0098] In another example, besides adding debug assertions to the translated general-purpose programming language program, this disclosure can also add auxiliary debugging statements, which are mainly used to provide users with prompts related to the cause of the runtime interruption. For example, auxiliary debugging statements may include statements for obtaining debug exception location information (such as statements for outputting the line number at the debug exception location), allowing users to quickly locate the program code causing the debug exception, thus improving program debugging efficiency; as another example, auxiliary debugging statements may include statements for obtaining context information at the exception location (such as statements for outputting the complete program code at the debug exception location), allowing users to promptly and intuitively understand the content that caused the debug exception.

[0099] Exemplary device

[0100] The structure of one embodiment of the semantically aware type conversion compiler disclosed herein is as follows: Figure 2 As shown. The apparatus of this embodiment can be used to implement the corresponding method embodiments of this disclosure. Figure 2 The apparatus shown mainly includes a decision tree generation sub-device 200 and a code generation sub-device 210 for a general-purpose programming language. The decision tree generation sub-device 200 includes a semantic feature acquisition module 201, a type component setting module 202, and a decision tree building module 203. The code generation sub-device 210 for the general-purpose programming language includes a statement recognition module 211, a decision processing module 212, and a translation module 213.

[0101] The semantic feature acquisition module 201 is mainly used to acquire the first semantic features of each syntax rule set by the simulation modeling language for each first entity type. For example, the semantic feature acquisition module 201 can perform syntactic analysis on the syntax manual of the simulation modeling language to acquire the syntax rules set by the simulation modeling language for each first entity type. Then, the semantic feature acquisition module 201 performs semantic analysis on each acquired syntax rule to obtain the first semantic features of each syntax rule. Finally, the semantic feature acquisition module 201 sets the first entity type and the first semantic features of each syntax rule in the type semantic knowledge base. The first entity type can include at least one of the following: event, resource, queue, list, and variable.

[0102] The type component module 202 is mainly used to set the corresponding second entity type and required components based on the general programming language for each syntax rule set for each first entity type in the simulation modeling language. For example, the type component module 202 sets the second entity type and required components based on the general programming language for each record belonging to the first entity type and the first semantic feature in the type semantic knowledge base.

[0103] The decision tree building module 203 is mainly used to build a decision tree based on the first entity types and first semantic features obtained by the semantic feature acquisition module 201, and the second entity types and required components set by the type component setting module 202. The second entity types and required components are used as leaf nodes of the decision tree. For example, the decision tree building module 203 can construct a type semantic graph based on all records in the type semantic knowledge base, and then organize the type semantic graph into a decision tree. More specifically, for any first entity type, the decision tree building module 203 can construct a type semantic graph corresponding to that first entity type based on all records in the type semantic knowledge base that contain that first entity type. Different first entity types correspond to different type semantic graphs. Then, the decision tree building module 203 organizes each type semantic graph into a decision tree for the corresponding first entity type, with different first entity types corresponding to different decision trees.

[0104] The statement recognition module 211 is mainly used to recognize entity-based statements in simulation modeling language programs in order to determine the first entity type and second semantic features corresponding to the entity-based statements.

[0105] In one example, the statement recognition module 211 can also obtain the entity behavior corresponding to each entity-based statement in the simulation modeling language program based on its recognition results, and determine the lifecycle behavior of each entity based on the entity behavior corresponding to each entity statement. Then, the statement recognition module 211 can perform abnormal entity behavior detection on the lifecycle behavior of each entity, and output corresponding abnormal information based on the statement corresponding to the abnormal entity behavior when an abnormal entity behavior is detected. More specifically, the statement recognition module 211 can generate a lifecycle behavior map for each entity based on its lifecycle behavior. Then, for any entity, the statement recognition module 211 can determine whether each entity behavior is an abnormal entity behavior based on the entity behavior in the entity's lifecycle behavior map, its context entity behavior, and the transition of entity states.

[0106] The decision processing module 212 is mainly used to perform decision processing on the first entity type and second semantic features obtained by the statement recognition module 211 based on the decision tree established by the decision tree generation sub-device 200, so as to determine the leaf node corresponding to the aforementioned entity-based statement. When the statement recognition module 211 performs abnormal entity behavior detection, for statements corresponding to detected normal entity behavior, the decision processing module 212 can perform decision processing on the first entity type and second semantic features corresponding to the statement based on the decision tree, so as to determine the leaf node corresponding to the statement.

[0107] The translation module 213 is primarily used to generate target program code based on a general-purpose programming language for the entity-based statement, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement obtained by the decision processing module 212. For example, for entities of event or resource type, the translation module 213 can generate target program code based on shared smart pointers for the entity-based statement, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement. As another example, for entities of resource type, the translation module 213 can generate target program code based on a mutex lock encapsulated in a resource acquisition and initialization mechanism for the entity-based statement, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement.

[0108] In another example, the translation module 213 can also set debug runtime assertions and auxiliary debugging statements based on a general programming language for the target program code. The auxiliary debugging statements may include statements for obtaining debug runtime exception location information and statements for obtaining context information at the exception location.

[0109] Exemplary electronic devices

[0110] The following is for reference. Figure 3 To describe an electronic device according to embodiments of the present disclosure. Figure 3 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. (As follows) Figure 3 As shown, the electronic device 31 includes one or more processors 311 and memory 312.

[0111] The processor 311 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 31 to perform desired functions.

[0112] The memory 312 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, and flash memory. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 311 may execute the program instructions to implement the semantically aware type conversion compilation methods of the various embodiments of this disclosure described above and / or other desired functions.

[0113] In one example, electronic device 31 may further include input device 313 and output device 314, etc., these components being interconnected via a bus system and / or other forms of connection mechanism (not shown). Furthermore, the input device 313 may include, for example, a keyboard, mouse, etc. The output device 314 can output various information to the outside. The output device 314 may include, for example, a display, speaker, printer, and communication network and its connected remote output devices, etc.

[0114] Of course, for the sake of simplicity, Figure 3 Only some of the components of the electronic device 31 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 31 may include any other suitable components depending on the specific application.

[0115] Exemplary computer program products and computer-readable storage media

[0116] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the semantically aware type conversion compilation methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0117] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0118] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the semantically aware type conversion compilation method according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0119] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (not an exhaustive list) may include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0120] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0121] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0122] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0123] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0124] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0125] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0126] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.< / event>

Claims

1. A semantically aware type conversion compilation method, characterized in that, The method includes: a decision tree generation stage and a code generation stage in a general programming language; The decision tree generation stage includes the following steps: Obtain the first semantic features of each syntax rule set by the simulation modeling language for each first entity type; For each syntax rule set by the simulation modeling language for each first entity type, set its corresponding second entity type and required components based on a general programming language; A decision tree is established based on the first entity type, the first semantic feature, the second entity type, and the required component; wherein the second entity type and the required component are used as leaf nodes of the decision tree. The code generation phase of the general-purpose programming language includes the following steps: Entity-based statements in simulation modeling language programs are identified to determine the first entity type and second semantic feature corresponding to the entity-based statements. The decision tree is used to perform decision processing on the first entity type and the second semantic feature corresponding to the entity-based statement in order to determine the leaf node corresponding to the entity-based statement. Based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement, generate target program code based on a general programming language for the entity-based statement.

2. The method according to claim 1, characterized in that, The first semantic features of the syntax rules set for each first entity type by the simulation modeling language include: Syntactic analysis is performed on the syntax manual of the simulation modeling language to obtain the syntax rules set by the simulation modeling language for each first entity type. Semantic analysis is performed on each of the acquired grammatical rules to obtain the first semantic feature of each grammatical rule; Set the first entity type and the first semantic features of each grammatical rule in the type semantic knowledge base.

3. The method according to claim 2, characterized in that, For each syntax rule set for a first entity type in the simulation modeling language, the corresponding second entity type and required components based on a general programming language are set, including: For each record belonging to the first entity type and the first semantic feature in the type semantic knowledge base, set a second entity type and the required components based on a general programming language; Furthermore, the step of establishing a decision tree based on the first entity type, the first semantic feature, the second entity type, and the required components includes: Based on all records in the type semantic knowledge base, a type semantic graph is constructed, and the type semantic graph is organized into a decision tree.

4. The method according to claim 3, characterized in that, The step of constructing a type semantic graph based on all records in the type semantic knowledge base includes: For any first entity type, a type semantic graph corresponding to the first entity type is constructed based on all records of the first entity type in the type semantic knowledge base, and different first entity types correspond to different type semantic graphs; The step of organizing the semantic graph of the type into a decision tree includes: Each type of semantic graph is organized into a decision tree for the corresponding first entity type, and different first entity types correspond to different decision trees.

5. The method according to claim 1, characterized in that, The step of identifying entity-based statements in a simulation modeling language program to determine the first entity type and second semantic feature corresponding to the entity-based statement further includes: Based on the recognition results, the entity behaviors corresponding to each entity-based statement in the simulation modeling language program are obtained. Based on the entity behavior corresponding to each entity-based statement, determine the lifecycle behavior of each entity; Abnormal entity behavior is detected for the lifecycle behavior of each entity, and when abnormal entity behavior is detected, the corresponding abnormal information is output according to the statement corresponding to the abnormal entity behavior.

6. The method according to claim 5, characterized in that, The step of determining the lifecycle behavior of each entity based on the entity behavior corresponding to each entity-based statement further includes: Based on the lifecycle behavior of each entity, a lifecycle behavior map is generated for each entity. Furthermore, the abnormal entity behavior detection for each entity's lifecycle behavior includes: For any given entity, determine whether each entity behavior is an anomalous entity behavior based on the entity behaviors in the entity's lifecycle behavior graph, the behavior of its context entities, and the transitions of the entity's state.

7. The method according to claim 5, characterized in that, The step of performing decision processing based on the decision tree on the first entity type and second semantic features corresponding to the entity-based statement to determine the leaf node corresponding to the entity-based statement includes: For the statements corresponding to the detected normal entity behavior, the decision tree is used to make a decision on the first entity type and the second semantic feature corresponding to the statement in order to determine the leaf node corresponding to the statement.

8. The method according to any one of claims 1 to 7, characterized in that, The first entity type includes at least one of the following: event, resource, queue, list, and variable.

9. The method according to claim 8, characterized in that, The step of generating target program code based on a general-purpose programming language for the entity-based statement according to the second entity type and required components contained in the leaf node corresponding to the entity-based statement includes at least one of the following: For entities of event or resource type, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement, target program code based on shared smart pointers is generated for the entity-based statement; For entities of resource type, based on the second entity type and required components contained in the leaf node corresponding to the entity-based statement, target program code for a mutex lock encapsulated based on the resource acquisition and initialization mechanism is generated for the entity-based statement.

10. The method according to claim 9, characterized in that, The step of generating target program code based on a general-purpose programming language for the entity-based statement according to the second entity type and required components contained in the leaf node corresponding to the entity-based statement further includes: For the target program code, set debugging assertions and auxiliary debugging statements based on a general programming language; The auxiliary debugging statements include: statements for obtaining debugging operation exception location information, and statements for obtaining context information at the exception location.

11. A semantically aware type conversion compilation device, characterized in that, The device includes: a decision tree generation sub-device and a code generation sub-device for a general programming language; The decision tree generation sub-device includes: The semantic feature acquisition module is used to acquire the first semantic features of each syntax rule set by the simulation modeling language for each first entity type. The Type Components module is used to set the corresponding Second Entity Type and required components based on the general programming language for each syntax rule set for each First Entity Type in the simulation modeling language. A decision tree building module is used to build a decision tree based on the first entity type, the first semantic feature, the second entity type, and the required component; wherein the second entity type and the required component are used as leaf nodes of the decision tree. The code generation sub-device for the general programming language includes: The statement recognition module is used to recognize entity-based statements in the simulation modeling language program to determine the first entity type and second semantic feature corresponding to the entity-based statement. The decision processing module is used to perform decision processing on the first entity type and second semantic features corresponding to the entity-based statement based on the decision tree, so as to determine the leaf node corresponding to the entity-based statement. The translation module is used to generate target program code based on a general programming language for the entity-based statement according to the second entity type and required components contained in the leaf node corresponding to the entity-based statement.

12. A computer-readable storage medium storing a computer program for performing the method of any one of claims 1-10.

13. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method of any one of claims 1-10.

Images