JP3102030B2 - Program creation device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Industrial Application Field] The present invention relates to a program creating apparatus capable of efficiently describing real-time software. More specifically, the present invention relates to a program creation device capable of efficiently and easily creating a parallel processing program for causing a plurality of tasks to be processed in parallel by a single or a plurality of microprocessors on the same screen.

[Conventional technology]

Conceptually speaking, software installed for the purpose of control device control, communication control, etc. always has the inside of the software and the outside world to be controlled, and operates while maintaining some mutual relationship with the outside world. Is what you do. When any change occurs in the outside world, it is necessary to perform processing for the change within a limited time. in this way,
Software that is required to perform a predetermined process within a specified time is called real-time software. Among such real-time software, software that receives a stimulus as an input from the outside world and performs processing in a series of performing processing on the stimulus is a discrete event-driven real-time software. That is, the software of a control device incorporating a so-called microprocessor is usually included in this category.

In recent years, with the development of software engineering, techniques for efficiently creating software using structured programming languages, high-level languages, etc., have been proposed, and these are techniques that can be applied to all software wafers. . However, the discrete event-driven real-time software described above has special characteristics compared to other software,
In addition to the creation method applicable to the entire software, there is still room for improvement for efficiently and easily creating such software.

[Problems to be solved by the invention]

That is, such discrete event-driven real-time software includes a plurality of operating software operating in parallel on a local area network, as represented by software for driving a plurality of working robots arranged on a production line. You need to describe the process. However, such conventional software is programmed by describing one step at a time on a CRT using a certain programming language. In such a creation method, a plurality of processes that operate in parallel are individually created, and then the individually created processes are combined so that the created process is executed in a parallel operation state on each microprocessor. There is a need.

However, by programming multiple processes to be processed in parallel in this way, the program creator must accurately define the overall flow of control and the flow of control performed individually by the microprocessor. It is difficult to recognize, and it is difficult to ensure their consistency. For this reason, it is often difficult to efficiently create a target program.

In view of the above, an object of the present invention is to realize a program creating apparatus capable of efficiently and easily creating such discrete event driven real-time software.

[Means for solving the problem]

Based on the above background, the present inventor has realized a language suitable for describing discrete event-driven real-time software and a development support environment therefor. Hereinafter, this language is called a planet (PLANET). In the program creating apparatus of the present invention using this planet, various requirements such as parallel operation and synchronization of processes can be expressed in a description format based on Petri nets. In addition, a diagram can be introduced throughout the entire programming to improve the descriptiveness and intelligibility of processing requirements.

That is, the present invention provides a program creation device for creating a program that is processed in parallel by a plurality of control entities on a network, wherein the hardware information holding means holds hardware information of a network including the plurality of control entities, Screen display means for displaying the program creation area as one screen, program creation means for creating a program on the display screen, translation means for translating the created program into machine language, and Storage means for storing a program.

The above-mentioned program creating means is a language element of the planet, and a graphic pattern generating means for creating a program capable of generating a plurality of types of drawing patterns for displaying the contents of each processing performed in time series of the program; It is provided with hardware information input means capable of inputting hardware information on one display screen for creating a program, and pattern selection means for sequentially selecting graphic patterns and displaying them on the program display screen. A drawing pattern, which is a programming language element, includes a plurality of types of graphic patterns indicating processing contents, a directed branch indicating a chronological flow direction of a processing object, and at least two branches, and a chronologically succeeding processing. A first directed branch indicating that the requirement is to be processed in parallel, and at least a forked bifurcated branch are combined so that subsequent processing requirements are processed in synchronization with completion of a plurality of preceding processing requirements. And a second directional branch that indicates the processing operation to be performed.

On the other hand, the translating means converts, based on the information obtained from the hardware information holding means, each of the plurality of processing element sequences following the first directional branch into a program which is processed in parallel by each of the plurality of control entities. It has a parallel processing program allocating means for categorizing and allocating, and the program created by the operator on one screen is automatically classified for each control means by this means, and is assigned to these control subjects. Assigned.

[Action]

In the program creation device of the present invention, the program creator uses the pattern selection means to display a graphic pattern indicating processing requirements and a directed branch on one program creation screen displayed by the screen display means. Alternatively, the program can be created on the same screen by repeating the operation of alternately selecting the directional branch. here,
If multiple screens can be displayed by the screen display means,
The lower layer program of the processing element of the program created on the same screen can be created on another screen defined as the lower layer of the processing element.

The program created in this way is converted by the translation means into a program composed of a machine language that can actually drive the microprocessor. In the conversion processing by the translation means, a group of processing elements to be processed in parallel connected by a directional branch and a bifurcated directional branch, which are program languages, are converted into a program for each control entity based on hardware information. Classify and assign to the corresponding control entity. Thus, in the present invention, a program to be processed in parallel can be easily created on the same screen.

The created program is debugged by debugger means. By this debugging means, the same screen as at the time of creation is reproduced and displayed, and debugging can be performed on this screen. The program after the debugging is stored in a storage medium such as a ROM, for example, and is run on an actual processing device.

〔Example〕

 Hereinafter, examples of the present invention will be described.

First, the contents of the programming language Planet (PLANET) suitable for description in the real-time control software newly developed according to the present specification will be described.

In this planet, software is configured by a mutual relationship between a control entity (a task divided by defining an input event from the outside world and internal processing) and the control entity. further,
Various requirements such as parallel operation and synchronization of processes included in the internal processing of the control entity are expressed in a description format based on Petri nets. At this time, by introducing a diagram throughout the programming, the description and understanding of the processing requirements are improved.

Description format by planet The real-time control system has input groups (various sensor groups) /
An output group (actuator group) and a communication path are connected. In a relatively large-scale system having many inputs / outputs, an input / output group is divided for each function. Conventionally, a method has been applied in which a system has a plurality of modules (tasks) for controlling each divided input / output group, and the system is described by exchanging these modules. In this manner, the input event from the outside world and the internal processing are defined, and the function modules which are independent and continue to exist in the system when driven are referred to as control entities or subsystems in Planet. Further, the exchange between the control entities is performed by transmitting and receiving messages.

(Modeling of Control Entity) The operation of the control entity divided as described above can be represented by a model shown in FIG. In this figure, an input event set E is a finite set of various sensors and time information related to the control entity, and state transition items such as sensors are input from ei in a stream as time elapses. The input message set Mi is a set of messages input to the control entity in a stream. The internal state holding set S is a vector expressing the internal state of the control entity. The output element set O is a set of elements for driving various actuators involving the control entity, and the output message set is a set of messages output in a stream from the control entity. The output message becomes the input message of another control entity. This coupling may be via a network. Further, based on the input event set E, the input message set Mi, and the internal state set S, there are mappings F and G that define an output requirement set O and an output message set Mo, and these define the internal processing of the control entity. I do. That is, FIG. 1 monitors the ever-changing state (E) of the sensor, receives a message (Mi) arriving from the outside, updates the internal state (S), and updates the output condition (O) corresponding to the input. , The operation of the control entity that generates the output message (Mo).

FIG. 2 is an example in which a simple part of the operation of a certain embedded industrial machine is described by a planet. Here, the operation of the industrial machine is "console", "conveyor", "assembl"
It is divided into five control entities named "y", "partsmanager", and [measurementsystem], and the interrelationship of these control entities is described from each viewpoint. That is, "console", "conveyor", "ass
"embly", "partsmanager", and "measurementsystem" represent each control entity. expressing. Further, the message terminals are connected by directional branches, and the direction of the message to be updated is defined by the direction of the arrow. The control entity is activated when a message arrives at an input terminal with a special name "begin", and the internal processing of the control entity and the message transmission / reception function start operating. The message is output each time the control entity performs a transmission operation, and the directional branches are communicated by FIFO management in a pipeline manner.

The processing requirements described in FIG. 2 are as follows. According to the start request output from the control entity that monitors the control panel called "console", "conveyor", "asse
Four control entities of “mbly”, “partsmanager”, and “measurementsystem” are driven. The parts supplied by "partsmaneger" are incorporated by "assembly" into the input pallet carried by "conveyor", and "measurementsyste
The "conveyor" carries it out via the "m". At the same time, the pallet input by the "measurement system" is received and output, and the measurement data is sent out of the built-in industrial machine. If "partsmanager" detects a shortage of parts, it issues a warning to "console". In this way, the exchange of control entities can be seen in a bird's-eye view for each viewpoint,
The description is easy to understand.

(Sequence Description by Directed Graph) Next, the constituent means of the internal processing of the control entity will be described. In the operation specifications of internal processing, empirically, "When ○ is in the state of ○, ● indicates ●, ◎ indicates ◎, □ indicates □
State transition "is often used. In this expression, XX is the internal state of the control entity before event input (pre-processing state), ●● is the input event, ◎◎ is the activity requirement (response), and □□ is the internal state of the control entity of the processing (after processing). State). A model represented by these four things is generally called a stimulus response model. The particulars of this declaration are extremely simple and can be easily implemented. However, due to the nature of real-time control software, multiple input events occur asynchronously, and the events to be detected change every moment depending on the internal state. It is a big bottleneck when writing.

In order to express such processing honestly, in Planet, instead of a conventional one-dimensional processing sequence using character strings,
The description method is adopted by a directed graph structure based on Petri net. In other words, the input event and the activity requirement are expressed as nodes with the message input terminal as the start and the message output terminal as the end, and the processing sequence is described in a diagram in which they are connected by a directed branch that defines the execution order. The internal state is represented by where the control is at the moment, ie, a marking in the Petri net.

FIG. 3 shows an example of internal processing of a control entity described by a planet. An input oval node with no directed branch (a node marked "start", whose name corresponds to the message input terminal name of the control entity described above) represents the beginning of the processing sequence. A section surrounded by double rectangular sections (even
This is a section marked with t, and in fact, a phrase for condition determination for event detection such as “Is the sensor turned on?” indicates input event detection and is filled in. When an event occurs, the process is terminated. On the other hand, a section enclosed by a single rectangular clause (action and a clause, which actually describes a response phrase such as "turn on solenoide") indicates an activity requirement, If so, the process is performed immediately. The directed branch connecting each clause expresses the execution order relation of the processing, and the "action
Branching into a plurality, such as a directional branch extending from “1” and “action2”, indicates that subsequent processing is executed simultaneously, that is, parallel processing is performed. Also, "acti
A processing requirement input by a plurality of directed edges, such as "on2" and "action5", indicates that the processing is driven when the processing of all preceding elements of the processing requirement is completed, that is, that synchronization is expressed. As described above, the processing sequence in which the execution order is defined ends in an oval node corresponding to the message output terminal of the control entity.

(Procedure Hierarchy) As shown in FIG. 3 described above, in the planet, a series of integrated processing groups is represented as a single diagram. Naturally, if the program scale becomes large, the diagram becomes huge and complicated, and it becomes difficult to understand. Also,
I want to use general-purpose procedures in common, and also use a recursive calling mechanism. Therefore, in the planet, a group of processes is stored in one diagram, and can be called as one processing requirement in a diagram of a higher abstract level. FIG. 4 shows this relationship. This relationship is hereinafter referred to as procedure hierarchy. The processing of the lower layer is driven when the control reaches the processing requirement of the upper layer.
That is, control is passed to the "begin" input terminal in the lower hierarchy diagram, and the lower hierarchy processing sequence starts executing. Then, when the processing of the lower layer proceeds and the control reaches the “end” output terminal, all the controls in the lower layer are discarded and the control is returned to the upper layer. The returned control continues the processing requirements in the upper layer.

In short, on one screen, the vertical direction means the time-series direction of the processing, and the spread on the left and right means the parallelism of the processing. The so-called depth direction of the screen means the hierarchy. These relationships are shown in FIG.

(Language Constituent Elements) In the above, the description has been given of the interrelation between control entities and the description method of internal processing as the programming format in the planet. Next, each language component for actually describing a program in the planet is defined.

 The language components are listed below.

 Program frame Subsystem block Message input / output terminal Event wait clause Activity processing clause Conditional branch clause Selective event wait clause Iterative control framework Formula and data type Each language component is described below.

Program frame This is a single diagram (screen) that represents the internal processing of the control entity or the procedure in the lower hierarchy. In this program frame, as shown in FIG. 6, a column for entering a name is set at the lower right. The name written here becomes the name of the control entity or lower-layer procedure. This name is treated as an identifier and is used to specify the destination of the message or to specify a lower-level call destination. The syntax of the name is shown below.

Name :: = Character | Name Character | Name Numeric character Character :: = English character | Kana character | _ Subsystem A subsystem is a control entity as viewed from the outside. When this processing requirement appears, as shown in FIG. 7, the control entity name is expressed as a figure surrounded by a rectangular frame. The message input / output terminals of the control entity are located on the upper and lower sides of the subsystem and are represented by small rectangular frames accompanied by terminal names. Terminal names are unique within the same subsystem. If there is more than one terminal with the same name in the program, the name is interpreted as common. A message transmission / reception operation between control systems via a network is also described in the same manner as the center between control entities inside the control system. The shape of the message packet required at this time is automatically generated by a compiler described later.

The control entity is activated when the message reaches the input terminal named "begin". The internal processing is described by a program net whose constituent elements are nodes and whose execution order is defined by arrows. When the internal processing of the control entity proceeds and the control reaches an output terminal named "end", all controls operating in the control entity are interrupted and discarded.

Blocks When the internal processing of the control entity becomes large-scale and complicated, the procedures are hierarchized, and a set of subprocedure programs described as control requirements of an upper-layer program is called a block. The block is named, and the lower layer block is called by writing the name in the processing requirement of the upper layer block.

When control reaches the processing requirement in the upper layer, the lower layer block is called. Recursion and indirect recursion are permitted for calling the lower hierarchical block. The called lower-level block starts executing from the oval terminal named "begin", and when processing progresses and control reaches the oval terminal named "end", the inside of the block is called. All processes are interrupted and destroyed.
Thereafter, the control is returned to the processing requirement of the upper layer, and the execution of the upper layer block is continued.

Arguments can be given to the block call, in which case the variable name or value is replaced by ",
Use a list separated by parentheses in parentheses. When a variable is used as an argument of a block, the argument is given by a so-called name call. That is, when the value of the argument given in the above hierarchy is updated in the lower hierarchy, the value of the variable changes when returning to the upper hierarchy.

As an example, FIG. 8 shows a block "Find the factorial of n" using a recursive call. In this example, the value obtained in the argument “f” in the “begin” input terminal is stored and “factoria
The value is used as a result of calling "l". To reiterate the message I / O terminals that appear in the lower hierarchical block, since the block is represented as a sub-procedure of the control entity, the I / O message terminals that appear in the block are those of the control entity that calls the block. Interpreted as a message terminal.

 The syntax of "begin terminal" and "end terminal" is shown below.

begin terminal :: = 'begin' | 'begin' () | 'begin' (argument list) end terminal :: = 'end' | 'end'('TRUE') | 'end' (FALSE ') argument list: : = Type declaration name | argument list, name | argument list, type declaration name The argument list is made up of type + name, or names separated by ",". Evaluating from left to right, type + name declares that the argument with that name is the specified type. In addition, only names separated by "," declare that the argument is of the same type as the left argument. Therefore, in the example of int a, b, char c, int d, float f, g, “a” and “b” are int type, “c” is char type,
“D” declares that it is an int type, and “f” and “g” declare that it is a float type.

 The syntax of the lower-level call is shown below.

Lower-level call ::: name | name (value list) | name | name (value list) value list ::: value | value list, value Planet supports split compilation,
When calling a lower-layer procedure that is not in the same source file, write "\" first.

Input / output terminal In the message transmission / reception operation between control entities, a terminal corresponding to a reception port is called an input terminal. on the other hand,
The terminal corresponding to the transmission port is called an output terminal.
The input / output terminals are shown in FIG. The input terminal and the output terminal have the same oval shape. An output terminal has an oval input arrow, and an input terminal does not have an arrow. The input / output terminals are given names. The "begin" terminal described in the hierarchy of procedures above and "en
The “d” terminal is not treated as an input / output terminal.

The message transmission operation is performed when control reaches the output terminal. The message receiving operation is performed when the message reaches the input terminal. That is, the input terminal functions as a message buffer. When an arrow is connected from the input terminal, the message is read out when the message is input, and the processes after the arrow are driven. On the other hand, a message is read from an input terminal without an arrow by a message reading operation described in a procedure series. The message reading operation is performed by writing the input terminal name in the condition judgment phrase.

The input / output terminals correspond to the message terminals of the subsystem when the control entity is viewed from the outside. That is, as shown in FIG. 8, when the control reaches the output terminal (a) and the message transmission operation is performed, the message is exchanged by the message combination as shown in (c). The message reaches the input terminal of (b), and the message can be used. Also, it is possible to transmit and receive messages of different control entities in an internal procedure as shown in (d), without describing the state of message connection as in (c).

When data is to be added to the message, a list of values separated by "," is enclosed in parentheses and sent and received together with the name of the output terminal as shown in (a) of FIG. 10 (in this case, "(1,5,1 .
234) "is that. It is also possible to use variables. ). On the other hand, in the message connection between the subsystems that receive the message, a list specifying the name and type of data is added after the name of the message terminal as shown in FIG. In this example, "(int x, int y, float z)" of the message terminal of the output side subsystem and "(x, y, z)" of the message terminal of the side subsystem are data lists. Further, a list "(int a, b, float f)" in which the data to be input and the type are specified after the name of the input terminal as shown in FIG. In this example, three values of integer-type data "1" and "5" and floating-point type data "1.234" are communicated in a message. When this message reaches the input terminal of (c), the arguments “a”, “b”, and “f” of the input terminal include:
Values of “1”, “5”, and “1.234” are set respectively. When a message is output to a different control entity in the internal procedure of the control entity as shown in (d), the value sequence of “(1,5,1.234)” must be described directly in the message terminal of the subsystem. Data can be transmitted.

Further, the data in the message on the diagram of FIG. 10 (b) showing the message combination can be processed. For example,
If the value list of the message terminal of the message input side subsystem is changed to "(y, x, z)", the values are exchanged for the input arguments "a", "b" and "c" of (c). , "5", "1", and "1.234" are set respectively. Also, "(x +
If the value is converted by an expression such as "1, y, 2 * z)", the obtained values "2", "5", and "2.468" are respectively set.

When transmitting and receiving a message including data, the arrangement of data types between the message terminal and the input / output terminal must match.

The syntax of the input / output terminal and the message terminal of the subsystem are shown below.

Input terminal :: = name | name () | name (argument list) Output terminal :: = name | name () / name (value list) Subsystem message output terminal ::: name | name (variable binding list) Subsystem Message input terminal :: = name | name (value list) Variable binding list ::: type declaration Name | name | variable binding list, type declaration name | speed binding list, name The variable binding list is different from the argument list described above. Make an evaluation. As an example, use the same declarations as in the argument list: int a, b, char c, int d, float f, g. The variable binding list is also type-name or name-separated by ",". Those whose names are separated by ",", for example, variables "b" and "f" are those declared elsewhere, such as internal variables and input arguments. Then, when the message is passed to the message terminal, the data in the message is stored in the variable.

Event Waiting Node The process of waiting for input from the outside world is called an event waiting node, and is described by a double rectangular node as shown in FIG. The processing is "wait until ● becomes". " In the rectangle, a condition judgment phrase “? Is ●?” Is described. When control reaches the event waiting node, the conditional clause is evaluated. The evaluation of the condition judgment phrase is repeated until the condition judgment phrase returns true.

The following three types can be applied as condition judgment phrases.

The value of the determination result of the input sensor state is, for example, a condition determination such as whether the switch is turned on or the value of the input port has reached a specific value.

Time wait element The processing is interrupted for the specified time based on the condition judgment whether the time has elapsed.

Input terminal name If a message arrives in the condition judgment of "has the message arrived at that input terminal?", A message read operation is performed.

Activity Processing Section Processing for outputting to the outside world, performing calculations, and substituting values is referred to as activity processing and is described in a single rectangular section as shown in FIG. In the rectangular section, a phrase for performing the processing of “do ◎” is written.

Conditional branch clause The conditional branch structure of a procedure sequence is described by a conditional branch clause. FIG. 13 shows a description example of a conditional branch clause. As shown in the figure, the conditional branch node has a shape in which rectangles are stacked, and has a plurality of output points. A conditional judgment phrase is written in each rectangle, and the control that has passed through the conditional branch node is output from an output point where the condition is satisfied among a plurality of output points. Since output points are sorted, conditional branching is realized. The evaluation of the conditional branch starts from the upper left corner downward, and the evaluation proceeds downward if the condition is satisfied, and proceeds to the right otherwise. If the evaluation reaches the point where there is no condition judgment below, the processing after the corresponding output point is continued. A special phrase "else" can be entered in the conditional judgment phrase of the conditional branch clause. “Else” is evaluated last in the operation “evaluation proceeds to the right if the condition is not satisfied” and always becomes “true”. Therefore, if all the conditions are not satisfied, the control is output to the output point "else".

In the case of the example of FIG. 13, “sw == ON” is evaluated first.
If sw is input, then "ph c == OFF" is evaluated, and if phc is not input, control is output from output point a. If phc is input, “i == 2” is evaluated, and if the variable i is 2, control is output from the output point b. If the variable i is not 2, the output point c is determined by "else".
Outputs the control. If sw is not input first, control is output from the output point d by "else" at the right end.

Selective event wait clause In the real-time processing requirements, multiple events are detected at the same time, and if one event is detected, processing corresponding to that event is continued and waiting for other events is abandoned. There are many things that result in the process of doing. The problem of performing an abnormal detection of a controlled object in a time waiting process, such as `` Waiting for the sensor to detect after energizing the solenoid, and warning if the sensor does not detect after 2 seconds, '' One switch is monitored, and processing is performed according to the switch that is input first. " This is called "selective event waiting" in the planet, and is described by the selective event waiting node as shown in FIG.

The selective event waiting node is a node in which event waiting nodes surrounded by a double rectangle are arranged side by side, and each waits for an output point, and has a shape very similar to a conditional branching node. The execution rules are as follows. If the Selective Event Waiting node is activated, all event queues that are next to each other are driven in parallel. The processing after the output point corresponding to the established one is continued. In FIG. 14 (a), two selective events of “sensor == ON” and “timer == 2000” are awaited. That is, if the sensor inputs first, the sensor exits from the output point a and performs normal processing. If the time has elapsed for two seconds, the error recovery processing is performed from the output point b. FIG. 14 (b) shows “sw1 == ON” and “sw2 ==
ON "and" sw3 == ON ". The three switches are scanned, and control is opened from output points c, d, and e, respectively, corresponding to the first input switch.

The operation of rejecting another control at the end of the selective event wait is effective even when the lower hierarchy is being called. This is a very powerful feature. The process of detecting a stop request at the same time as executing a series of procedure series and interrupting the running procedure series when the stop request is issued can be described by a selection event wait node. . The columns are shown in FIG. In the figure, it is assumed that "cycle" of the left event waiting node has a lower hierarchy and executes a series of procedural steps for controlling the machine. The event waiting node “stop” on the right is waiting for input of a stop request message “stop” to this control entity. When the control reaches the event waiting node at the time of selection in the figure, "cycle" is started. At the same time, the process of detecting the stop request message is also driven. Before the stop request message is input, the program controls the operation of the machine by the procedure "cycle". Due to the operation of the optional event waiting node that the stop request message arrives, all the control executing “cycle” is rejected, and the execution of “cycle” is interrupted. Then "sotp"
After the waiting output point, the reset operation of the machine body is performed, and the process ends.

Repetition control frame Describe the repetition structure of the processing series in a repetition frame. If a loop is formed by connecting the arrows, the structure becomes a repetition. However, since the program becomes complicated, it is desirable to use a repetition frame. FIG. 16 shows a description example. The repeating frame is
It is composed of a rectangular node indicating the control means at the upper left corner, a rectangular node surrounded by "end" at the lower right corner, and a frame having the two rectangles as diagonals.

The repetition control frame operates as follows. The repetitive structure starts when control reaches the rectangular node in the upper left corner. The control is distributed by the control means described in the rectangular section, but when the control is still in the repetitive structure because the escape condition has not been satisfied, the section from the rectangular section to the “end” rectangular section in the lower right corner is Execute a procedural sequence. When control reaches the “end” rectangular node, control is transferred again to the upper left corner control means node. In this way, the procedure sequence sandwiched between both rectangular nodes is repeatedly executed. When the condition is satisfied and the control means clause repeatedly escapes from the structure,
The procedure sequence after the “end” rectangle clause is executed. Furthermore,
It is also possible to forcibly escape from the repetitive structure by using a conditional branch clause or a clause waiting for an optional event. Control means include "loop" clause, "while" clause, "until" clause, "for"
A phrase is provided.

"Loop" clause The "loop" clause implements an infinite loop. Unconditionally "en
The execution of the control sequence leading to section "d" is repeated. In order to escape from the infinite loop, it is necessary to escape with a conditional branch clause or a selective event wait clause.

"While" clause The syntax of the "while" clause is as follows.

while clause ::: 'while' (condition decision clause) When control reaches the "while" clause, the condition decision clause enclosed in parentheses is evaluated. If so, control is distributed to the "end" clause.

"Until" clause The syntax of the "until" clause is as follows.

until clause :: = 'until' (condition judgment clause) When control reaches the “until” clause, the procedural sequence from the “until” clause to the “end” clause is executed, and control reaches the “end” clause. Then, the condition judgment clause enclosed in parentheses in the "until" clause is evaluated. Control is distributed after the "end" clause if the result is true, and after the "util" clause if false.

"For" clause The syntax of the "for" clause is as follows.

for clause :: = 'for' variable = value 'to' value | 'for' variable = value 'to' value 'step' constant The "for" clause is a control means for sequentially tracing an additional closed interval. The above "variable" must be declared. For example, in the for clause of "for i = x to y step c",
Area r surrounded by section start value x and section end value y
(R = {j | x <= j <y}) is repeated from the variable i by increments of x from the variable x until i is within r.

Expressions and Data Types The basic data types that can be manipulated by Planet are shown below.

The details of each data type are described below.

char type 8-bit binary number. Unsigned data from 0
Take values up to 255. Used to represent letters and small integers.

int 16-bit signed binary number. −32768 to +327
Take values up to 67. The MSB in the 16-bit data represents the code. Negative numbers are represented by two's complement. This is a commonly used integer.

long type 32-bit signed binary number. A very large range of integers from −2147483648 to + 2147483647j can be represented. Like the int type, negative numbers are represented by two's complement.

float A floating point number. It consists of 32 bits including the sign bit, exponent part and mantissa part. The format of the data is called short real and conforms to the IEEE standard. FIG. 17 shows the data format.

Used to operate the sensor / actuator connected to the bit type I / O port. The operation of a bit-type variable sets the bit variable to zero judgment and sets the bit variable to 1. Set the bit variable to 0. Other than this, for example, you cannot take or or and.

port type Used to perform 8-bit operation of I / O port. In the port type, a physical address is specified by an I / O port address. When a port type variable is referenced, it is treated as char type data. To set a value to a port type variable, data other than bit type can be used, and the value set at this time is converted to char type and stored.

Internal variables and I / O variables Char, int, long, and float data can be stored in memory. The language processing element that says this is an internal variable declaration. The description of the internal variable declaration is shown below.
Further, when accessing I / O port data, that is, bit type and port type data during the procedure, the same declaration as the internal variable declaration is made.

int i, j, k, char ch; long cout, float data; bit sensor, solenoid; port outport; In the above table, the variables "i", "j" and "k" are int type,
"Ch" is char type, "count" is long type, "data" is float
It is declared as a type, and each area is allocated in memory. Bit-type and port-type data are used to notify the compiler that I / O data with the declared name is being used without securing an area on the memory.

 The syntax of the internal variable declaration is shown below.

Internal variable declaration ::: type declaration name | 'global' type declaration name | internal variable declaration, name | internal variable declaration, type declaration name | internal variable declaration; internal variable declaration | internal variable declaration [positive constant] type declaration :: = 'Char' ￥ | 'int' | 'long' | 'float' | 'b
it '|' port '| Data structure vs. declaration name This section describes how to secure the storage area for internal variables. The internal procedures of the control entity form a hierarchy. Variables declared in the top-level procedure are allocated in static memory, and remain present throughout the execution of the program. On the other hand, when an internal variable is declared in a block declared as a lower layer, the internal variable is dynamically generated on the stack frame when the lower layer is activated. Then, when the lower hierarchy ends the procedure, the secured variable area disappears. In the lower-layer procedure, if the qualifier "global" is described before the type declaration as described in the above syntax, the top-level statically declared variable can be accessed.

Lower layer call and input argument The data given when calling the lower layer procedure is called an input argument. As mentioned earlier, "begin
The argument list written in "terminal" corresponds to it. Data declared as input arguments can be accessed in the same way as internal variables. The above six data types can be given as input arguments. The lower-level calling mechanism is as follows. The input argument is passed the address of the variable (this implements a name call). Argument is
For char, int, long, and float types, the address in memory is passed. In case of bit type / port type, I
The / O port address, I / O port address and bit position are passed. When accessing an input argument, a data value is obtained from a given address and used. When a value that is not a variable name is passed as an argument of the lower hierarchy call, for example, an immediate value such as “1” or “3.1415” or “i +
In the case of an operation result value such as "1", the address cannot be defined because it is not a variable. When passing such a value to the lower hierarchy, the processing system first secures a temporary memory area and stores the value. Next, a running code is generated to pass the address of the stored area to the lower and lower layers.

Data in message The access of the data contained in the message is described. Since a message is frequently generated and deleted, a unique storage area management different from a stack frame is performed. From the time the message is entered, the data contained therein can be accessed in the same way as internal variables.

Data Structure The basic data types arranged on the memory of the char type, int type, lont type and float type constitute more complicated data structures called arrays and structures. Since they are arranged as a unit in a continuous memory area, they can be applied to various algorithms and can easily express various problems. The arrangement and structure are described below. The handling of the data structure conforms to C.

Array An array is an array in which a specified number of contiguous areas are allocated for the data of the structure described below, such as char, int, long, and float. Planets can also use multidimensional arrays. For array data, the number of data elements immediately after the data name (positive constant)
Is declared by enclosing it with "[]". Each element is 0
An example will be described in which a set having attribute values from “to 100” and a frequency distribution in increments of 10 are obtained. At this time, "int
histgram [11] "and an array expressing the histogram are declared. The elements in the array are specified by the number of elements counted from the top. The first element of the array is 0. "Histgram [i]" specifies the i-th element of the frequency, and the value of i is 0 to
There are 10 11 types. Thus, the data structure is determined and all the elements 0 of the array are initialized. Thereafter, when an element having the attribute value atr is given, the “art / 10” th element in the histgram is incremented by one. When this is performed for all the elements of the specified set, the number of elements that take the value of 0
In [0], the number of elements taking values from 10 to 19 is histgram [1]
..., The number of elements taking 100 is obtained in histgram [10]. In the case of a multidimensional array, "char b [10]
Declare by arranging the number of elements enclosed in [] as in [5]. In this example, it is declared that the char type data is bundled in 10 × 5 two dimensions.

Structure A structure is used when you want to handle tabular data in a program. The current value measured by a certain measuring device is taken. The measurement data may include a plurality of data such as a measurement item when there are a plurality of measurement locations, a measurement date and time when measurement is continuously performed, and a current value. "Current value"
It is composed of a plurality of items. Declare this matter as a structure as shown in Fig. 18,
Can be used. Structures are named to specify their type. In this case, “CurrentData” corresponds to this. When handling structure data in a program, declare the name of the structure and use it when declaring variables and arguments.

Items declared in the structure are called members.
Data declared as a structure can be operated on an item-by-item basis. To specify a specific member in the structure, use "." As shown in FIG. A structure declared separately can be used as a member of the structure.
They can also be arranged in members.

An immediate such as the constant 1, 3.1415 or 'a' is called a constant. Constants are provided with character constants, integer constants, and floating-point constants.

Operators Various operations can be performed on the basic data described above. It has the same notation as the C operator.
Operators include unary, binary, ternary and assignment operators.

Planet Development Environment Next, the configuration of a program creation device that creates a program using a planet will be described.

The entire system (hardware) can be composed of, for example, the following components.

Main unit microprocessor (editor, compiler) Main storage device (capacity: 640 KB or more) Display (analog RGB display) Console (mouse) Target drive system processor communication device storage device I / O Prepared as a planet environment The main software is listed below.

xed.exe Editor xp1.exe Parser xp2.exe Intermediate code generator xp3.exe Z80 code generator xp3cc.exe Data generator for C language template xp4.exe Network linker commdrv.exe HDLC communication driver xnet.exe HDLC network configurator xdb.exe Debug Monitor xio.exe I / O checker xhex.exe ROMization utility The flow of program development using Planet will be described with reference to FIG.

Planet programs are edited with the editor xed.
The syntax of the edited program information is checked by the parser xp1. The parser generates an intermediate code for each diagram. These intermediate codes generated by the parser xp1 are converted into a large group of intermediate code files by taking in required intermediate codes for each processor (control subject) declared by the sorter xp12.
This intermediate code file is applied to a code generator xp3 to generate a z80 machine code. PC9801, P
When operating on C286 / 386, the 8086 machine code generator is not created, so it is necessary to write a program that performs the same operation in C language. Since the information of the communication packet required at the time of execution is output as a header file of C, the information is fetched and used. In order to generate the data necessary to generate this header file, it is necessary to apply xp3cc for PC9801.

The z80 machine code or the header information for C generated in this manner is converted into a code that actually operates by adjusting the command field included in the packet that flies over the network by the linker xp4. Furthermore, the linker xp4 is ".re1" written in the z80 assembler.
Import a file. That is, when a link between the planet and the assembler is required, the link operation is performed at the stage of applying the linker xp4.

Here, the files used by the planet development environment are listed below.

● It is a .src source file. In this file, all the graphic information of the program is stored. It is also possible to create multiple source files and link them.

dtstruc.def Stores the structure of the data structure. Required when parsing source files.

● .p1 ● Intermediate code file generated after parsing .src. An intermediate code file is generated for each diagram, and the analysis results of all the diagrams included in the source file ● .src are included.

hardware.def Stores the network topology (shape), the name of each processor (control body) and network address on the network, and the names and addresses of I / O ports and I / O bits used by each processor. I have. Intermediate code file ● .p1 is used to generate running code for each processor by collecting it.

srcs.tab This is the input file for the sorter xp2, in which the names of all the source files ● .src to be used are entered. This file is an ASCII file and is created by the user using a commercially available ASCII editor.

◎ .p1 A file created for each processor by the sorter xp2. This file stores all the schematic intermediate codes required by each processor. I / O
Information close to the hardware, such as port addresses,
Although not included in the intermediate code file ● .p1, it is added to the file ◎ .p2 by the sorter xp2. here,
"◎" indicates the processor name.

◎ .tr Debug information file input to the debugger.
The location of the source file, the hierarchical structure of the program, and the like are stored.

cpus.tab This file contains a list of processors that appear in the program. This file contains the processor name, processor type, and its network address. This file is an ASCII file.

◎ .cod This is a binary file of the actual running code output by the z80 code generator xp3.

◎ .p3 For a program that requires a link on the network, the definition of the packet format and network information such as the real address of a reference table for the definition are stored. Further, link information with an assembler for referring to an external library is also included.

◎ .dpx This is a debug information file generated by the code generator. Information such as which address of the actual code corresponds to what is described in the source file is stored.

◎ .bin This is a runnable binary file generated by the linker xp4. This is the final output file that can be downloaded from the debugger xdb or burned to ROM and run on a real machine.

◎ .cm This is a C program header file generated by the linker xp4 when the processor type is not z80.

The relationship between the input and output files of each part in the compiler that is a planet processing system is listed below.

Next, the operation of the editor and the operation of each processing unit constituting the compiler will be described.

(Editor xed) The editor xed edits the graphic information of the planet program and generates a source file for storing the graphic information. In the program information, a .src file that stores planet procedures created by the programmer, a hardware.def file that stores hardware input / output port information, and dtstruc that stores information of data structure declarations.
There is a def file. These three files are edited by the editor xed.

The planet program is formed for each screen, and it is necessary to edit each screen. Therefore, the maximum allowable area length in one screen is set in advance, and storage management is performed using a continuous storage area of the maximum length as one unit. This unit storage area is called a memory block. In the editor, a plurality of memory blocks can be held in main storage or auxiliary storage so that a plurality of screens can be displayed and edited at once. Here, the screen of the planet program has a hierarchical tree structure from its language specification. Accordingly, a block tag (Block Tag) as shown in FIG. 20 is set to represent the block management information.

The editing operation is performed using, for example, a mouse and a keyboard. This operation is performed in a multi-window system. As described above, a planet program is created for each diagram. One sheet displaying the diagram corresponds to one window. The window includes a hardware address declaration and a data structure declaration in addition to the program schema. While displaying these windows in a superimposed manner, it is possible to edit a number of windows at the same time. That is, the planet program management information is linked to the window system, and has a list structure shown in FIG. Therefore, planet program screen information can be obtained from a mouse event by the following procedure.

The window system obtains the identifier of the corresponding window from the x and y coordinates of the mouse event.

The display block list is searched for an element that matches this window identifier, and block management information “Block Tag” is obtained.

Screen information is obtained from the storage medium based on the contents of the block body in the “Block Tag”.

Here, when there are a plurality of processors on the network, the planet compiler creates the respective running codes operating on the respective processors at one time. To do this, the compiler needs to know what processors are present on the network, how each processor is connected, and what
Information such as which I / O ports are built in and what hardware is connected to which port address is required. Specifying such information is called a hardware declaration. This declaration is necessary as well as the procedure of the program. This declaration will be described using a system having a network structure as shown in FIG. 22 as an example.

First, the declaration of each processor in this declaration will be described. A processor on a network needs a name because it is a control entity itself. In the illustrated example, two processors “measurement” and “assembly” are connected to the processor “host”. Furthermore, “subm” is connected to “measurement”. In this figure, the numbers described at the left shoulder represent network addresses. The declaration of each processor is performed by specifying the processor name, the processor type, and the network shape, respectively. The processor name is specified by inputting a character string that can be described as a control entity name from the keyboard. The processor type is specified, for example, by inputting one of the following keywords. The compiler generates running code according to the drive system of the Jupiter STD-Bus system Jupiter, which generates different outputs for each processor type.

IO Generates a running code that matches the drive system for the IO system IO.

Personal Computer Generates a header file that declares the shape of a communication packet for a C program running on a personal computer. The program entity is programmed by the user with C.

Next, the declaration of the network shape will be described. This declaration is to declare the processors that exist in one hierarchy in the tree network. In the illustrated network, measurement and assembly are combined, so that processor processor
ent and assembly are declared. FIG. 23 (A) shows an example in which three processors existing in one hierarchy are declared. In this figure, a network address, a processor type, and a processor name are declared in order from the left. In addition, the network relationship of these processors is shown in the vertical arrangement relationship. In this way, the processor connection relation of the one-layer network statement is declared. Here, in the network shown, the processor subm must also be declared. This processor is connected to the lower layer of measurement. Measurement to declare this
Subm is declared as shown in FIG. 23 (B). The planet compiler detects a processor included in the program based on the information of such a network declaration, and creates a running code to be allocated to the processor.

(Compiler) This is a processing system that converts the graphic information of the planet program input by the user into a program that can be directly executed on the control device. It introduces the execution control rules of Petri net at the time of program analysis, and uses DFS and BFS in graph theory. , DAG
The control flow and the data flow are analyzed by using a method such as that described above, and the planet program structure obtained by the graphic is developed into a plurality of sequential processes operating in parallel.
The actual running code is generated by applying code selection of the microprocessor and optimization of the generated code to each of the processes generated as described above. Hereinafter, each processing system of the compiler will be described.

Parser xp1 The parser xp1 analyzes the graphic information file ● .src of the planet program created by the editor xed, and generates a three-address code which is a running code of the virtual machine. The third address code of the program is stored in an intermediate code file called ● .p1. The parser xp1 performs analysis for each program frame. The generated program information for each sheet is combined into one by the following operations to form a large program.

Sorter xp2 The sorter xp2 links, at the intermediate code level, the analysis result for each block output by the parser xp1. The linked intermediate code is stored in a file for each processor. Apply this file to the code generator described below,
A machine code that can be actually run can be obtained for each processor.

 The operation of the sorter xp2 is as follows.

First, the processor "◎" stored in the hardware.def file created by the editor xed is obtained.

A block that matches the processor name is searched from the specified input file group, and the intermediate code of the block is stored in the file ◎ .p2.

Further, when a block having the same name as the processor calls a lower hierarchical block, the lower hierarchical block is searched and added to ◎ .p2. In addition, all control entity blocks in which those blocks are activated are similarly searched and added to the ◎ .p2 file.

When storing all necessary blocks ◎ .p2 files, the processor ◎ searches for leaked I / O ports, bit address and name information, and finds I / O ports, If bits are used, write those addresses to the ◎ .p2 file.

Links global variables accessed by lower-level blocks.

Here, before starting this sorter xp2, it is necessary to create a file called srcs.tab that defines the input file list. This file can be edited with a commercially available ASCII file editor. In the srcs.tab file, enter the names of all source files needed by the program. The sorter xp2 detects the input file by reading this file, and performs the above-described operation.

Code Generator xp3 The code generator xp3 receives the intermediate code of the virtual machine output by the sorter xp2 as input, and generates a machine code that can run z80 equivalent to the intermediate code. The generated machine code depends on a planet driving system described later. The ◎ .p2 file output by the sorter xp2 contains all information that the processor can run alone. Based on the information, the generator xp3 generates not only machine code but also link information on a network and link information with other languages.

Linker xp4 Linker xp4 links all of those requirements based on the link information on the network generated by the code generator xp3 and the link information with the assembler, and the machine code that can actually operate on the planet drive system Generate In addition, a C header file is created for linking the processor described in C on the network. The linker xp4 operates by receiving the output of the code generator. First, the consistency of link information on the network output by the code generator is detected, and the shape of a communication packet flying over the network is determined. next,
Based on the information for linking the module described by the assembler, the module is searched from the specified library file, and the running code is added. The traveling code thus obtained is output as an actual traveling code file. When a plurality of processors are described in the planet program, the actual running code files of all the processors are generated at once.

(Debugger xdb) Whether or not the executable machine code obtained through the Planet compiler operates correctly can be verified using a debug monitor. The debug monitor program can be executed on, for example, PC9801, PC286 / 386. The contents of this debugger include functions such as downloading programs, tracing programs, monitoring I / O ports, and referencing and updating variables. With this debugger, the operation of the target processor can be monitored at the source level. Since it can be debugged at the source level,
Debugging work can be performed efficiently. This debugging work can be performed on a multi-window using a mouse and a keyboard as in the case of creating a program using an editor.

The monitoring of the target processor is done by the debugger xdb
It is performed via a network in which the processing system on which is running and the target processor are connected by a dedicated HDLC communication reselection. An inquiry command is issued to the target processor via a communication path, and the status of the target processor is monitored based on the response.

Here, in order to reduce the load at the time of execution of the target processor driving system for operating the planet program, an operation called an network configuration is performed. This operation is to add various information of the network to the board for controlling the communication in advance, and thereby the communication board and the drive system are operated in parallel to distribute the functions. In the drive system where this configuration is performed, this information is used, for example, for backup.
It is held in a storage device such as a RAM.

The debugging operation will be described. First, the network information of the planet driving system is displayed on the screen. That is, the network information of the file hardware.def edited by the editor xed is displayed. This display screen is called a processor window, and is displayed as shown in FIG. In this figure, the number on the left of each processor is the network address, and the number on the lower left is the identifier of the processor. These pieces of information are automatically generated by the combiner from the information in the file hardware.def.

Next, a target processor to be monitored is specified, and hierarchical information of all procedures included in the running code of the processor is displayed. This procedure is sorter xp2
And the procedure gathered by the linker xp4. No. 2
FIG. 5 shows a hierarchical diagram of the processor “host”. A source program in a target block of the hierarchical information is called. The specified source program is searched from the source file. FIG. 26 shows the source program of the called “main” block. After calling the source program in this way, the program is downloaded to the specified target processor.

Next, a breakpoint is set. When a breakpoint is set at a certain processing requirement, an indication that the setting has been made is displayed in the frame of the processing requirement. After setting the breakpoint, execution of the target processor is started.

During the execution of the target processor, the source program consisting of the graphic information in the created state is continuously displayed. When control reaches the section where the breakpoint is set, for example, a red Flashes to indicate that, and the control stops at this point.

When the process reaching the breakpoint is traced and the control is executed step by step, a red circle indicating the processing position is sequentially displayed in the active processing requirements.

After being debugged in this way, the program
It is stored in a storage medium such as a ROM.

Next, a drive system for executing the planet program created as described above will be described.

FIG. 27 shows the overall configuration of the drive system (kernel). In the figure, arrows indicate the flow of the process. Here, the process refers to the program control activated in the kernel.

In the figure, Initial Control sends the process to be executed initially (if any) to Process Execution when the kernel starts up. CP / in is a communication port that receives packets from other processes. The bucket itself is also a process. The Rx packet management evaluates the received packet and performs processing represented by the packet. Send the process to Process Exencution as needed. Process Execution is Initial Control or RxP
Execute the process sent from acket Management in order. If the executing processor issues a time wait request, the process is sent to Delay Control. When the execution process issues another processor execution request, the request is shaped into a process and sent to Tx Packet Management. De
The lay control receives the process sent from Process Executiont with the waiting time as a parameter, holds the process for the specified time, and then returns to Process Exec
ution. Tx Packet Management sends the received process to another processor via CP / out.

(Parallel Driving Control of Processes) During the execution of the planet program, one or more processes exist in the processor. As a method for operating multiple processes simultaneously, TSS (Time Shea
ring System) is generally adopted. However, in this method, side effects always occur due to the fact that multiple processes access the shared variable. Since this side effect is considered to be a major bottleneck in program verification and makes debugging difficult, there is a need for an alternative method. Hereinafter, this point will be described in detail.

In view of the characteristics of the device embedded software, the operation of the target control device can be considered to be sufficiently slow in comparison with the processing capability of the CPU. For example, the response speed of the photocoupler of the I / O board that controls the machine is even on the order of 10 milliseconds, and with this time, it is possible to perform considerable processing even at z80. is there. In view of this point, a plurality of processes that operate in parallel are executed “waiting and catching” while waiting for some event. Then, if an event occurs, a response process is performed in an instant. As described above, generally, the time required for the response processing is extremely shorter than the time interval of the occurrence of the event. In consideration of this point, the planet driving system adopts the following principle as the principle of the parallel driving process.

Consider a case where a plurality of processes are each in an event waiting state. In this case, each process detects the occurrence of an event. If no event has occurred, make a system call (SWAP) to execute another process. In this way, a plurality of event waits are sequentially detected, and when an event occurs, the process immediately performs a response process, and thereafter runs to the next event wait process in the sequence.

That is, Process Execution is Initial Control,
It accumulates processes sent from Rx Packet Management or Delay Control. These processes accumulate by coupling to a ring queue, as shown in FIG. Further, a pointer to a process called Rung is set.
The parallel operation form of Process Excecution is as follows.

The control is passed to the code address indicated by the Program Code address tag of the process specified by Rung.

The process given control runs the given code and returns control to the program execution.

Step through the process directed by Rung.

The above operations are repeated.

 The details of the running code of the process will be described.

FIG. 29 shows a sequential procedure of “executing action1 after detecting event1, and further detecting event2”;
An example of a sequential procedure "execute action2 after detecting event3" is shown. In this figure, (b)
The code UPDATEPC appearing in (d) is a system call. This functions to set the running code address immediately after UPDATEPC when the process drive is performed by the above SWAP. The execution of the process will be described following the running code. When the process running in the procedure sequence (b) reaches (a), the address (b) is registered in the PCB (Process Control Block) representing the process by UPDATAPC. Next, the event detection of (a) is performed, and if this does not occur, the execution of the process is interrupted by the SWAP of (c). When the process is executed again, the process is executed from the address (a) set by UPDATAPC. If event1 has not occurred, execution is interrupted again by SWAP. However, if event1 has occurred, the execution code of action1 of (d) is run, and then UPDATEPC of (e) for event waiting is performed, and event waiting event2 is detected. Similarly, a procedure for detecting event3 is performed.

(Process drive control) In order to provide services with repetitive CPU time to processes, PCBs that correspond to each process
Are connected to a ring queue (drive queue) in the drive system as described above. PC coupled to drive queue
B is executed at that time. PCB for this drive queue
There is a system call to insert or delete a file.

Of these, the system call FORK is for inserting a new PCB into the drive queue when a planet program is executed, thereby generating a new process and operating it in parallel. In this FORK, the start address of the procedure to be invoked is set as a parameter. In terms of process execution, when a process reaches the FORK system call, the driving system obtains a new process and inserts it into the driving queue. After processing the newly inserted process, the process that issued the FORK continues execution. After FORK finishes processing, it generates an identifier of the created process.

This procedure is shown in FIG. As shown in the figure,
When the running code of the process in the execution state under the process execution issues a FORK to the process execution, another code acquires the process and participates in the parallel driving state. By giving the driven code address as an input parameter of this procedure and calling the FORK procedure, a process identifier is obtained as an output parameter.

The ABORT system call is then issued when abandoning a process that has executed a series of sequential procedures.
When this is issued, the drivetrain responds to the process
Remove PCB from drive queue and reject. That is, the third
As shown in Fig. 1, when a running process terminates running and abandons process driving, this process
Issuing an ABORT for ess Execution removes this process from the parallel drive.

The KILL system call is issued when you want to destroy a running process from another process. A process identifier is required as an input parameter. When KILL is issued, the drive system is the PC corresponding to the specified process.
Delete B from the drive queue and discard it. After this, KILL
Process continues to execute. That is, the 32nd
As shown in the figure, the running code of the process in the execution state is a process execution request
By issuing L, other processes are excluded from the parallel drive system. Procedure as an input parameter of the KILL procedure
Use the process identifier returned by FORK. That is,
The group of processes that are driven in parallel in association with each other need to have means for recognizing the identifier of the process to be stopped.

The DELAY system call is issued when suspending the process drive for the time specified by the input parameter. The PCB corresponding to the process that issued this call
It is deleted from the driving queue and re-inserted into the driving queue after a specified time. After insertion, execution is performed from the address after issuing DELAY. In this way, the process of waiting for the designated time is realized.

(Process Synchronous Processing) A description will be given by taking a planet program having a connection structure as shown in FIG. 33 as an example. This program describes the parallel driving of processes and their synchronization. Here, two processes are required. This is because the processing sequence is divided into two. Synchronization of these processes is generally realized by a counter as shown in the figure. Here, mvalue is that variable. First, the synchronization counter is initialized to 0 (A). Next, code is generated to execute "ml" (a). After this, since the arrow is divided into two, the FORK system call is executed so that the processing sequence on the left is executed by the current process and the right is executed by the new process (c). This FORK
When the processing is completed, the execution is started from the next address, so the left traveling module m2 is arranged at the position (d). Here, since the synchronization is realized as shown in (g) and (h), the user jumps into the code (e). Next, a module m3 to be operated in parallel is arranged (f). The code that achieves synchronization runs in two processes. The process reached first increases mvalue by 1
To Since mvalue is not 2, the process that arrived first is discarded. The next process arrives at mvalue 2
To As a result, the process is not
Drive on m4. In the example here, it is 2, but mval
The comparison value with ue matches the number of arrows to be input.
By the mechanisms (a), (g), and (h), a process for achieving synchronization is realized. The process that has reached the last synchronization mechanism will continue processing, and will perform the operation that is otherwise discarded.

(Hierarchy management) Hierarchy management is realized using a stack. Each process is provided with efp and erp representing the stack frame of the current hierarchy and a stack pointer sp. Each process accesses internal data by its own frame pointer and offset. Referring to FIG. 34, the procedure for invoking the lower hierarchy will be described below.

In order to obtain a storage area for storing output data, the stack pointer SP is reduced by the area length (SP1).

Push input data (SP2).

Push the current frame pointer (epr and efp) (SP3).

Push the return address (SP4).

Let the current stack pointer value be the new frame pointer. That is, epr is set to its own process ID, and efp is set to SP4.

Jump to the lower layer code address.

When the lower layer finishes processing and passes control to the upper layer, the procedure is as follows.

Set the stack pointer to the value of the frame pointer (SP
Four).

Pop return address (SP3).

Pop the frame pointer (SP2).

Updates the current frame pointer value to the value popped by.

To jump to the popped address.

Further, the procedure when the control is transferred to the upper hierarchy is shown below.

Stack pointer to destroy the input data area
Increase SP by region length.

Pop output data.

The actual running code generated by the planet compiler when calling the lower hierarchical block will be described below. In the planet program, different calling methods are performed depending on the types of processing requirements appearing in the upper hierarchical block. Input arguments, return addresses, and internal variables used in the lower hierarchical block are secured on the stack, and LIFO management is performed.
As a result, recursive calls can be realized.

First, if the activity processing clause has a lower hierarchy,
The call is realized by the following running code.

GETSTACK push parameter (n) 's pointer ··· push parameter (1)' pointer call subargument add sp, pushed size ABORTSTACK The stack of the process executing the program is usually a process. And a general-purpose memory area shared by the drive system. When calling the lower hierarchy, a stack is required. At this time, the stack is realized by the LIFO incorporating the unique storage management mechanism described above. The above-mentioned GETSTACK system call requests a stack from the storage management mechanism. When this system call is performed, a unique stack is allocated to the issuing process, and the process can call a lower hierarchy.

In Planet, a parameter pointer is passed as an argument of a lower hierarchy. This implements a name call. Therefore, if there is an input argument, the address of the variable, the I / O port or the address of the bit is pushed in order from the right of the argument list. In the lower hierarchy called in this way, the input argument is accessed with a positive offset from the stack frame pointer. When an input argument exists in a lower hierarchy, when calling the lower hierarchy, the address of the argument is pushed. Then, subarg
When ument is called and control returns from the lower hierarchy, the stack pointer is increased by the area length of the input argument pushed before calling, and returned to the stack pointer value previously obtained by GETSTACK. Further, it issues ABORTSTACK, a system call that returns the stack allocated to the storage management mechanism.

If the lower layer has the event waiting node, the call is made as follows.

GETSTACK push parameter (n) 's pointer push parameter (n-1)' spointer ... push-button (1) 'spointer size ABORTSTACK Same as for the active clause above, up to the point where the stack is obtained and the input argument pointer is pushed.
The rest is different. In other words, when the lower hierarchy is a condition judgment phrase, the compiler forms the running code so that the result of the condition judgment is returned to the HL register pair. In the case of event holding clause, after calling the lower hierarchy, the HL register pair is determined, and until this HL register is no longer 0.
Generates code to continue calling lower layers.
At this time, if a stack is secured each time, the time for securing the stack cannot be ignored. To do this, issue an UPDATEPC system call after pushing the input arguments onto the stack. Even when control is passed to another process that runs in parallel, the execution control method is adopted so that the area of the input argument is not destroyed, so it is possible to sandwich the lower hierarchy that continues to be called between UPDATEPC and SWAP. is there. When the lower layer returns a value other than 0, the stack is released. A similar running code is generated for the selective event waiting node.

Next, the call mechanism of the conditional branch clause is a simplified version of that of the above-described event wait clause, and is as follows.

GETSTACK push parameter (n) 's pointer push parameter (n-1)' pointer ... push parameter (1) 's pointer call subargument add sp, pushed size ABORTSTACK Test HL register pair and jump true address if n
on-zero In other words, the called lower hierarchy
Since it is returned to the HL register pair, its value is evaluated to generate a running code so as to realize a conditional branch structure.

(Message communication control between processors) The message that connects multiple processors is a dedicated HDLC
Performed on a serial communication line. The planet compiler generates a finite-length message buffer corresponding to the input / output terminal of the control entity in the program. When a process needs message communication, it performs read / write operations on the message buffer.

The message buffer is configured as a finite-length ring buffer having a fixed data length when the message contains data, the number of valid messages existing in the buffer, a message data read pointer, and a message data write pointer. , Consists of a data pool. If the message contains no data, it consists only of the number of messages.

First, message communication between control entities will be described. No. 35
As shown in the figure, an example in which the control entity B receives a message output by the control entity A will be described. The Planet Compiler uses
Write to message buffer output of control entity A
Generate running code to perform the operation. If an arrow is output from the message terminal of the subsystem, the message buffer outp of the control entity A is output.
Generate code to perform read operation on ut. read
Message buffer in of control entity B after operation
Place the code that performs the write operation in pout.
On the other hand, in the internal processing of the control entity B, the message buffer
Generate running code that performs read operation on input. Thus, the message output by the internal processing of the control entity A is used in the internal processing of the control entity B.

Here, in the planet program, since the processors themselves are control entities, message communication between the processors is realized by the same mechanism as the message communication between the control entities described above. In this case, the message buffer read / write operations, and the event detection to perform them,
This is performed by a remote procedure call to an external processor via a communication path. Read / wri of a certain message buffer
The te operation can issue a request from any processor in the network. Various parameters are required for such an issuing operation. Hereinafter, these parameters will be described, and the function of the procedure call will be described.

Processor identifier Network parameters are required to make a remote procedure call. That is, in order to specifically issue a processing request (procedure call) to a processor, a destination such as to which processor is to be sent is required. This is represented by the processor identifier.
All processors declared in the Planet program have network location numbers.
This identifier is set incrementally while traversing the tree structure of the network declared in the file hardware.def in a depth-first manner. This is done automatically by the compiler as described above. On the other hand, at the time of network configuration, information on the network connection shape and the processor identifier is distributed to all processors. Therefore, when the network is in operation, it is possible to specify the destination only by specifying the processor identifier, without being aware of the network shape.

Message Buffer Identifier It is possible that there are multiple message buffers in the processor running code. A message buffer identifier is required to specify which of these message buffers to operate on. This identifier is also generated automatically by the compiler. Based on the processor identifier and the message buffer identifier, it is specified which message buffer of which processor is to be operated.

Remote Procedure Call A remote procedure call implements a message communication function consisting of the following four steps.

Detection of whether or not the message buffer is full Write operation of the message buffer Detection of whether or not the message buffer is empty Read operation of the message buffer As an example, operation of performing a write operation to the message buffer x in the external processor X State. A detection request is issued to processor X to determine whether buffer x is full. When the buffer is full, a detection request is issued to the processor X at a certain period until a report that x is not full is returned. Then, the data in the message is given to the processor X, and a write request to the buffer is issued. With the above operation, the message is passed to the processor X.

Next, an operation of performing a read operation on a message buffer in the processor X will be described. When you get a reply that the buffer is empty, the buffer is no longer empty,
The detection request is continuously output to the processor in a certain cycle. When the buffer is no longer empty, the processor
Issue an ad request. The processor that received the read request re
Performs an ad operation and sends a reply with the data attached to the message. With the above operation, the message is passed from the processor.

〔The invention's effect〕

As described above, in the program creating apparatus of the present invention, a screen for creating a program is displayed by the screen display means, and on this screen, a program language element generated by the graphic pattern generating means is selected to execute the program. Can be created. The program language elements include a directional branch and a directional branch. In particular, a plurality of processing sequences branched by the directional branch are converted into a program that is automatically processed in parallel by the translation unit. It is supposed to be. Therefore, according to the present invention, it is possible to efficiently and easily create a parallel drive program or the like in a network or the like in which a plurality of control entities exist. In particular, a translating means for translating the created program into a machine language, based on information obtained from the hardware information holding means, controls each of a plurality of processing element sequences following the first directional branch to a plurality of control elements. Since there is a parallel processing program allocating means for classifying and allocating as a program to be processed in parallel by each of the subjects, it is possible to automatically generate an object code for each of the control subjects and download and operate each of the control subjects. This makes it much easier to create a program to be processed in parallel by a plurality of control entities on the network.

When a plurality of screens for program creation can be displayed, the lower layer side program of each processing element of the program created on the same screen is replaced with another one layer defined as a lower layer of the processing element. Can be created on the screen. Therefore, it is possible to efficiently create a large program from the top down or the bottom up.

On the other hand, the debugging means according to the present invention can reproduce and display the same screen as at the time of creation, and perform debugging on this screen. Therefore, there is also an advantage that the verification position of the program can be intuitively recognized, and the debugging work can be easily performed.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a model of a control entity in a planet which is a programming language. FIG. 2 is an explanatory diagram showing an example in which the relationship between control entities is described using a planet. FIG. 3 is an explanatory diagram showing a description example of internal processing of a control entity by a planet. FIG. 4 is an explanatory diagram showing the hierarchy of procedures by a planet. FIG. 5 is an explanatory diagram showing the hierarchy of procedures by a planet, similarly to FIG. FIG. 6 is an explanatory diagram showing a program frame of the planet. FIG. 7 is an explanatory diagram showing a description example of a subsystem of the planet. FIG. 8 is an explanatory diagram showing an example of description of a lower layer call by a planet. FIG. 9 is an explanatory diagram showing a description example of a message transmission / reception operation by a planet. FIG. 10 is an explanatory diagram showing a description example of message transmission / reception including data by the planet. FIG. 11 is an explanatory diagram showing a description example of a node waiting for an event by a planet. FIG. 12 is an explanatory diagram showing a description example of an activity processing section by a planet. FIG. 13 is an explanatory diagram showing an example of description of a conditional branch clause by a planet. FIG. 14 is an explanatory diagram showing a description format of a selection event waiting node by a planet. FIG. 15 is an explanatory diagram showing an example of a planet program for interrupting a procedure. FIG. 16 is an explanatory diagram showing a description example of a repetition control structure using a planet. FIG. 17 is a diagram showing the format of floating-point data. FIG. 18 is an explanatory diagram showing a description example of a data structure in a planet. FIG. 19 is an explanatory diagram showing a flow of program development using a planet. FIG. 20 is an explanatory diagram showing a block management state. FIG. 21 is an explanatory diagram showing a display block list. FIG. 22 is a block diagram for explaining a hardware declaration. FIG. 23 is an explanatory diagram for explaining the procedure of a network declaration. FIG. 24 is a diagram showing a processor window. FIG. 25 is a diagram showing a screen displaying a hierarchical structure of a certain processor. FIG. 26 is a view showing a screen on which the source program of the block “main” displayed on the screen of FIG. 25 is displayed. FIG. 27 is a block diagram of the entire configuration of the planet driving system (kernel). FIG. 28 is a diagram showing a ring queue of a process. FIG. 29 is an explanatory diagram showing a development example of event detection and response processing. FIG. 30 is an explanatory diagram showing the "FORK" procedure. FIG. 31 is an explanatory diagram showing the “ABORT” procedure. FIG. 32 is an explanatory diagram showing the “KILL” procedure. FIG. 33 is an explanatory diagram showing an example of synchronizing a plurality of processes. FIG. 34 is an explanatory diagram showing hierarchical management. FIG. 35 is an explanatory diagram showing an example of message communication. [Explanation of symbols] xed ... editor xp1 ... parser xp2 ... sorter xp3 ... code generator xp4 ... linker xdb ... debugger.

──────────────────────────────────────────────────続 き Continuation of the front page (56) References JP-A-2-236624 (JP, A) JP-A-63-167932 (JP, A) JP-A-62-2242280 (JP, A) JP-A-4- 130958 (JP, A) JP-A-4-18605 (JP, A) Uchihira et al., "Design method of parallel program using hierarchical Petri net", Information Processing Society of Japan research report (89-SE-69), ( 1989.11.24); 7.1-7.8 Iwabuchi et al., “Embedded Software Development Device”, Proc. Of the 39th Annual Conference of Information Processing Society of Japan (late 1989) (▲ II ▼), (1988.10. 16), p. 1578-1579 (58) Field surveyed (Int.Cl. ⁷ , DB name) G06F 9/06-9/44 G05B 15/00-19/46 G06F 11/28-11/36

Claims (4)

(57) [Claims] 1. A program creating apparatus for creating a program to be processed in parallel by a plurality of control entities on a network, comprising: hardware information holding means for holding hardware information of a network including the plurality of control entities; Screen display means for displaying a program creation area on a display screen, program creation means for creating a program on the display screen, translation means for translating the created program into machine language, and translated machine language Storage means for storing a program, wherein the program creation means is capable of generating a plurality of types of drawing patterns for displaying the contents of each processing performed in time series of the program; Hardware information capable of inputting the hardware information on the display screen And a pattern selecting means for sequentially selecting the graphic patterns and displaying them on the program display screen, wherein the graphic patterns include a plurality of types of graphic patterns indicating processing contents and a time-series of processing requirements. Directional branch indicating a flow direction, a first branch directional branch indicating that at least two branches are to be performed, and a subsequent processing requirement in a time series should be processed in parallel, and a branched branch having at least two branches. A second branch-oriented branch indicating that the branching branch is a processing operation in which the subsequent processing requirement is processed in synchronization with the end of a plurality of preceding processing requirements, and the translation means comprises: Based on information obtained from the hardware information holding means, a plurality of processing element sequences following the first branch directed branch are each processed by the plurality of control entities in parallel. A parallel processing program allocating means for classifying and allocating the plurality of control patterns by alternately selecting a graphic pattern indicating a processing requirement and the directional branch or the directional branch by the pattern selecting means. A program creation device wherein a parallel processing program executed by a subject is created on the same screen. 2. The program according to claim 1, wherein said screen display means is capable of displaying a plurality of program creation screens.
The lower-level program of the processing element displayed by each graphic pattern of the program created on one screen can be created on another screen, and the processing element and the lower-level program formed on another screen can be created. A program management device having a hierarchy management means for defining a hierarchy relationship with the program. 3. The apparatus according to claim 1, further comprising a debugging unit for debugging the created program, wherein the debugging unit is configured to execute the created program at the time of debugging. A program creating apparatus, comprising: reproduction display means for reproducing and displaying the same graphic pattern as above; and display means for displaying a program execution position during debugging on the reproduced and displayed program. 4. The apparatus according to claim 3, wherein said display means comprises:
A program creating apparatus, wherein a plurality of processing parts that are processed in parallel can be displayed simultaneously in a part of processing elements that are processed in parallel.