CA1186801A - Central processing unit for executing instructions of variable length - Google Patents
Central processing unit for executing instructions of variable lengthInfo
- Publication number
- CA1186801A CA1186801A CA000410221A CA410221A CA1186801A CA 1186801 A CA1186801 A CA 1186801A CA 000410221 A CA000410221 A CA 000410221A CA 410221 A CA410221 A CA 410221A CA 1186801 A CA1186801 A CA 1186801A
- Authority
- CA
- Canada
- Prior art keywords
- operand
- specifier
- instruction
- operand specifier
- operation code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
- G06F9/3016—Decoding the operand specifier, e.g. specifier format
- G06F9/30167—Decoding the operand specifier, e.g. specifier format of immediate specifier, e.g. constants
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
- G06F9/30149—Instruction analysis, e.g. decoding, instruction word fields of variable length instructions
- G06F9/30152—Determining start or end of instruction; determining instruction length
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
- G06F9/3016—Decoding the operand specifier, e.g. specifier format
Abstract
Abstract:
A central processing unit for use in an electronic system is designed for executing instructions of variable length in which an operand specifier, i.e. an instruction for specifying the addressing mode of an operand, is independent of an operation code for determining the kind of an operation and the number of operands. Each operand specifier is formed of one or more data bytes, and has a stop bit flag indicating whether or not the particular operand specifier is the last operand specifier. By adding the stop bit flag, the operand specifier can be shared, and different processing car be executed with an identical operation code. In a case where, when operation code decoding means has provided an output indicative of the last operand, the stop bit flag is not detected in the corresponding operand specifier, the corresponding instruction is detected as an error.
A central processing unit for use in an electronic system is designed for executing instructions of variable length in which an operand specifier, i.e. an instruction for specifying the addressing mode of an operand, is independent of an operation code for determining the kind of an operation and the number of operands. Each operand specifier is formed of one or more data bytes, and has a stop bit flag indicating whether or not the particular operand specifier is the last operand specifier. By adding the stop bit flag, the operand specifier can be shared, and different processing car be executed with an identical operation code. In a case where, when operation code decoding means has provided an output indicative of the last operand, the stop bit flag is not detected in the corresponding operand specifier, the corresponding instruction is detected as an error.
Description
CENTRAL PROCESSING UNIT FOR EXECUTING
INSTRUCTIONS OF VARIABLE LENGTH
The present invention relates to a central processing unit for use in an electronic system. The unit is designed for e~ecuting instructions of variable length in which an operand specifier, i.e. an instruction for specifying the addressing mode of an operand, is independ-`~ ent of an operation code for determining the kind of processing of an operation and the number of operands.
In general, in a variabl~-length instruction scheme, even in the case of an identical operation codel instructions have various lengths. Moreover, although the head field of each instruction is always an operation code, the other parts have various significances. Therefore, the significances c~ fields in instructions are not uniquely determined.
In addition, an operand speclfier included in an instruction has its length varied corresponding to an addressing mode. Therefore, even in the case of 2n identical operation code, the lengths of instructions take various values.
Two typical known examples of instruction schemes having operand specifiers of variable lengths are as follows.
One of them consists of instruction formats used with Burroughs Corporation's Computer sl700 as COBOL/RPG-ori~nted architecture. This is described in 'IBl700 COBOL/
RPG-S-Language, 1058823-015, Copyright 1973, Burroughs Corporation".
~ (3~
The other example is an instruction scheme with operand specifiers variable in le~gth, which the architecture of DEC (Digital Equipment Corporation)'s Computer ~AXll/780 possesses. This is clescribed in "VAXll Architecture Handbook, Copyright 1~7'3" and U.S.P.
No. 4,236,206~
These two conventional instruction schemes have the feature that the parts for specifying the format of an operand and an addressing mode are prescribed by an operand specifier of variable length and are independent of the operation code.
With such conventional variable-length instructions, however, the number of operands to be processed and the operand specifiers for specifying the address;ng modes of the operands to be processed are held in correspondence at l-to-l. For example, to the two processing (operations) of:
A + B ~ B
A t B ~ C
two operation codes need to be allotted.
That is, in the processing of A + B ~B, it is necessary for the operation code to specifical~y prescribe processing of the two operands and using of the sec~7nd operand twice.
If, in the processing of A + B ~B, the number of operands is made three and three operand specifiers are prepared, the distinction between A + B ~B and A + B ~C
need not be made significant, but the two (identic-ll) operand specifiers need to be provided in the processing of A + B ~ B. This drastically lowers the packaging efficiency of a memory when the operand specifier itself ass~lmes plural bytes (in general, a long one assumes 7 bytes).
Originally, distinguishing the processing c A + B ~B and A + B >C by the use of operation ccdes has been performed in order to raise the packaging efficiency of a memory. That is, in the instruction of A + B ~ B, the opera-tion code is used to specify that the number of opc?rands ~Trade Mark is two and that the second operand specifier is used twice, wnereby the two operand specifiers are made suEficient.
Although the example of A + B--~B has been referred to, the processing of A - B --~B is similar, and the above applies to all examples in which A and ~ are operated on and the result is stored in B. In general, they are expressed as A ~ B ~B.
In this manner, ~ith conventional variable-length instructions, processing that uses the same operand a plurality of times needs to be distinguished from other processing of the same function by the operation code, and the number of processing operations that can be specified by the operation code is limited.
In addition, in a scheme in which the number of operand specifiers is ascertained by an operation code, the detection of errors in instructions has been difficult, because the relationship between the numbex of operands and that of the operand specifiers cannot be checked.
The principal object of the present invention is to provide a central processing unit for executing instructions of variable length that permit operand specifiers to be shared without distinguishing them by the use of operation codes.
Another object of the present invention is to provide a central processing unit that enhances error detectibility for instructions of variable length that permit a plurality of operands to share operand speci~iers.
To this end, the invention consists of a central processing unit for executing instructions of variable length in which an operand specifier for specifying the addressing mode of an operand is independent of an operation code for ascertaining the ~ind of an operation and the number of operands, comprising instruction fetch means for fetching an instruction from memory means storing instructions and operands, decoding means connected to said instruction fetch means for decoding an operation code and an operand speci~ier, address calculating means connected to said decoding means for calculating an address of an operand on the basis of the decoded result of the Gperand specifier from said decoding means, (D) operand fe~ch means connected to said address calculat.ing means for fetching the operand from said memory means on the basis of the calculated address, and (E) executing means connected to said operand fetch means as well as said decoding means for executing the instruction successively by the use of the operands from said operand fetch means and in accordance with the decoded results of the operation codes from said decoding means, said decoding means including; (i) operation c~de decoding means for decoding the operation codes of the instruction and delivering information on the operands in the operand specifiers, (ii) operand specifier decoding means for decoding information added to specific fields of the respective operand specifiers for deciding whether or not the particular operand specifier is the last operand specifier, and (iii) means for causing the operand specifier to be used again, in both of the cases when the information indicative of the last operand specifier is received from the operand specifier decoding means and when the information indicative of the last operand is not received from the operation code decoding means.
In the preferred embodiment of the present invention, end information (hereinbelow, termed "end flags") of operand specifiers are added to specific f'elds of the operand specifiers for specifying the addressing modes of operands; only the last operand specifier has the end flag set at "1"; and when operand specifier decode means has detected said end flag set at "1", the particular operand specifier is judged to be the last forming one instruction, whereupon the instruction is executed. As will be described later, in a case where the operand specifier decode means has detected the set of the end flag (ind:icating that the particular operand specifier is the last) beore operation code decode means provides information on the last operand, the operand corresponding to the particular operand specifier is used again. In this case, the last operand specifier is used repeatedly until the number of operands ascertained by the operation code is reached.
As another feature of the embodirnent, the error of an instruction is detected on the basis o~ the content of the (3 end flag and the number of operands ascertained by the operation code. In a case where the operand specifier decode means does not detect the set of the end flay/ wner.
the operation code decode means has provided the ~nformation on tne last operand, the particular instruction is detected as an error.
Other features of the embodirnent will become apparent from the appended claims, in the light of the follo~inq description taken in conjunction with the drawings in which:
Figure 1 is a fundamental conceptual diagram of a data processing system to which the present invention can be applied;
Figures 2A and 2B are diagrams showing examples of the format of a variable-length instruction and the format of an operand specifier for use in the present invention;
Figure 3 is a block diagram of a specific embodiment, in a case where the present invention is applied to a central processing unit as in Figure l;
Figure 4 is a block diagram of a specific embodiment of a decode unit in Figure 3, as forming an essential portion of the embodiment;
Figures 5A and 5B show the formats of operand specifiers for use in Figure 4i Figure 6 is a block diagram of an embodiment of a decode sequence controller of Figure 4, Figures 7A and 7B are explanatory diagrams for use in the explanation of the operations of an operand specifier decoder; and Figure 8 is a circuit diagram of an embodiment of a decode controller.
Figure 1 is a fundamental conceptual diagram of a data processing system to which the present invention can be applied.
A memory unit 1 and a plurality of central processing units 2 are connected by a common bus 3, through which information can be exchanged.
The memory unit 1 is constructed of a memory 11 which stores instructions and operands to be handled by the instructions, and a memory control unit 12 which controls the reading and writing of the instructions and operands. The memory 11 and the memory control unit 12 are connected by a memory bus 13.
Since the memory unit 1 is not directly pertinent to the subject matter of the present invention and its construction and operations are well known, detailed explanation of this part is om-tted.
A plurality (in the illllstration, two) of central processing units 2 can be connected to ~he common bus 3 and they access instructions and operands from the memory unit 1 so as respectively to process the instructions in successionO
Illustrated is an example wherein, in order to process instructions at high speed, instructions and operands once read out are respectively copied in an instruction cache 21 (fast buffar memory) and an operand cache 22 (fast buffer memory), and an instruction unit 23 that fetches and decodes instructions and calcula*es operand addresses, and an execution unit that etches operands and executes instructions to perform pipeline processing, respectively.
The use of such an instruction cache or operand cache, and the pipeline processing of the instruction unit and the execution unit, are known in themselves.
Figure 2A shows an example of the format of a variable-length instruction that a central pro~essing unit 2 handles.
One instruction is constructed of one operation code (usually called "ope-code") OP, and one or more operand specifiers OSl, OS2 and Sn each of which accompanies an end flag S.
The operation code oP indicates the content of the processing (the sort of processing) of the particular instruction, the number of operands necessary for the processing, and the properties (data length, distinction between read/write, data type: fixed point/floating point....
etc.) of the operands. It is composed of one to several bytes.
As described before, the operand specifier specifies the addressing mode of an operand, and whether or not the particular operand specifier is ~he last one. The length of the operand specifier is one ~o several bytes, and it varies depending upon the addressing mode and is independent of the content of the operation code.
The operand specifiers are arrayed in the order of operands to be used in the cGrresponding instruction, and only the last operand specifier has the end flag S set at "1".
In a case where the num~er of operand specifiers decoded in one instruction is smaller than the operand number indicated by the operation code OP, the operand corresponding to the last operand specifier is used repeatedly.
While the repeated use of the same operand is realized by various methods, th~ most desirable method will be the repeated use of the last operand specifier. This point will be explained in detail later.
There will now be explained an example in which the operand number specified by the operation ccde OP and the number of operand specifiers disagree~ In a case where the operation code OP indicates, e.g., the processing Gf addition, the function is generally expressed by:
A + B- -~ C
If A ~ B ~ C, it requires three operand specifiers. However, when a plurality of identical operands are used, as in the case of A = B = C, or when A ~ B = C, an identical operand specifier can be used a plurality of times. Therefore, the number of operands ascertained by the operation code and the nu~ber oi operand specifiers do not always agree.
For example, in the case of A = B = C, that is, in the processing of:
A + A D~ A
the identical operand specifier is used three times~ whereby one operand specifier suffices.
g~
In the case of A ~ B = C, tha-t is, in the processing of:
A ~ B ~B
the second operand specifier is used twice, whereby two operand specifiers suffice.
In this manner, even in addition processing of the same operation code which ascertains the operand number of three, different processing can be executed in accordance with the operand specifier numbers of one, two and three.
Specific examples of operand specifiers are shown in Figure 2B.
Examples Nos. l 24 are listed, and the formats thereof and the corresponding operands are indicated in l-to-l correspondence.
In Figure 2B, the brackets ( ) of the operand designates the content of that address o a memory which is indicated by a value ~ith the brackets ( ).
In the format, DISP designates a displacement and IM
'immediate' (data direct), and a suffix denotes the size zo thereof in terms of the number of bits.
Further, RX designates an index register and Rn a general register, and L ~enotes the size of the operand in bytes.
The relationships between the formats and operands in Figure 2B will be largely understood but will nevertheless be briefly explained below.
No. l is register direct addressing, in which the content of the general register, indicated by Rn, itself becomes an operand directly.
All of No. 2 and the following examples are operand specifiers that use the contents of a memory as operands, the addresses of the memory being calculated in the Eorms indicated in the column of operands.
No. 2 is indirect addressing, in which the content of the general register indicated by Rn becomes the address of an operand.
In each of Nos. 3, 5 and 7, a value indicated by ~ 3~
g DISP is added to ~he content of the general register indicated by ~n, and the sum becomes the address of an operand.
In Nos. 4, 6 and 8, the memory contents of the addresses ob~ained in Nos. 3, 5 and 7 respectively become the addresses of operands.
Nos. 9 - 11 are immediate data, in which the values of IM8, IM16 and IM32 become operands in themselves.
Nos. 12 - 17 differ from Nos. 3 - 8 in only the fact that a program counter PC i5 used instead of the general register Rn. The counter PC holds an address next an operand specifier to be decoded.
Nos. 18 - 24 are such that the values of the index register RX are further added to Nos. 3 - 8. In this case, the values of the index register Rx are multiplied by the data lengths L of operands (Rx L).
This is processing required for permitting the value of the index register ~x to be set as a displacement from the head irrespective of the data length L.
In other words, the multiplication by L (indicating the data length) allows the index register Rx to store a value indicating the No. of the data as reckoned from the head, irrespective of the data length.
For example, when "10" is stored in the index regi5ter Rx, i~ is the tenth data as reckoned from the head~
and, as the address thereof, 10 is automatically added (L = 1) when the data is a byte, 20 (L - 2) when it is a word, or 40 (L = 4) when it is a long word, whereby the user can set the value of the index register RX irrespective of the data length.
Figure 3 is a more specific block diagram of the central processing unit 2 in Figure 1.
In Figure 3, the parts of an instruction fetch unit (IFU) 25, an aligner (ALIG) 26, a decode unit (DU) 27 and an a~dress calculating unit (AU) 28 correspond to the instruction unit 23 in Figure 1, and an operand fetch unit ~OFU) 29 and an execute unit (EU) 30 correspond to the execu~ion unit 24.
The arrangement of Figure 1 has been described to the effect that the instruction unit 23 and the execution unit 24 perform the pipeline processing. In the example shown in Figurc 3, the respective units are Eurther divided into the instruction fetch unit IFU 25, decode unit DU 27 and address calculating unit AU 28 and into the operand fetch unit OFU
29 and execute unit 30, which perform pipeline processing respectively.
Since, however, the subject matter of the present invention is not directly pertinent to such pipeline processing, detailed description 3f it is omi~ted.
In figure 3, the instruction fetch unit 25 has a program counter 50 for fetching an instruction in advance, which coùnter performs the process of previously reading out the instruction to be subsequently execu~ed from the instruction cache 21.
An address desired to be read out is sent to the instruction cache 21 via an address line 100, and the co~responding instruction of 4 bytes is transmitted to the instruction fetch unit 25 via a data line 101.
In a case where the corresponding instruction does not exist in the instruction cache 21, the particular instruction is read out from the memory 1 through the common bus 3 and is stored in the instruction cache 21. The operations of the cache are well known, and are described in, e.g., "A Guide to the IBM System/370 Model 168".
When the instruction of 4 bytes has been transmitted to the instruction fetch unit 25, the program counter 50 is subjected to plus 4 (+ 4) and supplies the instruction cache 21 with a request for transmitting the next instruction.
This operation is continued until a buffer (not shown) disposed within the instruction fetch unit 25 is filled up.
The instruction read out in advance is transmitted from the instruction fetch unit 25 to the aligner 26 through a bus 103.
The aligner 26 transmits the particular instructior *Trade Mark 3~
-to a bus 104 after shifting it by the number of bytes instructed on a signal line 102 from the decode u~it 27.
Although the aligner 26 is shown here as being distinguished from the instruction fetch unit 25, the formex may well be considered as being included in the latter.
By properly operating the value on the siynal line 10?, the bus 104 is supplied with the instruction so that, as illustrated in Figure 5, when the first operand specifier of the instruction is to be processed, the operation code OP
may be located at the left hand end, followed by the first operand specifier, while, when the second or subsequent operand specifier is to be processed, the operand specifier may be arranged ~ith a dummy o~ 1 byte preceding. The above control will be described in detail la~er.
The decode unit 27 decodes the operation code and the operand specifiers transmitted from the aligner 26, and sends the following information to the address calcula~ing unit 28~
tl) An addressing mode is sent through a bus 105.
As explained before, there are the following addressing modes (a) - (h), one of which is specified:
(a) Register direct --- No. 1 (b) Rn --- No. 2 (c) Rn + DISP type --- Nos. 3, 5 and 7 (d) Rn + DISP indirect type --- Nos. 4, 6 and 8 (e) Immediate --- Nos~ 9, 10 and 11 (f) PC + DISP type --- Nos. 12, 14 and 16 (g) PC + DISP indirect type --- Nos~ 13, 15 and 17 (h) With indexes in (b) - (d) --- Nos. 18 - 24 Nos. 1 - 24 correspond to those of the operand specifier formats shown in Figure 2B.
~2) The DISP or immediate data is sent in 32 bits through a bus 106;
(3) The address of the general register ~n is sent through a bus 107;
(4) The address of the index register ~x is sent through a bus 108; and - ~ ~.8~
(5) The value of the program counter to be used for the address calculation is sent through a bus 116.
In accordance with the addressing mode indicated by the bus 105 and at any mode other than (a) and (e), the address calculating unit 28 calculates the address of an operand and delivers the calculated address to a bus 109.
On the other hand, in the case of (a), the content of the bus 107 is delivered to a bus 113 as it is, and in the case of (e), the content of the bus 106 is delivered to the bus 109.
In any mode other than (a) and (e), the operand fetch unit 29 supplies a bus 110 with the content of the bus 109 indicative of the sent address. When the operand is "read", the unit 29 requests the operand cache 22 to perform a read processing.
When a read operand has been delivered from the operand cache 22 to a bus 111, the operand fetch unit 29 delivers the read operand to the e~ecute unit 30 through a bus 112 and communicates to the effect that the operands are ready.
When the operand is "writ~", the operand fetch unit 29 continues to deliver the address to the bus 110 until write data from the execute unit 30 is delivered to the bus 111.
On the other hand, as regards mode (a), the operand fetch unit 29 accesses the general register (not shown) on the basis of the register address 113 transmitted from the address calculating unit 28. The only difference from the modes other than (a) is whether the memory or the register is accessed.
Regarding (e), the unit 29 supplies the bus 111 with the content of the bus 109 as it is, and informs the execute unit 30 to the effect that the operands are ready.
In addition, the execute unit 30 receives the head address of a microprogram transmitted through an operation code bus 114 from the decode unit 27, and it successi~ely processes the instruction by employing the operands of the bus 112, in the case of a "read" operand, and by delivering 3~
the operands (data) to the bus 111 in the case of a "write"
operand.
Further, in a case where the ins-truction is a branch instruction, a new program counter value is set in the program counter 50 of the inskruction fetch unit 25 or in a DP register 69 (Figure 4) within the decode unit 27 to be explained later~ and simultaneously, the processed results, in the respective units, on the operands previously processed by the pipeline processing are cancelled, by the use of a bus llS.
- The above is the outline of processing for one operand specifier, and the respective units (25 - 30~ perform the processing of the operand specifier in succession and in parallel by the pipeline processing me~hod.
As to the decode unit 27, a specific example will now be described in detail in connection with Figure 4.
The register 69 indicates the head of the instruction to be decoded by the decode unit 27. In decoding the first operand specifier, it indicates the address of the operation code, and in decoding the second or subsequent operand specifier, it indicates the address of (the head of the particular operand specifier) - 1.
The above address is transmitted to the aligner 26 and instruction fetch unit 25 shown in Figure 3, through the bus 102. The bus 104 is simultaneously supplied from the aligner 26 with plural bytes of data corresponding to the above address. As seen from Figure 5A, the first byte of the bus 104 is supplied with the operation code OP in the case of reading out the first operand specifier~ or with dummy data as shown in Figure 5B in the case of reading out the second or subsequent operand specifier. The second byte is supplied with the operand specifier including the end flag S, and the third to seventh bytes are supplied wikh the other inormation of the particular operand specifier.
A bus 204 affords information indicating which operand is being processed. When the information indicates the end of processing of all the operands, the first by-te of the bus 104 is set in an operation code regisker 640 An output from the operation code register 64 is sent to a microprogram address generatox (MAG) 61 which finds the head address of the microprogram of the corresponding instruction in the execute unit 30, and a decode sequence controller (DSC) 63 which provides information for the operands of the corresponding instruction.
The output re~ult 201 of the MAG 61 is set in a head address register 62, and it is delivered to the execute unit 30 through the operation code bus 114 in synchronism with . the delivery of the first operand from the operand fetch unit 29 to the execute unit 30.
The DSC 63 has, for example, an arrangement as shown in Figure 6. Information as shown in Figure 6 is set in a ROM 82 beforehand, and is read out by employing the operation code and the information indicative of the processing of Nos. of the operands as addresses.
More specifically, when the first byte has been set in the operation code register 64, the side of a bus 200 is selected by a selector SEL 81, and information on the first operand is read out with the operation code as an address The information read out includes:
(1) the properties of the operand, namely, information R/W
of read operand or write operand and information indicating the data length L (byte, word, long word) of the operand,
INSTRUCTIONS OF VARIABLE LENGTH
The present invention relates to a central processing unit for use in an electronic system. The unit is designed for e~ecuting instructions of variable length in which an operand specifier, i.e. an instruction for specifying the addressing mode of an operand, is independ-`~ ent of an operation code for determining the kind of processing of an operation and the number of operands.
In general, in a variabl~-length instruction scheme, even in the case of an identical operation codel instructions have various lengths. Moreover, although the head field of each instruction is always an operation code, the other parts have various significances. Therefore, the significances c~ fields in instructions are not uniquely determined.
In addition, an operand speclfier included in an instruction has its length varied corresponding to an addressing mode. Therefore, even in the case of 2n identical operation code, the lengths of instructions take various values.
Two typical known examples of instruction schemes having operand specifiers of variable lengths are as follows.
One of them consists of instruction formats used with Burroughs Corporation's Computer sl700 as COBOL/RPG-ori~nted architecture. This is described in 'IBl700 COBOL/
RPG-S-Language, 1058823-015, Copyright 1973, Burroughs Corporation".
~ (3~
The other example is an instruction scheme with operand specifiers variable in le~gth, which the architecture of DEC (Digital Equipment Corporation)'s Computer ~AXll/780 possesses. This is clescribed in "VAXll Architecture Handbook, Copyright 1~7'3" and U.S.P.
No. 4,236,206~
These two conventional instruction schemes have the feature that the parts for specifying the format of an operand and an addressing mode are prescribed by an operand specifier of variable length and are independent of the operation code.
With such conventional variable-length instructions, however, the number of operands to be processed and the operand specifiers for specifying the address;ng modes of the operands to be processed are held in correspondence at l-to-l. For example, to the two processing (operations) of:
A + B ~ B
A t B ~ C
two operation codes need to be allotted.
That is, in the processing of A + B ~B, it is necessary for the operation code to specifical~y prescribe processing of the two operands and using of the sec~7nd operand twice.
If, in the processing of A + B ~B, the number of operands is made three and three operand specifiers are prepared, the distinction between A + B ~B and A + B ~C
need not be made significant, but the two (identic-ll) operand specifiers need to be provided in the processing of A + B ~ B. This drastically lowers the packaging efficiency of a memory when the operand specifier itself ass~lmes plural bytes (in general, a long one assumes 7 bytes).
Originally, distinguishing the processing c A + B ~B and A + B >C by the use of operation ccdes has been performed in order to raise the packaging efficiency of a memory. That is, in the instruction of A + B ~ B, the opera-tion code is used to specify that the number of opc?rands ~Trade Mark is two and that the second operand specifier is used twice, wnereby the two operand specifiers are made suEficient.
Although the example of A + B--~B has been referred to, the processing of A - B --~B is similar, and the above applies to all examples in which A and ~ are operated on and the result is stored in B. In general, they are expressed as A ~ B ~B.
In this manner, ~ith conventional variable-length instructions, processing that uses the same operand a plurality of times needs to be distinguished from other processing of the same function by the operation code, and the number of processing operations that can be specified by the operation code is limited.
In addition, in a scheme in which the number of operand specifiers is ascertained by an operation code, the detection of errors in instructions has been difficult, because the relationship between the numbex of operands and that of the operand specifiers cannot be checked.
The principal object of the present invention is to provide a central processing unit for executing instructions of variable length that permit operand specifiers to be shared without distinguishing them by the use of operation codes.
Another object of the present invention is to provide a central processing unit that enhances error detectibility for instructions of variable length that permit a plurality of operands to share operand speci~iers.
To this end, the invention consists of a central processing unit for executing instructions of variable length in which an operand specifier for specifying the addressing mode of an operand is independent of an operation code for ascertaining the ~ind of an operation and the number of operands, comprising instruction fetch means for fetching an instruction from memory means storing instructions and operands, decoding means connected to said instruction fetch means for decoding an operation code and an operand speci~ier, address calculating means connected to said decoding means for calculating an address of an operand on the basis of the decoded result of the Gperand specifier from said decoding means, (D) operand fe~ch means connected to said address calculat.ing means for fetching the operand from said memory means on the basis of the calculated address, and (E) executing means connected to said operand fetch means as well as said decoding means for executing the instruction successively by the use of the operands from said operand fetch means and in accordance with the decoded results of the operation codes from said decoding means, said decoding means including; (i) operation c~de decoding means for decoding the operation codes of the instruction and delivering information on the operands in the operand specifiers, (ii) operand specifier decoding means for decoding information added to specific fields of the respective operand specifiers for deciding whether or not the particular operand specifier is the last operand specifier, and (iii) means for causing the operand specifier to be used again, in both of the cases when the information indicative of the last operand specifier is received from the operand specifier decoding means and when the information indicative of the last operand is not received from the operation code decoding means.
In the preferred embodiment of the present invention, end information (hereinbelow, termed "end flags") of operand specifiers are added to specific f'elds of the operand specifiers for specifying the addressing modes of operands; only the last operand specifier has the end flag set at "1"; and when operand specifier decode means has detected said end flag set at "1", the particular operand specifier is judged to be the last forming one instruction, whereupon the instruction is executed. As will be described later, in a case where the operand specifier decode means has detected the set of the end flag (ind:icating that the particular operand specifier is the last) beore operation code decode means provides information on the last operand, the operand corresponding to the particular operand specifier is used again. In this case, the last operand specifier is used repeatedly until the number of operands ascertained by the operation code is reached.
As another feature of the embodirnent, the error of an instruction is detected on the basis o~ the content of the (3 end flag and the number of operands ascertained by the operation code. In a case where the operand specifier decode means does not detect the set of the end flay/ wner.
the operation code decode means has provided the ~nformation on tne last operand, the particular instruction is detected as an error.
Other features of the embodirnent will become apparent from the appended claims, in the light of the follo~inq description taken in conjunction with the drawings in which:
Figure 1 is a fundamental conceptual diagram of a data processing system to which the present invention can be applied;
Figures 2A and 2B are diagrams showing examples of the format of a variable-length instruction and the format of an operand specifier for use in the present invention;
Figure 3 is a block diagram of a specific embodiment, in a case where the present invention is applied to a central processing unit as in Figure l;
Figure 4 is a block diagram of a specific embodiment of a decode unit in Figure 3, as forming an essential portion of the embodiment;
Figures 5A and 5B show the formats of operand specifiers for use in Figure 4i Figure 6 is a block diagram of an embodiment of a decode sequence controller of Figure 4, Figures 7A and 7B are explanatory diagrams for use in the explanation of the operations of an operand specifier decoder; and Figure 8 is a circuit diagram of an embodiment of a decode controller.
Figure 1 is a fundamental conceptual diagram of a data processing system to which the present invention can be applied.
A memory unit 1 and a plurality of central processing units 2 are connected by a common bus 3, through which information can be exchanged.
The memory unit 1 is constructed of a memory 11 which stores instructions and operands to be handled by the instructions, and a memory control unit 12 which controls the reading and writing of the instructions and operands. The memory 11 and the memory control unit 12 are connected by a memory bus 13.
Since the memory unit 1 is not directly pertinent to the subject matter of the present invention and its construction and operations are well known, detailed explanation of this part is om-tted.
A plurality (in the illllstration, two) of central processing units 2 can be connected to ~he common bus 3 and they access instructions and operands from the memory unit 1 so as respectively to process the instructions in successionO
Illustrated is an example wherein, in order to process instructions at high speed, instructions and operands once read out are respectively copied in an instruction cache 21 (fast buffar memory) and an operand cache 22 (fast buffer memory), and an instruction unit 23 that fetches and decodes instructions and calcula*es operand addresses, and an execution unit that etches operands and executes instructions to perform pipeline processing, respectively.
The use of such an instruction cache or operand cache, and the pipeline processing of the instruction unit and the execution unit, are known in themselves.
Figure 2A shows an example of the format of a variable-length instruction that a central pro~essing unit 2 handles.
One instruction is constructed of one operation code (usually called "ope-code") OP, and one or more operand specifiers OSl, OS2 and Sn each of which accompanies an end flag S.
The operation code oP indicates the content of the processing (the sort of processing) of the particular instruction, the number of operands necessary for the processing, and the properties (data length, distinction between read/write, data type: fixed point/floating point....
etc.) of the operands. It is composed of one to several bytes.
As described before, the operand specifier specifies the addressing mode of an operand, and whether or not the particular operand specifier is ~he last one. The length of the operand specifier is one ~o several bytes, and it varies depending upon the addressing mode and is independent of the content of the operation code.
The operand specifiers are arrayed in the order of operands to be used in the cGrresponding instruction, and only the last operand specifier has the end flag S set at "1".
In a case where the num~er of operand specifiers decoded in one instruction is smaller than the operand number indicated by the operation code OP, the operand corresponding to the last operand specifier is used repeatedly.
While the repeated use of the same operand is realized by various methods, th~ most desirable method will be the repeated use of the last operand specifier. This point will be explained in detail later.
There will now be explained an example in which the operand number specified by the operation ccde OP and the number of operand specifiers disagree~ In a case where the operation code OP indicates, e.g., the processing Gf addition, the function is generally expressed by:
A + B- -~ C
If A ~ B ~ C, it requires three operand specifiers. However, when a plurality of identical operands are used, as in the case of A = B = C, or when A ~ B = C, an identical operand specifier can be used a plurality of times. Therefore, the number of operands ascertained by the operation code and the nu~ber oi operand specifiers do not always agree.
For example, in the case of A = B = C, that is, in the processing of:
A + A D~ A
the identical operand specifier is used three times~ whereby one operand specifier suffices.
g~
In the case of A ~ B = C, tha-t is, in the processing of:
A ~ B ~B
the second operand specifier is used twice, whereby two operand specifiers suffice.
In this manner, even in addition processing of the same operation code which ascertains the operand number of three, different processing can be executed in accordance with the operand specifier numbers of one, two and three.
Specific examples of operand specifiers are shown in Figure 2B.
Examples Nos. l 24 are listed, and the formats thereof and the corresponding operands are indicated in l-to-l correspondence.
In Figure 2B, the brackets ( ) of the operand designates the content of that address o a memory which is indicated by a value ~ith the brackets ( ).
In the format, DISP designates a displacement and IM
'immediate' (data direct), and a suffix denotes the size zo thereof in terms of the number of bits.
Further, RX designates an index register and Rn a general register, and L ~enotes the size of the operand in bytes.
The relationships between the formats and operands in Figure 2B will be largely understood but will nevertheless be briefly explained below.
No. l is register direct addressing, in which the content of the general register, indicated by Rn, itself becomes an operand directly.
All of No. 2 and the following examples are operand specifiers that use the contents of a memory as operands, the addresses of the memory being calculated in the Eorms indicated in the column of operands.
No. 2 is indirect addressing, in which the content of the general register indicated by Rn becomes the address of an operand.
In each of Nos. 3, 5 and 7, a value indicated by ~ 3~
g DISP is added to ~he content of the general register indicated by ~n, and the sum becomes the address of an operand.
In Nos. 4, 6 and 8, the memory contents of the addresses ob~ained in Nos. 3, 5 and 7 respectively become the addresses of operands.
Nos. 9 - 11 are immediate data, in which the values of IM8, IM16 and IM32 become operands in themselves.
Nos. 12 - 17 differ from Nos. 3 - 8 in only the fact that a program counter PC i5 used instead of the general register Rn. The counter PC holds an address next an operand specifier to be decoded.
Nos. 18 - 24 are such that the values of the index register RX are further added to Nos. 3 - 8. In this case, the values of the index register Rx are multiplied by the data lengths L of operands (Rx L).
This is processing required for permitting the value of the index register ~x to be set as a displacement from the head irrespective of the data length L.
In other words, the multiplication by L (indicating the data length) allows the index register Rx to store a value indicating the No. of the data as reckoned from the head, irrespective of the data length.
For example, when "10" is stored in the index regi5ter Rx, i~ is the tenth data as reckoned from the head~
and, as the address thereof, 10 is automatically added (L = 1) when the data is a byte, 20 (L - 2) when it is a word, or 40 (L = 4) when it is a long word, whereby the user can set the value of the index register RX irrespective of the data length.
Figure 3 is a more specific block diagram of the central processing unit 2 in Figure 1.
In Figure 3, the parts of an instruction fetch unit (IFU) 25, an aligner (ALIG) 26, a decode unit (DU) 27 and an a~dress calculating unit (AU) 28 correspond to the instruction unit 23 in Figure 1, and an operand fetch unit ~OFU) 29 and an execute unit (EU) 30 correspond to the execu~ion unit 24.
The arrangement of Figure 1 has been described to the effect that the instruction unit 23 and the execution unit 24 perform the pipeline processing. In the example shown in Figurc 3, the respective units are Eurther divided into the instruction fetch unit IFU 25, decode unit DU 27 and address calculating unit AU 28 and into the operand fetch unit OFU
29 and execute unit 30, which perform pipeline processing respectively.
Since, however, the subject matter of the present invention is not directly pertinent to such pipeline processing, detailed description 3f it is omi~ted.
In figure 3, the instruction fetch unit 25 has a program counter 50 for fetching an instruction in advance, which coùnter performs the process of previously reading out the instruction to be subsequently execu~ed from the instruction cache 21.
An address desired to be read out is sent to the instruction cache 21 via an address line 100, and the co~responding instruction of 4 bytes is transmitted to the instruction fetch unit 25 via a data line 101.
In a case where the corresponding instruction does not exist in the instruction cache 21, the particular instruction is read out from the memory 1 through the common bus 3 and is stored in the instruction cache 21. The operations of the cache are well known, and are described in, e.g., "A Guide to the IBM System/370 Model 168".
When the instruction of 4 bytes has been transmitted to the instruction fetch unit 25, the program counter 50 is subjected to plus 4 (+ 4) and supplies the instruction cache 21 with a request for transmitting the next instruction.
This operation is continued until a buffer (not shown) disposed within the instruction fetch unit 25 is filled up.
The instruction read out in advance is transmitted from the instruction fetch unit 25 to the aligner 26 through a bus 103.
The aligner 26 transmits the particular instructior *Trade Mark 3~
-to a bus 104 after shifting it by the number of bytes instructed on a signal line 102 from the decode u~it 27.
Although the aligner 26 is shown here as being distinguished from the instruction fetch unit 25, the formex may well be considered as being included in the latter.
By properly operating the value on the siynal line 10?, the bus 104 is supplied with the instruction so that, as illustrated in Figure 5, when the first operand specifier of the instruction is to be processed, the operation code OP
may be located at the left hand end, followed by the first operand specifier, while, when the second or subsequent operand specifier is to be processed, the operand specifier may be arranged ~ith a dummy o~ 1 byte preceding. The above control will be described in detail la~er.
The decode unit 27 decodes the operation code and the operand specifiers transmitted from the aligner 26, and sends the following information to the address calcula~ing unit 28~
tl) An addressing mode is sent through a bus 105.
As explained before, there are the following addressing modes (a) - (h), one of which is specified:
(a) Register direct --- No. 1 (b) Rn --- No. 2 (c) Rn + DISP type --- Nos. 3, 5 and 7 (d) Rn + DISP indirect type --- Nos. 4, 6 and 8 (e) Immediate --- Nos~ 9, 10 and 11 (f) PC + DISP type --- Nos. 12, 14 and 16 (g) PC + DISP indirect type --- Nos~ 13, 15 and 17 (h) With indexes in (b) - (d) --- Nos. 18 - 24 Nos. 1 - 24 correspond to those of the operand specifier formats shown in Figure 2B.
~2) The DISP or immediate data is sent in 32 bits through a bus 106;
(3) The address of the general register ~n is sent through a bus 107;
(4) The address of the index register ~x is sent through a bus 108; and - ~ ~.8~
(5) The value of the program counter to be used for the address calculation is sent through a bus 116.
In accordance with the addressing mode indicated by the bus 105 and at any mode other than (a) and (e), the address calculating unit 28 calculates the address of an operand and delivers the calculated address to a bus 109.
On the other hand, in the case of (a), the content of the bus 107 is delivered to a bus 113 as it is, and in the case of (e), the content of the bus 106 is delivered to the bus 109.
In any mode other than (a) and (e), the operand fetch unit 29 supplies a bus 110 with the content of the bus 109 indicative of the sent address. When the operand is "read", the unit 29 requests the operand cache 22 to perform a read processing.
When a read operand has been delivered from the operand cache 22 to a bus 111, the operand fetch unit 29 delivers the read operand to the e~ecute unit 30 through a bus 112 and communicates to the effect that the operands are ready.
When the operand is "writ~", the operand fetch unit 29 continues to deliver the address to the bus 110 until write data from the execute unit 30 is delivered to the bus 111.
On the other hand, as regards mode (a), the operand fetch unit 29 accesses the general register (not shown) on the basis of the register address 113 transmitted from the address calculating unit 28. The only difference from the modes other than (a) is whether the memory or the register is accessed.
Regarding (e), the unit 29 supplies the bus 111 with the content of the bus 109 as it is, and informs the execute unit 30 to the effect that the operands are ready.
In addition, the execute unit 30 receives the head address of a microprogram transmitted through an operation code bus 114 from the decode unit 27, and it successi~ely processes the instruction by employing the operands of the bus 112, in the case of a "read" operand, and by delivering 3~
the operands (data) to the bus 111 in the case of a "write"
operand.
Further, in a case where the ins-truction is a branch instruction, a new program counter value is set in the program counter 50 of the inskruction fetch unit 25 or in a DP register 69 (Figure 4) within the decode unit 27 to be explained later~ and simultaneously, the processed results, in the respective units, on the operands previously processed by the pipeline processing are cancelled, by the use of a bus llS.
- The above is the outline of processing for one operand specifier, and the respective units (25 - 30~ perform the processing of the operand specifier in succession and in parallel by the pipeline processing me~hod.
As to the decode unit 27, a specific example will now be described in detail in connection with Figure 4.
The register 69 indicates the head of the instruction to be decoded by the decode unit 27. In decoding the first operand specifier, it indicates the address of the operation code, and in decoding the second or subsequent operand specifier, it indicates the address of (the head of the particular operand specifier) - 1.
The above address is transmitted to the aligner 26 and instruction fetch unit 25 shown in Figure 3, through the bus 102. The bus 104 is simultaneously supplied from the aligner 26 with plural bytes of data corresponding to the above address. As seen from Figure 5A, the first byte of the bus 104 is supplied with the operation code OP in the case of reading out the first operand specifier~ or with dummy data as shown in Figure 5B in the case of reading out the second or subsequent operand specifier. The second byte is supplied with the operand specifier including the end flag S, and the third to seventh bytes are supplied wikh the other inormation of the particular operand specifier.
A bus 204 affords information indicating which operand is being processed. When the information indicates the end of processing of all the operands, the first by-te of the bus 104 is set in an operation code regisker 640 An output from the operation code register 64 is sent to a microprogram address generatox (MAG) 61 which finds the head address of the microprogram of the corresponding instruction in the execute unit 30, and a decode sequence controller (DSC) 63 which provides information for the operands of the corresponding instruction.
The output re~ult 201 of the MAG 61 is set in a head address register 62, and it is delivered to the execute unit 30 through the operation code bus 114 in synchronism with . the delivery of the first operand from the operand fetch unit 29 to the execute unit 30.
The DSC 63 has, for example, an arrangement as shown in Figure 6. Information as shown in Figure 6 is set in a ROM 82 beforehand, and is read out by employing the operation code and the information indicative of the processing of Nos. of the operands as addresses.
More specifically, when the first byte has been set in the operation code register 64, the side of a bus 200 is selected by a selector SEL 81, and information on the first operand is read out with the operation code as an address The information read out includes:
(1) the properties of the operand, namely, information R/W
of read operand or write operand and information indicating the data length L (byte, word, long word) of the operand,
(2) a flag E indicating the last of the operand, and
(3) an address in which the information of the ne~t operand of the same instruction is stored.
The information (1) is delivered to a bus 105~1 and transmitted to the address calculating unit 28t and the information t2) is delivered to a bus 203 and transmitted to a decode controller (DEC) 65.
The information of Items (2) and (3) is latched in a register 83, and is used as the address for reading out the information on the next operand.
o~
Upon receiving the information E of ~tem (2) at its selec-t terminal T, the selector gl selects the side of the bus 200 (the side of the operation code register 64) ~hen the information E is "1", and -the side of the bus 204 (the next operand information address) when the information is "0".
Accordingly~ when the information E is "0", information on the operand is successively read out from the ROM 82.
Also, the signal line 205 within the bus 104 that indicates the end flag S is connected to the decode controller 65.
Since the end flag S is indicated by one bit, it merely passes through an operand specifier decoder 66.
However, in a case where the end information S itself is added to the operand specifier as one code signal, this signal is detected by the operand specifier decoder 66 to check if the particular operand specifier is the last operand specifier~
In addition, the head 7 bits of the operand 20 specifier are sent to the operand specifier decoder 66 by a bus 206.
The operand specifier is decoded by the information of 7 bits, and an example of the decoding will be explained with reference to Figures 7A and 7B.
When, by way of example, the operand specifier (Rn + DISP8) indicated at No. 3 in Figure 2B has been sent, it is detected that 3 bits in the upper 7 bits are 010, as shown in Figure 7A, whereby the following five pieces Gf information can be provided:
(1) The operand specifier has a length of 2 bytes.
(2) In a case where the content of a bus 208 is de].ivered to the bus 106, a right shift of 3 bytes is necessary for adjusting the digit of the DISP.
(3) In order to render the DISP value 4 bytes, the upper 3 bytes are provided by code-expanding the most significant bit (M) of the DISP8~
~ 16 -
The information (1) is delivered to a bus 105~1 and transmitted to the address calculating unit 28t and the information t2) is delivered to a bus 203 and transmitted to a decode controller (DEC) 65.
The information of Items (2) and (3) is latched in a register 83, and is used as the address for reading out the information on the next operand.
o~
Upon receiving the information E of ~tem (2) at its selec-t terminal T, the selector gl selects the side of the bus 200 (the side of the operation code register 64) ~hen the information E is "1", and -the side of the bus 204 (the next operand information address) when the information is "0".
Accordingly~ when the information E is "0", information on the operand is successively read out from the ROM 82.
Also, the signal line 205 within the bus 104 that indicates the end flag S is connected to the decode controller 65.
Since the end flag S is indicated by one bit, it merely passes through an operand specifier decoder 66.
However, in a case where the end information S itself is added to the operand specifier as one code signal, this signal is detected by the operand specifier decoder 66 to check if the particular operand specifier is the last operand specifier~
In addition, the head 7 bits of the operand 20 specifier are sent to the operand specifier decoder 66 by a bus 206.
The operand specifier is decoded by the information of 7 bits, and an example of the decoding will be explained with reference to Figures 7A and 7B.
When, by way of example, the operand specifier (Rn + DISP8) indicated at No. 3 in Figure 2B has been sent, it is detected that 3 bits in the upper 7 bits are 010, as shown in Figure 7A, whereby the following five pieces Gf information can be provided:
(1) The operand specifier has a length of 2 bytes.
(2) In a case where the content of a bus 208 is de].ivered to the bus 106, a right shift of 3 bytes is necessary for adjusting the digit of the DISP.
(3) In order to render the DISP value 4 bytes, the upper 3 bytes are provided by code-expanding the most significant bit (M) of the DISP8~
~ 16 -
(4) With Rn + DISP8, the address or the operand can be calculatedO
(5) The information of P~ exists in the lower 4 bits of the first byte.
Likewise, when (Rn ~ DISP32) at No. 7 in Figure 2s has been sent, it is detected that the upper 7 bits except the end flag bi~ S are 1110110, as shown in Figure 7B, whereby the following five pieces of information can be provided:
(1) The operand specifier has a length of 6 bytes.
(2) In a case where the content of the bus 208 iCI delivered to the bus 106, a left shift of 1 byte is necessary for adjusting the digit of the DISP.
(3) Since the DISP has all 32 bits specified, it must be provided as it is.
~4) With Rn + DISP32, the address of the operand can be calculated.
(5) The information of Rn exists in the lower 4 bits of the second byte of the operand specifier.
These two examples can be summed up as follows:
The operand specifier decoder 66 decodes the operand specifier sent in, and provides the respective information mentioned below.
(1) A bus 215 is supplied with the length of the operarld specifier. By way of example, when khe operand specifier (Rn + DISP8), which is the operand specifier No. 3 in the Figure 2B, has been sent in, "2" is provided.
(2) A bus 211 is supplied with the number of shift bytes for an aligner 67 for displacement (DISP)/immediate (IM) data.
For example, in the case of the operand specifier (Rn + DISP8), l-he right shift of 3 bytes is instructed as shown in Figure 7A, and in the case of (Rn + DISP 32), the left shift of 1 byte as shown in Fiyure 7B.
(3) A bus 212 is supplied with instruction data of mask bytes for the aligner 67.
That is, in the data of 4 bytes which are delivered to the bus 106 for the aligner 67, the mask of the upper 2 bytes or 3 bytes is instructed, whereby the DISP or IM
information of 1 byte or 2 bytes can be rendered 4 bytes by code exp~nsion.
For example, the DISP8 is shifted by 3 bytes as shown in Figure 7A, and the DISP32 is shifted leftward by 1 byte, because it is preceded by one surplus byte of "-Rn", as shown in Figure 7B.
The reason is that, unless the upper 3 bytes of the DISP8 have therein the code bits of the DISP8 as expanded, the normal address calculation of 32 bits cannot be performedO (The bus 212 serves for the specification thereof).
t4) A bus 105-2 is supplied with an addressing mode, by which the operating mode of the addr~ss calculating unit 28 is instructed.
Regarding the addressing modes, the presence of the 8 modes (a) - (h) has already been explained in connection with the description of the address calculating unit 28 in Figure 3.
(5) A bus 216 is supplied with information indicating whether the position in which the general register Rn exists is the first byte or the second byte.
The first byte is indicated for (Rn ~ DISP8), and the second byte for (Rn -~ DISP32).
On the other hand, the bus 108 is supplied with the part of the index register Rx in the operand specifier.
Depending upon the position at which the general register Rn is located, as indicated by the signal 216 (the signal indicative of the first byte or the second byte), the selector 68 supplies the bus lG7 with a part corresponding to the Rn (the content of a bus 207 or the content of a bus 210).
Since the aligner 57 is given the second to seventh bytes of the operand specifier by the bus 208, as stated before, it performs the shift processing by the shift number given by the signal line 211 and also performs the code expansion for the mask part given by the signal line 212, whereby to deliver the data of 4 bytes to the bus ]06.
o~
These are as shown in Figures 7A and 7B.
The decode controller 65 will now be described.
This portion is an essential part when handling the variable-length instruction (with -the S bit added) according to the present construction.
As stated previously, the decode controller 65 has three input signal lines: the signal line 203, indicating -the operand end flag E; the signal llne ~05, indicating the end flag S of the operand specifier; and the signal line 215~ indicating the byte number (OSB) of the operand specifier. It delivers the added value DPINCB of the DP 69 to a signal line 214 in byte units. The algorithm in this case is as follows:
If E = 1, DPINCB = OSB
Otherwise, at S = O, DPINCE~ = OSB - 1 and at S = 1, DPINCB = O
That is;
(1) in a case where the end flag E of the operand is "1", all the operands of the corresponding instruction have been obtained, and, hence, in order to point at the head of the ~ next instruction, the output is delivered to the signal line 214 so that the content of the DP register 69 may have the byte number ~OSB) of the operand specifier add~d thereto.
(2) In a case other than (1)~ namely in a case where E = O
and where the end flag S is not set yet, the output is delivered to the signal line 214 so that the value of ~the number of bytes of the operand specifier- OSB) - 1 may be added, in order to deliver the next operand specifier to the bus 104 with the dummy of 1 byte located at the head byte.
~3) In a case other than ~1), namely in a case where E = O
and where the end flag S is set, "O" is provided s~ that the DP register 69 may hold its value intact. The same operand specifier is thus used for processing the next operand and is used repeatedly.
3~
Figure 8 shows a hardware arrangement that realizes the algorithm in -the decode controller 65.
In the case of E - 1, an output gate 301 is ~nabled to deliver the content oss of the bus 215 to the bus 214, while in the case of E = O, at S = O, a gate 307 turns "on" and an output gate 303 is enabled to deliver OSB
- 1, and at S = 1, a gate 306 turns "on" and an output gate 302 is enabled to deliver "O".
Un].ess the S bit is 1 when E is 1, it is signified that operand specifiers larger in number than operands exist.
In Figure 8, an AND gate 309 turns "on" to provide an error signal lQ5-3 and to communicate the occurrence of the error to the address calculating unit 28.
The address calculating unit 28 communicates the error signal 105-3 to the ensuing unit (operand fetch unit 29), and the occurrence of the error is finally communicated to the execute unit 30.
In Fi~ure 8, numerals 304 and 305 designate inverters, numerals 306, 307, and 309 AND gates, and numeral 308 a subtractor for (OS8 - 1).
An adder 71 adds the current value of the DP
register 69 and that of the signal line 214 and sets the sum in the DP register 69 through a selector 70O The address of the next operand specifier is thus supplied to the bus 102.
In this way, the aligner 26 can deliver the next operand specifier to the bus 104 in the format shown in Figure 5A or B.
On the other hand, the content of the bus 115 is selecfed by the selector 70 and set in the DP register 69, whereby the change of the content of the DP register 69 in the foregoing branch instruction is also permittedO
An adder 72 adds the value ~OSB) of th~ signal line 215 (indicating the length of the corresponding op~rand specifier) to the value of the DP register 69 and further adds a carry input "1", whereby to supply the bus 116 with an address next the operand specifier being decodedO
Likewise, when (Rn ~ DISP32) at No. 7 in Figure 2s has been sent, it is detected that the upper 7 bits except the end flag bi~ S are 1110110, as shown in Figure 7B, whereby the following five pieces of information can be provided:
(1) The operand specifier has a length of 6 bytes.
(2) In a case where the content of the bus 208 iCI delivered to the bus 106, a left shift of 1 byte is necessary for adjusting the digit of the DISP.
(3) Since the DISP has all 32 bits specified, it must be provided as it is.
~4) With Rn + DISP32, the address of the operand can be calculated.
(5) The information of Rn exists in the lower 4 bits of the second byte of the operand specifier.
These two examples can be summed up as follows:
The operand specifier decoder 66 decodes the operand specifier sent in, and provides the respective information mentioned below.
(1) A bus 215 is supplied with the length of the operarld specifier. By way of example, when khe operand specifier (Rn + DISP8), which is the operand specifier No. 3 in the Figure 2B, has been sent in, "2" is provided.
(2) A bus 211 is supplied with the number of shift bytes for an aligner 67 for displacement (DISP)/immediate (IM) data.
For example, in the case of the operand specifier (Rn + DISP8), l-he right shift of 3 bytes is instructed as shown in Figure 7A, and in the case of (Rn + DISP 32), the left shift of 1 byte as shown in Fiyure 7B.
(3) A bus 212 is supplied with instruction data of mask bytes for the aligner 67.
That is, in the data of 4 bytes which are delivered to the bus 106 for the aligner 67, the mask of the upper 2 bytes or 3 bytes is instructed, whereby the DISP or IM
information of 1 byte or 2 bytes can be rendered 4 bytes by code exp~nsion.
For example, the DISP8 is shifted by 3 bytes as shown in Figure 7A, and the DISP32 is shifted leftward by 1 byte, because it is preceded by one surplus byte of "-Rn", as shown in Figure 7B.
The reason is that, unless the upper 3 bytes of the DISP8 have therein the code bits of the DISP8 as expanded, the normal address calculation of 32 bits cannot be performedO (The bus 212 serves for the specification thereof).
t4) A bus 105-2 is supplied with an addressing mode, by which the operating mode of the addr~ss calculating unit 28 is instructed.
Regarding the addressing modes, the presence of the 8 modes (a) - (h) has already been explained in connection with the description of the address calculating unit 28 in Figure 3.
(5) A bus 216 is supplied with information indicating whether the position in which the general register Rn exists is the first byte or the second byte.
The first byte is indicated for (Rn ~ DISP8), and the second byte for (Rn -~ DISP32).
On the other hand, the bus 108 is supplied with the part of the index register Rx in the operand specifier.
Depending upon the position at which the general register Rn is located, as indicated by the signal 216 (the signal indicative of the first byte or the second byte), the selector 68 supplies the bus lG7 with a part corresponding to the Rn (the content of a bus 207 or the content of a bus 210).
Since the aligner 57 is given the second to seventh bytes of the operand specifier by the bus 208, as stated before, it performs the shift processing by the shift number given by the signal line 211 and also performs the code expansion for the mask part given by the signal line 212, whereby to deliver the data of 4 bytes to the bus ]06.
o~
These are as shown in Figures 7A and 7B.
The decode controller 65 will now be described.
This portion is an essential part when handling the variable-length instruction (with -the S bit added) according to the present construction.
As stated previously, the decode controller 65 has three input signal lines: the signal line 203, indicating -the operand end flag E; the signal llne ~05, indicating the end flag S of the operand specifier; and the signal line 215~ indicating the byte number (OSB) of the operand specifier. It delivers the added value DPINCB of the DP 69 to a signal line 214 in byte units. The algorithm in this case is as follows:
If E = 1, DPINCB = OSB
Otherwise, at S = O, DPINCE~ = OSB - 1 and at S = 1, DPINCB = O
That is;
(1) in a case where the end flag E of the operand is "1", all the operands of the corresponding instruction have been obtained, and, hence, in order to point at the head of the ~ next instruction, the output is delivered to the signal line 214 so that the content of the DP register 69 may have the byte number ~OSB) of the operand specifier add~d thereto.
(2) In a case other than (1)~ namely in a case where E = O
and where the end flag S is not set yet, the output is delivered to the signal line 214 so that the value of ~the number of bytes of the operand specifier- OSB) - 1 may be added, in order to deliver the next operand specifier to the bus 104 with the dummy of 1 byte located at the head byte.
~3) In a case other than ~1), namely in a case where E = O
and where the end flag S is set, "O" is provided s~ that the DP register 69 may hold its value intact. The same operand specifier is thus used for processing the next operand and is used repeatedly.
3~
Figure 8 shows a hardware arrangement that realizes the algorithm in -the decode controller 65.
In the case of E - 1, an output gate 301 is ~nabled to deliver the content oss of the bus 215 to the bus 214, while in the case of E = O, at S = O, a gate 307 turns "on" and an output gate 303 is enabled to deliver OSB
- 1, and at S = 1, a gate 306 turns "on" and an output gate 302 is enabled to deliver "O".
Un].ess the S bit is 1 when E is 1, it is signified that operand specifiers larger in number than operands exist.
In Figure 8, an AND gate 309 turns "on" to provide an error signal lQ5-3 and to communicate the occurrence of the error to the address calculating unit 28.
The address calculating unit 28 communicates the error signal 105-3 to the ensuing unit (operand fetch unit 29), and the occurrence of the error is finally communicated to the execute unit 30.
In Fi~ure 8, numerals 304 and 305 designate inverters, numerals 306, 307, and 309 AND gates, and numeral 308 a subtractor for (OS8 - 1).
An adder 71 adds the current value of the DP
register 69 and that of the signal line 214 and sets the sum in the DP register 69 through a selector 70O The address of the next operand specifier is thus supplied to the bus 102.
In this way, the aligner 26 can deliver the next operand specifier to the bus 104 in the format shown in Figure 5A or B.
On the other hand, the content of the bus 115 is selecfed by the selector 70 and set in the DP register 69, whereby the change of the content of the DP register 69 in the foregoing branch instruction is also permittedO
An adder 72 adds the value ~OSB) of th~ signal line 215 (indicating the length of the corresponding op~rand specifier) to the value of the DP register 69 and further adds a carry input "1", whereby to supply the bus 116 with an address next the operand specifier being decodedO
6~3~
The address calculating unit 28 utilizes the content of the bus 116 as the value of the program counter PC for the address calculation.
There is thus the feature that the operation code and the operand specifier are independent and that the length of the operand specifier can be se~ arbitrarily. In addition, using one operation code, both instructions of the A ~ B ~ C type and of the A ~ B -~B type can be expressed with the optimum amounts of information of the respective instructions, so that the number of instructions that can be specified by the operation codes of equal lengths increases.
That is, in a case where the operation code lengths are equal J a larger number of high function instructions can be added~
More~ver, the error detection rate can be enhanced by performing a reasonable check of the number of operands and the number of operand specifiers.
While, I.n the foregoing embodiment, the end flag S
is added to the most significant bit of the operand specifier, the position need not always be restricted to thls part, but the end flag can be provided in any place in the operand specifier~
In the ~oregoing embodiment, utiliZation of the same operand a plurality of times is realized by repeatedly decoding the same operand specifier without renewing the content of the DP register 69. Alternatively, a special signal can be sent from the decode unit to the execute unit 30 to instruct the repeated utilization of the operand previously obtained.
The address calculating unit 28 utilizes the content of the bus 116 as the value of the program counter PC for the address calculation.
There is thus the feature that the operation code and the operand specifier are independent and that the length of the operand specifier can be se~ arbitrarily. In addition, using one operation code, both instructions of the A ~ B ~ C type and of the A ~ B -~B type can be expressed with the optimum amounts of information of the respective instructions, so that the number of instructions that can be specified by the operation codes of equal lengths increases.
That is, in a case where the operation code lengths are equal J a larger number of high function instructions can be added~
More~ver, the error detection rate can be enhanced by performing a reasonable check of the number of operands and the number of operand specifiers.
While, I.n the foregoing embodiment, the end flag S
is added to the most significant bit of the operand specifier, the position need not always be restricted to thls part, but the end flag can be provided in any place in the operand specifier~
In the ~oregoing embodiment, utiliZation of the same operand a plurality of times is realized by repeatedly decoding the same operand specifier without renewing the content of the DP register 69. Alternatively, a special signal can be sent from the decode unit to the execute unit 30 to instruct the repeated utilization of the operand previously obtained.
Claims (2)
1. A central processing unit for executing instructions of variable length in which an operand specifier for specifying the addressing mode of an operand is independent of an operation code for ascertaining the kind of an operation and the number of operands, comprising:
(A) instruction fetch means for fetching an instruction from memory means storing instructions and operands, (B) decoding means connected to said instruction fetch means for decoding an operation code and an operand specifier, (C) address calculating means connected to said decoding means for calculating an address of an operand on the basis of the decoded result of the operand specifier from said decoding means, (D) operand fetch means connected to said address calculating means for fetching the operand from said memory means on the basis of the calculated address, and (E) executing means connected to said operand fetch means as well as said decoding means for executing the instruction successively by the use of the operands from said operand fetch means and in accordance with the decoded results of the operation codes from said decoding means, said decoding means including;
(i) operation code decoding means for decoding the operation codes of the instruction and delivering information on the operands in the operand specifiers, (ii) operand specifier decoding means for decoding information added to specific fields of the respective operand specifiers for deciding whether or not the partic-ular operand specifier is the last operand specifier, and (iii) means for causing the operand specifier to be used again, in both of the cases when the information indicative of the last operand specifier is received from the operand specifier decoding means and when the information indicative of the last operand is not received from the operation code decoding means.
(A) instruction fetch means for fetching an instruction from memory means storing instructions and operands, (B) decoding means connected to said instruction fetch means for decoding an operation code and an operand specifier, (C) address calculating means connected to said decoding means for calculating an address of an operand on the basis of the decoded result of the operand specifier from said decoding means, (D) operand fetch means connected to said address calculating means for fetching the operand from said memory means on the basis of the calculated address, and (E) executing means connected to said operand fetch means as well as said decoding means for executing the instruction successively by the use of the operands from said operand fetch means and in accordance with the decoded results of the operation codes from said decoding means, said decoding means including;
(i) operation code decoding means for decoding the operation codes of the instruction and delivering information on the operands in the operand specifiers, (ii) operand specifier decoding means for decoding information added to specific fields of the respective operand specifiers for deciding whether or not the partic-ular operand specifier is the last operand specifier, and (iii) means for causing the operand specifier to be used again, in both of the cases when the information indicative of the last operand specifier is received from the operand specifier decoding means and when the information indicative of the last operand is not received from the operation code decoding means.
2. A central processing unit according to claim 1, wherein said decoding means further includes error detection means connected to the operation code decoding means and the operand specifier decoding means for detecting the instruction as an error, in a case where the information indicative of the last operand has been received from said operation code decoding means and said operand specifier decoding means does not receive the information indicative of the last operand specifier.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13271681A JPS5835642A (en) | 1981-08-26 | 1981-08-26 | Data processing device handling undefined length instruction |
| JP56132717A JPS5835643A (en) | 1981-08-26 | 1981-08-26 | Data processing device for error detection of undefined length instruction |
| JP132716/1981 | 1981-08-26 | ||
| JP132717/1981 | 1981-08-26 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1186801A true CA1186801A (en) | 1985-05-07 |
Family
ID=26467236
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000410221A Expired CA1186801A (en) | 1981-08-26 | 1982-08-26 | Central processing unit for executing instructions of variable length |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US4530050A (en) |
| EP (1) | EP0073424B1 (en) |
| KR (1) | KR880000297B1 (en) |
| CA (1) | CA1186801A (en) |
| DE (1) | DE3278442D1 (en) |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS58146941A (en) * | 1982-02-26 | 1983-09-01 | Hitachi Ltd | Processor for control data of microprogram |
| JPS60500187A (en) * | 1982-12-30 | 1985-02-07 | インタ−ナシヨナル・ビジネス・マシ−ンズ・コ−ポレ−シヨン | data processing system |
| JP2539357B2 (en) | 1985-03-15 | 1996-10-02 | 株式会社日立製作所 | Data processing device |
| US5206945A (en) * | 1985-03-15 | 1993-04-27 | Hitachi, Ltd. | Single-chip pipeline processor for fetching/flushing instruction/data caches in response to first/second hit/mishit signal respectively detected in corresponding to their logical addresses |
| US4829424A (en) * | 1985-06-28 | 1989-05-09 | Hewlett-Packard Company | Maximal length immediates with fixed sign position |
| US5349672A (en) * | 1986-03-17 | 1994-09-20 | Hitachi, Ltd. | Data processor having logical address memories and purge capabilities |
| JPS62226231A (en) * | 1986-03-27 | 1987-10-05 | Toshiba Corp | Processor |
| JPS62226232A (en) * | 1986-03-28 | 1987-10-05 | Toshiba Corp | Control system for branch instruction |
| US4785452A (en) * | 1986-04-25 | 1988-11-15 | International Business Machines Corporation | Error detection using variable field parity checking |
| US4943915A (en) * | 1987-09-29 | 1990-07-24 | Digital Equipment Corporation | Apparatus and method for synchronization of a coprocessor unit in a pipelined central processing unit |
| JP2902402B2 (en) * | 1987-09-30 | 1999-06-07 | 三菱電機株式会社 | Data processing device |
| JP2577023B2 (en) * | 1987-12-28 | 1997-01-29 | 株式会社日立製作所 | Address extension control method for information processing equipment |
| JPH01241636A (en) * | 1988-03-17 | 1989-09-26 | Internatl Business Mach Corp <Ibm> | Data processing system |
| JPH0766324B2 (en) * | 1988-03-18 | 1995-07-19 | 三菱電機株式会社 | Data processing device |
| US4974146A (en) * | 1988-05-06 | 1990-11-27 | Science Applications International Corporation | Array processor |
| DE68927313T2 (en) * | 1988-06-27 | 1997-05-07 | Digital Equipment Corp | Operand specifier processing |
| US5101341A (en) * | 1988-08-25 | 1992-03-31 | Edgcore Technology, Inc. | Pipelined system for reducing instruction access time by accumulating predecoded instruction bits a FIFO |
| US5249273A (en) * | 1989-01-17 | 1993-09-28 | Fujitsu Limited | Microprocessor having a variable length instruction format |
| US5167026A (en) * | 1989-02-03 | 1992-11-24 | Digital Equipment Corporation | Simultaneously or sequentially decoding multiple specifiers of a variable length pipeline instruction based on detection of modified value of specifier registers |
| EP0498654B1 (en) * | 1991-02-08 | 2000-05-10 | Fujitsu Limited | Cache memory processing instruction data and data processor including the same |
| JP2970821B2 (en) * | 1991-08-21 | 1999-11-02 | 松下電器産業株式会社 | Data processing device |
| GB2263565B (en) * | 1992-01-23 | 1995-08-30 | Intel Corp | Microprocessor with apparatus for parallel execution of instructions |
| SG45269A1 (en) * | 1992-02-06 | 1998-01-16 | Intel Corp | End bit markers for instruction decode |
| US5371864A (en) * | 1992-04-09 | 1994-12-06 | International Business Machines Corporation | Apparatus for concurrent multiple instruction decode in variable length instruction set computer |
| US6003120A (en) * | 1993-12-30 | 1999-12-14 | Intel Corporation | Method and apparatus for performing variable length processor write cycles |
| GB9412434D0 (en) | 1994-06-21 | 1994-08-10 | Inmos Ltd | Computer instruction compression |
| US5758116A (en) * | 1994-09-30 | 1998-05-26 | Intel Corporation | Instruction length decoder for generating output length indicia to identity boundaries between variable length instructions |
| US5630055A (en) * | 1995-05-05 | 1997-05-13 | Digital Equipment Corporation | Autonomous pipeline reconfiguration for continuous error correction for fills from tertiary cache or memory |
| US5958061A (en) * | 1996-07-24 | 1999-09-28 | Transmeta Corporation | Host microprocessor with apparatus for temporarily holding target processor state |
| US6370636B1 (en) | 1996-07-31 | 2002-04-09 | Hyundai Electronics Industries Co., Ltd. | Accessing byte lines from dual memory blocks and aligning for variable length instruction execution |
| US6199152B1 (en) | 1996-08-22 | 2001-03-06 | Transmeta Corporation | Translated memory protection apparatus for an advanced microprocessor |
| US6223275B1 (en) * | 1997-06-20 | 2001-04-24 | Sony Corporation | Microprocessor with reduced instruction set limiting the address space to upper 2 Mbytes and executing a long type register branch instruction in three intermediate instructions |
| US6425070B1 (en) * | 1998-03-18 | 2002-07-23 | Qualcomm, Inc. | Variable length instruction decoder |
| US6292845B1 (en) | 1998-08-26 | 2001-09-18 | Infineon Technologies North America Corp. | Processing unit having independent execution units for parallel execution of instructions of different category with instructions having specific bits indicating instruction size and category respectively |
| US7376814B1 (en) | 1999-09-07 | 2008-05-20 | Nxp B.V. | Method for forming variable length instructions in a processing system |
| US6721875B1 (en) * | 2000-02-22 | 2004-04-13 | Hewlett-Packard Development Company, L.P. | Method and apparatus for implementing a single-syllable IP-relative branch instruction and a long IP-relative branch instruction in a processor which fetches instructions in bundle form |
| US6968469B1 (en) | 2000-06-16 | 2005-11-22 | Transmeta Corporation | System and method for preserving internal processor context when the processor is powered down and restoring the internal processor context when processor is restored |
| US7711926B2 (en) | 2001-04-18 | 2010-05-04 | Mips Technologies, Inc. | Mapping system and method for instruction set processing |
| DE10120522A1 (en) * | 2001-04-26 | 2002-11-07 | Infineon Technologies Ag | Method for recognizing a correct command entry address when using command words of different lengths |
| US6826681B2 (en) | 2001-06-18 | 2004-11-30 | Mips Technologies, Inc. | Instruction specified register value saving in allocated caller stack or not yet allocated callee stack |
| JP2007122626A (en) * | 2005-10-31 | 2007-05-17 | Matsushita Electric Ind Co Ltd | Microprocessor |
| US8639882B2 (en) * | 2011-12-14 | 2014-01-28 | Nvidia Corporation | Methods and apparatus for source operand collector caching |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NL255604A (en) * | 1959-09-08 | |||
| US3377620A (en) * | 1964-04-10 | 1968-04-09 | Mohawk Data Science Corp | Variable word length internally programmed information processing system |
| US3344404A (en) * | 1964-09-10 | 1967-09-26 | Honeywell Inc | Multiple mode data processing system controlled by information bits or special characters |
| US4109310A (en) * | 1973-08-06 | 1978-08-22 | Xerox Corporation | Variable field length addressing system having data byte interchange |
| CA1114518A (en) * | 1977-10-25 | 1981-12-15 | William D. Strecker | Central processor unit for executing instructions with a special operand specifier |
| US4241399A (en) * | 1978-10-25 | 1980-12-23 | Digital Equipment Corporation | Calling instructions for a data processing system |
| US4236206A (en) * | 1978-10-25 | 1980-11-25 | Digital Equipment Corporation | Central processor unit for executing instructions of variable length |
-
1982
- 1982-08-17 US US06/408,924 patent/US4530050A/en not_active Expired - Lifetime
- 1982-08-19 DE DE8282107598T patent/DE3278442D1/en not_active Expired
- 1982-08-19 EP EP82107598A patent/EP0073424B1/en not_active Expired
- 1982-08-23 KR KR8203773A patent/KR880000297B1/en active
- 1982-08-26 CA CA000410221A patent/CA1186801A/en not_active Expired
Also Published As
| Publication number | Publication date |
|---|---|
| DE3278442D1 (en) | 1988-06-09 |
| US4530050A (en) | 1985-07-16 |
| EP0073424A3 (en) | 1984-05-23 |
| EP0073424B1 (en) | 1988-05-04 |
| KR880000297B1 (en) | 1988-03-19 |
| EP0073424A2 (en) | 1983-03-09 |
| KR840001350A (en) | 1984-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1186801A (en) | Central processing unit for executing instructions of variable length | |
| US4714994A (en) | Instruction prefetch buffer control | |
| US4395758A (en) | Accelerator processor for a data processing system | |
| CA1213674A (en) | Pipeline error correction | |
| EP0381469B1 (en) | Method and data processing unit for pipeline processing of register and register modifying specifiers within the same instruction | |
| US5481734A (en) | Data processor having 2n bits width data bus for context switching function | |
| EP0321793B1 (en) | Apparatus for forcing a reload from main memory upon cache memory error | |
| CA2173226C (en) | Hardware assisted modify count instruction | |
| JPH07210381A (en) | Processor and computer system | |
| US20020108027A1 (en) | Microprocessor and method of processing unaligned data in microprocessor | |
| US5241547A (en) | Enhanced error detection scheme for instruction address sequencing of control store structure | |
| EP0383899B1 (en) | Failure detection for partial write operations for memories | |
| EP0423726B1 (en) | Branch control circuit | |
| US4924425A (en) | Method for immediately writing an operand to a selected word location within a block of a buffer memory | |
| GB2352308A (en) | Conditional instruction execution | |
| US4309753A (en) | Apparatus and method for next address generation in a data processing system | |
| US5142630A (en) | System for calculating branch destination address based upon address mode bit in operand before executing an instruction which changes the address mode and branching | |
| US20030018936A1 (en) | High integrity cache directory | |
| US4245328A (en) | Binary coded decimal correction apparatus for use in an arithmetic unit of a data processing unit | |
| JPS5938677B2 (en) | Control word transfer control device | |
| US5278840A (en) | Apparatus and method for data induced condition signalling | |
| JPS5838819B2 (en) | Control file device for data processing systems | |
| EP0066670B1 (en) | Instruction processing in a data processing machine | |
| EP0157306B1 (en) | High speed processor | |
| US5243601A (en) | Apparatus and method for detecting a runaway firmware control unit |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKEC | Expiry (correction) | ||
| MKEX | Expiry |