JPS6149692B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to a data processing device that handles undefined length instructions in which an operand specifier that specifies the addressing mode of an operand is independent of the type of processing and the opcode portion that specifies the operand. be.

The length of the operand specifier changes arbitrarily depending on the addressing mode, and since the length of the instruction is variable, such an instruction is sometimes called a variable length instruction.

There is no particular difference in meaning between "undefined length instructions" and "variable length instructions," and even if the term "undefined length instructions" is replaced with the term "variable length instructions," they have the same meaning. However, here, for convenience, the instructions handled by the present invention are referred to as indefinite length instructions, and the conventional instructions are referred to as variable length instructions.

Two typical examples of well-known instruction systems having variable-length operand specifiers are shown below.

One is Burroughs Corporation.
This is the instruction format when the computer B1700 has an architecture suitable for COBOL/RPG.
1058823−015, Copyright 1973, Burroughs
Corporation”.

Another example is DEC (Digital Equipment)
This is an instruction system with variable-length operand specifiers that is part of the architecture of the VAX11/780 computer (VAX11/780).
Architecture Handbook, Copyright 1979” and USP No. 4236206.

In the two conventional instruction systems shown here, the part that specifies the operand format and addressing mode is specified by a variable-length operand specifier.
It has the characteristic that it is independent from the opcode.

However, in conventional variable-length instructions, there is a one-to-one correspondence between the number of operands to be processed and the operand specifier that specifies the addressing mode of the operands to be processed. For example, A+B→B A+B→C. For two processes (operations), 2
It was necessary to allocate two opcodes.

In other words, in the process of A+B→B, it is necessary to specifically specify in the operation code that two operands are processed and that the second operand is used twice.

If we process A+B→B and set the number of operands to 3 and prepare 3 operand specifiers, then
There is no need to be aware of the distinction between A+B→B and A+B→C, but in the process of A+B→B, it is necessary to provide two identical operand specifiers. (Generally, a long one is 7 bytes), which is not preferable because it significantly reduces memory implementation efficiency.

In the first place, the distinction between processing A+B→B and processing A+B→C was made in order to improve memory implementation efficiency. (For A+B→B, only two operand specifiers are required.) In this way, in the conventional method, processes that use the same operand multiple times need to be distinguished from other processes with the same function. There was a limit to the number of operations that could be specified using an opcode.

Although I explained using the example of A+B→B, this is A
The same goes for the process -B→B, and applies to all examples in which A and B are operated on and the result is stored in B. Generally, this is expressed as AOPB→B.

SUMMARY OF THE INVENTION An object of the present invention is to provide a data processing device that handles undefined length instructions that can share operand specifiers for a plurality of operands to be processed.

In other words, in the above example, for two processes, 1
The present invention aims to provide a data processing device that handles undefined length instructions that can distinguish and process two instruction codes.

A feature of the present invention is that operand specifier end information (hereinafter referred to as a flag) is added to each operand specifier that specifies the addressing mode of the operand, and the end flag is added only to the final operand specifier. If this end flag is set to "1" and it is detected that this end flag is set to "1", it is determined that one instruction is formed including the operand specifier, and processing is performed. That is what we are doing.

Specifically, as will be described later, if the end flag is detected to be set before the operation code decoding means outputs a signal indicating that the operand is the last (indicating that the operand specifier is the last), (in cases where the same operand is used repeatedly). in this case,
The last operand is used multiple times until the number of operands specified by the opcode is reached.

Hereinafter, the present invention will be explained in detail with reference to the drawings.

FIG. 1 is a basic conceptual diagram of a data processing system to which the present invention is applied.

A memory device 1 and a plurality of central processing units 2 are connected by a common bus 3, and information can be exchanged between them via the common bus 3.

The memory device 1 includes a memory unit 11 that stores instructions and operands handled by the instructions, and a memory control unit 1 that controls reading and writing of the instructions and operands.The memory unit 11 and the memory control unit 12 are connected to a memory bus 13. connected with.

Regarding the operation of the memory device 1, please refer to the patent application filed in 1983-
Although it is described in detail in the specification of No. 160758, detailed explanation of this part will be omitted because it is not directly related to the main part of the present invention.

A plurality of central processing units 2 can be connected to the common bus 3 (two units in the figure), each of which has a memory device 1.
The instructions and operands are accessed and the instructions are sequentially processed.

In order to increase speed, there is an instruction cache 21 (high-speed buffer memory) and an operand cache 22 (high-speed buffer memory) in which instructions and operands once read are copied, respectively, and instruction fetch, decode, and operand addresses are provided. An example is shown in which there is a unit 23 that performs arithmetic operations, and an E unit that fetches operands and executes instructions, each of which performs pipeline processing.

The use of the instruction cache and operand cache and the pipeline processing between the unit and the E unit are well known.

Now, FIG. 2A shows the format of an indefinite length instruction handled by the central processing unit 2.

One instruction consists of an operation code (commonly called an opcode) OP consisting of one or several bytes, and an operand specifier OS of one or more bytes with a termination flag S.
1, OS2...consists of OSn.

The operation code OP describes the processing content of the instruction (processing type), the number of operands required for processing, and the attributes of the operands (data length, read/write distinction, data type: fixed point/floating point...
etc.) are shown.

An opcode OP is followed by an operand specifier that is less than or equal to the number of operands indicated by the opcode OP.
OS1, OS2, etc. are shown and constitute one instruction (formally, an instruction word).

The operand specifiers are arranged in the order of the operands used in the relevant instruction, and only the last operand specifier has the end flag S set to "1". If the number of operand specifiers is less than the number of operands specified by the opcode OP, the operand corresponding to the last operand specifier is used repeatedly.

There are various ways to use the same operand repeatedly, but the most desirable method is
The last operand specifier would be used repeatedly. This point will be discussed in detail later.

An example where the number of operands specified by the opcode OP and the number of operand specifiers do not match is explained below.

For example, if the opcode OP is an addition operation, the function is A + B → C, which requires three operands, but if there is one operand specifier, it is A + A → A, and if there are two, it is A + B → B. is possible with the same opcode.
A specific example of an operand specifier is shown in FIG. 2B.

Here, we will show examples No. 1 to No. 24, and compare their formats and corresponding operands one-to-one.
It is shown in correspondence.

In Figure 2B, the operand ( ) is
Indicates that the value in parentheses is the memory content whose address is the address.

Also, during formatting, DISP calculates the displacement, IM
indicates immediate data (direct data), and the subscript indicates its size in bits.

Further, Rx indicates an index register, Rn indicates a general register, and L indicates the size of the operand in bytes.

In Figure 2B, the relationship between the format and operands can be understood to some extent;
A brief explanation will be given below.

No.1 is register direct addressing, Rn
The general register indicated by is itself a direct operand.

All of No. 2 and below use memory as an operand, and the address calculation is performed in the form shown in the operand column.

No. 2 is indirect addressing, in which the contents of the general register indicated by Rn are the address of the operand.

In Nos. 3, 5, and 7, the value indicated by DISP is added to the contents of the general register indicated by Rn, and this becomes the address of the operand.

In Nos. 4, 6, and 8, the contents of the memory at the addresses determined in Nos. 3, 5, and 7 are the addresses of the operands.

No.9 to 11 are immediate data,
The values of IM ₈ , IM ₁₆ , and IM ₃₂ themselves are operands.

For Nos. 12 to 17, program counter PC is used instead of general register Rn.
It is only different from Nos. 3 to 8. The PC holds the address next to the operand specifier to decode.

Nos. 18 to 24 differ in that the value of the index register Rx is further added to Nos. 3 to 8, and the value of the index register Rx is added by the value multiplied by the data length L of the operand. Ru.

This is a necessary process in order to be able to set the value of the index register Rx as a displacement from the beginning, regardless of the data length.

In other words, by multiplying by L (indicating the data length), the index register Rx only needs to contain a value indicating the number of data from the beginning, regardless of the data length.

For example, if "10" is stored in the index register Rx, this is the 10th data from the beginning, and its address is: if it is a byte, add 10 (L = 1), if it is a word, add 20. (L=2),
For long words, 40 is automatically added (L=4), and the user can set the value of the index register Rx regardless of the data length.

FIG. 3 is a more specific block diagram of the central processing unit 2 shown in FIG.

The unit 23 in FIG. 1 is an instruction fetch unit (IFU) 25, an aligner (ALIG) 26, and a decode unit (DU) 2 in FIG.
7 and an address calculation unit (AU) 28 correspond to this, and the E unit 24 corresponds to an operand fetch unit (OFU) 29 and an execution unit (EU) 30.

In FIG. 1, unit 23 and E unit 24
As mentioned above, each unit also has an instruction fetch unit IFU25 and a decode unit DU2, as shown in FIG.
7. Address calculation unit AU28, operand fetch unit OFU29, execution unit 30
An example is shown in which each file is divided into 2 parts, each of which undergoes pipeline processing.

However, since the gist of the present invention is not directly related to such pipeline processing itself, a detailed explanation of pipeline processing is omitted. Incidentally, pipeline processing itself is well known, and USP 4025771 discloses a pipeline high-speed signal processor.

By the way, in FIG. 3, the instruction fetch unit 25 has a program counter 50 for fetching an instruction in advance, and performs a process of reading an instruction that will be executed next from the instruction cache 21 in advance. ing.

An address to be read is sent to the instruction cache 21 via the address line 100, and 4 bytes of the corresponding instruction are sent to the instruction fetch unit IFU 25 via the data line 101.

If there is no corresponding instruction in the instruction cache 21, the corresponding instruction is read from the memory 1 via the common bus 3, and this instruction is stored in the instruction cache 21. The operation of the cache is well known; for example, "A Guide to the IBM
System/370 Model 168”.

When four bytes of instructions are sent to the instruction fetch unit 25, the program counter 50 is incremented by four (+4), and a request to send the next instruction is output to the instruction cache 21.

This operation continues until the buffer (not shown) in instruction fetch unit IFU 25 is full.

From the instruction fetch unit IFU25, bus 1
03, the command read out in advance is sent to the aligner (ALIG) 26.

The aligner 26 performs a shift process by the number of bytes indicated on the signal line 102 from the decoding unit DU 27, and sends the corresponding command to the bus 104.

By appropriately manipulating the value of the signal line 102, as shown in FIG.
However, when processing the second and subsequent operand specifiers, the operand specifiers are arranged and output with a 1-byte dummy so that the first operand specifier is lined up next.

The above control will be explained in detail later.

The decoding unit (DU) 27 is the aligner 2
6 (ALIG) and sends the following information to address calculation unit AU28.

(1) Send addressing mode via bus 105.

As explained above, there are the following addressing modes (a) to (h), and one of them is designated.

(a) Register direct……No.1 (b) Rn……No.2 (c) Rn+DISP type……No.3, 5, 7 (d) Rn+DISP indirect type……
No.4, 6, 8 (e) Immediate type……No.9, 10, 11 (f) PC+DISP type……No.12, 14, 16 (g) PC+DISP indirect type……
No.13, 15, 17 (h) Type with index (b) to (d)……
No. 18 to 24 Note that No. 1 to No. 24 correspond to No. 1 to No. 24 of the operand specifier format shown in FIG. 2B.

(2) Send DISP or immediate data in 32 bits via bus 106.

(3) General register Rn via bus 107
Send the address.

(4) Index register via bus 108
Rx address, and (5) Send the program counter value used for address calculation via bus 116.

The address calculation unit AU28 is connected to the bus 105.
According to the addressing mode indicated by
In cases other than (a) and (e) above, the operand address is calculated and the calculated address is sent to the bus 109.

On the other hand, in the case of (a), the contents of the bus 107 are sent as they are to the bus 113, and in the case of (e), the contents of the bus 107 are sent as they are to the bus 113.
is sent to bus 109.

In cases other than (a) and (e) above, the operand fetch unit OFU 29 sends the contents of the bus 109 indicated by the sent address to the bus 110, and when the operand is read, it sends the contents of the bus 109 to the operand cache 22. request read processing.

Read operand is operand cache 2
2, the operand fetch unit OFU 29 sends the read operand to the execution unit EU 30 via the bus 112 and notifies that the operands are ready.

When the operand is written, execution unit EU3
Operand fetch unit OFU2 continues until write data from 0 is output to bus 111.
9 continues to send addresses onto bus 110.

On the other hand, for (a) above, the operand fetch unit OFU29 is the address calculation unit AU.
The register address 113 sent from 28 accesses its own general register (not shown). The only difference from (a) is whether memory is accessed or registers are accessed.

For (e), leave the contents of bus 109 as is,
The data is sent to the bus 111, and the execution unit EU30 is notified that the operands are complete. The execution unit EU30 also receives the start address of the microprogram sent from the decoding unit DU27 via the opcode bus 114, and uses the operands on the bus 112 when reading, and uses the operands (data) when writing. The commands are output to the bus 111 and sequentially processed.

If the instruction is a branch instruction, the new program counter value is sent to the program counter 50 of the instruction fetch unit IFU 25 using the bus 115.
At the same time, the processing result in each unit of the operand that was previously processed in the pipeline processing is canceled.

The above is an outline of the processing for one operand specifier, and each unit 25 to 30 sequentially processes the operand specifiers in parallel using pipeline processing.

Next, the decoding unit 27 related to the gist of the present invention will be described in detail with reference to a specific example.

Figure 4 shows the decoding unit DU shown in Figure 3.
FIG. 27 is a block diagram showing a specific example of No. 27.

The DP register 26 is connected to the decoding unit DU27.
indicates the beginning of the instruction to be decoded, and when decoding the first operand specifier, it indicates the address of the opcode, and when decoding the second and subsequent operand specifiers, it indicates the address of the first minus one of the corresponding operand specifier. .

The above address is sent via bus 102 to the aligner ALIG 26 and instruction fetch unit shown in FIG.
Since it is sent to the IFU 25, the first byte is sent to the bus 104 as shown in FIG.
When reading the operand specifier, as shown in (A), the operation code is OP. When reading the second operand specifier and below, as shown in (B), the dummy data is written in the second byte. , end flag S
The first byte of the operand specifier containing
Other information of the operand specifier is output from the 7th byte to the 7th byte.

The bus 204 is information indicating which operand is being processed, and when this information indicates that all operands have been processed, the first byte of the bus 104 is set in the opcode register 64.

The output of the operation code register 64 is sent to the operation code decode unit 61 which obtains the start address of the microprogram of the execution unit EU 30 of the relevant instruction, and to the operand information ROM 63 which has information regarding the operand of the relevant instruction.

The output result 201 of the ROM 61 is set in the start address register 62 and is sent to the operation code bus 114.
is sent to the EU 30 via the operand fetch unit OFU 29 in synchronization with the first operand being passed from the operand fetch unit OFU 29 to the execution unit EU 30.

The ROM 63 has the configuration shown in FIG. 6, for example, and the information shown in FIG. 6 is input in advance, and the information about the operation code and the number of the operand to be processed is read out as an address. It can be done.

That is, when the first byte is set in the operation code register 64, the selector SEL81
Since the bus 200 side is selected, information regarding the first operand is read using the opcode as an address.

The information read out includes: (1) Attributes of the operand, that is, information indicating whether it is a read operand or a write operand, R/W, and the data length L (byte, word, long word) of the operand. (2) a flag indicating that it is the last operand; and (3) an address containing information about the next operand of the same instruction.

(1) is output to bus 105-1 and output to address calculation unit AU28, and (2) is output to bus 2
03, and sent to the decoding completed byte number detector 65.

Furthermore, the information in (2) and (3) is latched in the register 83, then output to the bus 204, and is used as an address for reading the next operand.

Since the latch information of the information in (2) is input to the selection terminal S of the selector 81, if the information in (2) is "1", the contents (200) of the operation code register 64 are used, and the information is "0". In this case, the information in (3) is used.

On the other hand, in the bus 104, a signal line 205 indicating the end flag S is sent to a decoding end byte number detector 65.

Furthermore, the first seven bits of the operand specifier are transferred to the operand specifier decoder 66 via the bus 206.
sent to.

The operand specifier is decoded using 7-bit information, and an example thereof will be explained with reference to FIG.

For example, as shown in No. 3 in Figure 2B (Rn+
When the operand specifier of DISP ₈ ) is sent, three more bits of the upper seven bits are sent as shown in Figure 7A.
010 is detected and the following information can be output.

(1) Must be a 2-byte operand specifier.

(2) When outputting the contents of bus 208 to bus 106, a 3-byte right shift is required to align the DISP digits.

(3) In order to convert the DISP value into 4 bytes, the most significant bit of DISP ₈ should be sign-extended and output for the upper 3 bytes.

(4) The address of the operand can be calculated using Rn+DISP.

(5) Rn information must exist in the lower 4 bits of the 1st byte.

There are five. Similarly, (Rn
+DISP ₃₂ ) is sent, it is detected that the upper 7 bits are 110110 as shown in FIG. 7B, and the following information can be output.

(1) Must be a 6-byte operand specifier; (2) When outputting the contents of bus 208 to bus 106, a 1-byte left shift is required to align the digits of DISP; (3) DISP (4) The address of the operand can be calculated using Rn + DISP. (5) The Rx information is stored in the lower 4 bits of the second byte of the operand specifier. There are five things: Existence.

The two examples above have been shown, but if we summarize them, we get the following.

The operand specifier decoder 66 decodes the received operand specifier and outputs the following information.

(1) The length of the operand specifier is output in bytes to the bus 215. For example, in Figure 2B
When the No. 3 operand specifier (Rn+DISP ₈ ) is sent, "2" is output.

(2) The number of shift bytes for the displacement (DISP)/immediate data aligner 67 is output to the bus 211.

For example, the operand specifier (Rn+DISP ₈ ) specifies a 3-byte right shift as shown in Figure 7A, and the operand specifier (Rn+DISP ₃₂ ) specifies a 1-byte left shift as shown in Figure 7B. do.

(3) Mask byte instruction data for the aligner 67 is output to the bus 212 .

This means that among the 4 bytes of data output to the bus 106, the upper 2 bytes and
Alternatively, by instructing a 3-byte mask, 1-byte or 2-byte DISP or IM information is sign-extended to become 4-byte.

For example, when DISP ₈ , as shown in FIG. 7A, there is a 3-byte shift, and when DISP ₃₂ , as shown in FIG. 7B, there is an extra byte "-Rn" in front, so there is a 1-byte left shift.

This means that when DISP ₈ is used, DISP ₈ is written in the upper 3 bytes.
If you do not expand the sign bit of
This is because correct bit address calculation cannot be performed. (Bus 212 is for that specification.) (4) Outputs the addressing mode to bus 105-2, thereby controlling the address calculation unit.
Indicates the operation mode of AU28.

Regarding the addressing modes, it has already been explained that there are eight modes (a) to (h) in connection with the explanation of the address calculation unit AU28 in FIG.

(5) Information indicating whether the general register Rn is located in the first byte or the second byte is output to the bus 216.

(Rn+DISP ₈ ), the 1st byte, (Rn+
DISP ₃₂ ), the second byte is specified.

On the other hand, the portion of the index register Rx in the operand specifier is output to the bus 108.

Further, the selector 68 selects the portion corresponding to Rn (the contents of the bus 207 or the bus 21
0 contents) to the bus 107.

As mentioned above, the aligner 67 uses the bus 2 bytes 2 to 7 of the operand specifier.
08, the shift processing is performed by the number of shifts given by the signal line 211, and the mask part given by the signal line 212 is sign extended, and 4 bytes are sent to the bus 106. Output as data.

These are as shown in FIGS. 7A and 7B.

Next, the decoding completed byte number detector 65 will be explained.

This part is the main part when handling an undefined length instruction (with S bit added) according to the present invention.

As described above, the decoding process end byte number detector 65 includes a signal line 203 indicating the operand end flag E, a signal line 205 indicating the stop bit S of the operand specifier, and a signal line indicating the number of bytes of the operand specifier (OS _B ). Three signal lines 215 are input, and DP69 is input to signal line 214 to indicate the address of the next operand specifier.
Outputs the added value DPINC _B in bytes. The algorithm in this case is as follows.

If E = 1, DPINC _B = OS _B Otherwise, if S = 0, DPINC _B = OS _B -1 Also, if S = 1, DPINC _B = 0 That is, (1) Operand If the end flag E is "1", the processing of the corresponding instruction has ended, and a signal is sent so that the DP register 69 is incremented by the number of bytes of the operand specifier (OS _B ) to point to the beginning of the next instruction. is output on line 214.

(2) If (1) is not met, and the end flag S is not set, the next operand specifier is set to the bus 104 with a 1-byte dummy in the first byte.
In order to output it to the signal line 214, a value of (number of bytes of operand specifier: OS _B )-1 is added.

(3) If (1) is not satisfied and the end flag S is set, "0" is output so that the DP register 69 takes the same value. This causes the same operand specifier to be used to process the next operand,
The same operand will be used repeatedly.

FIG. 8 shows the decoding completed byte number detector 6.
5 shows a hardware configuration for realizing the above algorithm in No. 5.

That is, when E=1, the output gate 301 opens and the contents OS _B of the bus 215 are output to the bus 214, and when E=0, the output gate 303 opens when S=0 and OS _B - 1 is output, and when S=1, the output gate 302 is opened and "0" is output.

Also, when E is 1, if the S bit is not 1,
This means that it is detected that there are more operand specifiers than the number of operands, and in FIG. 8, the AND gate 304 turns on and outputs the signal 105-3, notifying the address calculation unit AU28 of the occurrence of the corresponding error. It's becoming like that.

In the address calculation unit AU28, the mark is 10.
5-3 is communicated to the following unit (operand fetch unit OFU 29), and finally the execution unit EU 30 is notified of the error occurrence.

In FIG. 8, 304 and 305 are inverters, 306 and 307 are AND gates, and 308 is a subtracter.

The adder 71 adds the current value of the DP register 69 and the value of the signal line 214, and outputs the address of the next operand specifier to the bus 102 by setting it in the DP register 69 via the selector 70. becomes possible. This allows the Alight
ALIG 26 can output the next operand specifier to bus 104 in the format shown in FIGS. 5A and 5B.

On the other hand, by selecting the contents of the bus 115 and setting them in the DP register 69 using the selector 70, it is also possible to change the DP register 69 in the aforementioned branch instruction.

Note that the adder 72 adds the value of the DP register 69 to
Signal line 215 indicating the length of the corresponding operand specifier
value (OS _B ) and further carry input “1”
, the next address of the operand specifier being decoded is output to bus 116.

The address calculation unit AU28 is connected to the bus 116.
The contents of are used as the value of the program counter PC used for address calculation.

As described above, according to the present invention, the operation code and the operand specifier are independent, and the length of the operand specifier can be set arbitrarily, and
With two opcodes, both AOPB→C type instructions and AOPB→B type instructions can be expressed with the amount of information of each instruction being optimized, increasing the number of instructions that can be specified with an opcode of the same length.

In other words, when the opcode lengths are the same, according to the present invention, more high-performance instructions can be added.

Furthermore, by checking the rationality of the number of operands and the number of operand specifiers, the error detection rate can be improved.

In the above embodiment, the end flag S is added to the most significant bit of the operand specifier, but it is not necessarily limited to this part, and the end flag may be provided somewhere in the operand specifier.

Furthermore, in the above embodiment, the same operand is repeatedly used multiple times by repeatedly decoding the same operand specifier without updating the contents of the DP register 69. In addition to this, a special signal may be sent from the decoding unit to the execution unit EU30 to instruct it to repeatedly use the previously requested operand.

FIG. 9 shows that by providing an end flag S in one bit of each operand specifier, it is possible to specify various operands with the same opcode (OP) for the AOPB→C repertoire. That is, in the present invention, since the S bit indicates that operand specification has ended, S can be completed with fewer operands than those required by OP.
If there are any instructions, use them repeatedly.

[Brief explanation of the drawing]

FIG. 1 is a basic conceptual diagram of a data processing system to which the present invention is applied, FIGS. 3 is a block diagram of a specific embodiment of the central processing unit shown in FIG. 1, and FIG. 4 is a block diagram of a specific embodiment of the decoding unit of FIG. 5 is the format of the operand specifier used to explain FIG. 4, FIG. 6 is an explanatory diagram for explaining the contents of the operand information ROM 63 in FIG. 4, and FIG. 7 is the operand specifier decoder in FIG. 4. 66, FIG. 8 is an example diagram showing the hardware configuration of the decoding completed byte number detector 65 shown in FIG. 4, and FIG. 9 shows examples of specifying various operands according to the present invention. It is an explanatory diagram. 27...Decode unit, 61...Opcode decode unit, 63...Operand information
ROM, 65...Decode processing completed byte number detector, 66...Operand specifier decoder, 205
...End information (flag) S.

Claims (1)

[Scope of Claims] 1. In a data processing device that handles an instruction in which an operand specifier that specifies the addressing mode of an operand is independent of an opcode portion that specifies the type of processing and the number of operands, the instruction has at least The decoding means includes at least the operation code decoding means, the operand specifier decoding means, and the end information for detecting the end information added to the operand specifier. If the end information detecting means detects that the end information is set before the operation code decoding means outputs a signal indicating that the operand is the last, the same operand is repeatedly used. A data processing device that handles undefined length instructions. 2. If the end information detection means detects a set of end information before the operation code decoding means outputs a signal indicating the end of the operand, the address of the operand specifier that is currently used as the address of the operand specifier to be read out to the decoding means next. 2. A data processing device for handling indefinite length instructions according to claim 1, wherein the same operand is repeatedly used by reusing an address therein.