JPH10177559A - Device, method, and system for processing data - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method and system for commonly using result data in a multiprocessor computer system. SOLUTION: A multiprocessor computer system incorporates a plurality of processors and each processor incorporates an execution unit 304, a program counter 303, a result buffer 306 containing a plurality of entries which are assigned for holding the output value of the instruction executed by the execution unit 304, and an operation counter 307 which contains an operation count which is at least incremented when the instruction, the output value of which is stored in the buffer 306, is executed by the execution unit 304. The specific entry assigned in the result buffer 306 against a prescribed output value is selected as the function of the operation count when the instruction which generates a given output value is executed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to improved data processing in microprocessor computer systems.

[0002]

2. Description of the Related Art A block diagram of a conventional multiprocessor computer system is shown in FIG. 1 summarized in simplest terms. Processor 101, 111, 121
Interacts with the memory 102 via the system bus 122. A program counter 103 belonging to the processor 101 specifies the location in the memory 102 where the instruction is fetched. Instructions formatted as shown in FIG. 2 are dispatched to an execution unit 104 in the processor 101. Execution unit 104 performs an operation 201 specified by the instruction. As shown diagrammatically in FIG. 2, an input value 202 to operation 201 may be fetched from a location in memory 102 or from a location in register file 105 belonging to processor 101. Operation 201 is also illustrated schematically in FIG.
May be stored at some location in memory 102, or at some location in register file 105, or in program counter 103.

If the input value in an operation performed by a processor is the result of another instruction (ie, an output value) executed by another processor in a shared memory multiprocessor environment, the processing of the operation is more complicated. Become. First, a second processor, such as processor 111, obtains such a result in which the first processor, such as processor 101, is used as an input value.
Must first store these output values in memory 102, and then processor 101 retrieves these results from memory 102 and uses them as input values for executing instructions. Obviously, these prerequisite steps consume additional instructions and clock cycles,
Store and load these values from one processor to another. This will result in significant inefficiencies and unnecessary consumption of processor power. Also, execution of an instruction that requires the result of another executed instruction as input ensures that the first processor is actually accessing the appropriate result, rather than the previous stale value in memory 102. So that the processors are synchronized. The prior art requires complicated procedures for data management to maintain memory coherence in the system.

[0004] The inefficiency of sharing data between instructions executing on different processors in a shared memory multiprocessor configuration, while sharing data between instructions executing on the same processor, makes the algorithm inefficient. The defining style has been formed. For example, an algorithm created for a shared memory multiprocessor may reduce the performance degradation of sharing data generated by an instruction stream executing on one processor with an instruction stream executing on another processor. Carefully segmented to minimize. This data is typically shared via memory operations and synchronized via locking primitives. In contrast, algorithms created for a single processor do not have these limitations. The data produced by one instruction is shared with other instructions via a register file, high bandwidth, low latency mechanism,
Synchronized via a linear sequence of instruction execution.

[0005] The low bandwidth, high latency, high overhead parallelism provided by shared memory multiprocessors is not suitable for exploiting the fine-grained instruction level parallelism (ILP) inherent in many algorithms, Processor creators have taken other approaches to constructing systems that perform these algorithms efficiently. By employing pipeline technology, multiple execution units and sophisticated hardware and software instruction scheduling techniques, they achieve parallel execution of instructions found in a single instruction stream on a single processor ( They share data via register files), and provided a means to efficiently execute the algorithm indicating ILP.

[0006]

Unfortunately, two disadvantages limit the overall effectiveness of such an approach.
The first disadvantage is an increase in processor complexity. As simple processors, which execute one instruction at a time in program order, are extended to execute more than one instruction at a time, their scheduling, number of circuits, silicon area, circuit Complexity, test complexity, development time, risk and development costs all increase dramatically.

A second disadvantage is due to the fact that not all algorithms can take advantage of the computational bandwidth provided by a single processor capable of executing multiple instructions in parallel.
In other words, these algorithms tend to run efficiently on simple processors that can execute one instruction at a time, much as they do on complex processors that can execute multiple instructions at a time. Furthermore, many such algorithms can typically be scaled nicely when executed in a multiprocessor environment.

Conventionally, therefore, the ideal execution environment for the first class of algorithms is a single complex processor which can execute a plurality of instructions at a time and requires a high development cost. The ideal execution environment for the algorithm was a shared-memory or distributed-memory multiprocessor configuration, including multiple inexpensive and simple processors that could execute one instruction at a time.

[0009]

SUMMARY OF THE INVENTION The present invention provides a multiprocessor computer system including a plurality of processors, each processor having an execution unit, a program counter, and an output value of an instruction executed by the execution unit. And an operation counter that includes an operation count that is at least incremented when an instruction that stores an output value in the result buffer is executed by the execution unit. The particular entry assigned in the result buffer for a given output value is selected as a function of the operation count when the instruction that produces that given output value is executed.
Each processor further includes a decoder that extracts a processor identifier from the executed instruction that identifies one of the plurality of processors, and one or more input values of the instruction are retrieved from a result buffer of the identified processor. Each decoder also extracts a quantile from the executed instruction. This quantile provides the relative difference between the current operation count of the executing processor and the expected operation count of the identified processor when the desired input value is stored in the identified processor's result buffer. The decoder generates an access key as a function of the quantile value and the current operation count of the processor executing the instruction, and the input value from an entry in the result buffer of the identified processor, indexed by the access key. Take out. The above and additional objects, features and advantages of the present invention will become apparent from the following detailed description.

[0010]

DESCRIPTION OF THE PREFERRED EMBODIMENTS The emerging semiconductor technology makes it possible to package an increasing number of circuits on a single chip. By placing multiple logical entities on the same chip instead of different chips, processor creators can take advantage of a significant increase in data bandwidth as well as reduced latency. By placing the entire complex processor on a single chip, processor manufacturers have greatly improved the state of the art. As density increases, more complex single-chip processors can be developed at greater cost, while experiencing reduced performance gains.

However, by utilizing the high density in another manner, it is possible to package multiple simple processors on a single chip, a cost-effective solution to the second class of algorithms described above. Can be provided.

The present invention takes advantage of the significant increase in data bandwidth provided by placing multiple simple processors on a single chip. This extends the instruction set architecture to provide a multiprocessor data sharing and synchronization mechanism that exhibits high bandwidth and low latency register files. Since the present invention employs a simple processor multiprocessor configuration as a starting point, the embodiment can execute the second class of algorithms cost-effectively without modification.

However, embodiments of the present invention, which are usually described by a single instruction stream and which exhibit high ILP, can also efficiently execute the first class of algorithms described above. This is accomplished by recompiling the algorithm into multiple or distributed concurrent instruction streams. These instruction streams communicate with each other via the extensions described above and provide the high performance of the algorithm when executed simultaneously on multiple simple processors in the configuration. Similar performance is obtained by using multiple simple processors communicating via the present invention instead of a single complex processor, as shown in the preferred embodiment.

Alternatively, embodiments of the present invention may implement a completely new instruction set architecture instead of extending an existing instruction set architecture. Such an embodiment may further reduce the complexity of the processor design by using the mechanism of the present invention to replace, rather than augment, the register file found in most instruction set architectures.

Referring to FIG. 3, there is shown an integrated multiprocessor computer system according to a preferred embodiment of the present invention. Each processor 301, 312, 321 of a symmetric multiprocessor (SMP) system has a program counter 303, an execution unit 304, a register
File 305, result buffer 306, operation counter 3
07 and a decoder 308. The system of the present invention is preferably implemented on a single chip integrated circuit. Because
By using such a design, the required bandwidth,
Because it is more easily obtained. System bus 32
2 is a memory 302 and processors 301, 312, and 32
1 are interconnected. The addition of result buffers and operation counters within each processor facilitates processing of data within a multiprocessor. This is processor 301,
Achieved by providing a mechanism that allows the 312, 321 to simultaneously process related instructions and share data with very high bandwidth and very low latency, thereby enabling simultaneous input instructions. Means are provided for executing the stream. Thus, the multiprocessor system of the present invention utilizes an existing SMP workload as a SMP system without recompiling or utilizing a dramatically increased interprocessor communication bandwidth,
It can act as an ILP processing system that processes a single instruction stream that is recompiled into multiple concurrent instruction streams, as if the multiple processors were a single, complex superscalar processor.

A single instruction stream indicative of the IPL to act as an IPL processing system is partitioned by a computer compiler into multiple instruction streams, which are communicated via an instruction set architecture extension described below. These multiple streams, when executed concurrently by the dispatcher of the kernel on multiple simple processors 301, 312, 321, gain processing speeds approaching the performance of a single complex superscalar processor. As shown in FIG. 4, instructions decoded by decoder 308 and used by the multiprocessor system of the present invention may specify that output 403 be stored in the result buffer of the executing processor. Other options include storing the output in a processor register file or program counter or memory.
Also, as can be seen from FIG. 4, the instructions used by the present invention may specify that the input value 402 be fetched from the remote processor's result buffer, as well as any other fetches from memory or the processor register file. There is a choice.

The operation counter 307 includes the execution unit 30
4 includes an operation count that provides a unique numeric count value for each instruction or group of instructions executed.
Operation counter 307 is incremented when a particular instruction is executed by the processor. As will be described in detail below, the operation counter 307 is incremented at least when an instruction to store the output value in the result buffer 306 is executed by the execution unit 304. Further, the operation counter 307 is transmitted to the multiprocessors 301, 312 and 321.
Is provided. As will be appreciated, depending on the particular implementation, this synchronization can be achieved in many ways. For example, in the preferred embodiment, the instruction set architecture assigns all operation counters in a particular set of processors in a multiprocessor system to an arbitrary value (and then resets the associated result buffer). The built-in synchronizes the operation counts of the various processors. In another embodiment, upon occurrence of a particular event that is not directly correlated to the execution of an instruction, a mechanism within the processor assigns all operation counters within a particular set of processors within a multiprocessor to any value (next Resets the result buffer associated with.) When the selected instruction is executed in the execution unit 304,
The operation count contained in the operation counter 307 is incremented by 1 and remains unchanged in other cases. As implemented in the preferred embodiment, upon execution of each instruction that specifies that the output be stored in the result buffer 306, the operation counter must be incremented by one.

The following describes two methods for managing the result buffer entry allocation and deallocation.
Depending on the requirements of a particular embodiment, any of these methods may be more suitable for that embodiment.

The first method (M1) shown in FIGS. 5, 6 and 7 employs a "use count". Each time a result buffer entry is allocated, the instruction producing the result placed in the entry specifies the usage count. This usage count indicates the number of times that particular result is referenced by one or more subsequent instructions. Thus, after the result has been referenced the number of times specified by the usage count, the result is no longer needed and the result buffer entry may be deallocated.

The second method (M2), shown in FIGS. 8, 9 and 10, is to limit the difference in operation counts between processors in the system so that either processor is still read by another processor. Ensure that unseen results cannot be overwritten. For example, if each processor has 16 entries in its result buffer and a given processor writes data to its result buffer at the fastest possible rate (ie, one result per operation count), then that processor will Each time the result buffer is written, when the operation count is equal to the value obtained by subtracting 16 from the current operation count, the result generated by itself is overwritten. Further, when the processor (A) can read the result from the result buffer of another processor (B) using the operation count displacement of -1 to -4, the processor (A) receives the result from the other processor (B). The result generated when (B) has an operation count equal to the processor (A) 's current operation count minus 4 can be read. Thus, if the difference between the operation counts of any two processors in the system is prevented from exceeding 11, it is impossible for one processor to overwrite a result buffer entry that has not yet been read by another processor. It is.

While method M1 facilitates greater freedom in the relative advancement of the processor, method M2 requires the need to pre-calculate usage counts, as well as referencing the results across multiple condition code paths. Simplifies the task of the compiler by eliminating the need to balance

Referring to FIG. 5, there is shown a logical configuration of the local result buffer 306 according to a preferred embodiment of the present invention. The result buffer consists of a distinct number of entries, each of which is allocated to hold an output value and deallocated when that value is no longer needed. The entry 501 to be assigned is one of a plurality of entries in the result buffer 306, and includes the stored output value 502 and the usage count 503. Given entry 50
A 1 is uniquely associated with the processor's current operation count 504 at the time the entry was assigned to the result buffer. As will be appreciated, this association can be achieved in a number of ways. When a particular operation count is uniquely associated with a particular entry and the associated operation count is included in the operation counter, such as in a direct mapped configuration, the output value may be stored only in that entry. preferable. In the preferred embodiment, the result buffer 306 functions as a direct mapped cache, with each entry in the result buffer mapped directly to a particular operation count. It uses resources that make up half of the register file. This is because the number of addressable registers is halved when executing in ILP mode, as described below. In another embodiment, the result buffer may be configured as associative memory. Usage count 503 (or reference count) is associated output value 5
02 indicates the number of times used as an input value specified by another instruction executed in another one or more processors (that is, the number of times the data is referred to in another instruction). When the usage counter is 0, this indicates that the value stored in the result buffer entry is no longer needed, and thus the entry is free for future assignment.

Referring to FIG. 6, there is shown a flow diagram of a method for processing data when an instruction specifies that its output 403 be stored in local result buffer 306 in a multiprocessor of the present invention. The process begins at step 600 and then moves to step 601 where the instructions are decoded and executed within a multi-processor processor. The executed instruction generates an output value and a usage count of that value, and increments an operation counter of the processor executing the instruction. At step 602, the processor executing the instruction attempts to allocate an entry in the resulting buffer to store the output value. The assigned entry must be associated with the current value of the processor's operation count stored in the operation counter. This allows future operations to access entries in the result buffer by regenerating the appropriate operation count and using that operation count as a key to index the result buffer. If the allocation attempt fails, then step 6
The processor stalls at 03 and retries at step 602 until it succeeds. If the allocation attempt is successful, then at step 604, the output value and usage count generated at step 601 are stored in memory. The process ends at step 605.

Referring to FIG. 7, in the multiprocessor system of the present invention, when an instruction specifies that its input 402 be fetched from an entry in the remote processor's result buffer 306, the process of processing the data. A flow diagram is shown. In fact, the term "remote processor" as used in the present invention refers to either a processor other than the processor executing the instructions, or a processor executing the instructions. The process begins at step 700 and proceeds to step 701, where the processor decodes the instruction and extracts a processor identifier (PID) and a quantile from the input field 402.
In step 702, the quantile is combined with the operation count of the processor to form an access key. Step 70
At 3, the operation count of the remote processor indicated by the processor ID in step 701 is determined. At step 704, the access key formed at step 702 is compared with the remote operation count determined at step 703. If the access key is greater than the remote operation count, at step 705, the processor stalls and retries steps 703 and 704 until the access key is below the remote operation count. If the access key is less than or equal to the remote operation count, then at step 706, the selected entry is accessed from the remote processor result buffer indicated by the processor ID using the access key formed at step 702.

Thus, the displacement value is the relative difference between the operation count during the execution of the current instruction and the operation count during which the input value retrieved from the remote processor is generated and assigned in the remote processor's result buffer. It is. The access key is calculated to give the value of the actual operation count during the generation of the remote input value.
By stopping the process (step 705) until the remote operation count is determined to be greater than or equal to the access key (step 705), the result retrieved from the remote processor's result buffer produces the desired result. Ensure that it is retrieved after it has been created, not before. Thus, the processor of the present invention prevents premature retrieval of input values from a remote result buffer before the correct result is stored in that buffer. In addition, since the operation counters of the multiprocessor system are synchronized, the access keys not only provide the operation counts at which remote results are expected to be generated, but also a remote result buffer allocated to store those results. It also provides an index pointing to the entry in. This is because the remote processor operates as described in the process flow of FIG. 6 and assigns an output value entry in relation to the processor's current operation count. The entry, indexed by the access key and accessed in the remote result buffer, allows the correct output value to be fetched from that entry by the process (step 70).
7).

At step 708, the use (reference) count associated with the accessed entry in the remote result buffer is decremented. In step 709,
When the decremented use count decreases to 0, step 7
At 10, the entry in the remote result buffer is deallocated from the result buffer and may be reused by future allocations. In either case, the instruction in the direct processor requesting the remote result as an input value is
Is executed in step 711 by using the output value extracted as an input from. Thereafter, the process proceeds to step 71.
End with 2.

FIG. 8, FIG. 9 and FIG.
5, 6 and 7 in that a second method (M2) for managing entry allocation and deallocation is shown. This method does not require a usage count to be associated with each result buffer entry. In most respects, FIGS. 8, 9 and 10 show the same behavior as FIGS. 5, 6 and 7, and the numbering of the reference numbers used in FIGS. , And correspond to the numbering used in FIGS. Since the description of all of these figures is redundant, only the differences between FIGS. 8, 9 and 10 and the corresponding FIGS. 5, 6 and 7 will be described below. Therefore, all parts not described below should be assumed to be the same as corresponding elements in FIGS. 5, 6 and 7.

Referring to FIG. 8, method M2 differs from method M1 in that the result buffer entry does not include a usage count.
And different. In method M2, the instruction that produces the result written to the result buffer does not specify a use count. Thus, the usage count is not written to the result buffer entry, and the result buffer entry does not include a mechanism to keep the usage count.

Referring to FIG. 9, method M2 differs from method M1 as follows. At step 901, the instruction does not generate a usage count as in step 601. In step 902, the operation count of the current processor is compared with the operation counts of other processors. Let OCD be the difference between the operation count of the current processor and the operation count of the processor with the lowest operation count. Let D be the largest absolute displacement that can be used when generating the key in step 702 of FIG. For example, if the displacement field ranges from -1 to -4, D is 4. R
Let E be the number of entries found in each processor's result buffer. Given the values of OCD, D, and RE, step 902 behaves as follows. That is, if the sum of OCD and D is less than RE, an entry is allocated and control transfers to step 904. Otherwise, no entry is assigned and control returns to step 90
Move to 3. At step 904, unlike step 604, the usage count is not stored in the newly allocated result buffer entry.

Referring to FIG. 10, method M2 differs from method M1 in that the manipulation of the usage count and the deallocation of the result buffer entry performed in steps 708, 709 and 710 of FIG. 7 are not performed. Conversely, Method M
In step 2, as shown in FIG.
The process directly proceeds from step 07 to step 1011. This is due to the fact that in method M2, instructions that read values from a result buffer entry do not actively participate in deallocation of that entry. Conversely, an entry is implicitly deallocated when its associated operation count falls outside the range of operation counts that can be generated by any processor that forms the key as shown in step 702 of FIG.

Example Instruction Set Architecture: To illustrate the present invention, an example of a computer instruction set architecture that functions in the present invention will be described. First, a temporary computer instruction set architecture (A) showing the prior art will be described. next,
An example of a program fragment is coded for a conventional tentative architecture (A), describing how the program fragment is executed on a number of conventional computers. Next, the provisional architecture is extended (A ') to function in the multiprocessor system of the preferred embodiment of the present invention. Next, an example of a program fragment is shown to be re-encoded in the extended computer instruction set architecture (A ') of the preferred embodiment of the present invention, and in accordance with the present invention,
It is described that the re-encoded program fragment is executed on an example of a multiprocessor computer system.

The provisional computer instruction set architecture (A) is a stored program machine that has addressable memory (M) and 32 high-speed buffers used to hold data values, ie, general purpose A program including a set of registers (R), a set of eight high-speed buffers (CR) used to hold condition codes, and a memory address (in M) of an instruction (I) to be executed next・ It has a counter (PC). Instruction (I) types fall into several classes as follows. 1. ALU (arithmetic logic operation) instruction. This instruction is encoded by using an operation code (for example, addition, subtraction, multiplication, etc.) and 2
One input register name (i.e., 2 of 32 general purpose registers from which data values serving as inputs to the operation are taken)
Two 5-bit values), and one output register name (indicating a register in which the data value generated by the operation is located). 2. ALU / immediate instruction. This is the same as the ALU instruction, except that one of the input register names is replaced by an immediate data value encoded directly in the instruction. 3. Load instruction. The encoding of this instruction consists of an operation code,
The displacement value, one input register name (the displacement and data value in the nominated input register are added together to specify the name of the memory location from which the data value is to be retrieved), and one output register name (from memory Indicates the register where the fetched value is located). 4. Store instruction. The encoding of this instruction consists of an operation code,
The displacement value, one input register name (the displacement and data value in the nominated input register are added together to specify the name of the memory location where the data value is located) and another input register name (memory Indicates the register from which the data value located is located. 5. Test instruction. The encoding of this instruction consists of an operation code specifying a logical test, two input register names indicating registers whose data values are compared, and one output condition code register (CR) name (eight condition codes. Which of the slots is set to indicate the result of the test). 6. Test / immediate instructions. This is the same as the test instruction, except that one of the input register names is replaced by an immediate data value encoded directly in the instruction. 7. Flow control instructions. The encoding of this instruction comprises an opcode specifying a criterion for the PC to be set to point to a new location in memory, an input condition code register name containing a value according to the criterion, and If so, specifying the new location in memory where the next instruction will be fetched.

The following defines a program fragment created for the Temporary Computer Instruction Set Architecture (A). The mixture of assembler mnemonics and pseudo-code is the behavior of the algorithm,
And machine language instructions to implement the algorithm. These will be readily understood by those skilled in the art. The ID associated with a given instruction is used later to briefly refer to that particular instruction.

[Table 1] O. Execution Timing: Due to the complexity introduced into instruction execution timing due to factors such as cache misses, branch prediction and speculative execution, the timing shown in the example here assumes the following simplified assumption. That is,
a) All loads, stores and instruction fetches will hit in the cache, thus not causing stall cycles.
b) Flow control dependencies should be resolved before execution proceeds, thereby eliminating factors normally associated with branch prediction and speculative execution. However, the effects of all these factors are discussed when the timings of (A) and (A ') are compared. The unconditional branch (I24) is folded, causing no penalty and imposing no dependencies. Due to the fact that there are multiple possible execution paths for a program fragment, only one is shown here, the main loop (I11 to I30) repeats twice, and during the first iteration (I20 ) Following the non-branching path to (I20) during the second iteration.

The execution timing of the example program fragment will be described in connection with two conventional computer configurations that implement the computer instruction set architecture (A). One structure is called "simple" and has one execution unit and one per cycle.
The instructions must be executable and the instructions must be executed in the order in which they are fetched from memory. The other, called the "complex", has multiple execution units, can execute four instructions per cycle (for example) in any order, and can execute instructions during a given cycle in order to execute them. All data and flow control dependencies obey only the restrictions that must be satisfied during or prior to the previous cycle.

[Table 2]

[0036]

[Table 3]

In this example, the simple technique of (A) requires 44 cycles to execute a program fragment, while the complex technique requires only 20 cycles. Thus, configuring a complex machine provides a performance advantage in executing an algorithm that exhibits ILP behavior similar to that represented by this code fragment. This advantage is somewhat reduced when finite memory effects are considered, but the trend in the industry is for computer manufacturers to justify the large risks and expenditures involved in developing complex processors. In the next section, we will show how the present invention provides some of the performance benefits of a complex machine while enjoying the low design cost and complexity of a simple machine.

The present invention can be implemented as a new instruction set architecture or as an extension of an existing instruction set architecture. The former provides flexible functionality with a greatly simplified basic machine configuration, while the latter cooperates with multiple processors in the SMP configuration of the architecture to solve single-thread problems more quickly. Make it possible. The present invention describes the latter,
The architecture (A ') is generated by incorporating the features of the present invention into the hypothetical computer instruction set architecture (A). Also, the result buffer management method M1
The preferred embodiment incorporates method M1 to elaborate on the additional programming requirements imposed by.

As shown in FIG. 4, the output of an instruction can be routed to the result buffer of the processor, and the input of the instruction can be from the result buffer of the processor in which the instruction is being executed, or of the remote processor. Instruction encoding is extended so that it can be routed from the result buffer. This embodiment uses (5-bit name) instructions to address registers as inputs or outputs,
The instruction set is extended to specify either 1) one of the 16 general purpose registers or 2) one of the result buffers as input or output. It should also be noted that the present invention provides a means to ensure that only one output is written to the result buffer per operation count, and thus in this case per instruction. As described above, an entry in the result buffer is logically associated with the processor's operation count when data for that entry is stored in the result buffer. In the preferred embodiment, there are 16 result buffer entries, which are round robin 16
Associated with the operation count. Thus, when the next operation count occurs, the result data is stored in the first entry of the result buffer (assuming the previous data usage count has reached zero). Instructions that modify more than one general purpose register, such as a LOAD instruction that automatically updates the index register, may write only one output to the result buffer. The encoding of the input / output operations of the preferred embodiment is shown below.

[Table 4] 5-bit operation input / output encoding in (A): Input: 'RRRRR': Designates one of 32 registers via RRRRR. Output: 'RRRRR': One of 32 registers is specified via RRRRR. 5-bit operation input / output encoding in (A '): Input:' 0RRRR ': One of 16 registers is specified via RRRR. '1PPDD': Specifies the result buffer in one of the four processors via PP. Specify operation count displacement (-4 to -1) via DD. Output: '0RRRR': One of 16 registers is specified via RRRR. '1CCCC': Specifies the local processor result buffer. Specify the result usage count (0 to 15) via CCCC.

Although this effectively halves the number of general purpose registers available to processors of existing designs, the present invention is similar to processors that have traditionally been enjoyed only when interacting with a local register file. The high bandwidth provides the ability to communicate with each other in a buffered manner. Alternatively, the functionality of the present invention may be implemented by adding a result buffer register to the processor design.

For simplicity, it is assumed that the temporary machine in this example does not provide a file of floating point registers as in most machines. However, it is clear that the same technique of using general-purpose register encoding as a general-purpose result buffer is also applicable to floating-point register encoding and floating-point result buffers. Similarly, the hypothetical machine described herein specifies that the test instruction results be directed to one of eight condition code registers, and that the flow control instructions read input from these registers. As general register encoding is extended by the present invention, condition code register encoding can be extended as well.

[Table 5] 3-bit operation input / output encoding in (A): Input: 'RRR': One of eight CRs is specified via RRR. Output: 'RRR': One of the eight CRs is specified via RRR. 3-bit operation input / output encoding in (A '): Input:' 0RR ': Designates one of four CRs via RR. '1PP': Specify the result buffer in one of the four processors via PP. Specify operation count displacement -1. Output: '0RR': One of the four CRs is specified via RR. '1CC': Specifies the result buffer of the local processor. Specify the result usage count (0 to 3) via CC.

The processor field (which selects one of the four processors in this embodiment) does not actually limit the total number of processors interconnected according to the present invention. Conversely, this limits a single processor to only be able to interact directly with its neighbors (one of which may be the processor itself). By changing the embodiment, it is possible to realize an inter-processor connection topology suitable for specific needs. In order to more effectively teach the present invention, this embodiment employs a simple topology. Although the present invention does not preclude the use of an unlimited number of processors, for simplicity, the present embodiment restricts the compiler to distribute a given program to four virtual processors. This is by mapping each virtual processor directly to one of the four physical processors. Thus, the two bits (PP) described above provide a means to nominate one of the four physical processors in the SMP (in fact, the present invention does not require shared memory and has a processor with dedicated memory). May be used in some applications).

The encodings shown here are very arbitrary and are only provided as examples for a better understanding of the invention. Thus, the encoding and architecture of this example does not limit the scope of the invention, but is provided for illustrative purposes only.

As described above, various embodiments may increment the operation count under different circumstances, provided that the operation count is incremented at least each time a result is written to the result buffer.

Modifications of the embodiment of the present invention include the following. a) Increment the operation count upon execution of every single instruction. b) Increment the operation count only during execution of the instruction that writes the result to the result buffer. c) Read the one or more input values from the result buffer or increment the operation count only when executing an instruction that writes the result to the result buffer. d) When executing instructions, a flag indicating whether or not to increment the operation count is encoded in each instruction. e) Encode within each instruction a field that specifies the offset (0-n) to be added to the operation count when the instruction is executed. f) Incorporate into the instruction set architecture multiple modes of operation that can employ one of the variants described above.

Those skilled in the art will note the following. That is, the ability to associate a group of instructions of any size with a given operation count is a feature of the machine (because the processor cannot allocate a result buffer to store output values or to store output values). Associated with the processor being able to proceed at any speed through the operation count, unless stopped)
A means is provided for the processor to advance while their neighbors fail due to unpredictable execution time factors such as cache misses or mispredicted branches. This asynchronous nature of the present invention is, for example, VLIW
Synchronous (or lock-step) ILP that can cause any instruction in a group to be executed synchronously, such as (very long instruction word) to stall and to stall all other instructions in the group There is a clear advantage over implementation techniques.

Although the programmer views the operation count as a value that can grow without bound, the hardware technique represents the operation count by a small number of bits, and when it exceeds the maximum value, "rolls over" to zero. Is allowed to do so. The exact value of the operation count is not at all important, because it is the value of the operation count relative to the operation counts of other processors in the system. Since the relative difference between the operation counts of any two processors is limited by data dependencies and buffer allocation,
There is a known maximum distance between the operation counts of any two processors in the system. As long as this distance is represented by a given hardware technique of the operation counter, that technique will work correctly.

For simplicity, in this embodiment, each time the processor executes an instruction, its operation count is incremented.
This, of course, means that each processor must execute the same number of instructions to maintain "synchronization," and therefore the compiler may need to use several nops (NO -OP) instruction must be inserted.

As mentioned above, the correct embodiment of the invention is:
It requires certain means to put them in a known state so that the processors can communicate properly with each other. To this end, the present embodiment provides a single new user
A level instruction, one new supervisor-level instruction, and one new exception type are introduced as follows.

The SPAWN instruction is one of four processors.
And the instruction address. If the specified processor is the same as the processor executing the SPAWN instruction, the operation count of that processor is set to 0;
As a result, the buffer is cleared (ie, all reference counts are set to zero) and its program counter (PC) is set to begin fetching instructions from the newly specified instruction address. If the designated processor (PS) is different from the processor (PE) executing the SPAWN instruction, the PS operation count (OC) is set to that of the PE, the PS result buffer is cleared, and the PS The PC is set to start fetching instructions from the newly specified instruction address.

[0051] By using the SPAWN instruction, the instruction sequence being executed by a processor becomes:
Execution of the instruction sequence on another processor can be initiated and synchronized with. By repeating this process, all processors can begin executing concurrently dependent instruction sequences simultaneously.

The PREEMPT instruction is a supervisor-level instruction. This specifies the processor where the PREEMPT exception is issued. It is designed so that the kernel dispatcher can cause a task switch on all processors running concurrently dependent threads.

The PREEMPT exception, like any exception, causes the interrupted processor to stop executing instructions from its current instruction stream and begin executing the instruction pointed to by the exception vector. As described above, this occurs when another processor executes the PREEMPT instruction, and all concurrent dependent threads making up the task are
Designed to ensure that they can be switched in harmony by the dispatcher.

Example Program Fragment Recoded in Extended ISA (A ') of the Invention: The following is an example of a program fragment encoded to be executed in a preferred embodiment of the multiprocessor of the invention. Is shown. Additional extensions are defined to the standard set of pseudo-coded assembler mnemonics used in the previous example. These extensions provide the programmer with a means to represent the extensions available in (A ') in mnemonic form.

[Table 6]

[Table 7]

[0056]

[Table 8]

[0057]

[Table 9]

[0058]

[Table 10]

A number of instructions appear in the recoded coinciding program fragment that did not appear in the original fragment. In addition, some instructions appearing in the original fragment may appear in more than one re-encoded fragment. Next, a brief description will be given.

The SPAWN instruction at the beginning of the Processor 0 and Processor 1 fragments initializes and synchronizes four simultaneous input instruction streams.

Instruction I20 in original fragment
The condition paths starting with are slightly re-encoded (while maintaining the equivalent function), simplifying the distribution of the stream. In addition to the exceptions associated with this re-encoding, flow control instructions from the original fragment may be found in every re-encoded fragment. This is logical. This is because all four concurrent programs must follow a similar flow control path to maintain "synchronization" with each other.

A result buffer is used to enable communication between the four concurrent programs, but some of the data passing through the result buffer has a more permanent nature and may be used for future use. Have to be moved to a general purpose register. To this end, some instructions are added simply to transfer data values from the result buffer to general purpose registers.

As noted above, this embodiment (shown for ease of understanding) increments the processor's operation count upon execution of any instruction, so in this particular embodiment, each concurrent input code -It is necessary to include multiple Knop instructions to ensure that the fragment executes the same number of instructions and maintains the same operation count as the others.

Finally, since the data written to the result buffer must be consumed by a given number of future instructions (indicated by the usage count), the instructions IL and IN, which normally do not consume values, are conditional. Added to the path, ensuring that they are actually consumed the correct number of times (guaranteed that the usage count reaches zero). Note that embodiments incorporating the result buffer management method M2 do not have a usage count and therefore do not comply with such requirements.

Execution Timing: Next, when four simultaneous input program fragments are executed simultaneously on the four "simple" processors of the SMP, which is extended as defined by this embodiment. The execution behavior for each cycle will be described. The timing shown here assumes the same simplification as the previous timing example and shows the code following the same execution path as the previous timing example.

[Table 11]

As can be seen from the above example, the conventional ISA (A) simple technique of spending 44 cycles executing a program fragment,
Expanded to (A ') and the program fragment is divided into four processors (each of (A') according to the preferred embodiment.
When distributed between (a simple technique as), it takes 24 cycles to execute a distributed program fragment (including a one-time synchronization instruction that is executed beforehand). This is very close to the 20 cycle execution time for the complex technique of (A) (ie, superscalar processor).

Looking more closely at unpredictable stall conditions due to cache misses, mispredicted branches, and other factors, embodiments of the present invention, by virtue of their asynchronous nature, cause out-of-order execution. It has the same performance characteristics as most superscalar processors that support That is, they continue to perform as much work as possible, despite the fact that one instruction has been disabled.

For example, in this embodiment, all four instruction streams may execute a load instruction during the same cycle. If any of the four miss the cache, the other three can continue execution of the still following instructions (provided, of course, that there is no dependency on the stalled instruction stream). Therefore,
The other three instruction streams continue executing instructions, some of which may be load instructions that can hit or miss the cache. These behaviors are
Equivalent to the behavior of a single "complex" processor that continues to execute independent instructions out of order after encountering a miss.

In the case of a mispredicted branch instruction, a plurality of concurrently executed branches in a concurrent input stream executed on the SMP extended as defined by this embodiment Incurs the same penalties that occur in predicting "complex" processors.

Alternatively, according to the technique taught in the present invention,
Using the SPAWN instruction to generate a second stream of instructions following the conditional branch, executing both branch and non-branch paths simultaneously until the condition is resolved;
At that point, one of the streams may be terminated. Such an approach mimics the very high performance of speculative execution found in certain "complex" processors.

Although the present invention has been particularly described with reference to preferred embodiments, workers skilled in the art will recognize that various changes may be made in form and detail without departing from the spirit and scope of the invention. It will be understood that

In summary, the following items are disclosed regarding the configuration of the present invention.

(1) An execution unit for executing an instruction for generating an output value, a result buffer including a plurality of entries allocated to hold an output value of the instruction executed by the execution unit, When the instructions stored in the result buffer are executed by the execution unit,
An operation counter that includes at least an operation count that is incremented, wherein a particular entry assigned in the result buffer for a given output value is such that when the instruction that produces the given output value is executed, And an operation counter selected in response to the operation count. (2) An input wherein each output value in the result buffer is stored in association with a usage count, wherein the usage count is specified by another instruction whose associated output value is executed in another one or more devices. The data processing device according to the above (1), wherein the data processing device indicates the number of times of use. And (3) a decoder for extracting, from the instructions executed by the execution unit, a device identifier identifying one of a plurality of devices, wherein one or more input values of the instructions are a result buffer of the identified device. The data processing device according to the above (1), which is extracted from the data processing device. (4) the decoder extracts a displacement value from the instruction executed by the execution unit, wherein the displacement value is an operation count of a device executing the instruction and the result buffer of the identified device; Providing a relative difference with an expected operation count of the identified device associated with an entry of the one or more input values in the decoder, wherein the decoder operates the device to execute the displacement values and the instructions. The data processing device of claim 3, wherein in response to the count, an access key is generated and an input value is retrieved from an entry associated with the access key in the result buffer of the identified device. (5) The data processing device according to (4), wherein the displacement value is limited to be smaller than a selected amount. (6) including a plurality of processors, wherein each of the processors includes:
An execution unit for executing an instruction to generate an output value using one or more inputs; a result buffer including a plurality of entries allocated to hold an output value of the instruction executed by the execution unit; An operation counter including at least an operation count that is incremented when an instruction that stores a value in the result buffer is executed by the execution unit, the identification being assigned in the result buffer for a given output value. A plurality of entries from an operation counter and an instruction executed by the execution unit, wherein the plurality of processors are selected in response to the operation count when an instruction to generate the given output value is executed. A decoder that extracts a processor identifier identifying one of the instructions, wherein one or more input values of the instruction are associated with the identified processor. Is taken out from the serial result buffer,
A multiprocessor computer including a decoder
system. (7) each output value in the result buffer is stored in association with a usage count, wherein the usage count is specified by another instruction whose associated output value is executed in at least one other of the plurality of processors. The multiprocessor computer system according to (6), wherein the multiprocessor computer system indicates the number of times used as an input. (8) each of the decoders extracts a displacement value from the instruction executed by the execution unit, wherein the displacement value is an operation count of a processor executing the instruction and the result of the identified processor; Providing a relative difference with an expected operation count of the identified processor, associated with an entry of one or more input values in a buffer, wherein the decoder operates the processor to execute the instructions and the displacement values. The multiprocessor of claim 6, further comprising: generating an access key in response to the count; and retrieving an input value from an entry associated with the access key in the result buffer of the identified processor.
system. (9) The multiprocessor computer system according to (8), wherein the displacement value is limited to less than a selected amount. (10) The multiprocessor system according to (6), including a shared memory accessible by the plurality of processors. (11) A method for processing data in a data processing system, the method comprising: executing an instruction to generate an output value stored in a result buffer; incrementing an operation count; Storing the entries in an entry, wherein the entries are associated with an incremented operation count;
Including, methods. (12) generating a usage count stored in the result buffer in association with the output value, wherein the usage count is associated with another instruction whose associated output value is executed in at least one other processor. The method according to (11) above, wherein the method indicates the number of times used as an input specified by. (13) decoding the instruction before the instruction is executed, and extracting a processor identifier identifying one of a plurality of processors, wherein one or more input values of the instruction are the identified The method of claim 11, wherein the method is retrieved from the result buffer of a processor. (14) the identified processor, wherein the decoding step is associated with an operation count of a processor executing the instruction and an entry of the one or more input values in the result buffer of the identified processor. Extracting a displacement value that provides a relative difference from the expected operation count of the processor, the decoding step further generating an access key as a function of the displacement value and an operation count of the processor executing the instruction. The method of (13), further comprising retrieving an input value from an entry associated with the access key in the result buffer of the identified processor. (15) The method according to (14), including the step of preventing the displacement value from exceeding a selected amount. (16) A method for storing a result in a multiprocessing system having a plurality of processors, the method comprising: executing an instruction for generating a result in one of the plurality of processors; and an operation count associated with the processor. Incrementing, wherein the result is uniquely identified by association with the processor and the incremented operation count, and storing the result in the multiprocessing system. By a particular identification, wherein the result is defined by the processor and the incremented operation count, by any processor of the plurality of processors;
Storing in a storage device. (17) generating a usage count that is stored in association with the result, wherein the usage count is specified by other instructions executed in one or more of the plurality of processors. (16). The method according to (16), wherein the number of times used as an input is indicated. (18) The operation count of the plurality of processors is:
Preventing the selected amount from being exceeded.
The method according to the above (16).

[Brief description of the drawings]

FIG. 1 is a block diagram of a conventional multiprocessor computer system, summarized in simplest terms.

FIG. 2 is a diagram showing a conventional instruction execution format in a conventional multiprocessor.

FIG. 3 illustrates an integrated multiprocessor computer system according to an embodiment of the present invention.

FIG. 4 is a diagram showing an execution format of an instruction according to a preferred embodiment of the present invention;

FIG. 5 is a diagram illustrating a logical configuration of a local result buffer according to a preferred embodiment of the present invention.

FIG. 6 is a flow diagram of a method for processing data within a multiprocessor of the present invention when an instruction specifies that its output be stored in a local result buffer.

FIG. 7 processes data in a multiprocessor system of the present invention when an instruction specifies that its input be fetched from an entry in a remote processor result buffer in accordance with a preferred embodiment of the present invention. It is a flowchart of a process.

FIG. 8 illustrates another embodiment of the result buffer of FIG. 5, wherein storage of the usage count is removed.

FIG. 9 illustrates another embodiment of the data processing method shown in FIG. 6, where the need for a usage count is eliminated.

FIG. 10 illustrates another embodiment of the data processing method shown in FIG. 7, in which the need for a usage count is eliminated.

[Explanation of symbols]

101, 111, 121, 301, 312, 321 processor 102, 302 memory 103, 303 program counter 104, 304 execution unit 105, 305 register file 122, 322 system bus 201 operation 202, 402 input value 203, 403, 502 Output value 306 Result buffer 307 Operation counter 308 Decoder 501, 801 Entry 503 Usage count 504 Current operation count

Claims (18)

[Claims] An execution unit for executing an instruction to generate an output value; a result buffer including a plurality of entries allocated to hold an output value of the instruction executed by the execution unit; An operation counter that includes at least an incremented operation count when instructions stored in a buffer are executed by the execution unit, wherein a particular entry assigned in the result buffer for a given output value is An operation counter selected in response to the operation count when an instruction to generate a given output value is executed. 2. The method of claim 1, wherein each output value in the result buffer is stored in association with a usage count, wherein the usage count is specified by another instruction whose associated output value is executed in another one or more devices. 2. The data processing apparatus according to claim 1, wherein the data processing apparatus indicates a number of times used as an input. 3. A decoder for extracting a device identifier identifying one of a plurality of devices from an instruction executed by the execution unit, wherein one or more input values of the instruction are associated with the identified device. 2. The method of claim 1, wherein the information is retrieved from a result buffer.
The data processing device according to claim 1. 4. The decoder extracts a displacement value from the instruction executed by the execution unit, wherein the displacement value is an operation count of a device executing the instruction and the operation count of the identified device. An apparatus for providing a relative difference with an expected operation count of the identified device associated with an entry of the one or more input values in a result buffer, wherein the decoder executes the instruction with the displacement value. 4. The data processing apparatus according to claim 3, further comprising: generating an access key in response to the operation count of the input device; and retrieving an input value from an entry associated with the access key in the result buffer of the identified device. 5. The data processing apparatus according to claim 4, wherein said displacement value is limited to be smaller than a selected amount. 6. An execution unit including a plurality of processors, each of said processors executing an instruction to generate an output value using one or more inputs, and an output unit of an instruction executed by the execution unit. A result buffer including a plurality of entries allocated for holding; and an operation counter including at least an operation count that is incremented when an instruction to store an output value in the result buffer is executed by the execution unit. An operation counter, for a given output value, a particular entry assigned in the result buffer is selected in response to the operation count when an instruction to generate the given output value is executed. And a processor for extracting, from the instructions executed by the execution unit, a processor identifier identifying one of the plurality of processors. A decoder, wherein one or more input values of the instruction are retrieved from the result buffer of the identified processor. 7. Each output value in said result buffer is stored in association with a usage count, said usage count being determined by another instruction whose associated output value is executed in at least one of said plurality of processors. 7. The multiprocessor computer system of claim 6, indicating a number of times to be used as a designated input. 8. Each of the decoders extracts a displacement value from the instruction executed by the execution unit, wherein the displacement value is an operation count of a processor executing the instruction, and an operation count of the identified processor. Providing a relative difference with an expected operation count of the identified processor associated with one or more input value entries in the result buffer;
An entry associated with the access key in the result buffer of the identified processor, wherein the decoder generates an access key in response to the displacement value and an operation count of the processor executing the instruction. 7. The multiprocessor system according to claim 6, wherein an input value is obtained from the multiprocessor. 9. The multiprocessor computer system according to claim 8, wherein said displacement value is limited to less than a selected amount. 10. The multiprocessor of claim 6, further comprising a shared memory accessible by said plurality of processors.
system. 11. A method of processing data in a data processing system, the method comprising: executing an instruction to generate an output value stored in a result buffer; incrementing an operation count; Storing the entries in a result buffer, wherein the entries are associated with an incremented operation count. 12. The method of claim 11, further comprising generating a usage count stored in the result buffer in association with the output value, wherein the usage count is performed in at least one other processor. 12. The method of claim 11, wherein the method indicates a number of times used as an input specified by the instruction. 13. The method of claim 1, further comprising the step of: decoding the instruction before the instruction is executed; and extracting a processor identifier identifying one of the plurality of processors, wherein one or more input values of the instruction include the identification value. 12. The method of claim 11, wherein the result is retrieved from the result buffer of a designated processor. 14. The method of claim 14, wherein the decoding step is associated with an operation count of a processor executing the instruction and an entry of the one or more input values in the result buffer of the identified processor. Extracting a displacement value that provides a relative difference from an expected operation count of the processor, wherein the decoding step further comprises: an access key as a function of the displacement value and an operation count of the processor executing the instruction. And generating an input value from an entry associated with the access key in the result buffer of the identified processor. 15. The method of claim 14, including the step of preventing said displacement value from exceeding a selected amount. 16. A method for storing a result in a multi-processing system having a plurality of processors, the method comprising: executing an instruction to generate a result in one of the plurality of processors; and an operation associated with the processor. Incrementing a count, wherein the result is uniquely identified by association with the processor and the incremented operation count; and storing the result in the multiprocessing system. Wherein the result is accessed in a storage device by any processor of the plurality of processors with a particular identification defined by the processor and the incremented operation count. Method. 17. A method for generating a usage count stored in connection with said result, said usage count comprising:
17. The method of claim 16, wherein the associated result indicates a number of times to be used as an input specified by another instruction executed in one or more of the plurality of processors. 18. The method of claim 16, including the step of preventing the operation count of the plurality of processors from exceeding a selected amount.