JPH064498A - Multiprocessor - Google Patents

Abstract

PURPOSE:To execute parallel processing without recompiling object codes even when the hardware constitution of a parallel processing system is changed by providing a mechanism for exclusively controlling access to variables shared at the time of parallel execution and dynamically performing the processing block assignment of the parallel execution realized by an interpreter for executing an intermediate language outputted by a compiler. CONSTITUTION:This multiprocessor is provided with a compiling mechanism 102 having a means for analyzing program description for generating the access at least to shared memory source assignment and the means for analyzing the description for a program processing unit capable of parallel processing and performing processor assignment. Then, interpreting mechanisms 111 and 112 for executing the intermediate language outputted by the compiling mechanism 102 are provided to dynamically perform the processing block assignment of the parallel execution realized by the interpreting mechanisms 111 and 112.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to parallel execution processing by multiprocessors having different architectures.

[0002]

2. Description of the Related Art A system for performing uniform parallel processing by using a plurality of identical processors is already known.

On the other hand, for a system which performs parallel processing by using a plurality of processors having different architectures, a method of directly converting the system into a machine language by compiling is known. For example, a vector processor device of a large computer described in JP-A-62-34275 corresponds to this. However, this method cannot absorb the difference of each architecture and realize an execution environment equivalent to a homogeneous multiprocessor system.

Therefore, as a method for solving the problem, Japanese Patent Laid-Open No. 63-41934 proposes a method in which an intermediate code is interposed between the two instead of directly converting them into a machine language by compiling. In this method, processing is performed by a compiler that generates intermediate language object code and an intermediate language interpreter, thereby reducing the frequency of access between the CPU and external memory.

[0005]

However, since the above-mentioned conventional invention does not realize the exclusive control of the shared variables and the distribution of the execution units necessary for the parallel processing, the target program written in the parallel description language is actually used. There was a problem that was not executed in parallel.

The present invention has been conceived in order to solve such a problem. An object of the present invention is to provide a parallel description language specification in a system for performing parallel processing by using a plurality of processors having different architectures. It is to realize parallel execution by a target program written based on it, and to enable parallel execution without changing the target program even if the processor unit is changed and recompiling.

[0007]

In order to solve such a problem, the multiprocessor processing apparatus of the present invention analyzes a program description that causes an access to at least shared memory resource allocation and instructs exclusive control. And a interpreting mechanism for executing the intermediate language output from the compiling mechanism, and a compiling mechanism having means for performing a processor allocation by analyzing a description of a program processing unit capable of parallel processing And a mechanism for dynamically allocating processing blocks for parallel execution.

[0008]

EXAMPLES Examples will be described according to the following items.

0. Introduction 1. Source code compilation 1-1. Description of target system 1-2. Description method of parallel execution, synchronization, and exclusive control 1-3. Processing of lexical analysis and syntax analysis 1-3-1. Argument list analysis processing (S404) 1-3-2. Extraction of dependency between blocks (S405,
S416) 1-3-3. Shared variable processing (S412) 2. Code generation by intermediate language 2-1. Code generation means 108 for parallel execution 2-2. Code generation means for shared resource access procedure (S
418) 2-3. Operation of object file creating means 109 3. Intermediate language interpreter 3-1. Communication between intermediate language interpreters 3-2. Operating state of intermediate language interpreter 3-3. Runtime processing of parallel description part 3-4. Runtime process of shared resource access 3-5. 3. Procedure to specify the execution processor Supplementary explanation 4-1. Table used by compiler and interpreter 4-2. Development of the present example 4-2-1. Exclusive control and shared resource management 4-2-2. Implementation of an intermediate language interpreter 0. First, FIG. 1 is a block diagram of a multiprocessor system and its compiler suitable as an embodiment of the present invention. The source code 101 may be compiled on a computer different from the target system. At this time, the source code 101 is input and the intermediate language object 110 is input.
Is output. This intermediate language object 110 is executed in the actual target system.

FIG. 2 is a block diagram of a personal computer 200 suitable as an embodiment of the target system.

1. Source code compilation 1-1. Description of Target System The personal computer 200, which is the target system of the present embodiment, controls the display device by the control device 204.
Control user interface devices such as input devices,
Accept the operation of the user. The processor 113 is a general-purpose microcomputer, executes processing of the operating system 203, and manages processor resources and memory resources. Intermediate language interpreter 111
Is an independent process executed by calling the function of the operating system 203. A process is a unit at the time of allocation of processor resources and memory resources in an operating system. In this embodiment, the process includes a process header including process identifiers, execution management, and information for memory management, an area for saving the current register state of the processor at the time of suspension, and
It consists of an object code area and a stack area. When multiple processing is performed in the personal computer 200, a plurality of processes are activated and the processing is multiplexed according to the schedule for the processes. The object code of the target program written in the intermediate language is activated by the intermediate language interpreter 111 and executed on this interpreter.

The user can improve the function of the processor 113 of the personal computer 200 by adding hardware. The personal computer 200 has a system bus 202 for external expansion to meet this purpose. In the configuration of FIG. 2, the additional bus 201 is expanded using the system bus 202. Here, the processor 114 shares the processing part of the processor 113 and improves the processing speed of the personal computer 200 by performing parallel execution by a method described later. Such additional hardware is sometimes called an accelerator because of its role. The processor 114 executes the kernel program 205 to handle data transfer, interrupts, etc. via the system bus 202. The intermediate language interpreter 112 is a process managed by this kernel 205. The local memory 206 is used because the processor 114 executes these programs independently of the processor 113. Further, the connection between the processor 114 and the system bus 202 is made by the FIFOs 207 and 208 which are ordered memories configured so that the first-in first-out data can be taken out first.
The FIFOs 207 and 208 are assigned addresses in the memory space of the processor 113 and are accessed by the processor 113.

1-2. Description method of parallel execution, synchronization, and exclusive control In this embodiment, parallel execution by a plurality of processors is explicitly described in the source code at the stage of programming language description. Therefore, a language specification that allows parallel description is necessary. Here, a language in which a predicate for parallel description is added to the language Pascal will be taken up and described. In this embodiment, a procedure statement or f is used in the Pascal grammar to simplify the description.
A subprogram that starts with a unction statement is called a block, and a statement that starts with an assignment statement and a departure symbol such as if, while, repeat, or is called a statement. Also begin ... end
The sequence of "sentences" enclosed by is usually "compound sentence (compound
statement) ”, which is also called a statement here. The added specifications are the following two types.

(1) cobegin, coend cobegin, coend are the start and end statements of a block that allows parallel execution.

(2) Monitor Type The monitor type is a typing for declaring a so-called shared variable accessed by a plurality of blocks executed in parallel. The monitor type can be considered as an abstract representation of shared resources, but it provides resources that can be accessed only by specified procedures in a program. The method of handling exclusive control and synchronization for shared variables by this method is detailed in several publicly known examples (for example, Kazuki Ueda: Parallel Programming Language, Information Processing, Vol.27, No.
9, pp.995-1004 (1986), Brinch Hansen, P .: The Prog
ramming Language Concurrent Pascal, IEEE Trans. So
ftware Eng., Vol.1, No.2, pp.199-207 (1975), etc.).

FIG. 3 is an explanatory diagram of a program using a monitor. The program 300 is an example in which a parallel description language describes the processing content that the procedure 305 generates some integer type data and the procedure 306 consumes it one after another. This is, for example, the case where the procedure 305 is a process of receiving data from an external device, and the procedure 306 processes and displays the data. By declaring the variable buf as a buffer type that is a monitor type, the variable (variable name is buffer) 308 that is the actual state of the shared resource on the memory can be used only by the procedure 302 or 303 defined in the monitor type declaration 301. I cannot access it. In addition, each variable in the monitor is the procedure 304
Is initialized with. Producer procedure 305 is procedure buf.appe
When an attempt is made to substitute the variable 308 with nd (v), the process 302 is actually executed. At this time, if all the contents of the buffer, which is the array variable 308, are already filled, this request creates a queue putq and waits (309) (displayed as a procedure wait (putq)). In other cases, the element is added to the array variable 308, the pointer is updated, and the procedure signal (g
etq) is called (310). Procedure signal (getq)
Creates a queue getq and executes the waiting data acquisition processing call, if any, and returns the result. When the consumer procedure 306 tries to read one element of the content of the variable 308 by the procedure buf.fetch (v),
The processing procedure 303 is executed. At this time, array variable 30
If the content of buffer, which is 8, is empty, this request is made to wait by creating a queue getq (procedure wait (g
etq)). In other cases, the contents of the array variable 308 are read, the pointer is updated, and then the procedure signal
(putq) is called (312). Procedure signal (putq)
Executes the procedure call in the queue putq, if any, and returns the result. A monitor-type structure is considered to be a resource under the control of the block in which the monitor-type data is declared. In this embodiment, access to this resource is made by an intermediate language interpreter. Since the interpreter process itself is a sequential process, exclusive control to the shared variable and process synchronization can be guaranteed as a result. An intermediate language generation method when the monitor type definition is detected will be described below.

1-3. Lexical analysis and parsing processing The compiler 102 that has read the source code 101
The lexical analysis means 103 performs lexical analysis. Here, by sequentially reading the character strings appearing in the source code 101, the names and values of procedures, variables, constants, character constants, data type definitions, character strings, etc., as well as operators, special symbols, and reserved words of programming languages. Take out. The read result is recorded in the work area of the compiler 102.

Next, the syntactic analysis means 104 is implemented with the data of the read result of the lexical analysis means 103 as input. The parsing code of this embodiment has a Pascal grammar of LL (1).
Since it is a grammar of the nature called, well-known descending analysis is performed (there are many known examples of descending analysis such as Ikuo Nakata: Compiler, Sangyo Tosho (1981)). In languages such as Pascal, which have a block structure, variable names and block names are valid within the declared block. Therefore, in order to determine and refer to the value of a variable, information indicating the block depth and the order of appearance of blocks (when the block depths are the same) is required. The syntactic analysis unit 104 regards the program start level as block level = 0 and advances the processing. After this, the block level value is incremented by 1 every time the nested state of the block becomes one step deeper. Similarly, the block level value is decremented by 1 each time the nested structure is exited one step. That is, the main program has a block level = 0, and the procedure declared in the main program has a block level = 1.

The part of the syntax analysis means 104 of this embodiment different from the conventional method is the shared memory resource detection means 1 inside.
05, and the point where the parallel execution detection means 106 is processed.
The former defines a variable accessed by a plurality of processing units executed in parallel, and generates an execution code that establishes a processing procedure for the variable. The latter produces code for procedures and function calls that are executed in parallel.

The processing procedure of the syntax analysis means 104 will be described with reference to the flowchart of FIG. Since the syntax analysis of the language having the block structure is performed, the syntax analysis means 104 of this embodiment is used.
Performs a recursive descent analysis. That is, the block detection and the syntax analysis in the block are performed, and if there is a block definition in the block, the own process is recursively called to detect the block. It can be written in a pseudo programming language as follows.

Procedure block (....); var ident: predicate; ...; begin (* fetch the next predicate and assign it to ident *) ident: = next_word_in_source; if (ident = 'procedure') or (ident = 'function') then block (...) (* recursion *) else begin .... Other syntax ...; end end; When it enters (S401), the block level is incremented by 1 (S402), and the block number is incremented by 1 (S403). On the other hand, when the end of the block is detected, the block level is decremented by 1 (S423), and as a result, it is checked whether the magnitude of the block level is smaller than 0 (S).
424). When the block level becomes smaller than 0, it means that the end of the block has been detected at the level of the main program, indicating that the syntax analysis of the program has been completed. If the block level is 0 or higher, the syntax may continue and the process continues. The above is the outline of the processing flow of the syntax analysis unit 104. Next, the individual processing will be further described.

In the parsing process, it is necessary to record information such as the start address of the execution code, the storage position of the variable table, and the size of the stack area used for argument passing for each processing block. In this embodiment, the run-time block management table 501 and the block number management table 801 are used for this purpose.
To use. FIG. 5 is a diagram for explaining the data structure of the runtime block management table 501 used in this embodiment.
The runtime block management table 501 has a data structure 50.
It takes the form of an array with 2 as one element. Data structure 5
02 is a block number 503 and a chain 5 to a lower block
04, an offset 505 on the object code, a stack depth 506 consumed for argument passing, and a chain address 507 to the argument list.

Returning to the flowchart again, the description of the processing procedure will be continued.

By the processing S403, all processing blocks (procedures, functions) in the source code are given unique block numbers. In order to hold the relationship between the block number of each processing block and the block level, the block number management table 801 shown in FIG. 8a is generated in the processing of this embodiment. One element of the block number management table is a data structure including a block number 802, a block level 803, and a table entry 804. Process S
At 403, the values of the inner block number 802 and the block level 803 are recorded. Further, the process S403 is
Calculate how many bytes the relative position of the code generation start position of the current processing block from the object code start position of all programs. This value is recorded in the data structure 505 of the runtime block management table.

Each block (procedure or function) can receive arguments when it is called. At this time, the intermediate language interpreter loads the argument in the memory secured as the stack area and calls the process. Therefore, in order to schedule and execute a certain procedure in another processor during parallel execution, it is necessary to interpret the argument placed in this stack area and copy it to the work area of the intermediate language interpreter of another processor. Therefore, the argument list analysis process (S404) is performed. In this process, the argument list is recorded as a linked list in the data structure 507 of the runtime block management table 501. The details of this process are described in the next section.

Then, a link between blocks is generated (S405). This is for generating information necessary for processing block transfer during parallel execution. Details will be described later.

This post-processing is performed when a constant declaration is detected (S
406) registers it in the name table (S407), and when a type declaration is detected (S408), registers it in the type declaration dictionary (S409). Normally, in the parsing process, names other than reserved words appearing in the source program are registered in the name table without distinguishing constant names, variable names, procedure names, function names, and variable type names, and in the table, names and their objects are registered. Often the method of recording the type is adopted. This is a rational method to detect the inconvenience of name overloading (function name and constant name are the same). Also in this embodiment, the syntax analysis means 1
The management of names (identifiers) in 04 was based on this method.

However, when the variable declaration is detected (S410),
When the monitor type variable is detected by the shared memory resource detecting means 105 (S411), a shared variable process (S412) as described later is executed in addition to the registration in the normal name table. If it is a variable other than the monitor type, a table is created for variables in the block (S413), and code generation for local variable allocation is processed (S414).
Here, the start address on the work area of the compiler 102 of the variable table created for the variables in the block in step S413 is recorded as the value of the table entry 804 in the block number management table 801.

Next, the processing flow for the syntax other than the block start will be described.

In this embodiment, since parallel description is allowed in the language specification, the part to be executed in parallel is required to be explicitly described in the source code. In other words, cobe
Execution code in the sequential processing environment is generated for processing blocks that are not included in the range enclosed by gin and coend. This is done by the syntax analysis means 104 and the code generation means 107, 108, 11
From the standpoint of No. 7, the execution code of the block other than the processing unit for which parallel execution is designated by cobegin and coend performs the same code generation as at the time of normal compilation processing. Therefore, the syntax analysis unit 104 executes the parallel execution detection unit 106. The processing is the reserved word cobe in the source code syntax.
When gin is detected, the parallel execution flag = [true] is set (S
420), when the reserved word coend is detected, the parallel execution flag = [false] is set (S421). The actual execution code (intermediate language sentence) is generated while judging whether the flag is true or false.

If the retrieved predicate is an identifier and the name table registration is searched for a procedure name or a function name, it can be determined that the process is to call another processing block (S415). When this determination is [true], first, inter-block link processing is performed (S41).
6) Next, code generation for block calling is performed (S425). At this time, the content of the above-mentioned "parallel execution flag" is checked, and when the flag = [true], the code generation means 108 is executed. In other cases, the code generation means 117 is executed.

When the fetched predicate has a structure of "monitor type variable name" + "." + "Procedure name", the name table is searched by the monitor type variable name, and if the name exists, monitor type It can be determined that it is a procedure call (S417). In this case, the shared resource access procedure generation process (S418) is executed. The code generation means 107 is further processed as a substructure of this processing to generate an intermediate language sentence.

The above is the outline of the processing of the syntax analysis unit 104. Next, the operation of each part will be sequentially described.

1-3-1. Argument list analysis processing (S40
4) As is well known, when arguments are passed to a procedure in Pascal languages, there are two types of argument reference formats. "Argument by value (call by value)" and "Argument by name (call by ref)
erence) ”. In this embodiment, “reference type = 0” is used when passing by value as an internal representation of the argument reference type, and “reference type = 1” is used when passing a name.

The argument sequence starts with "(" following the block name in the syntax, and the variable name and the data type of the variable (integer,
Array, character, etc.). The end of the argument list is ");". Furthermore, the "argument for passing a name" starts with the reserved word "var". Argument list analysis processing S404
When the reserved word "var" is detected, the reference type = 1,
In other cases, the reference type is 0. Next, the data type of the variable is analyzed, and the value of the internal representation given to that data type is extracted. All available data types are given a unique value (integer value) as an internal representation. Analysis process S
404 adds this "reference type, variable type" value to the list of the data structure 509 following the chain address 507 of the runtime block management table. The data structure 509 has a linked list data type, and the end of the data is a chained address. The chain 509 from the chain address 507 is referred to as an argument list during the code generation processing.

1-3-2. Extraction of Dependence Relationship between Blocks (S405, S416) In the processing system of this embodiment, the target block to be executed in parallel is transferred (if possible) to the local memory space of another processor and executed. To do this, when you place a processing block in another processor, take out all the procedures and functions called from this processing block,
It is desirable to place this copy in local memory of the same processor as the processing block. This is a process for eliminating the need for interprocess communication every time a processing block calls a lower block. To realize this, when attention is paid to a certain processing block that is a target of parallel execution, a management unit that can specify a block that the processing block calls (hereinafter referred to as subordinate) will be implemented. In the present embodiment, this management means is realized by holding the data structure for holding the dependency relationship between the processing blocks in the runtime block management table 501.

Processes S405 and S416 in the flowchart of FIG.
Is a process for describing links between actual blocks in this runtime block management table.

From the characteristics of the language of this embodiment, when a program is written as in the source code of FIG. 6, the block structure between processing units and the block number given in processing S403 during syntax analysis are shown in FIG. Can be shown in. According to the concept of scope (valid range) given to identifiers such as variable names and procedure names, for example, it is possible to access variables of higher structure such as procedures p32 and p3 inside the processing of procedure p321 which is block number 11. Access to variables such as p31 and p2 is not allowed.

In order to extract the hierarchical relationship of the processing blocks while maintaining such a variable scope relationship correctly, step S405 performs processing while referring to the block number management table 801. This process is shown in the flowchart of FIG. If the block level of the own block is either 0 or 1, the own block is declared at the top level and is not subordinate to the upper hierarchy, so that link generation is unnecessary (S90).
1). Otherwise, the block number management table 8
The element in the table is traced back from the position of the own block of 01, and an element having a block level value smaller by one than the block level value of the own block is searched (S90).
2). The block number of the element is taken out (S90
3), using the value of the block number as a key, the matching block number 5 from the runtime block management table 501
Find the position of the block with 03 and access that element. Chain address 50 to the lower block of this element
A chain 508 from 4 is generated (S904). With the above processing, the chain to the own block can be recorded for the block located in the upper structure. FIG. 8B is a diagram for explaining the link operation between blocks by taking the program of FIG. 6 as an example. To make it easier to understand, the state of links between blocks is indicated by arrows on the right side of the contents of the block number management table 801. When a block number is given from the program of FIG. 6 according to the block structure as shown in FIG. 7, for example, the procedure p32 of block number = 10 is dependent on the procedure p3 of block number = 5. As shown in FIG. 8b, the value of the block level of the procedure p32 is 2, so if the element is searched for in the block number = 1 in the block number management table 801, the position of the procedure p3 of the block number = 5 is detected. it can.

On the other hand, the process S416 is a process for generating a chain to a block called by the own block. This process is simpler. That is, as a result of searching the name table according to the identifier in the syntax, if the name is the name of a procedure or function, the block number is extracted. The value of this block number is simply added to the chain 508 following the chain address 504 at the position of the own block in the runtime block management table. Further, when the chain 508 is generated, if an element having the same block number is already on the chain, it is not added to the chain to avoid duplication.

1-3-3. Shared variable processing (S412) The shared variable processing S412 secures an area of the execution code that actually accesses the monitor type variable. Next, the target code of the monitor type procedure prepared as the standard procedure of the intermediate language interpreter is loaded in this area. At this time, each monitor type variable is given a unique number in the order of declaration in the source code. This is recorded in the shared resource management table 1001 having the data structure shown in FIG. One element of the shared resource management table 1001 is
Resource number 1002, shared variable name 1003, block number 1004 of processing block that declares shared resource, offset value 100 to object code 1006 of monitor type procedure
It consists of 5.

2. Code Generation by Intermediate Language Next, a procedure for generating an intermediate language will be described. For simplification of description, a part of the table explaining the function of the intermediate language is shown in FIG. However, TOP represents the uppermost address of the stack type data area taken in the work area of the intermediate language interpreter, and SP represents the pointer pointing to the stack type data area. The interpreter stack of this embodiment has a first-in, first-out type memory structure in which elements are newly stacked in the smaller address value and the pointer is updated in the direction of the larger address value when the element is taken out. The address where the identifier x is stored is written as addr (x).

The intermediate language interpreter extracts the value stored at the address addr (x) from the instruction written as LODV addr (x), and stores it in the top level of the stack when the intermediate language interpreter is executed. Interpret as an instruction. (In the explanation below, for simplicity of explanation, this is simply
It is written as LODV x ”.) The instruction LODA addr (x) evaluates the address value of addr (x) itself and puts it on the top level of the stack.

LODN obj is a processing block or monitor type shared resource, and the value of the block number or resource number of the object is taken out and placed at the top of the stack.

LOD n calculates an address with a depth of + n bytes from the current stack pointer in the stack used by the interpreter, extracts the data at that address, and copies it to the top of the stack.

ALOC n advances the current stack pointer in the direction of the smaller address by n (that is, subtracts n), and allocates an area for a local variable.

UALC n is an instruction paired with ALOC n, and the value of the stack pointer is n.
Is added to restore the area vacated by the ALOC n command.

The CALL addr (x) processing branches to the head address of the identifier X, and when the instruction word RET is detected, the CALL addr (x) is returned to the next instruction position where the CALL X was previously executed.

ADD adds the value at the top of the stack and the value at the position next to the stack, advances the stack pointer in the direction of decreasing the stack by one stage, and stores the addition result at the new top of the stack.

The intermediate language also has instruction words for arithmetic processing, conditional branch processing, and the like. All instructions do not use the processor register as an accumulator, but operate on the stack. Needless to say, the specifications of this intermediate language may be other specifications as long as they are unified among the intermediate language interpreters that execute in parallel. The stack used here is a linear memory space taken in the work area of the intermediate language interpreter, and is different from the processor stack.

FIG. 13 is an explanatory diagram in which a part of the intermediate language description generation processing is described in a pseudo program language. The description is the code generation procedure 130 at the time of calling a block.
1 and the code generation procedure 1303 when the cobegin and coend statements are detected. The process at the time of calling a block includes a code generation procedure 1302 for arguments. In addition to this, it is necessary to generate an intermediate language at the time of arithmetic operation, but it is omitted because it is the same as the conventional method. The process of intermediate language generation is such that when a certain condition is detected, an intermediate language is generated according to the rule applied to the condition. Therefore, the process is an operation for repeating the process of incorporating the evaluation of the identifier, the value, the address, etc., taken out by the syntactic analysis, in addition to the condition detection and the rule-based code generation.

An example will be given below to explain how the above intermediate language occurs in the execution code.

2-1. Code generation means 10 for parallel execution
8 Generation of description in intermediate language will be described with reference to FIG.
When the definition of the procedure p1 shown in 1200 appears in the source code, the syntax analysis unit 104 analyzes the argument list as shown in the flowchart of FIG. 4 (S404). First argument 12
01 starts with the identifier x. The syntactic analysis unit 104 determines that this is an “argument for passing a value”. As a result, reference type = 0 is recorded, and since the argument type is integer, 1 which is the internal representation of the integer type is recorded as the “type name”. The second argument 1202 begins with the reserved word var. Therefore, the syntax analysis unit 104 determines that this is an “argument for passing a name”, and “reference type = 1” and “type name = 1” are recorded. As a result, the argument list is formed by the chain 509 from the chain address 507 of the runtime block management table 501. If the content of the argument list regarding the procedure p1 is taken out, it can be illustrated as 1203.

When the description 1204 appears in the source code and the code is not executed in parallel, the code generation means 117 is executed and the intermediate language description 1205 is generated according to the contents of the argument list 1203. The generation of this description is based on a method of arranging ruled command words in the order that they appear in the argument list 1203, and is a known method.

In this embodiment, the parts to be executed in parallel are
Generate an intermediate language description different from the conventional method. As a precondition, in the present embodiment, a procedure or function that allows parallel execution does not accept variable arguments other than monitor type variables. This is natural considering that the variable argument is an argument that allows assignment. Let procedure p2 be a procedure that has an integer passing by value as the first argument and a monitor type variable that is passing by name as the second argument, and procedure p3 be a procedure that has no arguments. Described in source code 12
When 06 appears, the syntax analysis unit 104 of this embodiment executes the processing of the next procedure.

Step 1 The parallel execution detecting means 106 is cobegi
The n statements are detected and the parallel execution flag is set to [true] (process S420 in the flowchart of FIG. 4).

Procedure 2 Described in the syntax analysis means 104 "
p2 (a, b); "is analyzed and detected as a block call (S415).

Step 3 The content of the parallel execution flag is checked. Since it is [true] here, the code generation unit 108 is executed.

Step 4 The code generation unit 108 searches the name table of the work area of the compiler 102, and
The block number of p2 and the argument list are specified.

Procedure 5 From the contents of the argument list, it can be known that the first argument is a pass by value (reference type = 0) and is an integer type.

Step 6 The code generation means 108 outputs the predicate of the intermediate language according to the generation rule. The rule here is "the argument passed by value outputs the instruction word {LODV x} format".

Procedure 7 It can be known from the contents of the argument list that the second argument is a variable passed by name and is of the monitor type.

Step 8 As a rule, "monitor type variable argument outputs instruction word {LODN obj} format" is used, and an intermediate language description is output.

Procedure 9 Generate an intermediate language description that calls procedure p2. Here, the rule "procedure call outputs command word {LODN obj, CALL addr (coexec)} format" is applied at the time of parallel execution.

Thereafter, the process is similarly performed for the procedure p3. Further, the following procedure is processed.

Step 10 The parallel execution detecting means 106 is cobe
The nd statement is detected and the parallel execution flag is set to [false] (process S421 in the flowchart of FIG. 4).

Procedure 11 The instruction word {CALL addr (sync)} is output according to the rule at the end of parallel execution.

The description 1207 is output as a result of the above procedure. Here the procedures coexec and sync are built-in procedures of the intermediate language interpreter. The operation of these built-in procedures will be described in the section "3-3. Runtime processing of parallel description part".

2-2. Shared resource access procedure code generation means (S418) When the syntax analysis means 104 detects a syntax involving access to a shared resource, the process S
418 is executed. Occurrence of the intermediate language accompanied by access to the shared resource can be expressed as 1304 in FIG. 13 when written in a pseudo programming language. In order to access the monitor type variable, the monitor type variable may be specified as a non-local variable in the procedure or may be specified in the argument list.

The former code generation is simple. Using Fig. 14a to show the case where the code is executed, the intermediate language interpreter puts the argument 1 to the monitor type procedure on the stack.
404 is placed, and the value of the monitor type resource number is 14 at the top.
Place 05 and call the procedure of append and fetch.
This can be realized by generating an intermediate language according to the following procedure from the viewpoint of the code generation side.

Procedure 1 Process S41 of the syntax analysis means 104
8 searches the shared resource management table 1001 using the monitor type name described in the syntax as a key, and extracts the resource number. Procedure 2 The code generation means 107 is called.

Procedure 3 The procedure described in the program 1304 is executed. The arguments for the monitor-type procedure due to the object code generation up to immediately before are placed in the topmost stage 1404 of the stack. Following this, the command word {LODN obj} is output.

Step 4 Whether the result of syntax analysis is an append call
It is judged whether it is a fetch call, and the command word {CALL addr (append or fetch)} is output.

On the other hand, when there are a plurality of shared resources and it is desired to distinguish the resources to be accessed while using the same procedure, the monitor type argument is required. Code generation in this case is rather complicated. The code including the monitor type argument is, for example, the case where the description 1208 appears in the source code. This will be described with reference to the stack usage history 1401 in FIG. 14B.

The arguments used when the procedure is called are stacked on the stack. After this, when the procedure is actually called, the command {ALOC
N} is executed and the local area 1402 is secured. Further, the target code for operations and the like consumes the stack, and the current processing result is placed in the top stage 1404 of the stack at this point. This is the argument to the monitor type procedure. Next, the monitor type resource number is placed at the top of the stack. For this purpose, the instruction word {LOD + d} is executed, and the value is copied onto the stack top from the position of the depth of + d bytes of the stack as indicated by arrow 1403. Then the append and fetch procedure calls are executed. From the code generation side, this can be realized by performing intermediate language generation according to the following procedure.

Procedure 1 A region for local variables is expanded. For this purpose, the command word {ALOC N} is output.

Step 2 Another object code is generated.

Step 3 When detected by the monitor type procedure call, the depth to the position where the monitor type variable in the argument list is placed on the stack is calculated. The instruction word {LOD + d} is generated with the calculation result as d.

Step 4 Whether the result of syntax analysis is the call to append
It is judged whether it is a fetch call, and the command word {CALL addr (append or fetch)} is output.

Step 5 If necessary, another object code is generated. After that, the command words {UALC N, RET} are output in this order.

As a result of the above processing procedure, the target code 1209 in the intermediate language is converted from the source code description 1208.
Is output.

2-3. Object file creation means 1
Operation of 09 The target code description is obtained by the above-mentioned procedure. The object file generating means is code generating means 107, 1.
The intermediate language object 110 is output with the object code description generated by 08 and 117 as an input. The purpose code description describes a procedure call by a block number linked to a procedure name (identifier). Since this is substantially equivalent to the name, the procedure name is used in the above description. However, what is needed at the time of execution is not the name of the procedure, but the number of bytes in which the procedure is recorded relative to the start position in the program. This information is the run-time block management table 50 already described.
It is held by the data structure 505 of 1. Therefore, the object file creating means 109 reads the target code description, and when it detects that the block name is called, searches the runtime block management table 501 using this block name (correctly, block number) as a key, and the relative position in the execution code Take out 505. Next, the block name of the intermediate language description is replaced with the value of the relative position 505 by this value.

Similarly, a monitor type variable / procedure which is a shared resource is designated by a resource number in the object code description. The object file creating means 109 also searches the shared resource management table 1001 by using the resource number as a key, extracts the offset value 1005 in the execution code, and extracts the part described as the resource number in the object code description. replace.

Following the above processing, the object file creating means 109 adds the contents of the runtime block management table 501 and the shared resource management table 1001 after the object code description and outputs the file as an intermediate language object 110.

3. Intermediate language interpreter 3-1. Communication between Intermediate Language Interpreters The compiler system described above need not be run on the target system. The intermediate language object 110 can be generated by using another computer system as a host device. The generated intermediate language object is output as a file and transmitted to the target system by a magnetic disk medium, a semiconductor ROM, communication means, or the like.
Alternatively, the intermediate language object 110 can be generated from the source code by directly executing the compiler having the above configuration on the target system.

The intermediate language interpreter is a processing system that operates using the intermediate language object 110 as an input. The intermediate language interpreter is required to be able to interpret and execute a given intermediate language, and for this purpose, any implementation form is possible. The simplest example is shown in FIG.
It is a method using a device that continues an infinite loop as shown in the flowchart in FIG. In this embodiment, as shown in FIG.
3 starts the process 111 on the operating system 203, and the process 111 realizes the processing of the flowchart of FIG. In addition, the processor 11
In No. 4, the process 112 is activated on the kernel 205 that supports interrupt processing and the like, and a similar processing flow is realized. Therefore, here, the processes 111 and 112 are called an intermediate language interpreter (hereinafter abbreviated as IPR). For the sake of explanation, the processor in which the main program is started is called a local processor. A processor in which some processing blocks are distributed after the parallel execution description is detected and is responsible for parallel execution is called a remote processor. Similarly, the intermediate language interpreter on the computer in which the main program is activated is called the master IPR, and the intermediate language interpreter executed on the remote processor is called the slave IPR.

The process which operates as an IPR is shown in FIG.
The process 1702 of FIG. Process 1
702 includes a process header in which information for process management is recorded, an execution code area indicated by the processor program counter 1703, a work area, and a processor stack 1711 indicated by a processor stack pointer 1710. An object code 1704 of an interpreter program and an object code 1705 of a built-in procedure group are stored in the execution code area. The code area 1706 in which the intermediate language object code is arranged and the stack area 1707 for the intermediate language are
Placed in the work area of the process. An instruction pointer 1708 for the intermediate language and a stack pointer 1709 for the intermediate language are placed in the same work area. In addition to this, the runtime block management table 501 and the shared resource management table 10 are also provided.
01, a runtime processor management table 1701 is placed. The IPRs 111 and 112 can communicate with each other using the FIFOs 207 and 208. When data is written in the FIFO 208, the processor 113 is transmitted via the system bus 202.
Is interrupted. This interrupt is fetched by the processing routine of the operating system 203, and the IPR
It is transmitted to 111. Further, the system bus 202 assigns addresses to the FIFO 207 in the address space of the processor 113. Therefore, when the processor 113 writes data to this address, the FIFO2
07 can generate an interrupt signal to the processor 114. The kernel 205 of the processor 114 takes out the data written in the FIFO 207 by the interrupt service routine and transfers it to the IPR 112.

The IPRs 111 and 112 are the FIFOs 207 and
It can be considered as a process that communicates using 208. Due to the design of this processing system, the personal computer 200
Multiple pieces of hardware can be added to the above. Therefore, the communication between the master IPR (IPR 111 in this case) and the slave IPR is not limited to one-to-one communication. Therefore, in this embodiment, a data string having a data structure of the format 1501, 1505 or 1510 shown in FIG. 15 is used for communication between processes operating as IPR. In this data structure, the processor number 1503 is the number of each processor uniquely determined by the system, and the process number 1504 is the number assigned to each process by each processor when the process is created. Therefore, even if a plurality of processes exist, the processor number 1503 and the process number 1504
It is possible to specify the process which is to specify both. On the other hand, what is used as the command 1502 is {connect lock}, {load}, {execute}, {release},
These are {fetch} and {append}. Communication 150
The IPR that receives 1, 1505 returns a message having a data structure of 1510 as a response. Here, five status codes 1511 are used: {busy}, {ready}, {accept}, {dern}, and {fail}.

The operation of the IPR will be described below with reference to the flowchart of FIG. When the IPR receives the command (S160
1) Judge whether the content is {connect lock} (S1)
602). If {connect lock}, the status code inside the IPR is set to {busy} (S1603), and the connect process S1604 is executed. The connect processing S1604 extracts the processor number 1503 and the process number 1504 from the received data string, records them in the internal work area, and returns a status code {accept} to the process that has generated {connect lock} processing. After this, after receiving the command, it is judged whether the process that transmitted the command is the process targeted for the connect process (S1605), and No
If so, the status code {busy} is returned (S1606).
When a command is received from the process that is the target of the connect process, one of {load}, {release}, and {execute} commands is executed. {append},
The {fetch} command is also responded to for processes other than the connected process.

If the command is {release}, the status code is set to {ready} (S1607), and the processor number and process number recorded for the connect process are discarded.
The process returns to the command reading process S1601.

If the command is {load}, load processing S1608 is executed. Load processing S1608 reads the object code 1507 described in the intermediate language in the work area of the slave IPR, and then the stack initialization data 1
508 is read, the data in the initial state is stored in the stack according to the instruction of this data, and the stack pointer is set. Then, the table initialization data 1509 is read and the contents of the runtime block management table 501 and the shared resource management table 1001 are initialized.

When the command is {execute}, the execution state is entered, and the sequential execution process (S1609) is started from the instruction designated by the instruction pointer of the code area 1706. Sequential execution processing S1609 executes the instruction word processing group 1610,
The processing contents of the built-in procedure processing group 1611 are executed according to the processing contents. In the case of the sequential execution processing loop, the polling processing S1612 is executed after the instruction execution. This is {busy} when confirming the end of processing of slave IPR after execution of sync command and request from other IPR.
When responding, it is necessary to check the queue from each communication port.

The above is the outline of the operation of the IPR.

3-2. Operating State of Intermediate Language Interpreter The IPR of this embodiment has an operating state of initial startup.
This operating state is an operating state created by the operating system 203 immediately after the intermediate language object 110 is executed under the control of the operating system 203. The operating system 203 determines that this is an IPR from the file attributes of the intermediate language object 110.
It is judged that the file is a file managed and executed by 111. As a result of this determination, the operating system 203 activates the IPR 111. (Apart from this method, a system with an interpreter system for operating systems called command shells can describe similar operations as text for command shells).

On the other hand, the IPR can acquire the arguments passed from the operating system when it is started. By the above operation, the intermediate language object file 1 as this argument
10 file reference numbers (file management information) are passed. At this time, the IPR loads the intermediate language object 110 into its work area and executes it. IP started here
The R111 becomes the master IPR below, and sends a command to the IPR 112, which is a slave IPR, as necessary to share a part of the processing.

The IPR in the initial startup state has a status code of {busy}. Therefore, the request cannot be accepted even if another IPR requests the sharing of processing in parallel and issues a {connect lock} message to this IPR. On the other hand, an IPR that is in an operating state other than initial startup
Can always act as a slave IPR.

3-3. Runtime Processing of Parallel Description Part Next, the operation of IPR during parallel execution will be described with reference to FIG.

The instruction word analysis processing 1801 of the master IPR is instructing the instruction word {CALL a during the description of the intermediate language object 110.
When ddr (coexec)} is detected, cobegin statement processing 1802
Is called. The cobegin statement process 1802 sends a {connect lock} command to all processors using the system bus 202. If the response is {busy}, or if there is no response after a certain period of time, it can be determined that those processors cannot share the parallel execution. On the other hand, depending on the margin of processor resources, there may be a processor executing a plurality of IPRs and a plurality of {accept} messages may be received. Therefore, the master IPR creates a runtime process management table 1701 in the work area. Runtime process management table 17
The contents of 01 are the processor number and the process number that were able to receive the {Accept} message, the block number of the processing block distributed (or scheduled) to be regarded as the slave IPR, and the request queue for each process. It is a pointer to 1807.

When the number of blocks to be executed in parallel is smaller than the number of acquired slave IPR processes, the master IPR sends a {release} message to unnecessary slave IPRs to release the connection. On the contrary, if the number of processing blocks to be executed in parallel is larger than the acquired slave IPR, the queue 1 for the acquired slave IPR.
807 is created, and the processing blocks to be executed in parallel are added to the elements of this queue. This processing is cobegin statement processing 18
02 is processed by the scheduler 1803. The scheduling algorithm of this embodiment is a simple algorithm in which new requests detected by the scheduler are placed in the shortest queue 1807.

On the other hand, some of the processing blocks can be processed by the master IPR. Therefore, the scheduler executes the predicate expansion process 1806. Predicate expansion processing 1806
Retrieves the sequence of predicates LODN foo CALL addr (coexec) in the intermediate language description and replaces the sequence of predicates NOP CALL addr (foo). Here, foo is a relative address of a certain procedure or function, and the command word NOP represents a command word that does not work. The instruction word description rewritten by the predicate expansion processing 1806 is again the instruction word analysis processing 1801.
Returned to and evaluated there. Therefore, the instruction word analysis processing 1801 and the predicate expansion processing 1806 rewrite the instruction pointer 1708 in the intermediate language according to the processing content.

In the above processing, the scheduler 1803 determines in what order the plurality of processing blocks to be executed in parallel are distributed to the master IPR and the slave IPR. The scheduler 1803 of this embodiment allocates at least one processing block to the master IPR unless a special instruction described later is used.

The master IPR enqueues the data string according to the data structure of the {load} message described above in the queue 1807 for the slave IPR 1808 and the {execute} message. Slave IP that executes this processing request
After the processing is completed, R returns a message composed of the data structure 1510. If the status code at this time is normal termination, {Dern} is returned. On the other hand, if any run-time error is detected, the status code {Fail} is returned. The source code of the target program needs to do something about error handling, which is the same as conventional programming. If the processing block is a function, the processing normally terminated by the status code {Dern} returns the value of the function as data 1512.

The master IPR that started parallel execution is coen
Wait for parallel execution to end with d statement. C as already explained
The intermediate language description generated for the oend statement is {CALL addr (sy
nc)}. Upon detecting this description, the command word analysis processing 1801 calls the sync statement processing 1805. The sync statement process 1805 waits for a {darn} message from the slave IPR, confirms the match with the processor number and process number in the runtime processor management table 1701, and records the end of the process. When the processing of all processing blocks is confirmed
The sync statement processing 1805 ends. As described above, the master IPR executes at least one processing block under the control of the scheduler 1803. Therefore, since the IPR itself is a sequential processing system, the sync statement processing 1805 is executed by the master IPR. After the block has finished executing.

3-4. Shared Resource Access Runtime Processing Next, the processing when a shared variable is accessed by a monitor type procedure call will be described using the flowchart of FIG. The command word analysis processing 1801 uses the procedure ap.
When a call to pend or fetch is detected, a monitor type resource number is fetched from the top level of the IPR stack (S1
901). The shared resource management table 1001 is searched using this resource number 1002 as a key (S1902). As the search result, the block number 100 in which the resource is declared
4 can be acquired (S1903). This block number is compared with the own block number (S1904), and if they match, the same processing as a normal procedure call is performed (S190).
7). Otherwise, the IPR starts from the block number being executed by its own process, to the runtime block management table 501.
The element 502 is accessed, and the chain 508 from the chain address 504 to the lower block is traced (S1905).
If a block with the same block number is found by this processing (S1906), procedure calling processing is performed (S1907). If a matching block number cannot be detected even after checking up to the end of the chain 508, the processor number and process number holding the monitor type resource are fetched from the runtime block management table, and the message is sent to the IPR specified by these two numbers. It sends {fetch} or {append} (S1908) and waits until the data string of the processing result is received (S1909).

On the other hand, the IPR that received this message
On the side, as shown in FIG. 16, fetch processing S1613 or append processing S1614 is performed. In this processing, the resource number of the monitor-type shared resource is extracted from the data part of the message, and the shared resource management table 100 according to this resource number.
Check 1 registration. Next, the corresponding element is taken out, the address is calculated on the execution code of the monitor type procedure from the data structure 1005, the actual processing is called, and the processing result is returned to the requesting IPR together with the status code {Dern}.

Here, when a monitor type variable in another processor is accessed, the IPR process for receiving a message and returning a response is a sequential process, and therefore is completely exclusive controlled. Further, since the IPR on the request side waits until there is a response from the IPR of another processor, it is possible to prevent the occurrence of overtaking processing on the request side. Even when a plurality of processes are created on the same processor and a plurality of IPRs are being executed, access to shared resources is limited to a dedicated process in the monitor type, and this process is executed sequentially by the IPR. Exclusive control is possible.

On the other hand, if the value is read before the actual data string is written in the shared resource, the processing content becomes invalid. Further, if data is further written while the buffer is all filled, the preceding data is lost (due to multiple writing). A synchronization mechanism is required to prevent these inconveniences, but the synchronization is maintained by the wait and signal processing for the queue described as a monitor-type internal procedure.

With the above processing, in this embodiment, a plurality of IPRs can be executed while performing exclusive control.

3-5. Procedures that specify the execution processor In the processing system described above, the processing blocks that are actually placed in the remote processor and the processing blocks that continue execution in the local processor use similar instruction words in the intermediate language description. It was a processing system. Therefore, the implementation method of the processing system that does not need to explicitly write the description that specifies the processor in the intermediate language description and the description that transfers the processing block to the local memory of the remote processor has been described. This is because the present invention aims to realize a processing system that does not need to be rewritten by changing hardware.

On the other hand, contrary to the above, when a dedicated processor is added (especially important in specific fields such as signal processing and image processing), there are cases where it is desired to explicitly specify the processors to be distributed. For this reason, the processing system of the present embodiment prepared function processor (slot: integer): boolean; as a built-in function. This is because if the number of the slot for the expansion board of the system bus is specified by the argument slot (integer type), when the processor board is mounted in the slot for the expansion board and the intermediate language interpreter is running, the logic [true ]
Is a function that returns. When this function is called, the master IPR sends a {Connect Lock} message specifying the processor number. This response is {Accept}
If there is a message response, {TRUE} is substituted for the return value of the function. Also, if there is no response for a certain period of time, or if the response is {busy}, the return value of the function is {FALS
E}.

Further, in the processing system of this embodiment, procedure distribute (slot: integer; procedure foo); is prepared as a built-in procedure. This is the argument of the slot number for the expansion board
It is a procedure that is specified by slot (integer type) and that the procedure specified by the procedure argument foo is placed and executed in the processor on the hardware of that slot. The second argument is function
You can specify it as foo: tt ;. Where foo is the function name and tt is the data type name. To realize this procedure, the master IPR sends a {connect lock} message specifying the processor number, and if there is a response of an {accept} message in response to this, sends a {load} and {execute} message successively. By this processing, the execution of the processing block specified by the procedure argument or the function argument in the above procedure is assigned to specific hardware. The above two built-in processes can be used to describe processor-specific execution. The following is an example of the description. This is a case where the procedure PROC1 having the arguments a and b and the procedure PROC2 having the argument a are executed in parallel, and it is possible to write PROC1 in the processor of the slot 4 of the system bus as follows.

Cobegin if processor (4) then dist
ibute (4, PROC1 (a, b)) else PROC1 (a, b); PROC2 (a); coend; In this example, if the expansion slot 4 does not have a processor board, the procedures PROC1 and PROC2 are parallel in a normal sequence. To be executed.

4. Supplementary explanation 4-1. Tables Used by Compiler and Interpreter The roles of various table structures shown in the description of the present embodiment will be summarized with reference to FIG.

The block number management table 801 is generated in the work area of the compiler 102, and is discarded when the compilation processing is completed. This table shows the compiler 102
In the syntactic analysis means 104, the block number, the pointer of the in-block variable table, etc. are recorded. Further, with reference to this table structure, chain generation between blocks of the runtime block management table 501 is performed.

The runtime block management table 501 is generated in the work area of the compiler 102 and then output to the file of the intermediate language object 110 by the object file creating means 109. Further, after the intermediate language object 110 is loaded into the intermediate language interpreter, it is also referred to in the intermediate language interpreter. In this table, the parsing result of the argument list when the block is called by the syntax analysis unit 104 of the compiler 102 and the dependency relation between the blocks are recorded.

After the shared resource management table 1001 is created in the work area of the compiler 102, the intermediate language object 11 is created by the object file creating means 109.
It is output to the 0 file. This table is also referenced in the intermediate language interpreter after the intermediate language object 110 has been loaded into the intermediate language interpreter. In the intermediate language interpreter, it is referred to for monitor-type procedure processing.

Runtime processor management table 1701
Is generated at run time in the interpreter work area. This table is used for managing the processors that can be used for parallel execution ({connect lock} has been created) and for managing the schedule of the results of parallel execution.

In addition to the above table structure, in the present embodiment, the compiler 102 uses a name table and an in-block variable table to manage identifiers such as variable names and block names.

4-2. Development of the present example 4-2-1. Exclusive control and shared resource management In the above description, the monitor type has been described as the exclusive control for the shared resource and the synchronization mechanism. This is used as an easy implementation in this example. However, the same configuration as this embodiment can be immediately applied to a well-known semaphore. For this purpose, which block is under the control of the semaphore to be accessed is recorded in the same data structure as the runtime block management table 501 of the present embodiment, and the semaphore outside the self processor is remotely communicated with the communication. All you have to do is prepare a built-in procedure to access.

The well-known exclusive control and synchronization mechanism can often be replaced by using a semaphore. From this, it can be said that the present embodiment can be applied to a shared variable realization method other than the monitor type.

In the monitor type shown in this embodiment,
When the structure without buffer memory allocation is used, it can be considered that a synchronous communication path by a specific procedure associated with a certain data type is realized by the intermediate language interpreter. Therefore, the intermediate language interpreter of the present invention can be implemented even when a communication path is realized by using a memory structure such as a FIFO between the interpreters. In this case, even a compiler of a programming language which does not have a shared variable and which exchanges data between parallel execution procedures by communication is implemented in a plurality of processors by outputting an intermediate language similar to that of this embodiment. It can be said that it can be executed by an intermediate language interpreter.

4-2-2. Implementation of Intermediate Language Interpreter An intermediate language interpreter equivalent to that shown in the above embodiment may be realized in a processing system including a plurality of processors. For example, it is conceivable to implement a kernel program that realizes parallel processing on a computer including four processors and run an intermediate language interpreter program on this kernel program. If this is further developed, the intermediate language interpreter of the present invention can be mounted on different multiprocessor systems having different topologies, and parallel programs that can be executed in a mixed topology environment can be written.

By using this method, a systolic array processor system advantageous for high-speed image processing,
It is possible to realize a high-level language that can be described on a system in which vector processor systems that are advantageous for processing such as signal processing and fast Fourier transform processing are combined.

In the conventional compiler, the output code of the compiler developed assuming the use of the vector processor, for example, generates a machine language code to be executed on the vector processor. This object code depends on the target system. The output of this kind of compiler will not be the optimum code unless it is recompiled for changes in the hardware specifications. For example, even if a new vector processor is added to the computer that was operating the object code compiled with the hardware of only the scalar processor as the execution environment, it is recompiled by the compiler that supports the vector processor to generate the object code. Without fixing it, the effect of improving the execution speed cannot be obtained.

On the other hand, the compiler shown in this embodiment generates the code executed by the intermediate code interpreter. Also, the intermediate code is dynamically scheduled by the processor at run time. Due to these two characteristics, when hardware (circuit board etc.) with an intermediate code interpreter is added to a system that operates compiled object code, it is recompiled to regenerate the object code of the target program. No steps required. The object code of the target program is executed by the multiprocessor system including the processor of the additional hardware and the processor that has been conventionally operated from the time when the hardware implementing the intermediate code interpreter is added. This is extremely advantageous at the stage of selling and operating commercial applications. This is because most commercial applications are sold to users only in the form of object code that does not include source code in order to protect the program copyright. With the object code developed by the compiler of this embodiment, it is not necessary to change the object code of the application software even if the user adds hardware. As a result, there is an effect that the maintenance is easy and the operation is easy.

[0126]

According to the present invention, a mechanism for exclusively controlling access to a variable shared during parallel execution, a compiler for generating an object code described by an intermediate language instruction word, and an intermediate language output by the compiler. This compiler is used even if the hardware configuration of the parallel processing system changes because it is composed of an interpreter that executes the above and a mechanism that dynamically allocates processing blocks for parallel execution realized by the interpreter. It is possible to execute parallel processing without recompiling the developed object code.

In other words, even if the user adds additional hardware such as an accelerator to improve the processing speed, the application program for the personal computer in which the processing system according to the present invention is mounted is changed by adding the hardware. You can enjoy the improvement of the processing speed by the added hardware without needing.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a multiprocessor processing apparatus suitable as an embodiment of the present invention and a compiler processing system thereof.

FIG. 2 is a configuration diagram of a personal computer that is a multiprocessor processing device that executes an object code developed by the compiler processing system of FIG.

FIG. 3 is an explanatory diagram of a monitor type.

FIG. 4 is a flowchart of the processing of the syntax analysis unit 104.

FIG. 5 is an explanatory diagram of a runtime block management table.

FIG. 6 is an explanatory diagram of a program given as an example.

FIG. 7 is an explanatory diagram of a dependency relationship of blocks of a program given as an example.

FIG. 8 is an explanatory diagram of a block management table.

FIG. 9 is a flowchart of a process of extracting a dependency relationship between blocks.

FIG. 10 is an explanatory diagram of a shared resource management table.

FIG. 11 is an explanatory diagram of functions of an intermediate language.

FIG. 12 is an explanatory diagram of an intermediate language generation process.

FIG. 13 is an explanatory diagram of an intermediate language generation procedure.

FIG. 14 is an explanatory diagram of a stack state during intermediate language processing.

FIG. 15 is an explanatory diagram of a data structure used for communication between processes that form an intermediate language interpreter.

FIG. 16 is a flowchart of processing of an intermediate language interpreter.

FIG. 17 is a block diagram of a process for realizing an intermediate language interpreter.

FIG. 18 is an explanatory diagram of processing of a cobegin statement and a sync statement.

FIG. 19 is a flowchart at the time of execution of shared resource access processing.

FIG. 20 is an explanatory diagram of a table structure.

[Explanation of symbols]

 101 ... Source code 102 ... Compiler 103 ... Lexical analysis means 104 ... Syntax analysis means 105 ... Shared memory resource detection means 106 ... Parallel execution detection means 107 ... Code generation means 108 ... Code generation means 109 ... Object file creation means 110 ... Intermediate language Object 111 ... Intermediate language interpreter 112 ... Intermediate language interpreter 113 ... Processor 115 ... Communication path 200 ... Personal computer 201 ... Additional hardware 202 ... System bus 203 ... Operating system 300 ... Source code 501 for explanation ... Runtime block management table 503 ... Block number 504 ... Chain address to lower block 507 ... Chain address to argument list 508 ... Chain 509 ... Chain 801 ... Block number management table 802 ... Block number 803 ... Block level 804 ... Table entry 1001 ... Shared resource management table 1002 ... Resource number 1003 ... Shared variable name 1004 ... Block number where shared resource is declared 1006 ... Monitor type procedure execution code 1203 ... Argument list 1401 ... Stack usage history 1501 ... Data structure 1502 ... Command 1503 ... Processor number 1504 ... Process number 1506 ... Data length 1507 ... Object code 1508 ... Stack initialization data 1509 ... Table initialization data 1511 ... Status code 1701 ... Runtime processor Management table 1702 ... Process 1706 ... Code area 1707 ... Stack area 1708 ... Instruction pointer 1709 ... Stack pointer 1801 ... Instruction word analysis processing 180 ... scheduler 1804 ... predicate expansion processing 1808 ... other intermediate language interpreter

Claims (1)

[Claims] 1. A means for instructing exclusive control by analyzing a program description that causes access to at least shared memory resource allocation, and a means for performing a processor allocation by analyzing a description for a program processing unit capable of parallel processing. And an interpreting mechanism for executing the intermediate language output by the compiling mechanism, and a mechanism for dynamically allocating processing blocks for parallel execution realized by the interpreting mechanism. And a multiprocessor processing device.