Electrical computers and digital processing systems: processing – Instruction decoding – Decoding instruction to accommodate plural instruction...
Reexamination Certificate
1998-04-30
2001-01-23
Ellis, Richard L. (Department: 2783)
Electrical computers and digital processing systems: processing
Instruction decoding
Decoding instruction to accommodate plural instruction...
C712S206000, C712S245000
Reexamination Certificate
active
06178495
ABSTRACT:
FIELD OF THE INVENTION
This invention is related to computer systems and in particular to processors that implement opcode compare logic to work around flaws that exist in the hardware design.
BACKGROUND OF THE INVENTION
In the IBM Technical Disclosure Bulletin publication article entitled “Designing Flexibility into Hardwired Logic” (TDB v37 n3 03-94 p321-324) the authors, M A Check, A Lo, and J R Smith, disclosed the use of opcode compare logic for adding flexibility to a logic design which contains hardwired logic. The primary reason for using hardwired logic is to maximize performance, but this has the disadvantage of being rigid, and the hardware must be replaced whenever there is a design change. In some situations changes occur frequently, and it becomes very costly for the manufacturer to replace hardware with each change. This article outlines a solution to this problem and shows how to design logic that is hardwired for performance and flexible to change. The technique is to design the hardwired logic and then implement some programmable logic on the side for use whenever the design must change. Design changes are performed by switching out a portion of the hardwired logic and replacing it with programmable logic. Since most changes are small, the system remains mostly hardwired and the impact on performance is usually negligible. As an application of this design technique, the focus will be on the instruction decode logic of a central processor. It is common for architecture changes to occur after the hardware has been released to the field. By making an instruction decoder which is partially programmable, the manufacturer can save a significant amount of money on the cost of doing field upgrades for changes in the instruction set. A second advantage of using a partially programmable decoder is its power as a debugging tool. Opcode Compare is a tool for debugging problems in the central processor (CP). It was described in the article as consisting of a set of programmable opcode registers, each with a control word. The user has the ability to control the way instructions decode and execute by writing values into the opcode and control registers. To modify the behavior of an instruction, the opcode is written to one of the opcode registers and a control word is also written. Each time that opcode decodes, its hardwired instruction characteristic is modified according to the value of the control word. Actions that can be controlled include disabling multiple instructions per cycle decode, disabling decode until all prior instructions complete (disable overlap), serialization and switching execution between hardware and microcode or mullicode elements.
Every computer system must deal with architectural changes. A common occurrence is the announcement of new instructions, where a previously reserved invalid opcode becomes valid. In cases where the hardware is in the field, the manufacturer usually offers to upgrade the customer's system to meet the new architecture. By using the design techniques discussed below, the manufacturer can minimize its hardware replacement cost. To do this, the manufacturer reprograms the hardware for the instruction decoder to mark the new opcode valid and dispatch it to an appropriate execution unit. Depending upon available space on chip, there are two choices for implementing this. If space is not a constraint, then every reserved invalid opcode is mapped into a unique address in an array. The array contains as instruction characteristic for each opcode. To change an opcode from invalid to valid, a new instruction characteristic is written to the array. Then, whenever this opcode is encountered, it will decode and execute as specified by the characteristic entered in the array. If space is a constraint, then a limit is placed on the total number of opcodes that can be transformed from invalid to valid. The opcodes to be transformed are entered into a set of registers similar to the ones used for Opcode Compare. Each compare register points to an address in the array. As above, to change an opcode from invalid to valid, a new instruction characteristic is written into the array and will be used whenever this opcode decodes. In both implementations the output of the hardwired decoder is blocked one cycle to give the array a chance to produce a new characteristic for this instruction. The article illustrates how to implement this type of flexibility.
However, in so far as we have been able to determine, until now Opcode Compare logic is commonly implemented in the instruction unit (I-unit) where it has the disadvantage where it can adversely affect cycle time. We have found no processor which has implemented Opcode Compare logic in the execution unit (E-unit), and we with this application report that we have found that there are advantages in doing so, as we will describe, specifically with respect to our processor E-Unit to I-Unit interface mechanism for instruction modification with these features below.
SUMMARY OF THE INVENTION
Our invention provides a system and method for alleviating computer design deficiencies implementing Opcode Compare logic in the E-Unit which improves the cycle-time of critical paths in the I-unit. It allows additional flexibility to the actions that can be performed by implementing this in the E-unit. And it solves problems associated with a different instruction being decoded after serialization and avoids processor loops.
Within this environment we have provided a mechanism for the E-unit to inform the I-unit on what instruction is being compared against and what action to take. The invention also provides a mechanism for the E-unit to avoid getting the processor into an endless loop. Other uses for this general mechanism which could be implemented includes work that is normally done in the decode cycle in the I-unit, is instead done in the E-unit to remove it from the cycle-time limiting path of the processor. We will delineate the processor E-Unit to I-Unit interface mechanism for instruction modification with these features below.
These and other improvements are set forth in the following detailed description. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.
REFERENCES:
patent: 5450556 (1995-09-01), Slavenburg et al.
patent: 5495590 (1996-02-01), Comfort et al.
patent: 5500947 (1996-03-01), Uhler et al.
patent: 5694587 (1997-12-01), Webb et al.
patent: 5713035 (1998-01-01), Farrell et al.
patent: 5881280 (1999-03-01), Gupta et al.
patent: 5983337 (1999-11-01), Marhalingaiah et al.
“Opcode Compare Facility” Research Disclosure, Jul. 1990, No. 315, PO889-0224.
“Designing Flexibility into Hardwired Logic” IBM Technical Disclosure Bulletin, vol. 37, No. 3, Mar. 1994, pp. 321-324.
Check Mark Anthony
Slegel Timothy John
Augspurger Lynn L.
Chang J.
Ellis Richard L.
International Business Machines - Corporation
LandOfFree
Processor E-unit to I-unit interface instruction... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Processor E-unit to I-unit interface instruction..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Processor E-unit to I-unit interface instruction... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2498147