JPH02197970A - Object code generating device for data drive type computer - Google Patents

Abstract

PURPOSE:To perform a due process within such a paractical time range where the processing frequency is proportional to the number of nodes by producing an object code which shows a destination node number according to the address that is finally assigned by an extension address generating part and sending the node number to an object code output part. CONSTITUTION:A reading part 4 reads a conventional object code, and an extention address generating part 5 detects a node requiring an extension address. Then the part 5 produces the extension address and reassings a node number. An object code output part 6 produces an object code based on a decided node number and outputs it. In this case, a memory area 7 is used as a working area. Thus it is possible to finish a due process in the number of steps approximately proportional to the number of nodes of a program.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to an object code generation device for a so-called data-driven computer that employs a method of driving processing based on inter-data dependencies.

[Conventional technology]

To explain the prior art, we will first explain a conventional data-driven computer.Next, we will explain a conventional object code generation device for a data-driven computer that generates an object code that runs on this conventional data-driven computer. After that, a patent application filed in 1983 entitled "Data Driven Computer" was filed by the applicant of the present application.
The invention of -*Umbrella-Semi-Umbrella Ratio No. and Patent Application No. 1988- *Axle*** will be explained.

A typical example of a conventional data-driven computer is the Proceedings of the Presentation of Research and Development Results for High-Speed Computing Systems for Science and Technology (1932).
June 25, 2009), pages 19 to 22, and IEE [
! It is disclosed on pages 486 to 490 of the C0NPCON '845 PRING proceedings (English).

These publicly known materials all explain the configuration and operation of a data-driven computer called Sigeba-1. A conventional data-driven computer as a first conventional example based on these publicly known materials will be described below.

FIG. 8 is a block diagram showing the configuration of the first conventional example of the data-driven computer mentioned above.

This data-driven computer includes a network interface 14 that is an interface with the outside of the computer, a matching memory IO that detects two pieces of data whose destination node number is 1 out of each data to be processed, and a calculation instruction based on the node number. an instruction fetching section 15 for extracting the code, an instruction execution section 12 for executing arithmetic processing according to the instruction code, a destination specifying section 16 for specifying the next destination node number of the data after the arithmetic processing, and a data path connecting them. It consists of

In addition, Figure 9 is a program (data flow graph) for explaining the specific operation of a conventional data-driven computer.
This is an example.

This data flow graph connects data A and B to node I
O, add this result data G and another data C
are multiplied at node 12 to obtain the resulting data I, and on the other hand, data D and E are added at node 11, and the resulting data H and another data F are added to node #4.
Multiply at node #7096 to obtain the resultant data J... Then, multiply data W and Find the result data Z.
It is structured as follows.

Packet (data with tag information) A (201) input from the outside via the network interface 14
) is composed of destination node number <0> and data [A]. This packet 201 is sent to the matching memory IO, but at the same time, the destination node number <O> (203) in the packet 201 is sent to the instruction fetching unit 1.
It will also be sent to 5. Assuming that packet B with data [B], which is the partner of the binary operation on data [A], has already been input and is waiting in matching memo January O, the destination nodes of these two packets A and B are Since both match in IIO, the matching memory 10 outputs a packet 206 in which data [A] and data [B] are paired.

On the other hand, the instruction fetching unit 15 reads and outputs the instruction code "+" (205), which is the content of the address corresponding to node number <0>.

The memory configuration of the instruction fetching unit 15 is shown in FIG. 10 (al).

Next, the destination node number <0
> is sent as is to the destination specifying unit 16 as the node number <O> (20). Further, the instruction code [+ j (205) read out by the instruction fetching unit 15 is included in the packet 2 together with the packet 206 of the data pair [A] and [B].
07 to the instruction execution unit 12. At this time, in the destination specifying unit 16, the result data of the addition which is the operation corresponding to the node number <0> in the data flow graph of FIG. 9 represents the next node I2 to go to <2> (
208) is read out.

The memory configuration of the destination specifying section 16 is shown in FIG. 9(b).

At the same time, in the instruction execution unit 12, [A]+[B]
The calculation is performed, and the calculation result data [0] (209)
The output 208 of the 0 destination designation unit 16 and the output 209 of the instruction execution unit 12, that is, the destination node number <0> and data [G], pass through the network interface 14 as a packet 210, and are sent to the instruction extraction unit again. 15 and matching memo sent on January 0.

Through the chain of processing as described above, operations corresponding to all nodes of the data flow graph shown in FIG. 9 are performed, and the execution of the program is completed. At this time, the processes at the nodes where there is a data dependency relationship, for example, node 0 and node I2, can only be executed sequentially in this order.
Nodes with no data dependencies, e.g. node I
Processing in O and node cloud 1 can be executed in parallel as far as processing resources allow.

Note that a data dependency relationship here refers to a connection relationship between two nodes in which input data necessary for processing the other node is supplied only when the processing of one node is completed. It refers to something.

The memory configurations of the instruction fetching unit 15 and destination specifying unit 16 are shown in FIG. Here, we assume that the bit width of the instruction code is 4 bits and the bit width of the destination node number is 16 bits.Also, since there is no specific description of the data copy operation in the above-mentioned publicly known materials, data copying is not widely available. It was assumed that a commonly known method would be used.

The most significant bit -co in the memory in the destination designation unit 16
py" is a copy bit, and when the calculation result at a certain node in the data flow graph shown in Figure 9 is sent to multiple nodes, data is copied and the destination node number is assigned to each data. For example, since the calculation result at node I2 is sent to both node #7097 and node I5, the copy bit at the second address of the memory is set to "1". is stored, in this case the destination node number #
7097 is read and the calculation result [! ] is added and output, the next address (third address) is continuously output, and the destination node number I5 is the same calculation result [! It is added to this and output.

A conventional subject code generation device for a data-driven computer is as follows.

An example of its configuration is described as ``Language processing system for graphical data-driven language υti'' on pages 211 to 212 of the proceedings of the 32nd National Conference of the Information Processing Society of Japan (first half of 1986). In addition, regarding the language specifications for data-driven computers, which are the regulations for input data to the object code generation device for data-driven computers, please refer to the Journal of the Institute of Electronics and Communication Engineers D
Vol, J71-D No, 3pp, 501-5
Published in March 1988 in "Design and Implementation of the Data Flow Language DFC".

A conventional example of the object code generation device according to the first embodiment will be described based on these publicly known materials.

FIG. 11 (18) is a block diagram showing the general configuration of a conventional object code generation device.

In FIG. 11(a), 55 is a source file.

This source file 55 is, for example, a graphical data-driven language UL1. A source program is described using a single graphic character or binary data according to the grammar of a description language such as the data flow language DFC.

Reference numeral 56 denotes an object code generation device, which reads a source program from the source file 55 and finally generates an object code 57. This object code generation device 56 is composed of an executable format generation section 58 and a physical format generation section 63.

Figure 11) shows an example of a data flow graph. In this 11th opening), 60 indicates the entire so-called data flow graph described by arrows representing the movement of data, and "O" indicates each node. and,
For example, node 62 is referred to as the destination node of node 61. Note that "O" indicating each node has an execution command, for example, "NOP (N.

0operation)"+"+(addition)", etc. are written.

The executable format generating section 58 generates an executable format 59 which is information equivalent to the data flow graph as shown in FIG. 59 to object code 5
Generate 7.

In the data flow graph 60, when the data is input to the node 61, the execution command at the node 61 is executed, the result is transmitted to the destination node 62 through the path of the arrow, and all of the input data to this node 62 is transmitted. When these are completed, the execution command of this node 62 is executed.

The executable format generation section 58 further includes a source file processing section 64 that reads the source program from the source file 55 and performs a grammar check, etc., and a data flow 1 information generation section 65 that generates the executable format 59.

Further, the physical format generation section 63 includes a physical format construction section 66 and a physical format output section 67.

FIG. 2 is an example of a source program written in the source file 55, and the data flow graph in FIG. 9 described above is a data flow graph equivalent to the executable format generated from the source program in FIG. .

FIG. 3 shows an object code equivalent to the data flow graph of FIG. 9 generated by the executable format 59.

Next, the operation of the conventional object code generation device configured as described above will be explained below.

In the object code generation device 56, the executable format generation section 58 and source file processing section 64 first generate the source file 5.
Load the source program from 5, source file 55
If the source file 55 is written in a graphical language such as the above-mentioned ULI, the reading process has an interactive editor function. Check whether it is true or not. Then, the data flow information generation unit 65 determines the command to be executed and detects the flow of data, and generates data flow information in the execution format 59. For example, in the source program shown in FIG. 2, for each equation, detection of input data and checking of output data are performed.

For example, in the case of the formula %formula%), the input data are data[A], data[B
] and data [C], and data [A] and data [B
], an execution command "+" is executed between the result and data [C], and an execution command "*" is executed between the result and data [C], and it is recognized that data [1F is output, and the data flow corresponding to the expression A graph is generated.

Similarly, such an analysis is performed for each expression.

Next, it is detected whether the output data written earlier and the input data written later on the source program have a connection as a data flow.

In this example, this output data [1] is connected to the input data [11 of ←r+J z4-t+w*x ] to determine the flow of data between the expressions. As a result, an executable format 59 equivalent to the data flow graph of FIG. 9 is generated.

Next, the physical format construction section 66 of the physical format generation section 63 determines the node number of each node, and the object code 57 is outputted from the physical format output section 67 in the order of the node number.

As shown in Figure 3, the object code sets the "copy" bit to "11" when data is copied in the order of node numbers, and "C0P" when copying is not performed.
Y" bit is set to "O", the execution instruction is converted into an instruction code (OPECODE) recognized on the computer, and the number of the destination node is determined according to the information of the destination node. Meanwhile, as a second prior art, the applicant of the present application The inventions of the previously filed patent application entitled ``Data Driven Calculator'' entitled ``Sin*Kasa*Ning Kasa'' in 1983 and 1987 - Hon*Kasa*Kasa are as follows.

Note that data-driven computers prior to the filing of the above invention had the following two problems.

The first problem is that the scale of the program memory is larger than that of a typical Neumann type computer.

In the case of the currently widely used Neumann type computer, processing is performed step-by-step sequentially according to the order written in the program, so the execution address is centrally stored in a single register called the program counter. Managed. Therefore, except for branch instructions, there is no need to specify the address of the next instruction to be executed (jump address), and programs with the same content can be stored in a smaller program memory than data-driven computers. can.

On the other hand, in the case of a data-driven computer, each instruction is processed in parallel, so it is impossible to centrally manage execution addresses. For this reason, in data-driven computers, it is in principle necessary to specify the address of the next instruction to be executed (destination node number) for every instruction, which inevitably increases the size of the program memory. It is the cause of this. In the first conventional example described above, the destination node number occupies 16 bits out of the 21-bit bit width (instruction code: 4 bits, 10 rows: destination node number: 17 bits).

The second problem is that the program memory is separated into an instruction fetch section and a destination specification section.

For this reason, as shown in Figure 10 (al, (bl), if we focus on a certain node, we find that even though the input addresses to these two memories are exactly the same, they are connected to separate pipes. Because it is arranged in the line stage, accesses are not performed simultaneously, requiring unnecessary processing time, and it is necessary to provide two independent sets of input address latches and address decoders, which unnecessarily increases the hardware scale. become.

The first of the two inventions of a data-driven computer previously filed by the applicant of the present application, namely, the patent application 1986-Umbrella*$
*The invention of Kasa-Kago was made with the aim of solving the first problem mentioned above, and by compressing the scale of program memory, it was possible to reduce the hardware scale of data-driven computers, and at the same time reduce the memory size. The aim is to improve performance by reducing memory access time due to size reduction.

Specifically, as a means to solve the first problem mentioned above, a configuration is adopted in which the destination node number in the program memory is stored, for example, at a relative address from the storage address of the current instruction. .

As a result of adopting this configuration, the relative address has a smaller amount of data than the absolute address, so the storage address of the next instruction to be executed is set to the relative address of the next instruction to the address of the current instruction. Since it is obtained by addition, it is possible to reduce the size of the program memory.

In addition, the second invention of the two inventions of a data-driven computer previously filed by the applicant, namely, the patent application filed in 1983-
The invention under the umbrella name ＊＊＊＊+s was made with the aim of solving the second problem mentioned above, and aims to shorten data processing time and reduce unnecessary hardware. .

Specifically, by integrating the instruction fetch function and destination specification function of conventional data-driven computers into one program memory, and arranging this program memory in parallel with the instruction execution section, redundant input address launch or decoder By eliminating this, reducing the hardware scale, and arranging the program memory and instruction execution section in parallel, the basic cycle for executing one instruction can be reduced by matching memory and ■ (program memory + instruction execution section). It consists of two pipeline stages.

As a result of this configuration, the program memory that stores both the instruction code and the destination node number is arranged in parallel with the instruction execution unit, so it is possible to execute the current instruction and read the next instruction and destination node number. The processing is performed in parallel, and execution of one instruction is completed in a total of two cycles: this cycle and the data waiting cycle in the coincidence detection section.

Such a third conventional example will be specifically explained below with reference to the drawings.

FIG. 12 is a block diagram showing an example of the configuration of the data-driven computer as the second conventional example mentioned above.

This second conventional data-driven computer has a network interface 14 which is an interface with the outside,
Matching memory as a match detection unit that detects two pieces of data with matching destination node numbers from each data to be processed A function to extract the code of an operation instruction based on the IO1 node number and the next destination node of the data after operation processing An instruction execution unit 12 as an arithmetic processing unit that executes arithmetic processing according to an instruction code in a program memory 1 having two functions for specifying a number, an adder 13 as an arithmetic means for updating a destination node number, etc. and a data path that connects them.

The program (data flow graph) shown in FIG.
The operation will be explained when executing.

The data flow graph shown in FIG. 13 is the same program as the program shown in FIG. 9 described above, but for the sake of explanation, the node numbers are assigned differently.

This data flow graph connects data A and B to node l.
O, add this result data G and another data C
are multiplied at node 2 to obtain the resultant data I, and on the other hand, data D and E are added at node 11, and this resultant data G and another data C are multiplied at node 15.
Multiply at node #7096 to obtain the resultant data J... Then, multiply data W and Find the result data Z.
It is structured as follows.

A packet 101 input from the outside via the network interface 14 includes a destination node number 〉O〉, data [A], and an instruction code ``+''.

In this second conventional data-driven computer, 2
Pipelining of cycles is performed.

The first stage is the waiting of data in the matching memory 10. bucket input from outside) 101 is
It is sent to the matching memory 10, but at this time, the binary operation "
+", if the packet containing data [B] has not yet arrived, the input packet 101 is temporarily stored in the matching memory and waits for the arrival of the packet containing data [B]. When a packet containing one data [B] arrives and is stored in the matching memory, it is detected that the destination node number <Q> of these two packets is - lost, and the input packet A packet 102 in which data [B] is added to 101 is sent out from the matching memory 10.

Among the information contained in the packet 102, the destination node number <O> (103) is sent to the program memo January 1 and the adder 13, which will be described later, and the remaining data [A].

[B] and the instruction code “+” are sent to the instruction execution unit 12 as a packet 104.

In the instruction execution unit 12, data [A] and [B] are added according to the instruction code "+", and the addition result data [G
] (107) is output.

On the other hand, the processing in the program memory 11 that is executed in parallel with the processing in the instruction execution unit 12 will be described below.

FIG. 4 is a schematic diagram showing the structure of the object code of the third conventional data-driven computer, which corresponds to the memory structure of the program memo January 1.

In the memory shown in Fig. 4, the most significant bit EX of each word
T" is an extended address flag to be described later.

The lower bit “copy” is “copy” in the conventional example.
This “copy” bit has the same meaning as the “copy” bit.
' If the bit is "l", it indicates that there are a plurality of destination nodes for the operation result, and that the instruction code and destination node number information regarding each of these destination nodes are stored at the next address or later.

The lower 4 bits following this @copy” bit contain the instruction code (OPECODE) to be executed in the next cycle.
is stored, and in the lower 6 bits, the destination node number is a relative address (R
NODE).

The specific operation of the data-driven needle 3E machine as a third conventional example configured as described above will be explained.

When packet 101 is detected as a match in matching memory 10 and packet 102 is output, packet 10
2's node number <0> (103) is entered in the program memo January 1. As a result, address 0 of the memory shown in FIG. 4 is accessed, the instruction code "+" and the relative destination node number 2> are read out, and the instruction code register (OPE-REG) 131 and the destination node are read out. Each number is written to the number register (DBST-REG) 132.

The instruction code is output as is from the instruction code register 131. On the other hand, the relative destination node number <2> is sent from the destination node number register 132 to the adder 13, and in the adder 13, the input node number <
0 > (103) is added to obtain the absolute value of the destination node number < 2 > (106).

The instruction code “+J1 destination node number <2>” obtained in this way and the data output from the instruction execution unit 12 [
The packet 108 composed of [G] is again supplied to the matching memo i month 0 via the network interface 14, and the entire program is executed by repeating this process.

However, in the present invention, since the bit width of the program memory 11 that stores the relative destination node number is limited to 6 bits, the actual value of the relative destination node number is 255.
(-2'-1), finger warmth occurs.

For example, this corresponds to the relative destination node number corresponding to the arrow from node 12 to node #7079 in the data flow graph of FIG. In such a case,
The present invention is configured such that by setting the topmost BIFVI EXT of the program memory corresponding to each node number to B, the next address can be used as an extended address bit area for storing overflowing digits. It is.

Input data [G] and [C] necessary for processing at node I2 in FIG. 13 are complete, and destination node number 2>1 instruction code "+" is output from matching memory IO.

A case will be described in which a packet composed of data [G] and [C] is output.

As described above, the instruction code and data are sent to the instruction execution unit 12, multiplication is executed, and result data [1] is output. In parallel with this, the destination node number 2> is sent to the program memory 11, and the destination node number is read out.

The detailed logical operation of the program memory 11 when the input node number is <N> is shown in the flowchart of FIG.

In this flowchart, "IIEADM" is an operation for reading address M in memory, and "bin" (6: 0), etc. is a bit string consisting of bits 6 to 0.
I! XT' and "C0PY" represent the values of the extended address flag bit and copy flag bit in the program memory, respectively.

When a packet having the destination node number 2> is manually entered in the program memo January 1, the contents of the second address of the program memo I711 are read out (step S4).

Of the read contents, the instruction code "+" is written to the instruction code register 131, and the relative destination node number <4> is written to the lower 6 bits of the destination node number register 132, that is, bit (6+O). (Step 35
．． S6).

Since the "EXT" bit of the read word is "θ" (step S7), the result of addition by the adder 13 between the instruction code and the value of the destination node number register (4) and the input node number (2) is 6> is output as the destination node number (step S8).

At this time, the “copy” bit of the read word is 11.
” Therefore, after incrementing the read address <2> (step 510) and clearing the loop count <l,> and the contents of the destination node number register 132 (
Step S2. S3), the third address which is the address after incrementing is read out (step S4).

As with the first read, the instruction code “+” in the read word and the relative destination node number <55> (-“11G
111') are written to the lower 6 bits of the instruction code register 131 and the destination node number register 132, respectively (steps 55 and 56), and the I! of the read word is written. X?
” Since the bit is 11111 (step 37), the read address is incremented (step S1,
The contents of the fourth address are read and the lower 10 bits of the read word are written into bits 15 to 6 of the destination node number register 132 (step 513).

Since the value of the EXT bit of the last read word is '1' (step 515), the current instruction code '+' and the contents of the destination node number register 132 < 7095
>(="0001101110110111") and the input node number 12, the addition result <7097> is output (step S8).

Also, the value of the copy bit of the last read word is “
0'' (step S9), the series of processing for the input packet having the node number <2> ends.

As mentioned above, when the destination node number is given as a relative destination node number, even if the relative destination node number overflows beyond the predetermined bit width, the next address in the program memory is set to the extended address of the relative destination node number. Processing is completed by using the area as an area, and this second conventional example can be implemented for programs of any size and with any node number allocation.

-a, since connections between nodes are local, it is considered that the relative destination node number rarely takes a large value, regardless of the program scale.

In fact, for a test program consisting of 3987 nodes, we evaluated the statistical distribution of relative destination node numbers when node numbers were assigned in such a way that nodes closest to the input were given smaller node numbers. . The results are shown in the graph of Figure 15. The horizontal axis of the graph shows the relative destination node number, the vertical axis shows the cumulative frequency percentage, and the number for each section shows the node failure included in that section. .

From the graph in Figure 15, approximately 90% (88χ) of the total
It is easily understood that the relative destination node number is within address 63. In other words, even if the bit width of the relative destination node number is 6 bits, there is a probability of approximately 10% that the above-mentioned extended bit width will be required.

The bit width of the program memory in the first conventional example described above is 2.
1 bit (instruction fetch section 4 bits + destination specification section 17
In contrast, in the case of this embodiment, it is 12 bits, and the number of extra words required to store the extended address when implementing the present invention is approximately 10% from the above statistics. However, the size of the memory is compressed by (12X 1.1) / 21'' = 0.63 times. In this example, the program memory space is 16 bits, but this compression effect becomes larger as the program memory space becomes larger. It becomes even more noticeable.

For example, if the program memory space is 32 bits, even if you expand the relative destination node number space to 8 bits and estimate that the proportion of extended address bits required is 20%, the memory size will be (relative destination node number + flag + instruction code) Xl, 2
(destination node number ten flag + instruction code), and when the actual number of bits is substituted, it becomes (8+2+4)Xl, 2 (32+1+4) times, and can be compressed to less than half.

In addition, in the above-mentioned second conventional example, for the sake of simplicity of explanation,
Although the relative destination node number is limited to a positive number, by using a signed number (two's complement representation), it is possible to send data to a node with a smaller node number than the output side node number. Become. As a result, this second conventional example can be implemented even for programs including repetitive structures.

Furthermore, in this second conventional example, the overflow bit of the relative destination node number is assigned to the extension bit, but another method is to divide the program into pages, express the address within the page with 6 bits, and It is also possible to adopt a method of assigning a relative page number to an extension bit when there are destination nodes beyond .

As explained above, in the data-driven computer as the second conventional example, by specifying the destination node number in the program memory as a relative address from the storage address of the current instruction, the destination node It becomes possible to significantly compress the bit width for storing numbers and reduce the size of program memory.

Furthermore, by integrating the instruction fetch section and destination specification section of the data-driven computer shown in the first conventional example above into one program memory, and arranging this program memory in parallel with the instruction execution section, redundancy can be reduced. The hardware scale can be reduced by omitting manual address launching, decoders, etc.

In addition, by arranging the program memory and instruction execution section in parallel, the basic cycle for executing one instruction consists of two pipeline stages: ■ matching memory and ■ "program memory + instruction execution section." Therefore, a short basic cycle comparable to that of conventional data-driven computers can be obtained, and the response time to a single command can also be kept short.

In general, data-driven computers are built on a computational model suitable for parallel distributed processing, and have the distinctive feature of autonomously executing multiple tasks in parallel without any special control. It is considered. However, in the case of the current system where the address of the program memory that stores each multitask is fixed,
Other tasks Tb that may share the program memory area with the currently executing task Ta cannot be executed at the same time even if there is free space in the program memory. The reality is that we are not able to take full advantage of our inherent ability to stay on task.

On the other hand, in the data-driven computer of the second conventional example mentioned above, the node numbers of all nodes are specified by relative destination node numbers from other nodes, so if there is free space in the program memory, A new task can be externally loaded into any free space and executed in parallel with other tasks, regardless of address.

The above describes multitasking execution on one processor, but as shown in Figure 16, it is possible to make individual tasks spanning each processor occupy the same program memory area within each processor. For example, it is possible to make multiprocessors that perform packet communication with each other via a network perform multitask execution and task generation, and it is possible to perform multitask execution and task generation using multiple data-driven computers. Problem] The object code for the data-driven computer of the second conventional example as described above, which was previously filed by the applicant of the present application, is capable of obtaining information about the destination node by performing a predetermined operation on the number of the current node. It is configured so that the stored number can be obtained. Only a small bit width is prepared as an area to store the information of the destination node. Therefore, if the information of the destination node does not fit into the bit width, set the extension bit and use the extension address. need to occur.

A relatively easy method for generating this extended address is as follows.

+1) Check whether extended addresses are necessary in order of node number.

B) If there is a node that requires an extended address, all nodes with higher node numbers than that node will have their numbers incremented by one. For this reason, as the number of nodes increases, it is checked whether the node number of the destination node of each node has increased for all nodes, and if the number of the destination node has increased, processing is performed accordingly. conduct.

The process in (2) above needs to be performed every time an extended address occurs. For example, in the case of a program for io and ooo nodes, if an extended address occurs in 10% of the nodes, each check in (2) must be performed. is 0, I
10000X I 0O00 = 107 times. However, this does not take into account the case where a new extended address is generated due to the change of the node number in the process (2). If this is taken into account, the process becomes even more complex and huge, making it unrealistic. There is a problem in that there is a possibility that a negative aspect may occur.

The present invention has been made to solve the above-mentioned problems, and can be executed within a realistic time in which the number of processing times is proportional to the number of nodes, and by simple repetition of processing, The purpose is to provide an object code generation device for data-driven computers.

[Means to solve the problem]

A first aspect of the object code generation device for a data-driven computer according to the present invention includes an extended address generation section that detects a node that requires an extended address and reassigns a node number as the extended address is generated. , and causes the object code output unit to generate and output an object code expressing the destination node number according to the address finally assigned by the extended address generation unit.

Further, the second invention of the object code generation device for a data-driven computer according to the present invention detects nodes that do not require extended addresses from a state where it is assumed that extended addresses are required for all nodes. , is equipped with an extended address vanishing unit that reassigns a node number as the assumed extended address vanishes, and converts the object code representing the destination node number into an object according to the address finally assigned by this extended address vanishing unit. Generate and output to the code output section.

[Effect]

The extended address generation unit of the object code generation device for a data-driven computer of the present invention first assumes that the node number has a node number in which no extended address is generated, Extended addresses are generated by checking for all nodes whether the location information of the destination node is included in the area, and node numbers are reassigned as the extended addresses are generated.

■If even one extended address is generated in the process of ■ above, the location information of the destination node changes with the generation of the extended address, so the address reassigned after the extended address is The process will be executed again. If no extended address is generated in the process (2), the node number assumed last time is a node number that includes all necessary extended addresses, so the process moves to the process (2) below.

(2) The location information of the destination node is generated for each node according to the node number determined by the processes (2) and (2) above, and finally an object code is generated.

The second invention of the object code generation device for a data-driven computer according to the present invention is to first assume an address when all nodes have an extended address, and then: By checking for all nodes whether the location information of the destination node can be stored in the memory area of the number, unnecessary extended addresses are deleted, and the node numbers are changed as the extended addresses are deleted.

(2) If no extended address is deleted in the process (2) above, proceed to the process (2) below. If even one extended address disappears, the location information of the destination node changes as the extended address disappears, so the process (2) is executed again for the address that was replaced after the extended address disappeared.

②Destination node location information is generated for each node according to the node number determined by the processes ① and ① above, and finally an object code is generated.

[Embodiments of the invention]

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described in detail below based on drawings showing embodiments thereof.

For clarity of explanation, the node number after the extended address is generated, that is, the node number obtained by reallocation, will be referred to as a node address.

Hereinafter, first, an embodiment of the first invention will be described. In this embodiment, the location information of the destination node is expressed as a relative address and stored in the program memory as unsigned 6 bits.

1. If the address is too large to be stored in an unsigned 6-bit address. Generate an extended address.

FIG. 1 is a block diagram showing the configuration of an object code generation device for a data-driven computer according to the first invention.

1 in the figure is an object code generated by a conventional object code generation device for a data-driven computer;
Reference numeral 2 denotes an object code generation device that reads a conventional object code 1, loads it onto a data-driven computer previously filed by the applicant of the present invention, and generates an object code 3 to be executed. This object code generation device 2 includes a reading section 4. The extended address generation section 5 is composed of an object code output section 6 and a memory area 7.

A reading unit 4 reads conventional object code. An extended address generating unit 5 detects a node that requires an extended address, generates an extended address, and reallocates a node number. An object code output unit 6 generates object code according to the determined node number,
Output. The memory area 7 is used as a working area when performing these processes.

Next, the operation of the object code generation device as the first aspect of the present invention configured as described above will be described below.

In addition, FIG. 2 is a schematic diagram of a source program, FIG. 3 is a schematic diagram showing the structure of a conventional object code for the source program shown in FIG. 2, and FIG. 4 is a schematic diagram showing the structure of object code 3. It is a diagram. Further, FIG. 5 is a flowchart showing the processing procedure of the extended address generation section 5.

The reading unit 4 reads the conventional object code l,
The read data is placed in arrays “C0DE []” and “NEXTMODE” for the number of nodes prepared in the memory area 7.
[]”, the “copy” bit and 0PIIC
ODE” to the element corresponding to the node number of the array “C0DE []” and the destination node to the array “NEXT N
0DE[]'' are stored in the elements corresponding to the node numbers.

Next, the extended address generator 5 generates an extended address. The details of this processing procedure will be explained with reference to the flowchart of FIG. However, what is referred to as the node number here is
The number is assigned to each node in order starting from number 1, and the node address is a record that indicates which code number from the beginning the information for each node is stored when it is generated as an object code. The 12-bit unit data shown in one line in FIG. 4 is called a code.

Each variable used in FIG. 5 will be explained.

``count'' is a variable for counting the number of processed nodes, and ``MAX No'' is the total number of nodes.

``MODE[]'' is an array consisting of ``MAX No'' elements, and stores the node address of the node having the same node number as its index.

EXT[]” is also an array consisting of “MAX No” elements, and if an extended address is generated for the node with the node number of that index, it will be “l”, otherwise it will be “0”. Each is stored.

"ext cnt" is a variable for counting the number of newly generated extended addresses, and "RET" is a variable that receives the return value of the function.

In step 321, first, "count" is set to "θ".
After initialization in step 323, the process in step 322 is repeated until the array "N0DH[]" becomes equal to the total number of nodes "MAX No".
”, and “0” is stored as an initial setting in each element of “EX↑[]”.

Next, in step 324, as initial settings for extended address generation, the counter "count" for counting the node number is set to "0", and the counter "ext cnt" for counting the number of extended addresses generated is set to "0".
are set respectively.

In the first loop L1, since ext cnt" is "0", no processing is performed in step 325.Next, in step 326, it is determined whether the countmth node requires an extended address or not. A check will be made. This check is a function @I! xt orNo
This is done by t'.

First, in step 5265, a check is made to see if an extended address has already been generated.

If an extended address has already been generated, there is no need to secure any more extended address, and after "RET" is set to "0" in step 5265, the process returns.

If no extended address has occurred, step 526
At step 2, it is checked whether the relative address to the destination node can be expressed with positive 6 bits, that is, whether it is between "02" and "63'". In this case, the relative address is the array “M
It is checked using the node address difference between the current node and the destination node stored in "ODE []". Therefore, if the destination node number is larger than the current node number, the correction due to the extended address generation has not yet been performed. Also, if an extended address occurs between the current node and the destination node, the final value has not been obtained in the calculation at this point. If it is within 6 bits, proceed to step 5.
After "RET" is set to "0" by H.265, the process returns. If it does not fit within 6 bits, step 5263
In step 5264, after the extended BISOVI EXT [count] is set to B, in step 5264
After T” is set to “l”, return. In this way, “R[! ? A case in which -1'' is returned is a case in which an extended address is generated.

Therefore, in step 327, ext cnt”
The number of generated extended addresses is counted by adding the return value "RUT" to . Then the node number″
count'' is incremented, and the next node is checked. At this time, in step S25, the address is corrected for the extended address generated in the node before the current node.

When the check is completed for all nodes, step 328
In this case, the process proceeds in the direction of "NO", and the process of step S29 is performed.

In step S29, it is checked whether an extended address has occurred in the immediately preceding loop L1. If even one extended address occurs, then the array “N0DE
The address stored in [] ′” should have been changed. In the process of step 5262, “MODE []
Since the address stored in " is checked to see if it can be stored in a fixed 6 bits, if there is a node that jumps across the node where the extended address occurred, the fixed address will be Therefore, loop L2 is repeated until no new extended address is generated.

Thereafter, in the object code output unit 6, for the node with the node number °B according to the determined node address, the extended bisobvi Ext[k]'', copy via h
, 0PECODE'code [k]''9 rows relative to destination node7)'!zsu'''N0DII! [NEXT
N0DH]-1JODE[k]'' are output in order of node number.

Next, an embodiment of the second invention will be described with reference to the drawings.

FIG. 6 is a block diagram showing the configuration of an object code generation device for a data-driven computer according to the second invention.

Note that the same reference numerals are given to the same or corresponding parts as in FIG. 1 referred to in the description of the first invention described above.

In the object code generation device of the second invention, an extended address erasure unit 24 is provided in place of the extended address generation unit 5 provided in the object code generation device of the first invention. This extended address erasure section 24
has a function that assumes that extended addresses exist for all nodes, selects nodes that do not require extended addresses, and eliminates the extended addresses of those nodes.

The conventional object code structure is the same as that shown in FIG. 3, and the memory structure is shown in FIG. 4. FIG. 7 is a flowchart showing the processing procedure of the extended address erasure unit 24.

Next, the operation of the object code generation device for a data-driven computer according to the second invention will be explained.

The second invention differs from the first invention only in that it includes an extended address erasing section 24 instead of the extended address generating section 5, so the extended address erasing section will be explained.

Among the variables used in Fig. 7, only "unexL cnt" is different from Fig. 4.
tcnt” is used to count the number of extended address disappearances.

In step S31, first, “count” is “0”.
After being initialized to 1, “count
” is equal to the total number of nodes “MAX No”, the process of step 332 is repeated until the array “MODE
The address when an extended address exists in ``[]'' is stored, and ``1'' is stored in each element of EXT[]'' as an initial setting.

Next, in step 334, as an initial setting for extended address deletion, '01' is set to the counter "count L" that counts the node number, and "0" is set to the counter "une+rt cnt" that counts the number of extended address deletions. It is set.

In the first J rape Lll, unext ant''
is "O", so no processing is performed in step S35.

Next, in step S36, a check is made to see if the 'count' node requires an extended address.This check is performed using the function 'No Ext or No
t”.

First, in step S36, a check is made to see if the extended address has already disappeared.

If the extended address has already disappeared, there is no need to erase the address any further, and after "l?ET" is set to '01' in step 3365, the process returns.

If the extended address has not disappeared, SteSob 536
At step 2, it is checked whether the relative address to the destination node can be expressed with positive 6 bits, that is, whether it is greater than or equal to "0" and less than or equal to "63". In this case, the relative address is the array “N
It is checked using the node address difference between the current node and the destination node stored in "0DH[]". If the result of the check is that it is not stored within 6 bits, "RUT" is set to "0" in step 8365. ” After being
Return. If it is stored within 6 bits, in step 3363, the extended bit EXT [count
t]"After the force is set to Om, "RUT" is set to "1' in step 3364, and then the process returns.

In this way °I? ET-1" is returned, this is the case when the extended address disappears.

Therefore, in step S37, unext cn
The number of deleted extended addresses is counted by adding the return value "RET" to "t". After that, the node number @count' is incremented and the next node is checked. At this time, in step 335, Addresses are corrected due to the influence of the extended address that disappeared at a node with a smaller number than the current node.

When the check is completed for all nodes, step 338
The process proceeds in the direction of "NO" from step S39.
processing is performed. In step S39, it is checked whether an object code of the requested size can be generated at the address determined in the previous loop 35. If the result of the check is that the object size is larger than the requested object size, processing proceeds to step 540, where it is checked whether the extended address has disappeared. Previous loop Ll
If no new extended address disappears in l,
Since no more extended addresses will disappear, a message is issued in step 341 and the process is terminated.

If there is no requested size, steps S39 and 3
By omitting the process in step 41, it is possible to obtain exactly the same object code as the object code generation device of the first invention.

In the above embodiment, a case has been described in which an object code generated by a conventional object code generation device is read as a source file, but as shown in FIGS. 17 and 18, a conventional object code is read as a source file. Similar to the generation device, it is also possible to have a configuration in which a high-level graphical language for data-driven computers or an assembler is directly read.

In addition, as for addresses, information on one node is explained as one address, but as an address, one byte is one address.
Of course, a configuration in which the address is used is also possible, and the length of one address can be easily accommodated.

In addition, especially as an embodiment of the first invention, the array “EX?
The value to be held in ``is the number of addresses required, and the function ``[! xt or Not' can be handled by calculating the number of necessary extension addresses and changing the condition to see if it can be stored in the prepared extension address.

〔Effect of the invention〕

As detailed above, in the present invention, detection of a node requiring an extended address and reallocation of an address upon generation or disappearance of an extended address are realized by repeating simple processes. Further, the algorithm for generating or destroying an extended address has a double loop structure, and the outer loop is provided to cope with the generation of a new extended address due to insertion of an extended address. Therefore, it is considered that the outer loop completes its processing after approximately 4 to 5 iterations. Therefore, for example 1000
In a program with 0 nodes, the basic processing for each node is 10000X 5-5 X104,
Furthermore, even if 10,000 processes are added to the output process, the process can be completed with a number of steps approximately proportional to the number of nodes in the program.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing a configuration example of an embodiment of an object code generation device for a data-driven computer according to the first invention. FIG. 2 is a schematic diagram showing an example of a source program written in a data-driven computer programming language. FIG. 3 is a schematic diagram showing the structure of a conventional object code. FIG. 4 is a schematic diagram showing the structure of an object code generated by the object code generation device for a data-driven computer according to the present invention, and is equivalent to the memory structure of a program memory. FIG. 5 is a flowchart showing the processing procedure of the extended address generation section of the object code generation device for a data-driven computer according to the first invention. FIG. 6 is a block diagram showing a configuration example of an embodiment of an object data generation device for a data-driven computer according to the second invention. FIG. 7 is a flowchart showing the processing procedure of the extended address erasure unit of the object code generation device for a data-driven computer according to the second invention. FIG. 8 is a block diagram showing an example of the configuration of a conventional data-driven computer. FIG. 9 is a schematic diagram showing an example of a program (data flow graph) executed by a conventional data-driven computer. Figure 1O (al is a schematic diagram showing the memory configuration of the instruction fetching unit in a conventional data-driven computer; Figure 1O (bl)
9 is a schematic diagram showing the memory configuration of the destination designation section, and each shows the memory contents when the program shown in FIG. 9 is stored. FIG. 11 is a block diagram showing an example of the configuration of a conventional object data generation device for a data-driven computer. FIG. 12 is a block diagram showing an example of the configuration of a data-driven computer as a second conventional example already filed by the applicant of the present application. FIG. 13 is a schematic diagram showing an example of a program (data flow graph) executed by the data-driven computer, and is the same program as FIG. 9 except for the assignment of node numbers. FIG. 14 is a flowchart showing the detailed processing procedure in the program memory of the data-driven computer. 1511iJ is a graph showing the distribution of values of relative destination node numbers. FIG. 16 is a conceptual diagram showing a program memory map in a multitask execution state in a multiprocessor configuration. FIG. 17 is a schematic diagram showing another embodiment of the object code generation device for a data-driven computer according to the first invention. FIG. 18 is a schematic diagram showing another embodiment of the object code generation device for a data-driven computer according to the second invention. 2... Object code generation device 3... Object code 4... Reading section 5... Extended address generation section 6... Object code output section 7
. . . Memory area 24 . . Extended address erasure portion Note that the same reference numerals in each figure indicate the same or equivalent portions.

Claims (2)

[Claims] (1) A source file reading unit that reads a source file that describes a program to be processed, and at least an execution instruction among the information between the execution instruction group obtained from the contents of the source file and the interdependence relationship between each data. Each piece of node information, including information indicating the destination node which is the next node to be executed, is stored in an area of a predetermined fixed number of bits, and if the location information of the destination node cannot be stored in the area, the following a storage unit that stores information that cannot be stored by using a necessary area after the address as an extended address; and a storage unit that stores information that specifies at least a destination node among each node information stored in the storage unit. In an object code generation device for a data-driven computer, which is equipped with an object code output unit that outputs an object code by converting the address at the time of a search into location information that specifies the location information, each node is A first process assumes an address, sequentially checks whether an extended address has occurred for all nodes, and re-assumes the address of each other node if an extended address occurs; If the occurrence occurs, a second process of repeating the first process for the re-assumed address; and calculating destination node location information for each node according to the address assumed by the first and second processes. 1. An object code generation device for a data-driven computer, characterized in that the object code generation device for a data-driven computer is provided with an extended address generation section that executes a process of generating and providing the object code to the object code output section. (2) A source file reading unit that reads a source file that describes a program to be processed, and at least one of the information between a group of execution instructions obtained from the contents of the source file and the interdependence relationship between each data. Each piece of node information, including information indicating the destination node which is the next node to be executed, is stored in an area of a predetermined fixed number of bits, and if the location information of the destination node cannot be stored in the area, the following a storage unit that stores information that cannot be stored by using a necessary area after the address as an extended address; and a storage unit that stores information that specifies at least a destination node among each node information stored in the storage unit. In an object code generation device for a data-driven computer, which is equipped with an object code output unit that outputs an object code by converting the address at the time of a call into specific location information, the Assuming an address, we sequentially check whether an extended address occurs for all nodes, and if there is a node where an extended address does not occur, we delete that node's extended address, and
a first process of re-assuming the address of each other node; and a second process of repeating the first process for the re-assumed address if the extended address disappears in the first process; , an extended address extinguishing unit that generates destination node location information for each node according to the addresses assumed in the first and second processes, and provides the information to the object code output unit. An object code generation device for a data-driven computer.