Method for converting and optimizing program codes in different program languages
By analyzing and processing the abstract syntax tree of the program code, the conversion and optimization between graphical programming languages and text programming languages are realized, solving the problem of ineffective conversion and optimization in existing technologies, improving the programming efficiency of PLCs and reducing development costs.
Patent Information
- Application Number
- CN202110356595.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-04-01
- Publication Date
- 2026-01-13
- Estimated Expiration
- 2041-04-01
AI Technical Summary
Existing program conversion programs cannot effectively convert program code between graphical programming languages and text programming languages, nor can they convert and optimize program segments, resulting in wasted PLC resources and increased development costs.
The abstract syntax tree of the program code is analyzed and processed by a syntax marker parser and a semantic combiner to realize the conversion between graphical programming languages and text-based programming languages. The semantic optimizer is then used to optimize the code and generate optimized program fragments that conform to the target programming language.
It achieves homogeneous conversion between different programming languages, improves PLC programming efficiency, saves PLC resource usage, shortens project integration time, and reduces the development cost of industrial automation production lines.
Smart Images

Figure CN115167860B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to program languages, and in particular, to a method for converting and optimizing program codes between different program language architectures. BACKGROUND
[0002] Currently, in the field of industrial automation, developers can use a variety of different program languages for development, and various program languages are respectively provided for different subject background persons and different industrial fields.
[0003] Specifically, the commonly used program languages in the field of industrial automation include traditional ladder diagrams, function block diagrams, continuous function charts, sequential function charts, structured texts, PASCAL, Java, C / C++ / C#, Python, Objective-C, Lua, etc., and can be generally divided into graphical program languages and textual program languages.
[0004] As described above, various different program languages have different user groups, so not all developers use all program languages. In order to overcome the above problems, some industrial control products on the market currently provide conversion programs that can convert program codes between a few graphical program languages.
[0005] However, the conversion programs currently available on the market are mainly designed for graphical program languages, and cannot convert program code logic written based on a graphical program language architecture into program code that conforms to a textual program language architecture and has a homogeneous semantic meaning, cannot convert program code logic written based on a textual program language architecture into program code that conforms to a graphical program language architecture and has a homogeneous semantic meaning, and also cannot exchange program codes between different textual program language architectures.
[0006] Furthermore, the aforementioned conversion program can only convert a complete program unit (POU) as a conversion unit, and cannot convert program segments, and cannot optimize the target program code after conversion. Therefore, the language conversion can generate inappropriate program code, causing waste of the registers, I / O points or memory of the programmable logic controller (PLC), and making the generated PLC file capacity too large, thereby increasing the overall development cost of the industrial automation production line. SUMMARY
[0007] The main purpose of the present application is to provide a method for converting and optimizing program codes between different program languages, which allows users to obtain program segments and convert them between graphical program languages and textual program languages to generate target program codes, and automatically optimize the target program codes after conversion.
[0008] To achieve the above-mentioned purpose, the conversion and optimization method of the present application is mainly applied to a program language editor, and includes the following steps:
[0009] a) obtaining a program segment written based on a source program language, wherein the source program language is a graphical program language or a textual program language;
[0010] b) obtaining an abstract syntax tree (AST) corresponding to the program segment, wherein the abstract syntax tree includes a plurality of blocks;
[0011] c) visiting one of the plurality of blocks in the abstract syntax tree by a syntax token parser;
[0012] d) querying a syntax token correspondence table according to the visited block to generate a syntax token corresponding to a target program language for the block, wherein the syntax token correspondence table records a correspondence relationship between a plurality of syntaxes of the source program language and a plurality of syntaxes of the target program language, and the target program language is a graphical program language or a textual program language;
[0013] e) repeating steps c and d before all the plurality of blocks are visited by the syntax token parser and the syntax token is generated;
[0014] f) visiting one of the plurality of blocks in the abstract syntax tree by a semantic combiner after all the plurality of blocks are visited by the syntax token parser and the syntax token is generated;
[0015] g) combining the content and the syntax tag of the block being visited with the content and the syntax tag of the last block being visited to generate an intermediate result;
[0016] h) repeating the step f and the step g to update the intermediate result before all the blocks are visited by the semantic combiner;
[0017] i) generating a target program segment according to the updated intermediate result after all the blocks are visited by the semantic combiner;
[0018] j) visiting a plurality of semantic combinations in the target program segment by a semantic optimizer, performing an equivalent replacement procedure when the plurality of semantic combinations meet a condition equation, and generating an optimized target program segment; and
[0019] k) outputting the optimized target program segment on the program language editor, wherein the optimized target program segment meets the target program language.
[0020] Compared with the related art, the present application can directly convert a source program segment written based on a graphical program language or a textual program language into a target program segment meeting an architecture of another program language, and make the target program segment have the same semantic as the source program segment. Therefore, the present application can greatly reduce the threshold for people with different academic backgrounds to enter the field of program design in the industrial automation industry, and improve the programming efficiency of a programmable logic controller (PLC), and shorten the integration time of a project.
[0021] In addition, the present application automatically performs optimization on the converted target program segment, thereby effectively saving the usage amount of a register, an I / O point, and a memory of the PLC, reducing the capacity of a generated PLC configuration file, and reducing the development cost of an industrial automation production line as a whole. BRIEF DESCRIPTION OF DRAWINGS
[0022] Figure 1 This is a first embodiment of a conversion and optimization flowchart of the present application.
[0023] Figure 2 This is a conversion scenario diagram of the present application.
[0024] Figure 3 This is a block diagram of a program language.
[0025] Figure 4A This is a conditional statement diagram of a program language.
[0026] Figure 4B This is a conditional operation diagram of a program language.
[0027] Figure 4C General diagram for a program language statement.
[0028] Figure 5 Second embodiment of the conversion and optimization flowchart of the present invention.
[0029] Figure 6 First embodiment of the recursive walk diagram of the present invention.
[0030] Figure 7 First embodiment of the abstract syntax tree diagram of the present invention.
[0031] Figure 8A First embodiment of the first flowchart of the syntax token of the present invention.
[0032] Figure 8B First embodiment of the second flowchart of the syntax token of the present invention.
[0033] Figure 9A First embodiment of the first flowchart of the semantic combination of the present invention.
[0034] Figure 9B First embodiment of the second flowchart of the semantic combination of the present invention.
[0035] Figure 10 First embodiment of the conversion diagram of the present invention.
[0036] Figure 11 Conversion diagram for different program languages.
[0037] Figure 12 First embodiment of the optimization flowchart of the present invention.
[0038] Figure 13 First embodiment of the optimization diagram of the present invention.
[0039] Figure 14A Second embodiment of the optimization flowchart of the present invention.
[0040] Figure 14B Third embodiment of the optimization flowchart of the present invention.
[0041] Figure 14C Fourth embodiment of the optimization flowchart of the present invention.
[0042] Explanation of reference signs:
[0043] 1... source program fragment
[0044] 11... first walk block
[0045] 12... second walk block
[0046] 13 third traversal block
[0047] 14 syntax tag
[0048] 2 destination program fragment
[0049] 21 first node
[0050] 22 second node
[0051] 23 third node
[0052] 24 fourth node
[0053] 25 fifth node
[0054] 31 general block
[0055] 32 consecutive block
[0056] 33 branching block
[0057] 41 conditional statement
[0058] 42 conditional operation
[0059] 43 general statement
[0060] 5 abstract syntax tree
[0061] 6 destination program fragment
[0062] 61 first network
[0063] 62 second network
[0064] 63 third network
[0065] 64 fourth network
[0066] 65 fifth network
[0067] 71, 73, 75 destination program fragment before optimization
[0068] 72, 74, 76 destination program fragment after optimization
[0069] S10-S15, S21-S31 conversion and optimization steps
[0070] S41-S57 tagging steps
[0071] S60-S77 combining steps
[0072] S80-S82 optimization steps DETAILED DESCRIPTION
[0073] A preferred embodiment of the present application will be described in detail below with reference to the accompanying drawings.
[0074] The present application discloses a method for converting and optimizing program codes between different program languages (hereinafter referred to as the optimization method in the specification). The optimization method is mainly applied in a program language editor of any program language, and is realized by an application program attached to the program language editor.
[0075] Specifically, the optimization method of the present application is written in the form of program codes into an application program which can be independently run and can analyze and process program codes. Based on the functions to be realized by the optimization method, the application program can be logically divided into a first sub-program used as a syntax tag parser, a second sub-program used as a semantic combiner, and a third sub-program used as a semantic optimizer. It is worth mentioning that the above-mentioned syntax tag parser and semantic combiner in the present application mainly analyze and process the Abstract Syntax Tree (AST) of the program codes to be analyzed and processed, but are not limited thereto.
[0076] Referring to Figure 1 and Figure 2 , wherein Figure 1 is the first specific embodiment of the conversion and optimization flowchart of the present application, Figure 2 is the conversion context diagram of the present application. As shown in Figure 1 , the optimization method of the present application first obtains the to-be-converted program codes written in the architecture of the source program language from the program language editor (step S10), then analyzes and processes the to-be-converted program codes by the syntax tag parser (step S11) to record the syntax tags corresponding to the architecture of the target program language for each program element in the to-be-converted program codes. Then, the optimization method analyzes and processes the to-be-converted program codes by the semantic combiner (step S12) to combine each program element with completed syntax tags, thereby generating the converted program codes conforming to the architecture of the target program language (step S13).
[0077] After step S13, the optimization method of the present application analyzes and processes the converted program codes by the semantic optimizer (step S14) to simplify the plurality of program elements contained in the converted program codes. Finally, the simplified program codes are output on the program language editor (step S15).
[0078] The optimization method of the present application can avoid generating complicated and lengthy converted program codes in the conversion process for meeting the normalized conversion rules by simplifying the converted program codes through the semantic optimizer. In this way, the usage of registers, I / O points and memory space of a programmable logic controller (PLC) can be effectively saved.
[0079] As mentioned above, the optimization method of the present application mainly analyzes and processes the Abstract Syntax Tree (AST) of a program code, rather than directly analyzing and processing the content of the program code. Therefore, the main purpose of the present application can be achieved, i.e., converting a program code written in a graphical programming language into a program code conforming to the architecture of a textual programming language or another graphical programming language, and converting a program code written in a textual programming language into a program code conforming to the architecture of a graphical programming language or another textual programming language.
[0080] In an embodiment, the graphical programming language may, for example, include a traditional Ladder Diagram programming language, a Function Block Diagram programming language, a Continuous Function Chart programming language and a Sequential Function Chart programming language, but is not limited thereto. The textual programming language may, for example, include a Structured Text programming language, a PASCAL programming language, a Java programming language, a C / C++ / C# programming language, a Python programming language, an Objective-C programming language and a Lua programming language, but is not limited thereto.
[0081] More specifically, the syntax token parser records at least one normalized syntax token correspondence table (not shown in the figure), which records the correspondence between the syntax of one program language and the syntax of other program languages. Through the query of the syntax token correspondence table, the syntax token parser can convert the syntax used in a program code between different program languages. Moreover, when a new program language appears, the content of the syntax token correspondence table only needs to be added, so that the optimization method of the present application can be further applied to the new program language. In this way, the expansion flexibility of the optimization method of the present application is effectively improved.
[0082] And, as mentioned above, the optimization method of the present application mainly analyzes and processes each program element contained in the program code respectively (i.e., analyzes and processes each node in the abstract syntax tree respectively, which will be described later), thus, not only a complete program unit (POU) in the program code can be taken as a conversion unit, but also a logically complete program segment can be taken as a conversion unit. In this way, the use flexibility and efficiency of the optimization method can be effectively improved.
[0083] It is worth mentioning that in some embodiments, the program editor does not need to convert a program segment from the architecture of the source program language to the architecture of the target program language. In this case, the optimization method of the present application can still analyze and process the source program code directly through the semantic optimizer, thereby directly simplifying the source program code to generate the optimized target program code without performing the conversion program.
[0084] As shown in Figure 2 , the program editor can open a first program language editor on a computer device. On the first program language editor, the program editor can open or write a program unit based on the first program language (for example, the ladder program language in the Figure 2 ). And, the program editor can also open a second program language editor on the same or different computer device. On the second program language editor, the program editor can open a project of another program language based on the second program language (for example, the structured text program language in the Figure 2 ). The computer device can be a desktop computer, a notebook computer, a tablet computer, or other smart devices, but the present application is not limited thereto.
[0085] In this working environment, the program editor can copy a logically complete source program segment 1 from the program unit on the first program language editor by a first operation instruction (for example, by copying or cutting through the keyboard or mouse), and then paste the source program segment 1 into the project on the second program language editor by a second operation instruction (for example, by pasting through the keyboard or mouse). One of the technical features of the present application is that when pasting the program, the optimization method of the present application can automatically detect the second program language used by the project, automatically convert the source program segment 1 into a target program segment 2 conforming to the architecture of the second program language and perform optimization, and then paste the converted and optimized target program segment 2 into the project, so that the program editor can directly use the converted and optimized target program segment 2 in the project.
[0086] As mentioned above, the optimization method of the present application is to correspond the syntax of different program languages through one or more syntax corresponding tables, so as to achieve the purpose of converting the program codes between different program language architectures. Therefore, the source program segment 1 before conversion and the target program segment 2 after conversion are two program segments 2 with the same semantic homogeneity. In other words, after executing the target program segment 2 on the second program language editor, the same result as executing the source program segment 1 on the first program language editor can be achieved.
[0087] Please refer to Figure 3 and Figures 4A-4C , in which Figure 3 is a block diagram of a program language, Figures 4A-4C are a conditional statement diagram, a conditional operation diagram and a general statement diagram of a program language, respectively.
[0088] Before starting to describe the optimization method of the present application in detail, the technical terms used in the following description are defined through the embodiments of Figure 3 and Figures 4A-4C . Specifically, Figure 3 and Figures 4A-4C are described by taking the ladder diagram program language as an example, but the same concept can be directly applied to other various program languages.
[0089] In the embodiments of Figure 3 , a single block is regarded as a normal block 31, two or more objects (including the normal block 31 or a branch block 33) connected in series are regarded as a continuous block 32, and two or more objects (including the normal block 31 or the continuous block 32) connected in parallel are regarded as a branch block 33. Moreover, in the embodiments of Figure 3 , the branch block 33 of the dashed line part is the upper layer of the continuous block 32 of the dashed line part, and the continuous block 32 of the dashed line part is the upper layer of the normal block 31 of the dashed line part.
[0090] Specifically, each of the above normal blocks 31 can include one object content (i.e., the question mark part above the block).
[0091] Please refer to Figures 4A-4C . Figure 4A The syntax of the conditional statement 41 is disclosed, and Figure 4A takes the conditional statement 41 of "IF……THEN……END_IF;" as an example, but is not limited thereto. Figure 4B The syntax of the conditional operation 42 is disclosed, and Figure 4BThe first embodiment of the general statement 43 is an example of "AND" and "NOT", Figure 4B The second embodiment of the general statement 43 is an example of "OR", but not limited to this. Figure 4C The syntax of the general statement 43 is disclosed, and Figure 4C The first embodiment of the general statement 43 is an example of "AND" and "NOT", Figure 4C The second embodiment of the general statement 43 is an example of "OR", but not limited to this. Figure 4C The third embodiment of the general statement 43 is an example of "OR logical statement" of the Boolean statement, but not limited to this.
[0092] Specifically, the syntax of the above-mentioned conditional statement 41, conditional operation 42 and general statement 43 belongs to the known technology in the field of program design, which will not be described here.
[0093] Referring to Figure 5 , the second embodiment of the conversion and optimization flowchart of the present application is shown. Specifically, as shown in Figure 5 , to execute the optimization method of the present application, first, the source program segment 1 written based on the source program language is obtained on the program language editor (step S21), and the abstract syntax tree of the source program segment 1 is obtained (step S22). In an embodiment, the source program segment 1 is a logically complete program segment, a complete program unit (POU) or an application program that has been written, which is not limited.
[0094] The abstract syntax tree has a plurality of blocks (or nodes) based on the content of the source program segment 1, which includes the general block 31, the sequential block 32 or the branch block 33. In an embodiment, the general block 31 can include an object content, which can include, for example, a conditional object, a function object or an end object. And the program language editor will configure a corresponding node temporary storage for each block, and record the object content of each block and the syntax token generated after the syntax token analyzer analyzes the syntax token in the node temporary storage configured for each block.
[0095] Please also refer to Figure 6 and Figure 7 , wherein Figure 6 is the first embodiment of the recursive tour schematic diagram of the present application, Figure 7 is the first embodiment of the schematic diagram of the abstract syntax tree of the present application.
[0096] Figure 6 A set of source program segments 1 (taking the ladder diagram program language as an example) and a set of target program segments 2 (taking the structured text program language as an example) obtained after the optimization method of the present application is disclosed,Figure 7 The abstract syntax tree 5 is disclosed. As can be seen by one skilled in the art, the abstract syntax tree 5 corresponds to the semantics of both the source program segment 1 and the destination program segment 2. Therefore, by traversing the blocks (i.e., nodes) of the abstract syntax tree 5, the optimization method of the present application can sequentially obtain each program element contained in the source program segment 1, and then combine the program elements after the conversion of the homogeneous semantics to form the destination program segment 2.
[0097] Returning to Figure 5 After step S22, the program language editor traverses one of the blocks of the abstract syntax tree 5 by using the syntax token parser (step S23). When performing the traversal operation, the syntax token parser obtains the object content of the block being traversed and the connection relationship between the block and the adjacent blocks, and then queries the syntax token correspondence table according to the object content and the connection relationship, thereby generating the syntax token corresponding to the destination program language and recording the syntax token in the node temporary storage assigned to the block (step S24).
[0098] As described above, the syntax token correspondence table records the correspondence relationship between the plurality of syntaxes of the source program language (which can be a graphical program language or a textual program language) and the plurality of syntaxes of the destination program language (which can be a graphical program language or a textual program language). In Figure 6 In the embodiment of the present application, the source program segment 1 uses the ladder program language, and the destination program segment 2 uses the structured textual program language. In step S24, the syntax token parser mainly queries a first syntax token correspondence table recording the correspondence relationship between the plurality of syntaxes of the ladder program language and the plurality of syntaxes of the structured textual program language, thereby generating the syntax token for each block of the source program segment 1. The syntax token mainly records the object content of each block of the source program segment 1 and the expression manner that the connection relationship should have in the destination program segment 2.
[0099] After step S24, the syntax token parser determines whether all the blocks of the source program segment 1 have been traversed (step S25), and repeatedly performs steps S23 and S24 before all the blocks are traversed, to traverse the next block of the source program segment 1 and generate the corresponding syntax token for the next block. In other words, the syntax token parser of the present application mainly traverses all the blocks contained in the source program segment 1 in a recursive manner.
[0100] It is worth mentioning that, based on the complexity of the source program fragment 1, it is possible that the syntax tagging of all blocks cannot be completed by a single recursive traversal action. For example, if the source program fragment 1 contains a complex final statement (e.g. with multiple ELSE or ELSEIF), the syntax tagging parser needs to perform at least two recursive traversals to complete the syntax tagging action. Specifically, in the above example, the syntax tagging parser needs to fetch all the final statements behind the block in the first recursive traversal action, and perform syntax tagging based on the object content of each block, the connection relationship between adjacent blocks, and all the final statements behind the block in the second recursive traversal action.
[0101] In view of the above problems, in another embodiment, the syntax tagging parser of the present application can traverse the blocks in the abstract syntax tree 5 in a forward recursive manner (i.e. in the order of the first traversal block 11, the second traversal block 12, and the third traversal block 13 shown in FIG. 1) when the source program language is a textual program language. If the source program language is a graphical program language, the syntax tagging parser can traverse the blocks in the abstract syntax tree 5 in a reverse recursive manner (i.e. in the order of the third traversal block 13, the second traversal block 12, and the first traversal block 11 shown in FIG. 1). By bringing the final statements behind the block into the next traversal action for reference, it can be ensured that the syntax tagging of all blocks in the source program fragment 1 can be completed in a single recursive traversal action. Figure 6 Figure 6 In view of the above problems, in another embodiment, the syntax tagging parser of the present application can traverse the blocks in the abstract syntax tree 5 in a forward recursive manner (i.e. in the order of the first traversal block 11, the second traversal block 12, and the third traversal block 13 shown in FIG. 1) when the source program language is a textual program language. If the source program language is a graphical program language, the syntax tagging parser can traverse the blocks in the abstract syntax tree 5 in a reverse recursive manner (i.e. in the order of the third traversal block 13, the second traversal block 12, and the first traversal block 11 shown in FIG. 1). By bringing the final statements behind the block into the next traversal action for reference, it can be ensured that the syntax tagging of all blocks in the source program fragment 1 can be completed in a single recursive traversal action.
[0102] Returning to Figure 5 If the syntax tagging parser determines in step S25 that all the blocks in the source program fragment 1 have been traversed, the program language editor further traverses one of the blocks in the abstract syntax tree 5 by the semantic combiner (step S26). Specifically, in step S26, the semantic combiner mainly traverses the blocks that have already been provided with syntax tagging.
[0103] After step S26, the semantic combiner takes out the object content and syntax tagging of the block being traversed from the node register of the block, and combines the object content and syntax tagging of the block with the object content and syntax tagging of the last block being traversed to generate an intermediate result (step S27). It is worth mentioning that, when the traversal action is performed for the first time, or when the current traversal action cannot be combined with the last traversal action, the semantic combiner directly combines the object content and syntax tagging of the current block being traversed to generate an initial intermediate result.
[0104] After step S27, the semantic combiner determines whether all blocks in the source program fragment 1 have been visited (step S28), and repeats steps S26 and S27 until all blocks have been visited, to update the intermediate result by the object content and the syntax tag of the next block. In other words, the semantic combiner of the present application visits all blocks in the source program fragment 1 in a recursive manner.
[0105] It is worth mentioning that the main function of the semantic combiner of the present application is to combine the object content and the syntax tag of each block, and therefore, whether the source program language is a text program language or a graphical program language, the semantic combiner can decide to visit each block in the abstract syntax tree 5 in a forward recursive manner, or in a backward recursive manner, without limitation.
[0106] If the syntax tag parser determines that all blocks in the source program fragment 1 have been visited in step S28, the semantic combiner can generate the destination program fragment 2 from the last updated intermediate result (step S29). The syntax tag parser of the present application generates the syntax tag of each block based on the syntax adopted by the destination program language, and the semantic combiner directly combines the object content and the syntax tag of each block. Therefore, the destination program fragment 2 generated in step S29 conforms to the architecture of the destination program language.
[0107] After step S29, the program language editor further visits one or more semantic combinations in the destination program fragment 2 by the semantic optimizer (step S30), and when the one or more semantic combinations meet the condition equation, performs an equivalent replacement procedure to generate an optimized destination program fragment (step S31). Finally, the program language editor can output the optimized destination program fragment on its page, which has been converted and optimized, for a program editor to directly use in the project of the destination program language.
[0108] In the present application, the equivalent replacement procedure mainly simplifies one or more semantic combinations in the destination program fragment 2 (for example, using the associative law, the distribution law, De Morgan's theorem, or the Mann graph in algebraic identities), to reduce the number of blocks included in the destination program fragment 2, thereby saving the usage rate of the node register and the I / O point in the PLC, and further reducing the development cost (to be described later).
[0109] Please also refer to Figure 6 , Figure 8A and Figure 8B , wherein Figure 8A and Figure 8BThe first flowchart and the first embodiment of the second flowchart of the syntax tag of the present application are used to specifically explain the recursive visiting action performed by the syntax tag parser of the present application.
[0110] Firstly, the syntax tag parser acquires a block which has not been visited in the source program segment 1 (step S41), and judges whether the block is a branch block 33 (step S42). If the block is a branch block 33, it is further judged whether the branch block 33 is the last block with conditional execution in the upper block (step S43). If the branch block 33 is indeed the last block with conditional execution in the upper block, the syntax tag parser acquires the corresponding conditional statement 41 (such as THEN, END_IF, etc.) according to the connection relationship between the branch block 33 and the adjacent block, inquires the syntax tag corresponding table according to the conditional statement 41 to acquire the syntax tag of the destination program language for the conditional statement 41, and records the syntax tag in the node temporary storage of the branch block 33 (step S44).
[0111] In addition, when the syntax tag parser judges that the currently visited block is a branch block 33, it acquires a corresponding conditional operation 42 (i.e. OR conditional operation) based on the function of the branch block 33 regardless of whether the branch block 33 meets the judgment of step S43, inquires the syntax tag corresponding table according to the conditional operation 42 to acquire the syntax tag of the destination program language for the conditional operation 42, and also records the syntax tag in the node temporary storage of the branch block 33 (step S45). After step S45, the syntax tag parser completes the visiting action of a branch block 33.
[0112] It is worth mentioning that if the syntax tag parser visits the blocks in the abstract syntax tree 5 in a reverse recursive manner, the syntax tag parser will bring the end statement (such as Out) pointed by the end object in the last general block 31 visited (such as shown in the subsequent step S56) into the next visiting action.
[0113] If the syntax tag parser visits in a reverse recursive manner, the syntax tag parser further brings the record of the end statement obtained in the last visiting action in step S45. In this way, in the current visiting action, the syntax tag parser can judge the syntax tag of the currently visited branch block 33 based on the record of the end statement (for example, according to the record of the end statement, it is judged that the conditional object in the analysis block 33 visited this time is the conditional statement 41 "THEN", "ELSE" or "ELSEIF", etc.).
[0114] The above description is only one specific embodiment of the present application, but is not limited thereto.
[0115] If the current block being visited is not a branch block 33, the syntax token parser further determines whether the block is a continuous block 32 (step S46). If the block is a continuous block 32, the syntax token parser further determines whether the continuous block 32 is the last conditionally executed block in the upper block (step S47). If the continuous block 32 is indeed the last conditionally executed block in the upper block, the syntax token parser obtains the corresponding conditional statement 41 (e.g., THEN, END_IF, etc.) based on the connection of the continuous block 32 with its neighboring blocks, queries the syntax token corresponding table with the conditional statement 41 to obtain the syntax token for the conditional statement 41 in the target programming language, and records the syntax token in the node register of the continuous block 32 (step S48).
[0116] Similarly, if the syntax token parser is performing the visiting action in a backward recursive manner, the syntax token parser will always bring in the record of the end statement obtained in the last visiting action in step S49, regardless of whether the continuous block 32 being visited is the last conditionally executed block in the upper block, for the same reason as above. After step S49, the syntax token parser has completed a visiting action for a continuous block 32.
[0117] If the block being visited is neither a branch block 33 nor a continuous block 32, the syntax token parser determines that the block being visited is a general block 31. Accordingly, the syntax token parser determines whether the general block 31 contains a condition object (step S50), a function object (step S54), or an end object (step S56).
[0118] If the general block 31 being visited is determined to contain a condition object in step S50, the syntax token parser further determines whether the condition object is the first condition object or the last condition object in a continuous condition object (step S51). If the condition object is determined to be the first condition object or the last condition object in a continuous condition object, the syntax token parser obtains the corresponding conditional statement 41 based on the connection of the general block 31 with its neighboring blocks, queries the syntax token corresponding table with the conditional statement 41 to obtain the syntax token for the conditional statement 41 in the target programming language, and records the syntax token in the node register of the general block 31 (step S52).
[0119] For example, if the general block 31 being visited contains a condition object, and the condition object is determined to be the first condition object in a continuous condition object, the syntax token parser obtains the syntax token for the THEN statement in the target programming language, and records the syntax token in the node register of the general block 31. Figure 6In the embodiment of FIG. 1, the condition item "D" is the first condition item in the consecutive condition items, so when the syntax token parser visits the general block 31 containing the condition item "D", the syntax token parser will query the syntax token correspondence table according to the condition statement "IF", and record the syntax token obtained from the table in the node register of the general block 31. For another example, Figure 6 In the embodiment of FIG. 1, the branch block 33 is the last condition item in the consecutive condition items (the end item is not counted in the consecutive condition items), so when the syntax token parser visits the branch block 33, the syntax token parser will query the syntax token correspondence table according to the condition statement "THEN", and record the syntax token obtained from the table in the node register of the branch block 33.
[0120] In addition, if the current visited general block 31 contains a condition item (step S50), the syntax token parser will further obtain the corresponding condition operation 42 according to the connection relationship between the general block 31 and the adjacent block, query the syntax token correspondence table according to the condition operation 42 to obtain the syntax token of the target program language for the condition operation 42, and record the syntax token in the node register of the general block 31 (step S53).
[0121] For example, in the embodiment of FIG. 1, the condition item "B" itself contains the condition operation "NOT", so when the syntax token parser visits the general block 31 containing the condition item "B", the syntax token parser will query the syntax token correspondence table according to the condition operation "NOT", and record the syntax token obtained from the table in the node register of the general block 31. For another example, Figure 6 In the embodiment of FIG. 1, the condition item "D" and the connection relationship between the rear block are in series, so when the syntax token parser visits the general block 31 containing the condition item "D", the syntax token parser will query the syntax token correspondence table according to the condition operation "AND", and record the syntax token obtained from the table in the node register of the general block 31. Figure 6
[0122] It is worth mentioning that if the syntax token parser performs the visiting action in a reverse recursive manner, the syntax token parser will bring the end statement (such as Out) pointed by the end item in the general block 31 visited last time (such as shown in the subsequent step S56) into the next visiting action. In the above step S53, the syntax token parser further brings the record of the end statement obtained in the last visiting action, for the same reason as described above.
[0123] After step S53, the syntax token parser completes the visiting action of a general block 31 containing a condition item.
[0124] It is worth mentioning that if a branch block 32 contains multiple general blocks 31 (i.e., the branch block 32 is the upper layer of the multiple general blocks 31), the syntax tag parser needs to visit each general block 31 in the branch block 32 in sequence in addition to visiting the branch block 32. For example, Figure 6 The branch block 32 in Figure 8A , Figure 8B needs to perform three visiting actions in sequence according to the flow of
[0125] If it is determined that the currently visited general block 31 contains a function object (step S54), the syntax tag parser directly obtains the function statement of the function object, queries the syntax tag correspondence table according to the function statement to obtain the syntax tag of the function statement in the target program language, and records the syntax tag in the node temporary storage of the general block 31 (step S55). After step S55, the syntax tag parser completes the visiting action of a general block 31 containing a function object.
[0126] If it is determined that the currently visited general block 31 contains an end object (step S56), the syntax tag parser obtains the corresponding condition statement 41 (such as ELSEIF, END_IF, etc.) according to the connection relationship between the general block 31 and the adjacent block, and queries the syntax tag correspondence table according to the end statement (such as Out) of the end object and the condition statement 41 to obtain the syntax tag of the end statement and the condition statement 41 in the target program language, and records the syntax tag in the node temporary storage of the general block 31 (step S57).
[0127] It is worth mentioning that if the syntax tag parser performs the visiting action in a reverse recursive manner, the syntax tag parser will bring the record of the end statement into the next visiting action when it is determined that the currently visited general block 31 contains an end object (step S57), for the same reason as described above. After step S57, the syntax tag parser completes the visiting action of a general block 31 containing an end object.
[0128] The specific description of the above visiting action will be described below in combination with Figure 6 , Figure 8A and Figure 8B . In Figure 6In the embodiment of FIG. 1, since the source program segment 1 is written in a graphical programming language, the syntax token parser will be described in a reverse top-down manner, but not limited thereto. As described above, whether the source program segment 1 is written in a graphical programming language or a textual programming language, the syntax token parser can perform the visiting operation in a forward top-down manner or a reverse top-down manner.
[0129] As shown in FIG. 2, when the visiting operation is started, the syntax token parser first acquires the third visiting block 13 (i.e., starting from the last block of the source program segment 1 in a reverse top-down order), and determines that the third visiting block 13 is a general block 31 and contains an end object (Out). In this case, the syntax token parser acquires the corresponding conditional statement 41 according to the connection relationship between the general block 31 and the adjacent block (i.e., the last block in the upper block), and queries the syntax token correspondence table according to the end statement of the end object and the conditional statement 41 to acquire the syntax tokens of the destination programming language for the end statement and the conditional statement 41 (i.e., "END_IF;" and "Out := TRUE;" in this embodiment). Then, the syntax token parser records the syntax tokens in the node register of the general block 31. Figure 6
[0130] Since the third visiting block 13 contains the end object, the syntax token parser carries the end statement to the next visiting operation.
[0131] Then, the syntax token parser acquires the second visiting block 12 in the source program segment 1, determines that the second visiting block 12 is a branch block 33, and determines that the branch block 33 has a conditional operation 42 "OR", the branch block 33 is the last block in the upper block having a conditional execution, and the rear of the branch block 33 is connected to an end object based on the record of the last visiting operation. According to the above information, the syntax token parser queries the syntax token correspondence table to acquire the syntax tokens of the destination programming language for the conditional operation 42 and the conditional statement 41 (i.e., "OR" and "THEN" in this embodiment), and records the syntax tokens in the node register of the branch block 33.
[0132] Since the second visiting block 12 (i.e., the branch block 33) contains two general blocks 31, the syntax token parser then sequentially (in a reverse top-down manner) visits the two general blocks 31 in the branch block 33.
[0133] First, the syntax token parser obtains the last general block 31 in the second traversal block 12, judges that this general block 31 contains the condition item "B" and the condition operation 42 "NOT", this general block 31 is not the last condition item in the continuous condition items, and this general block 31 is the last block in the branch block 33 of the upper layer (i.e. no connection condition operation 42 "OR" is needed in the rear). Accordingly, the syntax token parser can query the syntax token corresponding table based on the above information to obtain the syntax token of the condition operation 42 "NOT" in the target program language, and record this syntax token in the node temporary storage of this general block 31.
[0134] Next, the syntax token parser obtains the first general block 31 in the second traversal block 12, judges that this general block 31 contains the condition item "A", this general block 31 is not the last condition item in the continuous condition items, and this general block 31 is not the last block in the branch block 33 of the upper layer (i.e. connection condition operation 42 "OR" is needed in the rear). Accordingly, the syntax token parser can query the syntax token corresponding table based on the above information to obtain the syntax token of the condition operation 42 "OR" in the target program language, and record this syntax token in the node temporary storage of this general block 31.
[0135] After the traversal of the second traversal block 12 is completed (including the branch block 33 itself and all blocks contained therein), the syntax token parser then obtains the first traversal block 11 in the source program fragment 1.
[0136] Next, the syntax token parser can judge that the first traversal block 11 is a general block 31, and judge that this general block 31 contains the condition item "D", this general block 31 is not the last block in the continuous block 32 of the upper layer (i.e. connection condition operation 42 "AND" is needed in the rear), and this general block 31 is the first block in the continuous condition block (i.e. connection condition statement 41 "IF" is needed in the front). Accordingly, the syntax token parser can query the syntax token corresponding table based on the above information to obtain the syntax tokens of the condition operation 42 "AND" and the condition statement 41 "IF" in the target program language, and record these syntax tokens in the node temporary storage of this general block 31.
[0137] Accordingly, the syntax token parser has completed the traversal action of all blocks in the source program fragment 1, and generated the syntax tokens relative to the target program language for all blocks respectively.
[0138] It is worth mentioning that, no matter the source program language is a graphical program language or a textual program language, the destination program language is a graphical program language or a textual program language, and the syntax token parser adopts a forward recursion or a backward recursion, the syntax token parser of the present application can adopt the same logic as described above to perform the visiting action on the plurality of blocks in the source program segment 1, which will not be described again.
[0139] As described above, the syntax token parser of the present application mainly performs a recursive visiting on the abstract syntax tree 5 corresponding to the source program segment 1, and thus, in the embodiment of the present application, the syntax token parser will record the generated syntax tokens in the node temporary storage of the first node (the conditional object "D") 21, the second node (the branch block 33) 22, the third node (the conditional object "A") 33, the fourth node (the conditional object "B") 34, and the fifth node (the end object "Out") 35 after the visiting is completed. In this way, in the step S27 of the above embodiment, the semantic combiner can combine the object contents and the syntax tokens of each block based on the information recorded in the node temporary storage of the nodes 21-25 to generate the destination program segment 2, and perform an output after the combination is completed. Figure 6 Figure 5 As described above, the syntax token parser of the present application mainly performs a recursive visiting on the abstract syntax tree 5 corresponding to the source program segment 1, and thus, in the embodiment of the present application, the syntax token parser will record the generated syntax tokens in the node temporary storage of the first node (the conditional object "D") 21, the second node (the branch block 33) 22, the third node (the conditional object "A") 33, the fourth node (the conditional object "B") 34, and the fifth node (the end object "Out") 35 after the visiting is completed. In this way, in the step S27 of the above embodiment, the semantic combiner can combine the object contents and the syntax tokens of each block based on the information recorded in the node temporary storage of the nodes 21-25 to generate the destination program segment 2, and perform an output after the combination is completed.
[0140] Please refer to the following Figure 6 , Figure 9A and Figure 9B , wherein Figure 9A and Figure 9B are the first specific embodiment of the first flowchart and the second flowchart of the semantic combination of the present application, which are used to specifically describe the recursive visiting action performed by the semantic combiner of the present application.
[0141] As shown in Figure 9A and Figure 9B , after the syntax token parser completes the syntax tokens of all the blocks in the source program segment 1, the optimization method of the present application re-performs the visiting on the source program segment 1 with the completed tokens by the semantic combiner, and acquires one block in the source program segment 1 which has not been visited (step S60), and judges whether the block is the branch block 33 (step S61). If the block is the branch block 33, the semantic combiner further judges whether the inside of the branch block 33 has been visited (step S62).
[0142] When the inside of the branch block 33 has not been visited, the semantic combiner first combines the object contents and the syntax tokens recorded in the node temporary storage of the branch block 33 to generate an intermediate result (step S63). If the inside of the branch block 33 has been visited, the semantic combiner combines the result obtained in the last visiting action and the current intermediate result to update the intermediate result (step S64).
[0143] Further, the semantic combiner determines whether there is a syntax token of a conditional statement 41 in the node register of the branch block 33 (step S65), and when the conditional statement 41 exists, the semantic combiner further combines the conditional statement 41 and the current intermediate result to update the intermediate result (step S66). After step S66, the semantic combiner completes the visiting action of the branch block 33.
[0144] After the semantic combiner obtains a block in the source program fragment 1 which has not been visited (step S60), it can also determine whether the block is a continuous block 32 (step S67). When the block is a continuous block 32, the semantic combiner further determines whether the inside of the continuous block 32 has been visited completely (step S68).
[0145] When the inside of the continuous block 32 has not been visited completely, the semantic combiner continues the visiting action of other blocks in the inside of the continuous block 32.
[0146] When the inside of the continuous block 32 has been visited completely, the semantic combiner combines the result obtained from the last visiting action and the current intermediate result to update the intermediate result (step S69). After step S69, the semantic combiner completes the visiting action of the continuous block 32.
[0147] When the semantic combiner determines that the block obtained in the above step S60 is not a branch block 33 nor a continuous block 32, it determines that the block currently visited is a general block 31. At this time, the semantic combiner determines whether there is a syntax token of a conditional statement 41 in the node register of the general block 31 (step S70). When there is a conditional statement 41 (such as IF, THEN, etc.) in the node register, the semantic combiner combines the object content recorded in the node register and the conditional statement 41 to update the current intermediate content (step S71).
[0148] Further, the semantic combiner also determines whether there is a syntax token of a conditional operation 42 in the node register of the general block 31 currently visited (step S72). When there is a conditional operation 42 (such as AND, OR, NOT, etc.) in the node register, the semantic combiner combines the object content recorded in the node register and the conditional operation 42 to update the current intermediate content (step S73).
[0149] Further, the semantic combiner determines whether the end statement syntax tag exists in the node register of the current general block 31 (step S74). Specifically, the end statement is one of the embodiments of the general statement 43. If the end statement (e.g., OUT := TRUE) exists in the node register, the semantic combiner combines the result of the last traversal action, the content of the end statement, and the current intermediate result to update the intermediate content (step S75).
[0150] Further, the semantic combiner determines whether the upper block of the current general block 31 is the branch block 33 and whether the current general block 31 is the last block in the upper branch block 33 (step S76). If the current general block 31 is the last block in the upper branch block 33, the semantic combiner further removes the condition operation redundantly added in step S73 from the current intermediate result to update the current intermediate result because the condition operation 42 "OR" does not need to be added after the current general block 31 (step S77).
[0151] After step S77, the semantic combiner completes the traversal action of one general block 31. Further, after all the blocks in the source program fragment 1 complete the traversal action, the semantic combiner outputs the destination program fragment 2 according to the last updated intermediate result.
[0152] The following detailed description of the above traversal action is combined with Figure 10 , Figure 9A and Figure 9B , wherein Figure 10 is the first embodiment of the conversion diagram of the present application.
[0153] As shown in Figure 10 , first, the semantic combiner obtains the first traversal block 11 from the source program fragment 1, determines that the first traversal block 11 is the general block 31, the object content "D", the condition statement 41 "IF", and the condition operation 42 "AND" exist in the node register of the general block 31, and thus the semantic combiner combines the object content, the condition statement 41, and the condition operation 42, updates the intermediate result to "IF D AND", and completes the current traversal action.
[0154] Next, the semantic combiner takes the second tour block 12 from the source program fragment 1, determines that the second tour block 12 is a branch block 33, and that the interior of this branch block 33 has not yet been toured. Accordingly, the semantic combiner takes the object content (i.e., the block that has not yet been toured) and the syntax token (in this embodiment, the conditional operation 42 "OR") from the node register of the branch block 33, and combines the object content and the syntax token to update the intermediate result to "__OR__".
[0155] Next, the semantic combiner tours the first block inside the branch block 33, determines that this block is a general block 31, and that the node register of this general block 31 has object content "A" and the conditional operation 42 "OR". Accordingly, the semantic combiner combines the object content and the conditional operation 42, updates the intermediate result to "A OR", and completes this tour action.
[0156] Next, the semantic combiner tours the second block inside the branch block 33, determines that this block is a general block 31, and that the node register of this general block 31 has object content "B", the conditional operation 42 "NOT", and the conditional operation 42 "OR". Accordingly, the semantic combiner combines the object content and the conditional operations 42, updates the intermediate result to "A OR NOT B OR". Also, the semantic combiner determines that this general block 31 is the last block in the branch block 33 above, so it further removes the redundant conditional operation 42 "OR" from the intermediate result, updates the intermediate result to "A OR NOT B", and completes this tour action.
[0157] It is worth mentioning that in the embodiment of Figure 10 In this embodiment, the destination program fragment 2 is in structured literal program language, so the semantic combiner further adds parentheses to the intermediate result, resulting in the result "(A OR NOT B)".
[0158] At this point, the semantic combiner has completed the tour of all blocks inside the second tour block 12 (i.e., the branch block 33), so it combines the record of the last tour action (i.e., "IF D AND") with the current intermediate result (i.e., "(A OR NOT B)") to update the intermediate result to "IF D AND(A OR NOT B)". Also, since the node register of the second tour block 12 has the conditional statement 41 "THEN", the semantic combiner further combines this conditional statement 41 with the current intermediate result to update the intermediate result to "IF D AND(A OR NOT B) THEN".
[0159] After the second tour of the block 12 itself and the blocks inside it is completed, the semantic combiner further obtains the third tour block 13 from the source program fragment 1, judges that the third tour block 13 is a general block 31, and there is an end object "Out:=TRUE" in the node register of the general block 31. Therefore, the semantic combiner combines the record obtained in the last tour action (i.e., "IF D AND(A OR NOT B)THEN") with the current intermediate result to update the intermediate result as:
[0160] IF D AND(A OR NOT B)THEN
[0161] Out:=TRUE;
[0162] Further, the semantic combiner judges that the conditional statement 41 "END_IF" is also included in the node register of the general block 31, and therefore the semantic combiner also combines the conditional statement 41 with the current intermediate result to update the intermediate result as:
[0163] IF D AND(A OR NOT B)THEN
[0164] Out:=TRUE;
[0165] END_IF;
[0166] At this point, the semantic combiner can complete the current tour action.
[0167] As described above, the optimization method of the present application performs syntax corresponding and marking for each block in the source program fragment 1 by the syntax marker parser, and combines the semantics of each block converted and marked by the semantic combiner. In this way, the source program fragment 1 can be converted into the target program fragment 2 conforming to the architecture of the target program language. Further, the above is an example of converting the program fragment written in the graphical program language architecture (ladder program language) into the program fragment conforming to the architecture of the textual program language (structured textual program language), but the optimization method of the present application can actually convert the program fragment between various program languages.
[0168] Please refer to Figure 11 for a conversion diagram of different program languages. As Figure 11As shown, example (1) is a program fragment that conforms to the architecture of the ladder diagram programming language, example (2) is a program fragment that conforms to the architecture of the function block diagram programming language, example (3) is a program fragment that conforms to the architecture of the continuous function chart programming language, example (4) is a program fragment that conforms to the architecture of the structured text programming language, example (5) is a program fragment that conforms to the architecture of the JAVA programming language, and example (6) is a program fragment that conforms to the architecture of the Python programming language.
[0169] As will be apparent to those skilled in the art, although examples (1) to (6) belong to different programming language architectures, the program fragments shown therein all possess homogeneous semantics. Through the optimization method of this invention, regardless of the programming language on which the source program fragment 1 is written, the programmer can directly convert the source program fragment 1 into the target program fragment 2, which conforms to the architecture of another programming language. Therefore, the programmer does not need to rewrite the program, nor does he / she need to understand the writing style and logic of other programming languages.
[0170] However, although the present invention can convert source program fragment 1 into target program fragment 2 through a syntax marker parser and a semantic combiner, the technical solution of the present invention mainly uses a normalized syntax marker mapping table to convert a syntax between different programming languages. Therefore, it is possible that the target program fragment 2 will be less than appropriate after conversion (e.g., too many lines or overly verbose syntax). Therefore, the present invention further uses a semantic optimizer to simplify the generated target program fragment 2.
[0171] See Figure 12 This is a first specific embodiment of the optimized flowchart of the present invention. Figure 12 This is used to specifically illustrate the recursive visit operation performed by the semantic optimizer of the present invention.
[0172] like Figure 12 As shown, after the semantic combiner generates the target program segment 2, the optimization method of the present invention obtains one or more semantic combinations in the target program segment 2 in a recursive manner through the semantic optimizer (step S80), and determines whether the currently obtained one or more semantic combinations have two or more blocks that meet the algebraic identity condition (step S81).
[0173] If, in step S81, it is determined that there are no two or more blocks in the currently obtained semantic combination that satisfy the algebraic identity condition, the semantic optimizer does not perform any simplification procedure. In this case, the semantic optimizer returns to step S80 to obtain other semantic combinations in the target program segment 2. Specifically, the semantic combination referred to in this invention refers to a semantic combination consisting of multiple adjacent blocks in the same network (or hierarchy), or a semantic combination consisting of multiple blocks between adjacent networks.
[0174] If, in step S81, it is determined that there are two or more blocks in the currently obtained semantic combination that meet the algebraic identity condition, then the semantic optimizer performs an algebraic simplification procedure on the two or more blocks that meet the algebraic identity condition (step S82), thereby updating one or more semantic combinations in the target program segment 2.
[0175] In this invention, the semantic optimizer recursively visits all semantic combinations in the target program segment 2. After visiting all semantic combinations, it terminates the execution of the equivalent substitution procedure and converts the target program segment 2 into an optimized target program segment. Finally, the programming language editor can output the optimized target program segment at the location specified by the programmer for direct use.
[0176] It is worth mentioning that, since algebraic identities often occur between adjacent program networks (e.g., using the output of the previous network as the input of the next network), in one embodiment, the semantic optimizer of the present invention can be executed in a backward recursive manner. Figure 10 The aforementioned visits are not limited to these actions.
[0177] Please also refer to Figure 13 This is a first specific embodiment of the optimized schematic diagram of the present invention. Figure 13 Another target program fragment 6 is disclosed, and this target program fragment 6 includes a first network 61, a second network 62 and a third network 63, wherein each network 61-63 is composed of multiple blocks.
[0178] In this embodiment, if the semantic optimizer uses a reverse recursive approach to traverse one or more semantic combinations in the target program segment 6, it will find that the output of the second network 62 (containing the general block of the ending object "M2") is the input of the third network 63 (containing the general block of the condition object "M2"). Therefore, the semantic optimizer first simplifies the second network 62 and the third network 63 using De Morgan's laws, and generates... Figure 13 The fourth network 64 is shown. The De Morgan's theorem is common knowledge in the field of mathematics and will not be elaborated upon here.
[0179] By Figure 13 It can be seen that after the second network 62 and the third network 63 are simplified into the fourth network 64, the general block (or node) containing the object "M2" disappears. Thus, one node register can be saved, and one I / O point on the PLC can be saved, and memory space can be saved.
[0180] Moreover, when the semantic optimizer obtains the next semantic combination (for example Figure 13 the semantic combination of the first network 61 and the adjacent fourth network 64), it is found that the output of the first network 61 (containing the general block of the end object "M1") is the input of the fourth network 64 (containing the general block of the conditional object "M1"). In this embodiment, the semantic optimizer can simplify the first network 61 and the fourth network 64 by the associate law, and generate the fifth network 65 shown in Figure 13 . The associate law is generally known in the mathematical field, and will not be described here.
[0181] As shown in Figure 13 , the target program segment 6 before optimization has three networks (i.e., the first network 61, the second network 62, and the third network 63), and the three networks 61-63 together contain nine blocks (including eight general blocks and one branch block). In contrast, the target program segment after optimization has only one network (i.e., the fifth network 65), and the fifth network 65 contains only four general blocks. Compared with the target program segment 6 before optimization, the target program segment after optimization saves five block node registers in total, which has considerable economic benefits for program editing and use.
[0182] Please also refer to Figures 14A-14C , which are the second, third, and fourth specific embodiments of the optimization flowchart of the present application.
[0183] In the embodiment of Figure 14A , the target program segment 71 before optimization has two networks, and one input block of the next network is the output block of the previous network (i.e., the general block containing the end object "M1"). In this embodiment, after the semantic optimizer obtains the corresponding semantic combination, it can combine the two networks into a single network by the associate law, and output the target program segment 72 after optimization.
[0184] As shown in Figure 14AAs shown, the pre-optimization target program fragment 71 requires eight node registers (including six general blocks and two branch blocks), while the post-optimization target program fragment 72 requires only five node registers (including four general blocks and one branch block). Thus, the post-optimization target program fragment 72 saves three block node registers compared to the pre-optimization target program fragment 71.
[0185] In an embodiment of the present application, the pre-optimization target program fragment 73 uses two general blocks containing the conditional item "X" in the same network. In this embodiment, the semantic optimizer can simplify the network by the distributive law after obtaining the corresponding semantic combination, and output the post-optimization target program fragment 74. Figure 14B
[0186] As shown, the pre-optimization target program fragment 73 requires six node registers (including five general blocks and one branch block), while the post-optimization target program fragment 74 requires only five node registers (including four general blocks and one branch block). Thus, the post-optimization target program fragment 74 saves one block node register compared to the pre-optimization target program fragment 73. Figure 14B In an embodiment of the present application, the pre-optimization target program fragment 75 has two networks, in which the input block of the next network is the output block of the previous network (i.e., the general block containing the terminal item "Ml"). In this embodiment, the semantic optimizer can combine the two networks into a single network by De Morgan's theorem after obtaining the corresponding semantic combination, and output the post-optimization target program fragment 76.
[0187] Figure 14C As shown, the pre-optimization target program fragment 75 requires six node registers (including five general blocks and one branch block), while the post-optimization target program fragment 76 requires only three node registers (including three general blocks). Thus, the post-optimization target program fragment 76 saves three block node registers compared to the pre-optimization target program fragment 75.
[0188] Figure 14C In addition to the above-mentioned algebraic identities, the semantic optimizer of the present application can generate post-optimization target program fragments by other simplification methods, such as the self-complement law, the power identity, the complement identity, the identity law, the elimination law, the Mann diagram, etc., without being limited to the above. The above-mentioned simplification methods are common technical means in the field of mathematics, and will not be described here.
[0189] In addition to the above-mentioned algebraic identities, the semantic optimizer of the present application can generate post-optimization target program fragments by other simplification methods, such as the self-complement law, the power identity, the complement identity, the identity law, the elimination law, the Mann diagram, etc., without being limited to the above. The above-mentioned simplification methods are common technical means in the field of mathematics, and will not be described here.
[0190] Through the technical solution of the present application, the compiler of the product firmware only needs to use any kind of graphical or literal program language, and the front-end application of other program languages of the terminal user can be provided through the above-mentioned optimization method. In this way, the terminal products of various language design platforms on the market can be regarded as potential programmable logic control compiling carriers of industrial control products. In this way, the development time and cost of industrial control products can be greatly reduced, and the threshold of people with different academic backgrounds in the field of program design in industrial automation can be lowered.
[0191] The above is only the preferred specific examples of the present application, and is not limited to the claims of the present application, so any equivalent changes made in accordance with the content of the present application are also included in the scope of the present application, and it is hereby declared.
Claims
1. A method for converting and optimizing program code between different programming languages, applied to a programming language editor, comprising: a) Obtain a program fragment written in a source programming language, wherein the source programming language is a graphical programming language or a textual programming language; b) Obtain an abstract syntax tree corresponding to the program fragment, wherein the abstract syntax tree includes multiple blocks; c) Visit one of the multiple blocks of the abstract syntax tree using a syntax marker parser; d) Based on the content of an object in the visited block and its connection relationship with adjacent blocks, query a syntax mark mapping table to generate a syntax mark corresponding to a target programming language, wherein the syntax mark mapping table records a correspondence between the complex syntax of the source programming language and the complex syntax of the target programming language, and the target programming language is a graphical programming language or a text programming language. e) Repeat steps c and d before all the blocks have been visited by the syntax parser and the syntax tag has been generated; f) After all the blocks have been visited by the syntax tag parser, one of the blocks in the abstract syntax tree is visited by a semantic combiner; g) Combine the object content and syntax markup of the visited block with the object content and syntax markup of the previously visited block to produce an intermediate result. h) Before all the blocks have been visited by the semantic combiner, repeat steps f and g to update the intermediate results; i) After all the blocks have been visited by the semantic combiner, a target program fragment is generated based on the updated intermediate result, wherein the target program fragment conforms to the architecture of the target program language. j) By using a semantic optimizer to visit one or more semantic combinations in the target program segment, and performing an equivalent substitution procedure to generate an optimized target program segment when the one or more semantic combinations satisfy a conditional equality; and k) Output the optimized target program fragment to the programming language editor.
2. The method of claim 1, wherein the plurality of blocks in the abstract syntax tree includes a branch block, a continuous block, or a general block, the branch block includes at least two parallel blocks, the continuous block includes at least two serial blocks, the general block records a condition object, a function object, or an end object, and each block corresponds to a node register, the object content and the syntax tag of each block are recorded in the node register.
3. The method of claim 2, wherein step c involves traversing the plurality of blocks in the abstract syntax tree in a forward recursive manner when the source programming language is a text-based programming language, and traversing the plurality of blocks in the abstract syntax tree in a reverse recursive manner when the source programming language is a graphical programming language.
4. The method of claim 2, wherein step d comprises the following steps: d11) When the currently visited block is the branch block, and the branch block is the last block with conditional execution in the upper-level blocks, obtain a corresponding conditional statement based on the connection relationship between the branch block and adjacent blocks, query the syntax tag mapping table based on the conditional statement to obtain the syntax tag corresponding to the conditional statement in the target programming language, and record the syntax tag in the node register of the branch block; and d11) When the currently visited block is the branch block, query the syntax tag mapping table according to an OR condition operation to obtain the syntax tag corresponding to the OR condition operation of the target programming language, and record the syntax tag in the node register of the branch block.
5. The method of claim 4, wherein step d is further comprising step d21): When the currently visited block is a contiguous block and the contiguous block is the last block with conditional execution in the upper-level blocks, the corresponding condition statement is obtained based on the connection relationship between the contiguous block and the adjacent blocks. The syntax tag correspondence table is queried based on the condition statement to obtain the syntax tag corresponding to the condition statement of the target programming language, and the syntax tag is recorded in the node register of the contiguous block.
6. The method of claim 5, wherein step d further comprises the following steps: d31) When the currently visited block is the general block, the content of the object in the general block contains a condition object, and the condition object is the first or last condition object in a series of condition objects, the corresponding condition statement is obtained according to the connection relationship between the general block and the adjacent blocks. The syntax tag correspondence table is queried according to the condition statement to obtain the syntax tag corresponding to the condition statement in the target programming language, and the syntax tag is recorded in the node register of the general block containing the condition object. d32) When the currently visited block is the general block, obtain a corresponding conditional operation based on the connection relationship between the general block and the adjacent blocks, query the syntax tag correspondence table based on the conditional operation to obtain the syntax tag corresponding to the conditional operation of the target programming language, and record the syntax tag in the node temporary register of the general block containing the conditional object. d4) When the currently visited block is the general block and the object content of the general block contains a functional object, query the syntax tag mapping table according to the functional statement indicated by the functional object to obtain the syntax tag corresponding to the functional statement of the target programming language, and record the syntax tag in the node register of the general block containing the functional object. and d5) When the currently visited block is the general block and the object content of the general block contains an ending object, obtain the corresponding condition statement based on the connection relationship between the general block and adjacent blocks, query the syntax tag mapping table based on the ending statement indicated by the ending object and the condition statement to obtain the syntax tag corresponding to the ending statement and the condition statement of the target programming language, and record the syntax tag in the node register of the general block containing the ending object.
7. The method of claim 6, wherein step c is to traverse the plurality of blocks in the abstract syntax tree in a reverse recursive manner, step d11) simultaneously carries in the record of the ending statement obtained from the previous traversal action; step d32) simultaneously carries in the record of the ending statement obtained from the previous traversal action; step d further includes a step d22): when the currently traversed block is the contiguous block, carrying in the record of the ending statement obtained from the previous traversal action; step d5) carrying in the record of the ending statement in the next traversal action.
8. The method of claim 2, wherein step g comprises the following steps: g11) When the currently visited block is the branch block and the internal part of the branch block has not been completely visited, combine the object content and the syntax tag recorded in the node register of the branch block to produce the intermediate result. g12) When the currently visited block is the branch block and the internal visit of the branch block is completed, combine the result obtained from the previous visit action with the current intermediate result to update the intermediate result. and g13) When the currently visited block is the branch block and the condition statement exists in the node register of the branch block, combine the condition statement with the current intermediate result to update the intermediate result.
9. The method of claim 8, wherein step g includes a step g21): When the currently visited block is a contiguous block, and the internal traversal of the contiguous block is completed, the result obtained from the previous traversal action is combined with the current intermediate result to update the intermediate result.
10. The method of claim 9, wherein step g comprises the following steps: g31) When it is determined that the block currently being visited is the general block and the condition statement exists in the node register of the general block, the object content recorded in the node register and the condition statement are combined to update the intermediate result. g32) When it is determined that the currently visited block is the general block and the condition operation exists in the node register of the general block, the object content recorded in the node register and the condition operation are combined to update the intermediate result. g33) When it is determined that the block being visited is the general block and the node register of the general block contains the ending statement, the result obtained from the previous visit action, the content of the ending statement, and the current intermediate result are combined to update the intermediate result. and g34) When it is determined that the currently visited block is the general block, the upper layer of the general block is the branch block, and the general block is the last general block in the branch block, remove the redundant conditional operation added in step g32) to update the intermediate result.
11. The method of claim 2, wherein step j comprises the following steps: j1) Obtain one or more sets of the semantic combination in the program segment for the purpose of the task; j2) Perform an algebraic simplification procedure on two or more blocks that satisfy algebraic identities to update one or more semantic combinations; j3) Repeat steps j1 to j2 until all adjacent semantic combinations in the target program segment have been evaluated; and j4) After all adjacent semantic combinations in the target program segment have been judged, stop the equivalent substitution procedure and generate the optimized target program segment.
Citation Information
Patent Citations
Method for transforming and optimizing codes between different programing languages
TW202240377A