Patent Publication Number: US-9424036-B2

Title: Scalable decode-time instruction sequence optimization of dependent instructions

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This is a Continuation Application to U.S. patent Ser. No. 13/251,409 “SCALABLE DECODE-TIME INSTRUCTION SEQUENCE OPTIMIZATION OF DEPENDENT INSTRUCTIONS”, filed Oct. 3, 2011, which application is incorporated herein by reference. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates to the field of computer processors, and more particularly, to optimizing instructions for execution at instruction decode time in a processor. 
     BACKGROUND 
     US Patent Application Publication No. 2011/0087865 “Intermediate Register Mapper” filed Apr. 14, 2011 by Barrick et al. and incorporated herein by reference teaches “A method, processor, and computer program product employing an intermediate register mapper within a register renaming mechanism. A logical register lookup determines whether a hit to a logical register associated with the dispatched instruction has occurred. In this regard, the logical register lookup searches within at least one register mapper from a group of register mappers, including an architected register mapper, a unified main mapper, and an intermediate register mapper. A single hit to the logical register is selected among the group of register mappers. If an instruction having a mapper entry in the unified main mapper has finished but has not completed, the mapping contents of the register mapper entry in the unified main mapper are moved to the intermediate register mapper, and the unified register mapper entry is released, thus increasing a number of unified main mapper entries available for reuse.” 
     U.S. Pat. No. 6,314,511 filed Apr. 2, 1998 “Mechanism for freeing registers on processors that perform dynamic out-of-order execution of instructions using renaming registers” by Levy et al., incorporated by reference herein teaches “freeing renaming registers that have been allocated to architectural registers prior to another instruction redefining the architectural register. Renaming registers are used by a processor to dynamically execute instructions out-of-order in either a single or multi-threaded processor that executes instructions out-of-order. A mechanism is described for freeing renaming registers that consists of a set of instructions, used by a compiler, to indicate to the processor when it can free the physical (renaming) register that is allocated to a particular architectural register. This mechanism permits the renaming register to be reassigned or reallocated to store another value as soon as the renaming register is no longer needed for allocation to the architectural register. There are at least three ways to enable the processor with an instruction that identifies the renaming register to be freed from allocation: (1) a user may explicitly provide the instruction to the processor that refers to a particular renaming register; (2) an operating system may provide the instruction when a thread is idle that refers to a set of registers associated with the thread; and (3) a compiler may include the instruction with the plurality of instructions presented to the processor. There are at least five embodiments of the instruction provided to the processor for freeing renaming registers allocated to architectural registers: (1) Free Register Bit; (2) Free Register: (3) Free Mask; (4) Free Opcode: and (5) Free Opcode/Mask. The Free Register Bit instruction provides the largest speedup for an out-of-order processor and the Free Register instruction provides the smallest speedup.” 
     “Power ISA™ Version 2.06 Revision B” published Jul. 23, 2010 from IBM® and incorporated by reference herein teaches an example RISC (reduced instruction set computer) instruction set architecture. The Power ISA will be used herein in order to demonstrate example embodiments, however, the invention is not limited to Power ISA or RISC architectures. Those skilled in the art will readily appreciate use of the invention in a variety of architectures. 
     “z/Architecture Principles of Operation” SA22-7832-08, Ninth Edition (August, 2010) from IBM® and incorporated by reference herein teaches an example CISC (complex instruction set computer) instruction set architecture. 
     SUMMARY 
     In an embodiment, a first instruction of an instruction set architecture (ISA) and a second instruction of the ISA in program order are fetched for execution, the second instruction dependent on results of execution of the first instruction, wherein the second instruction is modified by the processor to include attributes of the first instruction, enabling the modified second instruction to be executed and completed out-of-order relative to the first instruction. 
     In an embodiment, the processor determines that the first instruction and second instructions are configured to be executed in-order, comprising determining that the first instruction specifies a target operand location for a target operand and the second instruction specifies a source operand location for a source operand, wherein the first instruction is configured to store a target operand at the target operand location, wherein the source operand location is the same as the target operand location, wherein the second instruction is configured to obtain a source operand at the source operand location. The processor replaces the second instruction with a new second instruction not of the ISA, wherein the new second instruction is not dependent on the target operand of the first instruction. The processor executes the first instruction and the new second instruction, and permits out-of-order completion of the first instruction and the new second instruction. 
     In an embodiment, the first instruction comprises a first immediate field and the second instruction comprises a second immediate field, wherein portions of the first immediate field and the second immediate field are incorporated as immediate fields of the new second instruction. 
     In an embodiment, the incorporating portions of the first immediate field and the second immediate field comprises concatenating a portion of the first immediate field with a portion of the second immediate field. 
     In an embodiment, the new instruction specifies the source operand locations of the first instruction and at least one source operand location of the second instruction. 
     In an embodiment, the target operand location is a first target register of the first instruction and the source operand location is a source register of the second instruction. 
     In an embodiment, the second instruction is determined to be configured to be replaced by the new instruction, wherein the determining that the second instruction is configured to be replaced is based on the opcodes of the first instruction and the second instruction, that the first instruction and the second instruction perform a compatible function and that the compatible function is configured to use the first immediate field of the first instruction to produce a first portion of the first target register and that the compatible function is configured to use the second immediate field of the second instruction to produce a second portion of the first target register of the second instruction, wherein one of said first portion and said second portion consists of most significant bits and the other of said first portion and said second portion consists of least significant bits. 
     In an embodiment, determining that the first instruction and second instructions are configured to be executed in-order further comprises determining that a low order portion of a low order immediate field is a positive value. 
     In an embodiment, responsive to determining that a low order immediate field is a negative value, a 1 is effectively subtracted from a high order portion of the immediate field of the new instruction before executing the new instruction. 
     System and computer program products corresponding to the above-summarized methods are also described and claimed herein. 
     Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which: 
         FIG. 1  depicts an example processor system configuration; 
         FIG. 2  depicts a first example processor pipeline; 
         FIG. 3  depicts a second example processor pipeline; 
         FIG. 4A  depicts an example optimization analysis engine environment; 
         FIGS. 4B-4C  depict example optimization; 
         FIG. 5  is an example flowchart depicting aspects of the invention; 
         FIG. 6  is an example flowchart depicting aspects of the invention; 
         FIG. 7  is an example flowchart depicting aspects of the invention; and 
         FIG. 8  is an example flowchart depicting aspects of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     An Out of Order (OoO) processor typically contains multiple execution pipelines that may opportunistically execute instructions in a different order than what the program sequence (or “program order”) specifies in order to maximize the average instruction per cycle rate by reducing data dependencies and maximizing utilization of the execution pipelines allocated for various instruction types. Results of instruction execution are typically held temporarily in the physical registers of one or more register files of limited depth. An OoO processor typically employs register renaming to avoid unnecessary serialization of instructions due to the reuse of a given architected register by subsequent instructions in the program order. 
     According to Barrick, under register renaming operations, each architected (i.e., logical) register targeted by an instruction is mapped to a unique physical register in a register file. In current high-performance OoO processors, a unified main mapper is utilized to manage the physical registers within multiple register files. In addition to storing the logical-to-physical register translation (i.e., in mapper entries), the unified main mapper is also responsible for storing dependency data (i.e., queue position data), which is important for instruction ordering upon completion. 
     In a unified main mapper-based renaming scheme, it is desirable to free mapper entries as soon as possible for reuse by the OoO processor. However, in the prior art, a unified main mapper entry cannot be freed until the instruction that writes to a register mapped by the mapper entry is completed. This constraint is enforced because, until completion, there is a possibility that an instruction that has “finished” (i.e. the particular execution unit (EU) has successfully executed the instruction) will still be flushed before the instruction can “complete” and before the architected, coherent state of the registers is updated. 
     In current implementations, resource constraints at the unified main mapper have generally been addressed by increasing the number of unified main mapper entries. However, increasing the size of the unified main mapper has a concomitant penalty in terms of die area, complexity, power consumption, and access time. 
     In Barrick, there is provided a method for administering a set of one or more physical registers in a data processing system. The data processing system has a processor that processes instructions out-of-order, wherein the instructions reference logical registers and wherein each of the logical registers is mapped to the set of one or more physical registers. In response to dispatch of one or more of the instructions, a register management unit performs a logical register lookup, which determines whether a hit to a logical register associated with the dispatched instruction has occurred within one or more register mappers. In this regard, the logical register lookup searches within at least one register mapper from a group of register mappers, including an architected register mapper, a unified main mapper, and an intermediate register mapper. The register management unit selects a single hit to the logical register among the group of register mappers. If an instruction having a mapper entry in the unified main mapper has finished but has not completed, the register management unit moves logical-to-physical register renaming data of the unified main mapping entry in the unified main mapper to the intermediate register mapper, and the unified main mapper releases the unified main mapping entry prior to completion of the instruction. The release of the unified main mapping entry increases a number of unified main mapping entries available for reuse. 
     With reference now to the figures, and in particular to  FIG. 1 , an example is shown of a data processing system  100  which may include an OoO processor employing an intermediate register mapper as described below with reference to  FIG. 2 . As shown in  FIG. 1 , data processing system  100  has a central processing unit (CPU)  110 , which may be implemented with processor  200  of  FIG. 2 . CPU  110  is coupled to various other components by an interconnect  112 . Read only memory (“ROM”)  116  is coupled to the interconnect  112  and includes a basic input/output system (“BIOS”) that controls certain basic functions of the data processing system  100 . Random access memory (“RAM”)  114 . I/O adapter  118 , and communications adapter  134  are also coupled to the system bus  112 . I/O adapter  118  may be a small computer system interface (“SCSI”) adapter that communicates with a storage device  120 . Communications adapter  134  interfaces interconnect  112  with network  140 , which enables data processing system  100  to communicate with other such systems, such as remote computer  142 . Input/Output devices are also connected to interconnect  112  via user interface adapter  122  and display adapter  136 . Keyboard  124 , track ball  132 , mouse  126  and speaker  128  are all interconnected to bus  112  via user interface adapter  122 . Display  138  is connected to system bus  112  by display adapter  136 . In this manner, data processing system  100  receives input, for example, throughout keyboard  124 , trackball  132 , and/or mouse  126  and provides output, for example, via network  142 , on storage device  120 , speaker  128  and/or display  138 . The hardware elements depicted in data processing system  100  are not intended to be exhaustive, but rather represent principal components of a data processing system in one embodiment. 
     Operation of data processing system  100  can be controlled by program code, such as firmware and/or software, which typically includes, for example, an operating system such as AIX® (“AIX” is a trademark of the IBM Corporation) and one or more application or middleware programs. Such program code comprises instructions discussed below with reference to  FIG. 2 . 
     Referring now to  FIG. 2 , there is depicted a superscalar processor  200 . Instructions are retrieved from memory (e.g. RAM  114  of  FIG. 1 ) and loaded into instruction sequencing logic (ISL)  204 , which includes Level 1 Instruction cache (L1 I-cache)  206 , fetch-decode unit  208 , instruction queue  210  and dispatch unit  212 . Specifically, the instructions are loaded in L1 I-cache  206  of ISL  204 . The instructions are retained in L1 I-cache  206  until they are required, or replaced if they are not needed. Instructions are retrieved from L1 I-cache  206  and decoded by fetch-decode unit  208 . After decoding a current instruction, the current instruction is loaded into instruction queue  210 . Dispatch unit  212  dispatches instructions from instruction queue  210  into register management unit  214 , as well as completion unit  240 . Completion unit  240  is coupled to general execution unit  224  and register management unit  214 , and monitors when an issued instruction has completed. 
     When dispatch unit  212  dispatches a current instruction, unified main mapper  218  of register management unit  214  allocates and maps a destination logical register number to a physical register within physical register files  232   a - 232   n  that is not currently assigned to a logical register. The destination is said to be renamed to the designated physical register among physical register files  232   a - 232   n . Unified main mapper  218  removes the assigned physical register from a list  219  of free physical registers stored within unified main mapper  218 . All subsequent references to that destination logical register will point to the same physical register until fetch-decode unit  208  decodes another instruction that writes to the same logical register. Then, unified main mapper  218  renames the logical register to a different physical location selected from free list  219 , and the mapper is updated to enter the new logical-to-physical register mapper data. When the logical-to-physical register mapper data is no longer needed, the physical registers of old mappings are returned to free list  219 . If free physical register list  219  does not have enough physical registers, dispatch unit  212  suspends instruction dispatch until the needed physical registers become available. 
     After the register management unit  214  has mapped the current instruction, issue queue  222  issues the current instruction to general execution engine  224 , which includes execution units (EUs)  230   a - 230   n . Execution units  230   a - 230   n  are of various types, such as floating-point (FP), fixed-point (FX), and load/store (LS). General execution engine  224  exchanges data with data memory (e.g. RAM  114 , ROM  116  of  FIG. 1 ) via a data cache  234 . Moreover, issue queue  222  may contain instructions of IP type. FX type, and LS instructions. However, it should be appreciated that any number and types of instructions can be used. During execution, EUs  230   a - 230   n  obtain the source operand values from physical locations in register file  232   a - 232   n  and store result data, if any, in register files  232   a - 232   n  and/or data cache  234 . 
     Still referring to  FIG. 2 , register management unit  214  includes: (i) mapper cluster  215 , which includes architected register mapper  216 , unified main mapper  218 , intermediate register mapper  220 , and (ii) issue queue  222 . Mapper cluster  215  tracks the physical registers assigned to the logical registers of various instructions. In an exemplary embodiment, architected register mapper  216  has 16 logical (i.e., not physically mapped) registers of each type that store the last, valid (i.e., checkpointed) state of logical-to-physical register mapper data. However, it should be recognized that different processor architectures can have more or less logical registers, as described in the exemplary embodiment. Architected register mapper  216  includes a pointer list that identifies a physical register which describes the checkpointed state. Physical register files  232   a - 232   n  will typically contain more registers than the number of entries in architected register mapper  216 . It should be noted that the particular number of physical and logical registers that are used in a renaming mapping scheme can vary. 
     In contrast, unified main mapper  218  is typically larger (typically contains up to 20 entries) than architected register mapper  216 . Unified main mapper  218  facilitates tracking of the transient state of logical-to-physical register mappings. The term “transient” refers to the fact that unified main mapper  218  keeps track of tentative logical-to-physical register mapping data as the instructions are executed out-of-order. OoO execution typically occurs when there are older instructions which would take longer (i.e., make use of more clock cycles) to execute than newer instructions in the pipeline. However, should an OoO instruction&#39;s executed result require that it be flushed for a particular reason (e.g. a branch miss-prediction), the processor can revert to the check-pointed state maintained by architected register mapper  216  and resume execution from the last, valid state. 
     Unified main mapper  218  makes the association between physical registers in physical register files  232   a - 232   n  and architected register mapper  216 . The qualifying term “unified” refers to the fact that unified main mapper  218  obviates the complexity of custom-designing a dedicated mapper for each of register files  232  (e.g., general-purpose registers (GPRs), floating-point registers (FPRs), fixed-point registers (FXPs), exception registers (XERs), condition registers (CRs), etc.). 
     In addition to creating a transient, logical-to-physical register mapper entry of an OoO instruction, unified main mapper  218  also keeps track of dependency data (i.e. instructions that are dependent upon the finishing of an older instruction in the pipeline), which is important for instruction ordering. Conventionally, once unified main mapper  218  has entered an instruction&#39;s logical-to-physical register translation, the instruction passes to issue queue  222 . Issue queue  222  serves as the gatekeeper before the instruction is issued to execution unit  230  for execution. As a general rule, an instruction cannot leave issue queue  222  if it depends upon an older instruction to finish. For this reason, unified main mapper  218  tracks dependency data by storing the issue queue position data for each instruction that is mapped. Once the instruction has been executed by general execution engine  224 , the instruction is said to have “finished” and is retired from issue queue  222 . 
     Register management unit  214  may receive multiple instructions from dispatch unit  212  in a single cycle so as to maintain a filled, single issue pipeline. The dispatching of instructions is limited by the number of available entries in unified main mapper  218 . In conventional mapper systems, which lack intermediate register mapper  220 , if unified main mapper  218  has a total of 20 mapper entries, there is a maximum of 20 instructions that can be in flight (i.e., not checkpointed) at once. Thus, dispatch unit  212  of a conventional mapper system can conceivably “dispatch” more instructions than what can actually be retired from unified main mapper  218 . The reason for this bottleneck at the unified main mapper  218  is due to the fact that, conventionally, an instruction&#39;s mapper entry could not retire from unified main mapper  218  until the instruction “completed” (i.e., all older instructions have “finished” executing). 
     According to one embodiment, intermediate register mapper  220  serves as a non-timing-critical register for which a “finished”, but “incomplete” instruction from unified main mapper  218  could retire to (i.e. removed from unified main mapper  218 ) in advance of the instruction&#39;s eventual completion. Once the instruction “completes”, completion unit  240  notifies intermediate register mapper  220  of the completion. The mapper entry in intermediate register mapper  220  can then update the architected coherent state of architected register mapper  216  by replacing the corresponding entry that was presently stored in architected register mapper  216 . 
     When dispatch unit  212  dispatches an instruction, register management unit  214  evaluates the logical register number(s) associated with the instruction against mappings in architected register mapper  216 , unified main mapper  218 , and intermediate register mapper  220  to determine whether a match (commonly referred to as a “hit”) is present in architected register mapper  216 , unified main mapper  218 , and/or intermediate register mapper  220 . This evaluation is referred to as a logical register lookup. When the lookup is performed simultaneously at more than one register mapper (i.e., architected register mapper  216 , unified main mapper  218 , and/or intermediate register mapper  220 ), the lookup is referred to as a parallel logical register lookup. 
     Each instruction that updates the value of a certain target logical register is allocated a new physical register. Whenever this new instance of the logical register is used as a source by any other instruction, the same physical register must be used. As there may exist a multitude of instances of one logical register, there may also exist a multitude of physical registers corresponding to the logical register. Register management unit  214  performs the tasks of (i) analyzing which physical register corresponds to a logical register used by a certain instruction, (ii) replacing the reference to the logical register with a reference to the appropriate physical register (i.e. register renaming), and (iii) allocating a new physical register whenever a new instance of any logical register is created (i.e., physical register allocation). 
     Initially, before any instructions are dispatched, the unified main mapper  218  will not receive a hit/match since there are no instructions currently in flight. In such an event, unified main mapper  218  creates a mapping entry. As subsequent instructions are dispatched, if a logical register match for the same logical register number is found in both architected register mapper  216  and unified main mapper  218 , priority is given to selecting the logical-to-physical register mapping of unified main mapper  218  since the possibility exists that there may be instructions currently executing OoO (i.e., the mapping is in a transient state). 
     After unified main mapper  218  finds a hit/match within its mapper, the instruction passes to issue queue  222  to await issuance for execution by one of execution units  230 . After general execution engine  224  executes and “finishes” the instruction, but before the instruction “completes”, register management unit  214  retires the mapping entry presently found in unified main mapper  218  from unified main mapper  218  and moves the mapping entry to intermediate register mapper  220 . As a result, a slot in unified main mapper  218  is made available for mapping a subsequently dispatched instruction. Unlike unified main mapper  218 , intermediate register mapper  220  does not store dependency data. Thus, the mapping that is transferred to intermediate register mapper  220  does not depend (and does not track) the queue positions of the instructions associated with its source mappings. This is because issue queue  222  retires the “finished, but not completed” instruction is after a successful execution. In contrast, under conventional rename mapping schemes lacking an intermediate register mapper, a unified main mapper continues to store the source rename entry until the instruction completes. Under the present embodiment, intermediate register mapper  220  can be positioned further away from other critical path elements because, unified main mapper  218 , its operation is not timing critical. 
     Once unified main mapper  218  retires a mapping entry from unified main mapper  218  and moves to intermediate register mapper  220 , mapper cluster  214  performs a parallel logical register lookup on a subsequently dispatched instruction to determine if the subsequent instruction contains a hit/match in any of architected register mapper  216 , unified main mapper  218 , and intermediate register mapper  220 . If a hit/match to the same destination logical register number is found in at least two of architected register mapper  216 , unified main mapper  218 , and intermediate register mapper  220 , multiplexer  223  in issue queue  222  awards priority by selecting the logical-to-physical register mapping of unified main mapper  218  over that of the intermediate register mapper  220 , which in turn, has selection priority over architected register mapper  216 . 
     The mechanism suggested by Barrick by which the selection priority is determined is discussed as follows. A high level logical flowchart of an exemplary method of determining which mapping data values to use in executing an instruction, in accordance with one embodiment. In an embodiment, a dispatch unit  212  dispatching one or more instructions to register management unit  214 . In response to the dispatching of the instruction(s), register management unit  214  determines via a parallel logical register lookup whether a “hit” to a logical register (in addition to a “hit” to architected register mapper  216 ) associated with each dispatched instruction has occurred. In this regard, it should be understood that architected register mapper  216  is assumed to always have hit/match, since architected register mapper  216  stores the checkpointed state of the logical-to-physical register mapper data. If register management unit  214  does not detect a match/hit in unified main mapper  218  and/or intermediate register mapper  220 , multiplexer  223  selects the logical-to-physical register renaming data from architected register mapper  216 . If register management unit  214  detects a match/hit in unified main mapper  218  and/or intermediate register mapper  220 , register management unit  214  determines in a decision block whether a match/hit occurs in both unified main mapper  218  and intermediate register mapper  220 . If a hit/match is determined in both mappers  218  and  220 , a register management unit  214  determines whether the mapping entry in unified main mapper  218  is “younger” (i.e., the creation of the mapping entry is more recent) than the mapping entry in intermediate register mapper  220 . If entry in unified main mapper  218  is younger than the entry in intermediate register mapper  220 , multiplexer  223  selects the logical-to-physical register renaming data from unified main mapper  218 . If the entry in unified main mapper  218  is not younger than the entry in intermediate register mapper  220 , multiplexer  223  selects the logical-to-physical register renaming data from intermediate register mapper  220 . 
     If a match/hit does not occur in both unified main mapper  218  and intermediate register mapper  220 , it is determined whether an exclusive hit/match to unified main mapper  218  occurs. If an exclusive hit to unified main mapper  218  occurs, multiplexer  223  selects the logical-to-physical register renaming data from unified main mapper  218 . However, if a hit/match does not occur at unified main mapper  218  (thus, the hit/match exclusively occurs at intermediate register mapper  220 ), multiplexer  223  selects the logical-to-physical register renaming data from intermediate register mapper  220  (block  320 ). A general execution engine  224  uses the output data of the logical register lookup for execution. 
     In an example embodiment a dispatch unit  212  dispatches one or more instructions to register management unit  214 . A unified main mapper creates a new, logical-to-physical register mapping entry. Issue queue  222  maintains the issue queue position data of the dispatched instruction, which utilizes the mapping entry that is selected via the logical register lookup (described in  FIG. 3 ). General execution engine  224  detects whether any of the instructions under execution has finished (i.e., one of Us  130  has finished execution of an instruction). If the issued instruction has not finished, the method waits for an instruction to finish. In response to general execution engine  224  detecting that an instruction is finished, unified main mapper  218  moves the logical-to-physical register renaming data from unified main mapper  218  to intermediate register mapper  220 . Unified main mapper  218  retires the unified main mapping entry associated with the finished instruction. A completion unit  240  determines whether the finished instruction has completed. If the finished instruction has not completed, completion unit  240  continues to wait until it detects that general execution unit  224  has finished all older instructions. However, if completion unit  240  detects that the finished instruction has completed, intermediate register mapper  220  updates the architected coherent state of architected register mapper  216  and the intermediate register mapper  220  retires its mapping entry. 
     U.S. Pat. No. 6,189,088 “Forwarding stored data fetched for out-of-order load/read operation to over-taken operation read-accessing same memory location” to Gschwind, filed Feb. 13, 2001 and incorporated herein by reference describes an example out-of-order (OoO) processor. 
     According to Gschwind,  FIG. 3  is a functional block diagram of a conventional computer processing system (e.g., including a superscalar processor) that supports dynamic reordering of memory operations and hardware-based implementations of the interference test and data bypass sequence. That is, the system of  FIG. 3  includes the hardware resources necessary to support reordering of instructions using the mechanisms listed above, but does not include the hardware resources necessary to support the execution of out-of-order load operations before in-order load operations. The system consists of: a memory subsystem  301 ; a data cache  302 : an instruction cache  304 ; and a processor unit  300 . The processor unit  500  includes: an instruction queue  303 ; several memory units (MUs)  305  for performing load and store operations; several functional units (FUs)  307  for performing integer, logic and floating-point operations; a branch unit (BU)  309 ; a register file  311 ; a register map table  320 ; a free-registers queue  322 ; a dispatch table  324 ; a retirement queue  326 ; and an in-order map table  328 . 
     In the processor depicted in  FIG. 3 , instructions are fetched from instruction cache  304  (or from memory subsystem  301 , when the instructions are not in instruction cache  304 ) under the control of branch unit  309 , placed in instruction queue  303 , and subsequently dispatched from instruction queue  303 . The register names used by the instructions for specifying operands are renamed according to the contents of register map table  320 , which specifies the current mapping from architected register names to physical registers. The architected register names used by the instructions for specifying the destinations for the results are assigned physical registers extracted from free-registers queue  322 , which contains the names of physical registers not currently being used by the processor. The register map table  320  is updated with the assignments of physical registers to the architected destination register names specified by the instructions. Instructions with all their registers renamed are placed in dispatch table  324 . Instructions are also placed in retirement queue  326 , in program order, including their addresses, and their physical and architected register names. Instructions are dispatched from dispatch table  324  when all the resources to be used by such instructions are available (physical registers have been assigned the expected operands, and functional units are free). The operands used by the instruction are read from register file  311 , which typically includes general-purpose registers (GPRs), floating-point registers (FPRs), and condition registers (CRs). Instructions are executed, potentially out-of-order, in a corresponding memory unit  305 , functional unit  307  or branch unit  309 . Upon completion of execution, the results from the instructions are placed in register file  311 . Instructions in dispatch table  324  waiting for the physical registers set by the instructions completing execution are notified. The retirement queue  326  is notified of the instructions completing execution, including whether they raised any exceptions. Completed instructions are removed from retirement queue  326 , in program order (from the head of the queue). At retirement time, if no exceptions were raised by an instruction, then in-order map table  328  is updated so that architected register names point to the physical registers in register file  311  containing the results from the instruction being retired: the previous register names from in-order map table  328  are returned to free-registers queue  322 . 
     On the other hand, if an instruction has raised an exception, then program control is set to the address of the instruction being retired from retirement queue  326 . Moreover, retirement queue  326  is cleared (flushed), thus canceling all unretired instructions. Further, the register map table  320  is set to the contents of in-order map table  328 , and any register not in in-order map table  328  is added to free-registers queue  322 . 
     A conventional superscalar processor that supports reordering of load instructions with respect to preceding load instructions (as shown in  FIG. 3 ) may be augmented with the following: 
     1. A mechanism for marking load instructions which are issued out-of-order with respect to preceding load instructions; 
     2. A mechanism to number instructions as they are fetched, and determine whether an instruction occurred earlier or later in the instruction stream. An alternative mechanism may be substituted to determine whether an instruction occurred earlier or later with respect to another instruction; 
     3. A mechanism to store information about load operations which have been executed out-of-order, including their address in the program order, the address of their access, and the datum value read for the largest guaranteed atomic unit containing the loaded datum: 
     4. A mechanism for performing an interference test when a load instruction is executed in-order with respect to one or more out-of-order load instructions, and for performing priority encoding when multiple instructions interfere with a load operation; 
     5. A mechanism for bypassing the datum associated with an interfering load operation: and 
     6. A mechanism for deleting the record generated in step (3) at the point where the out-of-order state is retired from retirement queue  326  to register file  311  in program order. 
     The mechanisms disclosed by Gschwind are used in conjunction with the mechanisms available in the conventional out-of-order processor depicted in  FIG. 3 , as follows. Each instruction is numbered with an instruction number as it enters instruction queue  303 . A load instruction may be dispatched from dispatch table  324  earlier than a preceding load instruction. Such a load instruction is denoted below as an ‘out-of-order’ load operation. In such a case, the entry in retirement queue  326  corresponding to the load instruction is marked as an out-of-order load. 
     The detection of the dispatching of an out-of-order load operation from dispatch table  324  to a memory unit  305  for execution is preferably accomplished with two counters, a “loads-fetched counter” and a “loads-dispatched counter”. The loads-fetched counter is incremented when a load operation is added to dispatch table  324 . The loads-dispatched counter is incremented when a load operation is sent to a memory unit  305  for execution. The current contents of the loads-fetched counter is attached to a load instruction when the load instruction is added to dispatch table  324 . When the load instruction is dispatched from dispatch table  324  to a memory unit  305  for execution, if the value attached to the load instruction in dispatch table  324  is different from the contents of the loads-dispatched counter at that time, then the load instruction is identified as an out-of-order load operation. Note that the difference among the two counter values corresponds to the exact number of load operations with respect to which load instruction is being issued out-of-order. Out-of-order load instructions are only dispatched to a memory unit  305  if space for adding entries in load-order table is available. 
     The load-order table is a single table which is accessed by all memory units  305  simultaneously (i.e., only a single logical copy is maintained, although multiple physical copies may be maintained to speed up processing). Note that if multiple physical copies are used, then the logical contents of the multiple copies must always reflect the same state to all memory units  305 . 
     The instruction number of the instruction being executed and the fact of whether an instruction is executed speculatively is communicated to memory unit  305  for each load operation issued. 
     An instruction set architecture (ISA), implemented by a processor, typically defines a fixed number of architected general purpose registers that are accessible, based on register fields of instructions of the ISA. In out-of-order execution processors, rename registers are assigned to hold register results of speculatively executed of instructions. The value of the rename register is committed as an architected register value, when the corresponding speculative instruction execution is “committed” or “completed. Thus, at any one point in time, and as observed by a program executing on the processor, in a register rename embodiment, there exist many more rename registers than architected registers. 
     In one embodiment of rename registers, separate registers are assigned to architected registers and rename registers. In another, embodiment, rename registers and architected registers are merged registers. The merged registers include a tag for indicating the state of the merged register, wherein in one state, the merged register is a rename register and in another state, the merged register is an architected register. 
     In a merged register embodiment, as part of the initialization (for example, during a context switch, or when initializing a partition), the first n physical registers are assigned as the architectural registers, where n is the number of the registers declared by the instruction set architecture (ISA). These registers are set to be in the architectural register (AR) state; the remaining physical registers take on the available state. When an issued instruction includes a destination register, a new rename buffer is needed. For this reason, one physical register is selected from the pool of the available registers and allocated to the destination register. Accordingly, the selected register state is set to the rename buffer not-valid state (NV), and its valid bit is reset. After the associated instruction finishes execution, the produced result is written into the selected register, its valid bit is set, and its state changes to rename buffer (RB), valid. Later, when the associated instruction completes, the allocated rename buffer will be declared to be the architectural register that implements the destination register specified in the just completed instruction. Its state then changes to the architectural register state (AR) to reflect this. 
     While registers are almost a universal solution to performance, they do have a drawback. Different parts of a computer program all use their own temporary values, and therefore compete for the use of the registers. Since a good understanding of the nature of program flow at runtime is very difficult, there is no easy way for the developer to know in advance how many registers they should use, and how many to leave aside for other parts of the program. In general these sorts of considerations are ignored, and the developers, and more likely, the compilers they use, attempt to use all the registers visible to them. In the case of processors with very few registers to begin with, this is also the only reasonable course of action. 
     Register windows aim to solve this issue. Since every part of a program wants registers for its own use, several sets of registers are provided for the different parts of the program. If these registers were visible, there would be more registers to compete over, i.e. they have to be made invisible. 
     Rendering the registers invisible can be implemented efficiently; the CPU recognizes the movement from one part of the program to another during a procedure call. It is accomplished by one of a small number of instructions (prologue) and ends with one of a similarly small set (epilogue). In the Berkeley design, these calls would cause a new set of registers to be “swapped in” at that point, or marked as “dead” (or “reusable”) when the call ends. 
     Processors such as PowerPC save state to predefined and reserved machine registers. When an exception happens while the processor is already using the contents of the current window to process another exception, the processor will generate a double fault in this very situation. 
     In an example RISC embodiment, only eight registers out of a total of 64 are visible to the programs. The complete set of registers are known as the register file, and any particular set of eight as a window. The file allows up to eight procedure calls to have their own register sets. As long as the program does not call down chains longer than eight calls deep, the registers never have to be spilled. i.e. saved out to main memory or cache which is a slow process compared to register access. For many programs a chain of six is as deep as the program will go. 
     By comparison, another architecture provides simultaneous visibility into four sets of eight registers each. Three sets of eight registers each are “windowed”. Eight registers (i0 through i7) form the input registers to the current procedure level. Eight registers (L0 through L7) are local to the current procedure level, and eight registers (o0 through o7) are the outputs from the current procedure level to the next level called. When a procedure is called, the register window shifts by sixteen registers, hiding the old input registers and old local registers and making the old output registers the new input registers. The common registers (old output registers and new input registers) are used for parameter passing. Finally, eight registers (g0 through g7) are globally visible to all procedure levels. 
     An improved the design allocates the windows to be of variable size, which helps utilization in the common case where fewer than eight registers are needed for a call. It also separated the registers into a global set of 64, and an additional 128 for the windows. 
     Register windows also provide an easy upgrade path. Since the additional registers are invisible to the programs, additional windows can be added at any time. For instance, the use of object-oriented programming often results in a greater number of “smaller” calls, which can be accommodated by increasing the windows from eight to sixteen for instance. The end result is fewer slow register window spill and fill operations because the register windows overflow less often. 
     Instruction set architecture (ISA) processor out-of-order instruction implementations may execute architected instructions directly or by use of firmware invoked by a hardware instruction decode unit. However, many processors “crack” architected instructions into micro-ops directed to hardware units within the processor. Furthermore, a complex instruction set computer (CISC) architecture processor, may translate CISC instructions into reduced instruction set computer (RISC) architecture instructions. In order to teach aspects of the invention, ISA machine instructions are described, and internal operations (iops) may be deployed internally as the ISA machine instruction, or as smaller units (micro-ops), or microcode or by any means well known in the art, and will still be referred to herein as machine instructions. Machine instructions of an ISA have a format and function as defined by the ISA, once the ISA machine instruction is fetched and decoded, it may be transformed into iops for use within the processor. 
     A computer processor may comprise an instruction fetching unit for obtaining instructions from main storage, a decode unit for decoding instructions, an issue queue for queuing instructions to be executed, execution units for executing function of instructions and a dispatch unit for dispatching instructions to respective execution units preferably in a pipeline. In embodiments, an issue queue, a decode unit or a dispatch unit, for example, alone or in combination, may modify an instruction such that it does not have to be executed after a previous instruction. 
     In an embodiment, the processor determines that there is a first instruction and a second instruction, wherein the second instruction is configured to use the results of execution of the first instruction in executing the second instruction. A test of the two instructions determines that they can be modified in order to produce instructions that can be executed more efficiently. In an example, the modification enables the two instructions to be executed out-of-order (the second instruction (second in program order) is not dependent on results of the first instruction (first in program order)). 
     In an example embodiment, an architected instruction set provides immediate instructions, (immediate instructions have an immediate field sometimes referred to as a displacement field or a constant field, the immediate field providing an immediate value). The immediate instruction may also include a register field, wherein an operand is a register value of a register identified by the register field or wherein an operand is a memory value of a memory location determined by the register value. The immediate instruction further has an opcode field having a value determining an operation to be performed (such as an ADD, SUBTRACT, AND, OR, Load, Store for example). Execution of the immediate instruction performs the operation using the operand value and the immediate value and may store the result in an immediate instruction specified result register (or main storage). 
     In an example architecture, the instruction set includes immediate instruction, wherein operation is performed on only a portion of the operand. Thus, an immediate value may be added to a low order portion of the operand for example. The instruction set may provide a 16 bit immediate field and a 32 bit register, in which case a constant to be loaded into a 32 bit register would require two immediate instructions. In an example sequence of instructions, a first immediate instruction is used to load the low order portion and a second immediate instruction is used to load the high order portion. In another instruction set, immediate fields may be 8 bits and registers 32 bits, in which case 4 immediate instructions would be needed to load a constant into the register. In some environments, only a portion of the operand may be needed, such as in creating a table address, only the low order portion is provided by an instruction in a sequence of instructions (each sequence of instructions identifying a table entry by using an immediate value to a low order portion of the register, but not effecting the high order portion that locates the table). In that case, only two 8 bit immediate instructions are needed for loading the low order 16 bits of the 32 bit register. 
     In an example embodiment, two immediate instructions are included in a program, a first immediate instruction is followed in program order by a second immediate instruction. Each instruction includes a 16 bit immediate (or displacement) field (disp) and a target register (RT). The function of the first immediate instruction is to load the value of the first disp field into the low order portion of the first RT. The function of the second immediate instruction is to load the value of the second disp field into the high order portion of the second RT. The processor executing the two instructions determines that the two instructions can be combined, for example in an issue queue of the processor, because the processor has the ability to detect the two instructions and combine the disp fields by concatenating the first disp and the second disp into an internal data value that fits in the pipeline, the first instruction is discarded and a modified second instruction is created having the concatenated value as a disp field. In an embodiment, the internal data value that is supported is narrow so only a portion of the second disp value can be combined, in which case the processor detects only the occurrence of second disp values that are small enough. The immediate instructions having the form: 
     RT←disp 
     where 
     first instruction: RT←disp(low) 
     second instruction: RT←disp(high) 
     modified second instruction: RT←disp(high)//disp(low) 
     In another embodiment, the first and second instructions further comprise a second register field (RA field) for identifying an operand register (RA). 
     instruction form RT←RA, disp 
     A function is performed by each instruction using the operand register RA and the disp field. An occurrence of the two instructions is detected where each instruction is performing the same operation but only on a portion of RA and RT. For example, a Logical AND instruction ANDS the RA value to the disp value: 
     first instruction: r2←r3, disp(high) [ands disp to the high portion of the value of the r3 register and puts the result in the high portion of the r2 register] 
     second instruction: r2←r3, disp(low) [ands disp to the low portion of the value of the r3 register and puts the result in the low portion of the R2 register] 
     modified second instruction: r2←r3, disp(high)//disp(low) [ands disp(high) concatenated with disp(low) to the value of the r3 register and puts the result in the r2 register] 
     In a variation an arithmetic operation is performed in two instructions in which case the two instructions must be executed in program order since the result of the first instruction is needed in order to execute the second instruction. In this example, an r2 and an r4 result must be stored in the registers. In this case the second instruction is modified in order to create an internal pair of instructions that can be executed out-of-order. 
     first instruction: r2←r3, disp(high) [adds an 8 bit disp concatenated with 8 low order 0&#39;s to the value of the 16 bit r3 register and puts the result in the 16 bit r2 register] 
     second instruction: r4←r2, disp(low) [adds a sign extended 8 bit disp (16 bits) to the 16 bit r2 register and puts the result in the 16 bit r4 register] 
     modified second instruction: r4←r3, disp(high)//disp(low) [adds disp(high) concatenated with disp(low) to the value of the r3 register and puts the result in the r4 register] 
     In an embodiment, a first instruction sequence consisting of at least a first instruction “i0” and a second instruction “i1”, and a sequence of multiple internal instructions (internal ops (iops)) that are improvements of the instruction sequence. For example, a producer instruction followed by a consumer instruction in program order (requiring in-order execution) might be optimized to create iop0 corresponding to the producer instruction and iop1 corresponding to the consumer instruction, where iop0 and iop1 can be executed out-of-order. 
     Referring now to  FIG. 4A , an exemplary embodiment is shown. A first decoder 0  402  receives from an instruction cache (I-Cache)  401 , a first instruction 0 (I0), and a second decoder 1  403  receives a second instruction I1. The decoders  402   403  perform initial decoding  405   407 , and provide information  411   412   413   416  about the decoded plurality of instructions (represented by at least an instruction I0 and an instruction I1) to an Optimization analysis engine (OAE)  409 . Instruction decode logic in decoders 0  405  and 1  407  also generates an initial decoded iop representation for the first and second instruction corresponding to a first iop (iop0)  414  and second iop (iop1)  415  when no optimization takes place. 
     In an embodiment, the OAE  409  compares the decoded characteristics of the instructions in example decoders 0  402  and 1  403  to determine whether they correspond to one of a plurality of compound sequences that are candidates for optimization. In accordance with one embodiment, the OAE  409  is also responsive to a plurality of control signals, to suppress the recognition of compound sequences, e.g., when a configuration bit is set. Configuration bits can correspond to implementation specific registers to disable all or a subset of compound instructions to disable decode time instruction optimization (DTIO) when a design error has been detected, when a determination has been made that performing a DTIO sequence is no longer advantageous, when a processor enters single-instruction (tracing) mode, and so forth. The OAE  409  can be a single entity as shown in  FIG. 4A , or can be replicated, distributed, split or otherwise integrated in one or more of decoders 0  402  and 1  403 , and the OAE  409  can be combined in a single large compound decoder, e.g., including but not limited to a complex decoder comprising the OAE  409 , decoder0  402  and decoder1  403  in a single structure, to facilitate logic optimization and circuit design improvements. 
     The OAE provides information indicating whether a compound sequence which can be optimized has been detected, as well as information about the nature of the sequence (i.e., which of a plurality of instruction, and specific properties of the sequence required by the decoder optimization logic to generate an optimized sequence. OAE also provides steering logic to a selector to select one of an unoptimized iop generated by the initial decode operation, or an iop corresponding to an iop in an optimized DTIO sequence which has been generated by “optimization logic” under control of the OAE control signals, and additional information received from decoders having decoded a portion of a compound sequence being optimized, such as register specifiers, immediate fields and operation codes for example. 
     OAE  409  may provide selection information  418  to selection logic  419   410  for determining if the respective instructions I0 or I1 should generate respective iop0  414  and iop1  415 , or if an optimized instruction should be used. 
     An embodiment of an OAE  409  process is demonstrated in the following example Pseudo-code: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 IF (decoder0_addis &amp;&amp; decoder1_additive_immed &amp;&amp; 
               
               
                   
                  decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   
                  decoder1_displacement_OK &amp;&amp; 
               
               
                   
                  decoder0_rt == decoder1_rt) THEN 
               
               
                   
                  decoder0_subsume &lt;= TRUE; 
               
               
                   
                  decoder1_concat_immed &lt;= TRUE; 
               
               
                   
                 ELSIF (decoder0_addis &amp;&amp; decoder1_additive_immed &amp;&amp; 
               
               
                   
                  decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   
                  decoder1_displacement_OK &amp;&amp; 
               
               
                   
                  decoder0_rt /= decoder1_rt) THEN 
               
               
                   
                  decoder0_subsume &lt;= FALSE; 
               
               
                   
                  decoder1_concat_immed &lt;= TRUE; 
               
               
                   
                 ELSIF (decoder0_li &amp;&amp; decoder1_addis &amp;&amp; 
               
               
                   
                  decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   
                  decoder1_displacement_OK &amp;&amp; 
               
               
                   
                  decoder0_rt == decoded1_rt) THEN 
               
               
                   
                  decoder0_subsume &lt;= TRUE; 
               
               
                   
                  decoder1_concat_immed &lt;= TRUE; 
               
               
                   
                 ELSIF (decoder0_li &amp;&amp; decoder1_addis &amp;&amp; 
               
               
                   
                  decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   
                  decoder1_displacement_OK &amp;&amp; 
               
               
                   
                  decoder0_rt /= decoder1_rt) THEN 
               
               
                   
                  decoder0_subsume &lt;= FALSE; 
               
               
                   
                  decoder1_concat_immed &lt;= TRUE; 
               
               
                   
                 ELSIF (decoder0_andis &amp;&amp; decoder1_and &amp;&amp; 
               
               
                   
                  decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   
                  decoder1_displacement_OK &amp;&amp; 
               
               
                   
                  decoder0_rt == decoder1_rt) THEN 
               
               
                   
                  decoder0_subsume &lt;= TRUE; 
               
               
                   
                  decoder1_concat_immed &lt;= TRUE; 
               
               
                   
                 ELSIF 
               
               
                   
                   
               
            
           
         
       
     
     In an example embodiment based on PowerPC architecture, the following two instructions are candidates for optimization: 
     first immediate instruction: ADDIS r9=r2, high_field (disp) 
     . . . 
     second immediate instruction: ADDI r3=r9, low-field(disp) 
     Where the first and second immediate instructions have the generic form: 
     
         
         
           
             ADDIS (RT)←(RA)+(SIMM//0x0000) 
             ADDI (RT)←(RA)+(sign extended SIMM)
 
wherein, the first instruction comprises a first immediate field (disp), a first register field (r2) and a first result register field (r9) and the first instruction is configured to perform an operation (ADDIS) using a value of the first immediate field and the high order portion of a register identified by the first register field and store the result in the first result register specified by the first result register field. The second instruction comprises a second immediate field (disp), a second register field (r9) and a second result register field (r3) and the second instruction is configured to perform an operation using a value of the second immediate field and the low order portion of a register identified by the first register field and store the result in the second result register specified by the second result register field. An example, an ADDIS instruction is the first instruction and an ADDI instruction is the second instruction. (These two instructions are used as examples to teach aspects of the invention but the invention is not limited to these instructions). Of course, there may be other intervening instructions between the first immediate instruction and the second immediate instruction in some environments.
 
           
         
       
    
     ADDIS concatenates a 16 bit immediate field value as a high order 16 bits to 16 low order 0&#39;s and arithmetically adds the concatenated sign extended 32 bit value to an operand located at an instruction specified RA register address. The result is stored in an instruction specified RT result register (r9). (it should be noted, in the PowerPC ISA, if the RA field specifies register 0, 32 or 64 0&#39;s are added to the concatenated 32 bit value). 
     ADDI concatenates sign-extends a 16 bit immediate field value and arithmetically adds the sign-extended value to an operand located at an instruction specified RA register address. The result is stored in an instruction specified RT result register (r9). (it should be noted, in the PowerPC ISA, if the RA field specifies register 0, 32 or 64 0&#39;s are added to the concatenated 32 bit value). 
     The Load Immediate (LI) instruction (the PowerPC li instruction is a form of the addi instruction where A=−0) stores a sign extended low order 16 bit immediate value in a target register (rD). 
     
       
         
           
               
             
               
                   
               
             
            
               
                 
                   
                     
                     
                         
                         
                     
                   
                 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                   
               
             
            
               
                 
                   
                     
                     
                         
                         
                     
                   
                 
               
               
                   
               
            
           
         
       
     
     The second instruction can be modified to include the first immediate field and the second immediate field (by concatenating all or part of the first immediate field with the second immediate field) and specify the second register specified by the r2 field (rather than the first register specified by the r9 field) so the resulting modified second instruction can be executed out-of-order with respect to the execution of the first instruction: 
     first immediate instruction: ADDIS r9=r2, high_field (disp) 
     modified second immediate instruction: ADDI r3=r2, high_field//low-field(disp) 
     In an embodiment wherein only a portion of the immediate fields can be concatenated due to pipeline restrictions, a detector circuit determines that the first immediate field has a predetermined number of high order ‘0’s and concatenates only a portion of the first immediate field with the second immediate field to form the modified instruction. If the first instruction has less high order ‘0’s it is executed in order without modification. In an alternate embodiment, a detector circuit can detect that the first immediate field has a predetermined number of high order ‘0’s or ‘1’s and concatenates only a portion of the first immediate field with the second immediate field to form the modified instruction. 
     In another example embodiment, 
     ADDIS r9=r2, low_field (disp) 
     ADDI r3=r9, high-field(disp) 
     the first instruction comprises a first immediate field (low-field (disp)) and the second instruction comprises a second immediate field (high-field (disp)) in which case, the second instruction may be modified similarly to the previous example by replacing the second register field with the first register field and, in concatenating all or a portion of the first immediate field (a low-field(disp) as a low order value with the second immediate field (a high-field(disp)) as a high order value. 
     first immediate instruction: ADDIS r9=r2, low_field (disp) 
     modified second immediate instruction (ADDI→ADDIM):
         ADDIM r3=r2, high_field (disp)//low-field (disp)       

     In an embodiment, a processor and a compiler cooperate to facilitate the function. The compiler developers identify combinations of first and second immediate instructions for compiled programs that would be suited for aspects of the invention. The processor is designed specifically to detect an occurrence of the first and second immediate instructions in an instruction stream and to modify the second immediate instructions according to a predefined criteria. The compiler, compiles code using instructions that will trigger the modified second immediate instructions accordingly. 
     In the previous example, the predefined criteria may be an ADDIS instruction (ADDIS opcode) followed by an ADDI instruction (ADDI opcode) wherein the RT (result register) field of the ADDIS is the same as the RA field of the ADDI instruction. In another embodiment, the order could be generalized wherein the preferred criteria is an ADDIS instruction (ADDIS opcode) in combination with an ADDI instruction (ADDI opcode, and including the special case of LI operation of the ADDI wherein RA=0) wherein the RT (result register) field of the first is the same as the RA field of the second instruction. 
     In an embodiment, the engine is configured to detect a plurality of patterns, and generate control signals. Example Analysis optimization engine Pseudo-code are as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 IF (decoder0_addis &amp;&amp; decoder1_additive_immed &amp;&amp;  /*1 st  Clause*/ 
               
               
                   decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   decoder1_displacement_OK &amp;&amp; 
               
               
                   decoder0_rt == decoder1_rt) 
               
               
                   THEN: 
               
               
                   decoder0_subsume &lt;= TRUE; 
               
               
                   decoder1_concat_immed &lt;= TRUE; 
               
               
                 ELSE; 
               
               
                 IF (decoder0_addis &amp;&amp; decoder1_additive_immed &amp;&amp;  /*2nd Clause*/ 
               
               
                   decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   decoder1_displacement_OK &amp;&amp; 
               
               
                   decoder0_rt /= decoder1_rt) 
               
               
                   THEN 
               
               
                   decoder0_subsume &lt;= FALSE; 
               
               
                   decoder1_concat_immed &lt;= TRUE; 
               
               
                 ELSE; 
               
               
                 IF (decoder0_li &amp;&amp; decode1_addis &amp;&amp;       /*3rd Clause*/ 
               
               
                   decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   decoder1_displacement_OK &amp;&amp; 
               
               
                   decoder0_rt == decoder1_rt) 
               
               
                   THEN 
               
               
                   decoder0_subsume &lt;= TRUE; 
               
               
                   decoder1_concat_immed &lt;= TRUE; 
               
               
                 ELSE; 
               
               
                 IF (decoder0_li &amp;&amp; decoder1_addis &amp;&amp;   /*4th Clause*/ 
               
               
                   decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   decoder1_displacement_OK &amp;&amp; 
               
               
                   decoder0_rt /= decoder1_rt) 
               
               
                   THEN 
               
               
                   decoder0_subsume &lt;= FALSE; 
               
               
                   decoder1_concat_immed &lt;= TRUE; 
               
               
                 ELSE 
               
               
                 IF (decoder0_andis &amp;&amp; decoder1_and &amp;&amp;  /*5th Clause*/ 
               
               
                   decoder0_target == decoder1_rs1 &amp;&amp; 
               
               
                   decoder1_displacement_OK &amp;&amp; 
               
               
                   decoder0_rt == decoder1_rt) 
               
               
                    THEN 
               
               
                    decoder0_subsume &lt;= TRUE; 
               
               
                    decoder1_concat_immed &lt;= TRUE; 
               
               
                   
               
            
           
         
       
     
     The example function is as follows. 
     1st IF Clause 
     x1 “addis rD1, rA1, SIMM(1)” 
     x2 “addi rD2, rA2, SIMM(2)” 
     any addis (x1) followed by certain additive instructions targeting a GPR (x2) (such as D-Form PowerPC instructions), wherein the target register of the addis is the same as a base register of the source (rD1 is the same register as rA2), that is not a store (i.e., addi instructions and loads, and where the displacement value in decoder0 meets a criterion expressed as displacement_OK (e.g., a limit n other number of bits) will generate control signals to indicate that a DTIO optimization has been detected (select_DTIO), a signal preferably connected to selection logic of  FIG. 4A  that will: 
     a) indicate the specific compound sequence (DTIO_SEQ_no) which will be used by optimization logic to generate modified signals 
     b) generate a control signal indicating whether the iop in decoder0 should be emitted or replaced by a NOP (decoder0_subsume) and whether decoder1 should combine the displacement from decoder0 with its own displacement. (In an embodiment, the 1 st  clause checks for rD1 and rD2 specifying the same register, in which case the first instruction (x1) is discarded or replaced by a no-op. 
     2nd IF Clause 
     x1 “addis rD1, rA1, SIMM(1)” 
     x2 “addi rD2, rA2, SIMM(2)” 
     any addis (x1) followed by an additive certain instruction targeting a GPR (such as D—Form PowerPC instructions) (x2), wherein the target register of the addis is the same as the base register of the source (rD1 is the same register as rA2), and where the displacement value (SIMM(1)//0x000) in decoder0 meets a criterion expressed as displacement_OK (e.g., a limit on the number of bits supported by iops of the processor) 
     This will generate control signals to: 
     a) indicate that a DTIO optimization has been detected (select_DTIO), a signal preferably connected to selection logic of  FIG. 4A ; 
     b) indicate the specific compound sequence (DTIO_SEQ_no) which will be used by optimization logic to generate modified signals 
     c) generate a control signal indicating whether the iop in decoder0 should be emitted or replaced by a NOP (no-ope) (decoder0_subsume) 
     and 
     d) indicate whether decoder1 should combine the displacement (SIMM) from decoder0 with its own displacement (SIMM) 
     3rd IF Clause 
     x1 “addi rD1, rA1, SIMM(1)” 
     x2 “addis rD2, rA2, SIMM(2)” 
     any load immediate (which is really an addi to register 0) followed by an addis, where the displacement (immediate value (SIMM(1)//0x0000)) on addis in decoder 1 meets the displacement criterion for merging displacements, where the target of the load immediate (rD1) is the same register as the target (rD2) and source (rA2) of the addis 
     This will generate control signals to: 
     a) indicate that a DTIO optimization has been detected (select_DTIO), a signal preferably connected to selection logic of  FIG. 4A ; 
     b) indicate the specific compound sequence (DTIO_SEQ_no) which will be used by optimization logic to generate modified signals 
     c) generate a control signal indicating whether the iop in decoder1 should be emitted or replaced by a NOP (decoder1_subsume) and whether decoder0 should combine the displacement from decoder1 with its own displacement 
     4th IF Clause: 
     x1 “addi rD1, rA1, SIMM(1)” 
     x2 “addis rD2, rA2, SIMM(2)” 
     any load immediate (x1) (which is really an addi to register 0) followed by an addis, where the displacement (immediate value (SIM4//x0x000)) on addis in decoder 1 meets the displacement criterion for merging displacements, where the target of the load immediate is NOT the same register as the target of the addis (rD2 not the same register as rD1), but is the same as the source of addis; (rD2 is; the same register as rA2) 
     This will generate control signals to: 
     a) indicate that a DTIO optimization has been detected (select_DTIO), a signal preferably connected to selection logic of  FIG. 4A ; 
     b) indicate the specific compound sequence (DTIO_SEQ_no) which will be used by optimization logic to generate modified signals 
     c) generate a control signal indicating whether the iop in decoder0 or decoder1 should be emitted or replaced by a NOP (decoder0 . . . subsume, decoder1_subsume) 
     and 
     d) indicate whether decoder0 should combine the displacement from decoder1 with its own displacement by prepending its own displacement to decoder0&#39;s displacement (decoder1_immed_merged0d1) 
     5th IF Clause: 
     detects a combination of an andis (“andis rDa, rAa, SIMM(a)”) and an andi (“andi rDb, rAb, SIMM(b)”) instruction, where the target of andis (rDa) is the same as the source and target of andi (rDb; rAb). 
     While PowerPC instructions is used to demonstrate aspects of the invention, the invention could be advantageously practiced by other PowerPC instructions as well as any ISA, including, but not limited to Intel® x86 ISA for example. 
     It should be noted that in the PowerPC examples above, concatenation of two SIMM immediate values in PowerPC iop can be performed when the low-order SIMM is positive (high order bit=0). However, for the case where the low-order SIMM is negative (sign extended), an effective ADD operation of the sign bits with the high order value is needed. This can be done at any stage in the pipeline, as long as the pipeline understands that a bit of the concatenated value should be treated as a sign bit which must be effectively propagated and added to a high order portion of an immediate constant. In an embodiment, only positive values are optimized. In another embodiment, the concatenation is performed and the pipeline is informed that the concatenated value includes an embedded sign bit, for example by providing a tag to the instruction that is passed in the pipeline. In an embodiment, the concatenated value is manipulated by the execution unit to effectively handle the sign bit which manipulation effectively subtracts a 1 (adds all 0&#39;s) to the high order portion of the concatenated value. In an embodiment, an arithmetic operation is performed on the high-order bits based on the sign bit in the decode unit to produce a corrected value in the optimized iop. In an embodiment, the decode unit creates an iop immediate field representing the combined low order value and high order value. 
     Although an ADD operation has been used to teach aspects of the invention, one skilled in the art will appreciate that the invention can be practiced with a variety of instructions having other than ADD operations, including logical operations (AND, OR, XOR for example) or other arithmetic operations and the like. 
     Accordingly, PowerPC offers other immediate instructions that would similarly lend themselves to be optimized using aspects of the invention. For example, the “OR Immediate” (ORI) and “OR Immediate Shifted” (ORIS) instructions as follows 
     
       
         
           
               
             
               
                   
               
             
            
               
                 
                   
                     
                     
                         
                         
                     
                   
                 
               
               
                   
               
            
           
         
       
     
                                                                       
oris RA←(RS)|(0x00000000/UI//0x0000)
 
     Performs a logical OR “|” operation of the immediate field (UI) with the high order 16 bits of the low order 32 bits of the 64 bit RS operand. 
     and 
     on RA←(RS)|(0x000000000000//UI) 
     performs a logical OR operation of the immediate field (UI) with the low order 16 bits of the 64 bit RS operand. 
     In an embodiment (with reference to the z/Architecture ISA), dependent instructions having register dependencies can be made independent. For example, 2 sequential instructions wherein the first instruction in program order stores to a target register (RT) and a next instruction uses the same register as a source register (RS). Thus, the instruction sequence 
     AGRK r5←r3 ADD r4 
     AGRK r6←r5 ADD r2 
     can be implemented by modifying the second instruction as shown: 
     AGRK r5←r3 ADD r4 
     LAM r6←r2 ADD r3 ADD r4 iop 
     where the LAM instruction is an iop instruction that adds content of 3 registers RA, RB and RC and stores the result in a register RT. 
     
       
         
         
             
             
         
       
     
     For ADD (A, AG, AGF, AGFR, AGR, AR, and AY) and for ADD IMMEDIATE (AFI, AGFI, AGSI, and ASI), the second operand is added to the first operand, and the sum is placed at the first-operand location. For ADD (AGRK and ARK) and for ADD IMMEDIATE (AGHIK and AHIK), the second operand is added to the third operand, and the sum is placed at the first operand location. 
     Also, in another embodiment 
     AGRK r5←r3 ADD r4 
     AGHIK r6←r5 ADD displacement 
     can be implemented by modifying the second instruction as shown 
     AGRK r5←r3 ADD r4 
     LA r6←disp ADD r3 ADD r4 
     where the LA instruction is an IOP instruction that adds 2 registers and a displacement value. 
     
       
         
         
             
             
         
       
     
     For ADD IMMEDIATE (AGHIK and AHIK), the second operand (immediate field I2) is added to the third operand (R3), and the sum is placed at the first operand (R1) location. For ADD IMMEDIATE (AGHIK), the first and third operands are treated as 64-bit signed binary integers, and the second operand is treated as a 16-bit signed binary integer. 
     Those skilled in the art will appreciate that while the exemplary embodiments have been directed towards the detection of two-instruction sequences, and OAE may be connected to more than two decoders, and identify DTIO sequences consisting of more than 2 instructions. Furthermore the DTIO sequence of instructions may be separated by additional instructions in an embodiment. 
     Referring to  FIG. 4B , an embodiment of an example optimizer  422  is shown. A first instruction  420  and a next sequential instruction (NSI)  421  are determined to be candidates for optimization  423 . The first example instruction  420  includes an opcode (OP1) a source register field (RA1), an immediate field (I1) and a result target field (RT1). The NSI example instruction  421  includes an opcode (OP2) a source register field (RA2), an immediate field (I2) and a result target field (RT2). If they are not optimizable according to the optimization criterion, they are executed in order (OP1  426  then OP2  427 ). If, however, they meet the criterion (including that RT1=RA2), the NSI is modified by the optimizer  422  to include a concatenated value of I1 and I2 to produce a new NSI  425 , that can be executed out-of-order relative to the first instruction  424 , preferably the modified NSI has a new effective opcode (OP2x). 
     Referring to  FIG. 4C , another embodiment of an example optimizer  422  is shown. A first instruction  430  and a next sequential instruction (NSI)  431  are determined to be candidates for optimization  433 . The first example instruction  430  includes an opcode (OP1) a source register field (RA1), another source register field (RB1) and a result target field (RT1). The NSI example instruction  430  includes an opcode (OP2) a source register field (RA2), another source register field (RB2) and a result target field (RT2). If they are not optimizable according to the optimization criterion, they are executed in order (OP1  426  then OP2  427 ). If, however, they meet the criterion (including that RT1=RA2), the NSI is modified by the optimizer  422  to include RB1 to produce a new NSI  435 , that can be executed out-of-order relative to the first instruction  434 , preferably the modified NSI has a new effective opcode (OP2x). 
     Referring to  FIG. 5 , in an embodiment, a first instruction and a second instruction in program order are fetched  501  for execution, the second instruction dependent on results of execution of the first instruction, wherein the second instruction is modified by the processor to include attributes of the first instruction, enabling the modified second instruction to be executed and completed out-of-order relative to the first instruction. 
     In an embodiment, the processor determines  502  that the first instruction and second instructions are configured to be executed in-order, comprising determining  503  that the first instruction specifies a target operand location for a target operand and the second instruction specifies a source operand location for a source operand, wherein the first instruction is configured to store a target operand at the target operand location, wherein the source operand location is the same as the target operand location, wherein the second instruction is configured to obtain a source operand at the source operand location. The processor replaces  504  the second instruction with a new second instruction, wherein the new second instruction is not dependent on the target operand of the first instruction. The processor executes  505  the first instruction and the new second instruction, and permits out-of-order completion of the first instruction and the new second instruction. 
     Referring to  FIG. 6 , in an embodiment, the first instruction comprises a first immediate field and the second instruction comprises a second immediate field  601 , wherein portions of the first immediate field and the second immediate field are incorporated as immediate fields of the new second instruction. 
     In an embodiment, the incorporating  602  portions of the first immediate field and the second immediate field comprises concatenating a portion of the first immediate field with a portion of the second immediate field. 
     In an embodiment, the new instruction specifies  604  the source operand locations of the first instruction and at least one source operand location of the second instruction. 
     In an embodiment, it is determined  605  that the target operand location is a first target register of the first instruction and the source operand location is a source register of the second instruction. 
     Referring to  FIG. 7 , in an embodiment, the second instruction is determined  701  to be configured to be replaced by the new instruction, wherein the determining  701  that the second instruction is configured to be replaced is based on the opcodes of the first instruction and the second instruction, that the first instruction and the second instruction perform a compatible function  702  and that the compatible function is configured  703  to use the first immediate field of the first instruction to produce a first portion of the first target register and that the compatible function is configured  704  to use the second immediate field of the second instruction to produce a second portion of the first target register of the second instruction, wherein one of said first portion and said second portion consists of most significant bits and the other of said first portion and said second portion consists of least significant bits. 
     Referring to  FIG. 8 , in an embodiment, it is determined  801  that the first instruction and second instructions are configured to be executed in-order further comprises determining that a low order portion of a low order immediate field is a positive value. 
     In an embodiment, responsive to determining that a low order immediate field is a negative value, a 1 is effectively subtracted  802  from a high order portion of the immediate field of the new instruction before executing the new instruction. 
     In an embodiment “decoding and optimization of one instruction of a program is performed in the microprocessor pipeline concurrently to the execution of other instructions of the same program in that microprocessor pipeline”, 
     In another embodiment, the decoding for the purpose of program optimization may be the same decoding also used to inject the decoded operation into the microprocessor pipeline for execution of said decoded instruction, when said decoded instruction has not been optimized. For an example, the processor interrupts the program between execution of the pair of instructions and on returning for execution, the processor executes the not-optimized instruction. 
     In another embodiment, the directly decoded or decode-time optimized internal operation (lop) sequence is directly injected into the microprocessor pipeline for immediate execution. 
     In an embodiment, a pair of instructions are determined to be candidates for optimization, in order to be executed out-of-order by any one of a decode logic circuit, a dispatch logic circuit, an issue queue logic circuit or a cracking logic circuit operating on the instructions to be optimized. In another embodiment an optimization circuit determines candidate instructions for optimization at or after an instruction decode circuit decodes the candidate instructions, and causes the optimized instruction to be effectively inserted in the pipeline rather than the original instruction being optimized. 
     I like (1) best, but we might pick any one as a dependent claim for ease of promotion into the independent claim, and put boiler plate for all of these differentiators to point examiner to during prosecution, in order to clear up any misunderstandings on the part of a misguided examiner. 
     In a commercial implementation of functions and instructions, such as operating system programmers writing in assembler language. These instruction formats stored in a storage medium  114  (also known as main storage or main memory) may be executed natively in a z/Architecture IBM Server, PowerPC IBM server, or alternatively, in machines executing other architectures. They can be emulated in the existing and in future IBM servers and on other machines of IBM (e.g., pSeries® Servers and xSeries® Servers). They can be executed in machines where generally execution is in an emulation mode. 
     In an embodiment, instructions and functions defined for a first processor designed for an instruction set architecture (ISA) are emulated on a second processor having a different ISA. Machine instructions of a first ISA for example, are translated to emulation program routines employing machine instructions and functions of a second ISA. The emulation program, running on the second processor, runs programs written to the first ISA by fetching machine instructions of the program, translating the fetched machine instructions to program modules comprising machine instructions of the second ISA and then executing the program modules on the second processor designed to the second ISA. 
     In emulation mode, the specific instruction being emulated is decoded, and a subroutine is built to implement the individual instruction, as in a C subroutine or driver, or some other technique is used for providing a driver for the specific hardware, as is within the skill of those in the art after understanding the description of an embodiment of the invention. 
     Moreover, the various embodiments described above are just examples. There may be many variations to these embodiments without departing from the spirit of the present invention. For instance, although a logically partitioned environment may be described herein, this is only one example. Aspects of the invention are beneficial to many types of environments, including other environments that have a plurality of zones, and non-partitioned environments. Further, there may be no central processor complexes, but yet, multiple processors coupled together. Yet further, one or more aspects of the invention are applicable to single processor environments. 
     Although particular environments are described herein, again, many variations to these environments can be implemented without departing from the spirit of the present invention. For example, if the environment is logically partitioned, then more or fewer logical partitions may be included in the environment. Further, there may be multiple central processing complexes coupled together. These are only some of the variations that can be made without departing from the spirit of the present invention. Additionally, other variations are possible. For example, although the controller described herein serializes the instruction so that one IDTE instruction executes at one time, in another embodiment, multiple instructions may execute at one time. Further, the environment may include multiple controllers. Yet further, multiple quiesce requests (from one or more controllers) may be concurrently outstanding in the system. Additional variations are also possible. 
     As used herein, the term “processing unit” includes pageable entities, such as guests: processors: emulators: and/or other similar components. Moreover, the term “by a processing unit” includes on behalf of a processing unit. The term “buffer” includes an area of storage, as well as different types of data structures, including, but not limited to, arrays; and the term “table” can include other than table type data structures. Further, the instruction can include other than registers to designate information. Moreover, a page, a segment and/or a region can be of sizes different than those described herein. 
     One or more of the capabilities of the present invention can be implemented in software, firmware, hardware, or some combination thereof. Further, one or more of the capabilities can be emulated. 
     One or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means or logic (e.g., instructions, code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately. The media (also known as a tangible storage medium) may be implemented on a storage device  120  as fixed or portable media, in read-only-memory (ROM)  116 , in random access memory (RAM)  114 , or stored on a computer chip of a CPU ( 110 ), an I/O adapter  118  for example. 
     Additionally, at least one program storage device  120  comprising storage media, readable by a machine embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided. 
     The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention. 
     Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.