JPS6160459B2 - - Google Patents

Description

[Detailed description of the invention]

The present invention relates to a data processing device that performs pipeline control, and more particularly to a data processing device that handles variable-length instructions in which an operand specifier that specifies the addressing mode of an operand is given independently from a code portion that specifies an operation. It is something. Instruction systems having variable-length operand specifiers are well known, and two typical examples are shown below. One is Burroughs Corpora.
This is the instruction format for the B1700 computer (B1700 COBOL/RPG-S-
Language，1058823−015，Copyright1973，
Burroughs Corporation”. The other one is DEC (Digital Equipment)
This is an instruction system with variable-length operand specifiers that is part of the architecture of the VAX11/780 computers of
“VAX11Architectre Handbook, Copyright
1979”. Figures 1A-D illustrate four typical addressing modes in the example of the Burroughs B1700. A is Short Literal
Indicates the operand specifier that specifies the operand address in mode, the Type field indicates the type of data (signed or not, identification of the basic length (4 bits or 8 bits) of the Literal Value field), and the "Length" Field and “Type”
field defines the length of the Literal Value field. Therefore, the Literal Value field can range from 4 bits to a maximum of 56 bits (specify 8-bit signedness in the “Type” field,
(when Length is 7). B indicates an operand specifier that specifies an operand address in the long literal mode, and is used when obtaining literal data with a length exceeding that in the short literal mode. C indicates an operand specifier that specifies the operand address in Descriptor Index mode;
The data at the address specified by the index value from the entry address of the descriptor table becomes the operand. D is an inline descriptor (Inline
Descriptor) Indicates an operand specifier that specifies the operand address in “Descriptor” mode.
The data given in the field becomes the operand. Of course, the four types of addressing modes described above are not all, and there are others. As shown in FIG. 1, the length of the operand specifier can vary. That is, Short of A
In Literal mode, the length l (bits) occupied in the instruction field of the operand specifier is l = 1 + 2 + 3 + "length" × 4 (or 8), and in B's Long Literal mode, l is l = 1 + 2 + 3 + 8 + "length" × 4 (or 8)
So, in C's Descriptor Index mode, l
becomes l=6, and in Inline Descriptor mode of D, l
becomes l=63. As described above, the above-mentioned instruction system is characterized in that the part that specifies the operand format and addressing mode is defined by a variable-length operand specifier, and is independent of the operation code. In the above instruction system, the operand addressing modes are only Literal and Descriptor, but of course addressing modes other than these addressing modes can also be considered. FIGS. 2A-2F show the format of operand specifiers for six typical addressing modes in the example of DEC's VAX11. A indicates the format of the operand specifier in literal mode, and 6 in the “Lit” field.
In this mode, bit data is the operand. B indicates the format of the operand specifier in register specification (Register) mode, and “Rn”
This is a mode in which the 4 bits of the field indicate the address of the register serving as the operand. C indicates the format of the operand specifier in register modification (Disp) mode, and is the memory address that is the sum of the contents of the register specified by the “Rn” field and the displacement section specified by the “Disp” field. This is a mode in which the data at the position is the operand. The length of the displacement section can be 16 bits or 32 bits in addition to the 8 bits shown in C. D indicates an operand specifier when index modification is added to the addressing mode of C, and the register at the address specified in the "Rx" field is added as an index register when calculating the address (Disp with Index) mode. E indicates the format of the operand specifier in the program counter relative addressing mode, and the operand is the data at the memory address that is the sum of the contents of the program counter and the displacement part specified by the "Disp" field. This is Relative mode. F indicates the format of the operand specifier in absolute mode, in which the field indicated by "Abso" indicates the memory address where the operand is located. As mentioned above, the VAX11 architecture is characterized in that the length of the operand specifier is configured with 8 bits (bytes) as the basic unit length. As a repertoire of addressing modes,
B1700 is suitable for languages such as COBOL, and VAX11
is suitable for FORTRAN, PL/I, etc. FIG. 3 shows an example of an instruction format that adopts the VAX11 addressing mode repertoire and also makes the length of the operand specifier bit variable in order to increase the efficiency of the operand specifier. Figures 3A and 3B are diagrams showing the format of an operand specifier when the operand is given as literal data. In the case of literal data of 5 bits or less, the format is Short Literal as shown in Figure 3A. In the case of literal data with a length of bits or more, the Long Literal shown in Figure 3B is used.
Take the format. FIG. 3C shows the format of the operand specifier in the register specification mode, and the register at the address specified by the "Rn" field becomes the operand. Figure 3D shows the format of the operand specifier in register modification mode, and “Rn”
It consists of a register at the address specified by the field, a "DispLen" section indicating the displacement length, and a displacement section "Disp". Figure 3E shows the format of the operand specifier in program counter relative mode.
It consists of a “DispLen” section and a “Disp” section. FIG. 3F shows the format of the operand specifier in the Absolute mode, in which the field indicated by "Abso" indicates the memory address where the operand is located. The format of the operand specifier shown in FIG. 3 is only one example of the many addressing modes, and it goes without saying that there are various other formats of operand specifiers, but these are not necessary for understanding the present invention. Since there is none, I will omit it. As mentioned above, in the example of the instruction format shown in FIGS. 1 to 3, since the addressing mode is defined for each operand, the addressing mode is not specified for the operation code (hereinafter abbreviated as "opcode") and between the operands. Mode independence is ensured. However, restrictions such as whether each operand is used as an access type, such as a read operand, a write operand, or a read and write operand, are specified by the opcode. (attribute for opcode). Therefore, each operand specifier needs to be an addressing mode that satisfies the attributes for the opcode. The access type is read, write,
Of course, there are other methods besides read and write. Furthermore, the length of the operand itself (data length) can be considered as an attribute for the opcode or specified by the operand specifier, but these differences do not affect the present invention, so An explanation of how to handle the data length will be omitted. In the above-mentioned command system, even if the opcode is the same, the length of the command word will generally vary.
Furthermore, although the field at the beginning of the instruction word is determined to be the opcode, the other parts can have various meanings, so the meaning of the field in the instruction word is not uniquely determined. Further, since the length of the operand specifier included in the instruction word changes depending on the addressing mode, the length of the instruction word takes various values even if the operation code is the same. Therefore, if an instruction decoding unit that handles such an instruction system were to take in one instruction word at a time and decode that instruction, the scale of the hardware would be enormous; It also has many drawbacks, such as the need for complex control. Another method for decoding instructions is to decide on a specific length unit and decode the instruction word by one or more unit lengths, but the basic unit is 8 bits (1 byte). In this case, the instruction length for a basic instruction is 3 to 7 bytes, so for example, if the instruction word is decoded in synchronization with the machine cycle, it will take as many machine cycles as the number of bytes of the instruction word to decode one instruction. This slows down instruction decoding, which has a big negative side in terms of speeding up processing. As described above, in a data processing device having the above-mentioned instruction system, the key is how to speed up the instruction decoding process and realize efficient pipeline processing. The present invention has been made in view of the above problems, and an object thereof is to provide a data processing device that executes variable length instructions at high speed. Another object of the present invention is to provide a data processing device that executes instructions containing any number of operand specifiers at high speed. Yet another object of the present invention is to provide a pipeline control data processing system that prepares one operand per machine cycle, regardless of the length of the operand specifier. Still another object of the present invention is to provide a pipeline control data processing device that performs pipeline processing between operands in addition to pipeline processing between instructions. Still another object of the present invention is to provide an operand specifier for an operand of an operand immediately preceding the final operand of an instruction when the addressing mode of the operand specifier of the final operand of the instruction is given as a register specification mode. An object of the present invention is to provide a data processing device that executes at high speed by simultaneously decoding the operand specifier of the final operand in the decoding cycle. The features of the present invention include: an instruction buffer means that reads and holds instructions in advance from a memory that stores variable-length instructions and operands; an instruction aligner means that extracts at least one set of operand specifiers from the instruction buffer means; an operation code decoding means for specifying an operand specifier included in an instruction extracted by the instruction aligner means and a function of the instruction; and an operand specification for decoding the operand specifier extracted by the instruction aligner means. It has a child decoding means, and prepares each different operand by decoding the operand specifier of at least one operand in one machine cycle, thereby realizing pipeline processing between multiple operands. That's true. Embodiments of the present invention will be described in detail below with reference to the drawings. FIG. 4 is a block diagram showing an embodiment of a pipeline control data processing device to which the present invention is applied. The abbreviations and official names in Figure 4 have the following relationship.

【table】

[Table] In Figure 4, main memory (MM) 301
is used to store the above-mentioned variable-length instructions and the operands handled by these instructions. Under the control of the main memory control unit (MCU) 302, it is stored in the high-speed buffer memories (BM ₁ ) 303 and (BM ₂ ) 304. Data is exchanged between the two. 320, 323, 340, and 342 are address buses, and 321, 324, 341, 343, and 410 are data buses. The instruction fetch unit (IFU) 305 sends the address of the instruction to BM ₁ 303 via a signal line 327.
The instruction word is read in advance. The instruction taken into the IFU 305 is sent to an instruction decode unit (DU) 309 via a signal line 329 in units of operation code and operand specifier, and is decoded. Address calculation unit (AU) 310
According to the addressing mode decoded at 309 (given via signal line 336),
The effective address of the operand is calculated and the result is output to the operand fetch unit (OFU) 311 via signal line 337. The OFU 311 sends the address of the operand passed from the AU 310 to the BM ₂ 30 via the signal line 330.
4 to fetch the operand in advance.
If the BM ₂ 304 has data on the address passed from the OFU 311, it immediately passes the data to the OFU 311 via the signal line 331,
If there is no data on the corresponding address
Access MM301 via MCU302,
Read the data on the address and send it to OFU31
Perform the action of passing to 1. Execution unit (EU) 312 receives operands from OFU 311 via signal line 338 and executes instructions. Here, each unit operates almost independently and performs pipeline processing between operands. Hereinafter, specific examples of the individual units of the data processing apparatus shown in FIG. 4 will be described with reference to FIGS. 5 to 9. FIG. 5 shows the configuration of the IFU 305, and the abbreviations and official names used here have the following relationship.

[Table] The main components of the IFU 305 are a fetch pointer (FP) 404 that sends the address of the instruction to be read from the BM ₁ 303, and an instruction buffer (IB) 401 that stores the data read in advance.
and _a control circuit (IF-
CONT) 403 and an incrementer (INC) 406 for incrementing the contents of FP404.
Then, the selector (SEL) 405 that selects the data to be set in the FP 404 and the instructions previously read out in the IB 401 are rearranged bit by bit in the order to be decoded next using the address 11A. Instruction aligner (ALIG)
It is 402. FIG. 6 shows an instruction decode unit (DU) 30.
9, and the abbreviations and official names used here have the following relationship.

【table】

[Table] μ program address generation circuit (ECSAG) 5
01 generates the first microprogram address 10B to be executed in the EU 312 according to the opcode given from the IFU 305 via the signal line 329. The operand information memory (DCS) 503 is
Information regarding the operand in the operation code given from the signal line 329 via the selector (SEL) 502 is stored. Operand specifier decoder (OS-DEC) 50
5 decodes the operand specifier in signal line 329. The control data generation circuit (ACIG) 504 is a DCS
503 and the information given from the OS-DEC 505, the address calculation unit (AU) 301 generates control data 336 for calculating the address of the operand. Register specification mode detection means (RD-DEC) 5
06 detects whether or not the OS following the operand specifier (OS) decoded by the OS-DEC 505 is in register specification mode. If it is in register specification mode, the address 12B of that register will be described later. Set in register (ARR) 610 in AU 310. The decode bit (byte) number calculation means (DBNC) 507 is an OS-DEC 505 and RD
-Receiving the signal from DEC506, IB401
The number of bits to be decoded in that cycle is calculated. The data aligner (D-ALIG) 508 is an OS-
If the OS to be decoded by the DEC 505 includes literal data, displacement, or absolute addresses, this is extracted and rearranged. The control circuit (D-CONT) 509 is IF-
DU3 receives signal 12A from CONT403
Controls the entire operation of 09. A register (DP) 510 indicates the first address to be decoded in that cycle. A selector (SEL) 511 selects data to be set in the DP 510. Incrementer (INC) 512 is DP510
The content 11A of is added by the number of bits of the instruction decoded in that cycle. The number of bits (bytes) required for decoding calculation means (NBNC) 513 receives the signal from the OS-DEC 505, reads it from the IB 401, and calculates the number of bits (bytes) required for decoding in that cycle. conduct. A program counter value calculation means for address calculation (TPCC) 514 calculates a program counter value necessary for performing address calculation relative to the program counter of the OS to be decoded. FIG. 7 shows the configuration of the address calculation unit (AU) 310 shown in FIG. 4, and the abbreviations and official names used here have the following relationship.

【table】

[Table] In Figure 7, register (AER) 601
holds the start address 10B of the microprogram generated by ECSAG 501 in FIG. The register (ACR) 602 is ACIG5 in FIG.
The control data 336 which is the output of 04 is held.
A decoder (A-DEC) 603 controls the overall operation of the AU 310. A flag (ACVF) 604 instructs the AU 310 to start operating. A register (ARAR) 605 stores a register address 11B that is referenced when calculating an operand address. A register file (ARF) 606 is a group of registers referenced when calculating addresses of operands. Selectors (SEL) 607 and 608 select inputs of arithmetic unit (A-ADR) 609. The A-ADR 609 performs calculations to obtain the address of the operand based on the signals selected by the SELs 607 and 608. The register (ARR) 610 is the register address 12B included in the operand specifier (OS).
hold. The register (DR) 611 holds displacement, absolute address, or literal data 13B included in the operand specifier (OS). A register (TPC) 613 holds a program counter value 16B necessary for performing program counter relative address calculation. The output 337 of the A-ADR 609 is output to the bus 410 via the bus driver 612. FIG. 8 shows the configuration of the operand fetch unit (OFU) 311 shown in FIG. 4, and the abbreviations and formal names used here have the following relationship.

【table】

[Table] In Figure 8, register (OER) 701
holds the starting address 10C of the microprogram. The register (OFCR) 702 is A- in FIG.
Holds output 11C of DEC603. A flag (OFCVF) 703 instructs the OFU 311 to start operating. Decoder (OF-DEC) 704 is OFU311
Control the entire operation. Register (MAR) 705 holds the memory address 337 of the operand. A selector (SEL) 706 selects data to be set in a register (OBR) 707. A register (OBR) 707 stores operands input via SEL 706. Data aligner (OALIG) 708 is OBR7
Sort the data in 07 and adjust the data format. Register (ORR) 709 is ARR6 in Figure 7.
The address 13C of the register given from 10 is held. Figure 9 shows the execution unit (EU) shown in Figure 4.
312, and the abbreviations and official names used here have the following relationship.

【table】

[Table] In FIG. 9, a microprogram controller (MPC) 801 controls the memory address of a microprogram memory (ECS) 802. Micro program memory 802
extracts the microprogram from the address specified by MPC 801 and sets it in microinstruction register (MIR) 803. The output of MIR803 is OF-DEC70 in Figure 8.
4. MPC801, selectors 804 and 8 to be described later
14 is output. Selectors 804 and 805 are arithmetic unit (EALU) 8
06 input data is selected. Temporary register (TR) 808 is connected to bus 4.
50 is temporarily held. A shift circuit (SHF) 809 shifts the data from the TR808 and sends the result to the bus driver 81.
0 to bus 450. The work register file (ERF) 811 is
This is a group of work registers used by the EALU 806. A general purpose register file (ERF) 812 is a group of general purpose registers also used by the EALU 806. Register (ERAR) 813 is ORR in Figure 8.
It holds the register address 11D transferred from 709. A selector (SEL) 814 selects the address of ERF 812. Next, an example of the instruction processing sequence of this embodiment will be described for a basic instruction. The IFU 305 uses the value of the FP 404 as an address to access the BM ₁ 303 and prefetch instructions. When data read from the BM ₁ 303 is sent, if there is an empty area in the IB 401 that can store the data, it is taken in, otherwise it is ignored. FP404 determines whether the above empty area exists or not.
Based on the value of and the output 11A from DP510, the IF
-CONT403 will do it. In this example, BM ₁ 30
There are more areas than the data read width from 3.
The data read if it exists in IB401
Store in IB401. The ALIG 402 uses the output 11A of the DP 510 as an address, and extracts data in the IB 401 by arranging the data in address order starting from the position on the corresponding address in the IB 401. In this embodiment, the data is extracted in units of bits, but of course, if the basic length of the instruction is bytes, it is also possible to align in units of bytes.
During the first decode cycle of an instruction, DP51
Since 0 indicates the address of the opcode,
The first data taken out from ALIG 402 corresponds to the opcode part, followed by the operand specifier part of the first operand. In a decode cycle in the middle of an instruction, the DP 510 may indicate the address of an operand specifier, and in this case, a series of data starting from the operand specifier corresponding to the address is retrieved. The output 329 from ALIG 402 is wide enough to include at least one set of operand specifiers and an opcode portion. DU 309 decodes instructions retrieved from ALIG 402. The DU 309 always decodes the output 329 of the ALIG 402, and the conditions for completing the decoding process will be described below. The effective data length to be used for decoding within IB 401 is obtained by the difference between FP 404 and DP 510. FP 404 indicates the address to be read from the memory by the next memory access, and DP 510 indicates the beginning of the memory address to be decoded next. Therefore, FP404 is DP510
Matching or progressing against. Therefore DP5
When 10 and FP404 are equal, there is no valid data in IB401. If FP404 and DP510 are not equal, the value obtained by subtracting FP404 from DP510 indicates the length of valid data. DU309 calculates the length required for decoding by NBNC513 and connects it to IF in IFU305 by signal line 13A.
Notify CONT403. IF-CONT403 compares the content of signal line 13A with the difference between FP404 and DP510, and if the former is equal to or smaller than the latter, it determines that the length necessary for decoding is within IB401, and the signal line 12A determines that the length necessary for decoding is within IB401. This is notified to the D-CONT 509 in the DU 309. D-CONT50
9 receives a notification via the signal line 12A that the number of bytes necessary for decoding is in the IB 401, and further receives a notification via the signal line 15B that the AU 310 is ready to receive the decoding result.
The result decoded by the DU 309 is sent to the AU 310, and the processing of the decoding cycle is completed. If the data necessary for decoding is not available in the IB 401, or if the AU 310 is not in a state where it can receive the decoding results, the processing for that decoding cycle is invalidated and the same processing is performed again in the next cycle. -CONT509 controls. The output 17B of the DBNC 507 is expressed by equation (1). 17B=α+β+γ (1) The output 13A of the NBNC513 is expressed by equation (2). 13A=α+β+δ……(2) Here, α and β are: When the DP510 indicates the address of the opcode α=Number of bits of the opcode β=Number of bits of the first operand specifier following the opcode The DP510 indicates the address of the operand specifier. When indicating an address, α=0 β=the number of bits of the operand specifier. γ is as follows: When two operand specifiers are decoded simultaneously, γ=number of bits of operand specifier in register specification mode, and when only one operand specifier is decoded, γ=0. δ is when simultaneous decoding of two operand specifiers is permitted (indicated by DCS503) δ = number of bits of operand specifier in register specification mode Simultaneous decoding of two operand specifiers is not permitted In the case δ=0. In the first decode cycle of the instruction, ALIG4
The first part output from 02 corresponds to the opcode. Therefore, the first part is used as the address of the DCS 503 to read the DCS 503. In the DCS 503, one word address is assigned to one operand specifier of each instruction. As shown in FIG. 10, one word of the DCS 503 indicates the access distinction (read, write, or read and a field (abbreviated as AD) that indicates the data length (DL) and a field that indicates the data length (DL
), if there is an operand specifier that follows the operand specifier, a field (abbreviated as JA) to indicate the address corresponding to the operand specifier in the DCS 503, and the final operand specification of the instruction. It consists of a field (abbreviated as E) that indicates if it is a child, and a field (abbreviated as RD) that indicates permission for simultaneous decoding of two operand specifiers. Of course, there are several other fields included, but they are not related to the present invention and will therefore be omitted. Each instruction is assigned as many words in the DCS 503 as the number of operand specifiers that the instruction has; for example, three words are assigned to an instruction with three operands. Of course, if there is no problem in sharing the address between instructions, DCS
It is also possible to reduce the capacity of 503. In the first decode cycle (t ₁ ) of a certain instruction, the opcode becomes the address of the DCS 503, and the information of the first operand that specifies the opcode, the address (JA) on the DCS 503 of the second operand, and other information. is read from the DCS 503. At this time, the first operand specifier is ALIG4
OS-DEC taken out from IB401 by 02
It is decoded at 505. If the operand specifier contains displacement, absolute address, or literal data, D-
The ALIG 508 takes them out, formats them, and stores them in the DR 611. DU309
is the result of decoding using the procedure described above.
In addition to setting each of the 10 registers, the ACVF
604 and causes AU310 to start calculating the address of the operand indicated by the operand specifier according to the decode result, and also calculates the number of bits of the instruction decoded in that cycle (opcode and first operand). The DBNC 507 calculates the number of bits constituting the operand specifier, and the INC 512 adds this value to the value of the DP 510 to update the contents of the DP 510. If the instruction has two or more operand specifiers, in the cycle (t ₂ ) following the first decoding cycle of the instruction, in the cycle t ₁
The JA field in the information read from the DCS 503 is used as an address, and the information of the second operand is read from the DCS 503 as defined by the operation code. At the same time, the operand specifier of the second operand is taken out from the IB 401 by the ALIG 402 and decoded by the OS-DEC 505 according to the same procedure as the decoding of the operand specifier of the first operand. At this time, if the AU 310 receives the decoding result of the operand specifier of the first operand, finishes calculating the address of that operand, and is ready to accept the calculation of the address of the next operand, the DU 309 The decoding result of the operand specifier of the second operand is set in each register of the AU 310, and the ACVF 604 is set to cause the AU 310 to start calculating the address of the operand indicated by the operand specifier of the second operand, and The number of bits of the instruction decoded in that cycle (the number of bits composing the operand specifier of the second operand) is calculated by the DBNC507, and the DP
In addition to the value of 510, the contents of DP510 are updated. As is clear from the above explanation, DU309 is
It decodes one operand specifier every machine cycle, sets the decoded result in a register in the AU310, and instructs the AU310 to calculate the address of the operand based on the decoded result in that cycle. The first decode cycle of the instruction converts the opcode to DCS
503 address, and the information specified by the opcode is retrieved in subsequent cycles. Also, from the opcode ECSAG501
The start address of the microprogram is determined by the ``AER'' 601 and set in the AER 601. In the AU310, the decoding result of a certain OS from the DU309 is set in the register in the AU310,
When the ACVF 604 is set, the operand address is calculated according to the decoding result, and the calculated operand address is stored in the OFU 311.
Transfer OFU311 operation control information to MAR705
Set each to OFCR702, OFCVF703
Set the OFU unit 311, and MAR
705 to start memory access on the address set. When the address calculation of the operand specifier of a certain operand is completed, the AU 310 receives the operand specifier following the operand specifier from the DU 309 and calculates the address of the operand specifier. In this way, the AU310 sequentially calculates the addresses of the operands specified by each operand specifier, but the address calculation for one operand specifier is not necessarily completed in one machine cycle. Of course, it may take several machine cycles. Furthermore, after address calculation for a certain operand specifier is completed, the next operand specifier that performs address calculation does not need to belong to the same instruction as the operand specifier. AU310
also transfers the microprogram start address 10C of the instruction stored in the AER 601 to the OER 701 of the OFU 311 when the address calculation of the (first) operand specifier at the start of the instruction is completed. OFU311 receives the address calculation information of a certain operand specifier from AU310 and sends it to MAR705.
When the operation control information of the OFU 311 is placed in each OFCR 702 and the OFCVF 703 is set, memory access is started. The read data is stored in the OBR 707, formatted by the OALIG 708, and transferred to the EU 312. In addition, the OFU 311 transfers the microprogram start address stored in the OER 701 to the MPC 80 of the EU 312 in the memory access cycle of the first (first) operand specifier of the instruction.
Transfer to 1. However, if the addressing mode of the operand specifier is literal data, no memory access is performed; however, in this case, MAR
The literal data operand passed to 705
When transferring to OBR707, transfer the microprogram start address to MPC801. As described above, information regarding the instruction (opcode and operand specifier) decoded by the DU 309 is transmitted to the EU 312 via the AU 310 and OFU 311 in this order. The EU 312 accesses the ECS 802 from the microprogram start address passed to the MPC 801, reads the microinstruction, and starts executing the instruction. The operand specified by the operand specifier is passed from the OBR 707 or the ERAR 813 as a register address. However, if the operand is deestination, the address of the operand is set in MAR 705. EU312 performs calculations using the operands passed from OFU311 and sends the results to ERF81.
2, ARF606 or BM ₂ via bus 334
304. All these operations are controlled by microprograms. FIG. 11 is a diagram showing a stage flow representing the flow of instructions and the accompanying instruction processing process. In Figure 11, three instructions (1), (2), (3)
is giving. Instructions (1) to (3) are all instructions with two operands. First cycle (t ₁ )
The instruction word of instruction (1) is read out (IF ⁽¹⁾ ). In the next cycle (t ₂ ), the opcode and the operand specifier of the first operand are decoded (D ⁽¹⁾ 1). In the next cycle (t ₃ ), the effective address of the first operand is calculated according to the decoding result (A ⁽¹⁾ 1), and at the same time, the operand specifier of the second operand is decoded (D ⁽¹⁾ 2). ). In the next cycle (t ₄ ), the first operand is fetched (OF ⁽¹⁾ 1) and the effective address of the second operand is calculated (A ¹ 2). Also, during the same cycle, the operation code of instruction (2) and the operand specifier of the first operand are decoded (D ⁽²⁾ 1). In the next cycle (t ₅ ), the second operand of instruction (1) is fetched (OF ⁽¹⁾ 2), the effective address of the first operand of instruction (2) is calculated (A ² 1), and the second operand is fetched (OF (1) 2). Decodes the operand specifier of the operand (D ⁽²⁾ 2). Next cycle ( _t6 )
Now execute instruction (1) (E ¹ ), and at the same time
Fetching the first operand of (2) (OF ⁽²⁾ 1), calculating the effective address of the second operand (A ⁽²⁾ 2), and decoding the operation code and operand specifier of the first operand of instruction (3) ( D ⁽³⁾ Do 1). Thereafter, each cycle from _t7 to _t11 is processed in the same manner. In Figure 11, commands (2) and (3)
The fetches (IF ⁽²⁾ , IF ⁽³⁾ ) indicate that an instruction is read in advance when the number of invalid areas in the IB 401 exceeds a predetermined number of bits. Although FIG. 11 shows an example in which the effective address calculation cycle and operand fetch cycle for each operand end in one cycle, depending on the addressing, the effective address calculation may not end in one cycle. The instruction flow and processing process are controlled by addressing modes such as Indirect mode (addressing mode where the operand address is obtained by referencing the memory twice), etc. , will vary. Figure 12 shows an instruction with three operands (3
2 is a diagram illustrating a stage flow representing the flow of instructions and the accompanying instruction processing process when operand instructions (operand instructions) are executed consecutively; FIG. Also in FIG. 12, three instructions I(1), I(2), and I(3) are given as in FIG. 11. The processing of instructions in each cycle is
This is similar to the case where the two-operand instructions are consecutive as explained in the figure. However, in a three-operand instruction, the third operand is generally not a source operand but a destination operand, so the third operand is not fetched. 3
The stage flow for instructions with more than one operand is also explained in Figures 11 and 12.
There is no essential difference between the stage flows of operand instructions and three-operand instructions. Further, there is no problem even if instructions having different numbers of operands are mixed together. Above, examples of 2-operand instructions and 3-operand instructions have been explained, but 1-operand instructions,
Of course, there is no essential difference from the stage flow shown in FIGS. 11 and 12 even for instructions having four or more operands. Next, a description will be given of simultaneous decoding of two operand specifiers in an instruction that is permitted to decode two operand specifiers simultaneously, and subsequent processing. Simultaneous processing of two operand specifiers is limited to instructions that are permitted to simultaneously decode two operand specifiers, as described above.
Of course, this can also be done for all instructions. Simultaneous processing of two operand specifiers means that in each decoding cycle of operand specifiers included in an instruction word, when decoding the operand specifier before the final operand specifier, This is performed when the addressing mode is register specification, and is not performed in modes other than register specification, in which case only the operand specifiers before the final operand specifier are decoded. As an example, an add instruction with two operand specifiers will be described below. The addition instruction performs a process of adding the contents of the first operand and the second operand and storing the result at the position of the second operand. Therefore, the first operand is a read operand and the second operand is a read-and-write operand. Therefore, the pattern of DCS 503 for the addition instruction is the 13th pattern.
The result will be as shown in the figure. That is, DCS5
On the address corresponding to the opcode value of 03,
The information of the first operand and the information of the second operand
Since the first operand is the operand before the final operand, the field RD of DCS 503 is included.
is "1" (indicating that simultaneous processing by two OSs is permitted). of the second operand
The address of the DCS 503 has a format in which information about the second operand and field E indicating that the second operand is the final operand of the instruction are "1". FIG. 14 shows a stage flow when addition instructions having operand specifiers of the same format are executed successively and the second operand is a register specification. If the second operand does not specify a register, the stage flow will not be as shown in FIG. 14, but will be as shown in FIG. 11. The instruction processing process at this time will be described below with reference to FIG. Instruction I(1) in the first cycle (t ₁ )
The data (instruction) on the address containing is read (IF ⁽¹⁾ ). In the next cycle (t ₂ ), the operation code of the instruction I(1) and the OS of the first operand are decoded, but at this time, the field RD of the DCS 503 is “1” and the RD-
The OS of the first operand is determined by DEC506.
When it is detected that the OS addressing mode of the second operand following is register specification,
RD-DEC506 extracts the register address from the OS of the second operand and stores it in ARR in AU310.
By placing a number in 610, two OSs are decoded at the same time (D1 & D2 ⁽¹⁾ ). In the next cycle (t ₃ ), the AU 310 calculates the address (A1 ^{(1)) of the first operand of the instruction I(1) according to the decoding result, transfers the result to the OFU 311, and also calculates the address of the first operand of the instruction I(1).} Transfer the register address of the second operand in 1) to ORR 709 in OFU 311. In the same cycle (t ₃ ), the DU 309 decodes instruction I(2) in the same way as in the cycle t ₂ (D1 &
D2 ⁽²⁾ ). In the next cycle (t ₄ ), ,OFU
311 performs a fetch (OF1 ⁽¹⁾ ) of the first operand of instruction I(1) and transfers the register address of the second operand of instruction I(1) to EU 312. In the same (t ₄ ) cycle, the AU310 calculates the address of the first operand of instruction I(2) (A1 ⁽²⁾ ), transfers the result to OFU311, and calculates the address of the second operand of instruction I(2). register address
Transfer to OFU311. DU3 in the same (t ₄ ) cycle
09 is the same decoding ( _D1
&D2 ⁽³⁾ ). In the next cycle (t ₅ ), EU3
12 receives the register addresses of the first operand of the instruction I(1) and the second operand of the instruction I(1) from the OFU 311, and executes the instruction I(1) (E ⁽¹⁾ ). In the same ( _t5 ) cycle, OFU311 executes the first instruction of instruction I(2).
An operand fetch (OF1 ⁽²⁾ ) is performed, and the register address of the second operand of instruction I (2) is transferred to the FU 312. In the same cycle (t ₅ ), the AU310 calculates the address of the first operand of instruction I(3) (A1 ⁽³⁾ ) and sends the result to the OFU31.
1, and also transfers the register address of the second operand of instruction I(3) to the OFU 311. Thereafter, each cycle of t ₆ and t ₇ is processed in a similar manner. Although FIG. 14 shows an example in which the effective address calculation cycle and operand fetch cycle for each operand are completed in one cycle, depending on the addressing, the effective address calculation may not be completed in one cycle. BM ₂ 30 during operand's fetish
If there is no data in MM 301 and there is no data in MM 301, multiple cycles are required. Therefore, in such a case,
The flow of instructions and processing steps vary. FIG. 15 is a diagram showing a stage flow representing the instruction flow and the accompanying instruction processing process when instructions of the same format having three operands are executed successively. Also in FIG. 15, three instructions I(1), I(2), and I(3) are given as in FIG. 14.
Each instruction is an instruction that is permitted to decode two operand specifiers simultaneously when the final operand is in the register specification mode, as in FIG. 14, during the decoding cycle of the operand before the final operand. FIG. 15 shows the stage flow in the addressing mode in which the final operand (corresponding to the third operand) is designated by a register. If the third operand is an addressing mode other than register designation, the stage flow will not be as shown in FIG. 15, but will be as shown in FIG. 12. In the case of the two-operand instruction shown in FIG. 14, in the cycle for decoding the operand specifier of the first operand,
I decoded two operand specifiers, but
The three-operand instruction shown in FIG. 15 differs in that two operand specifiers are decoded in the cycle in which the operand specifier of the second operand is decoded. This is a difference that occurs because the first operand corresponds to the operand before the final operand of the instruction in a 2-operand instruction, and the second operand corresponds to a 3-operand instruction.Of course, there is no essential difference. It is. Examples of 2-operand and 3-operand instructions have been explained above in FIGS. 14 and 15, but even in instructions with 4 or more operands, the final operand of the instruction is in a register-specified addressing mode. Sometimes, it takes two cycles to decode the operand specifier of the previous operand.
Of course, it is possible to decode multiple operand specifiers simultaneously. Further, there is no problem even if instructions having different numbers of operands are mixed together. As described above, according to an embodiment of the present invention, it is possible to realize a pipeline control data processing device that can quickly process variable-length instructions in which the operand specifier has an arbitrary number of bits. The average execution time for a 3-operand instruction is 2 machine cycles, and for a 3-operand instruction it is 3 machine cycles. Furthermore, if the operand specifier of the final operand of the instruction is in a register-specifying addressing mode, the execution time can be further shortened by one machine cycle. According to the present invention, in a variable length instruction that allows free addressing for each operand, pipeline processing between operands can be achieved by pipeline processing between a plurality of units, and instruction processing ability can be improved.

[Brief explanation of the drawing]

Figures 1 and 2 are explanatory diagrams showing the format of an operand specifier for a typical instruction in which the addressing mode of the operand is independent of the operation code, and Figure 3 is an illustration of the data processing explained in the present invention. FIG. 4 is an explanatory diagram showing the format of operand specifiers of instructions handled by the device. FIG. 4 is a block diagram of an embodiment of the data processing device constructed according to the present invention. FIGS. FIG. 10 is a block diagram showing the details of the block, and FIG.
12 is an explanatory diagram showing a signal for a certain command in a certain circuit showing the operation of the data processing device shown in FIG. 4, and FIG. 14 and FIG. FIG. 3 is a flow diagram showing the operation of a certain specific instruction. 301... Main memory device, 302... Main memory control unit, 303, 304... High speed buffer memory, 305... Instruction fetch unit, 309...
...Instruction decode unit, 310...Address calculation unit, 311...Operand fetch unit, 312...Execution unit, 401...Instruction buffer, 402, 508, 708...Data...
Aligner, 404...Instruction fetch pointer, 5
03... Control memory, 505... Operand specifier decoding circuit.

Claims (1)

[Claims] 1. In a data processing device that handles variable-length instructions in which an operand specifier that specifies the addressing mode of an operand is given independently from a code section that specifies an operation, the instruction is preceded from the memory that stores the instruction and operand. An instruction buffer means for reading and holding, an instruction aligner means for extracting an instruction including at least one set of operand specifiers from the instruction buffer means, and an operand specifier included in the instruction extracted by the instruction aligner means. and an operation code decoding means for specifying a function of an instruction, and an operand specifier decoding means for decoding an operand specifier extracted by the instruction aligner means, and operand specifiers of at least one operand in one machine cycle. 1. A data processing device characterized in that said instruction aligner means and said operation code decode means each prepare different operands so as to decode said operands, and perform pipeline processing among a plurality of operands.