Abstract:
A method, information processing system, and computer program product manage computer executable instructions. At least one machine instruction for execution is received. The at least one machine instruction is analyzed. The machine instruction is identified as a predefined instruction for storing a variable length first operand in a memory location. Responsive to this identification and based on fields of the machine instruction, a relative location of a variable length second operand of the instruction with location of the first operand is determined. Responsive to the relative location having the predefined relationship, a first cracking operation is performed. The first cracking operation cracks the instruction into a first set of micro-ops (Uops) to be executed in parallel. The second set of Uops is for storing a first plurality of first blocks in the first operand. Each of said first block to be stored are identical. The first set Uops are executed.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention generally relates to microprocessors, and more particularly relates to managing variable length instructions. 
       BACKGROUND OF THE INVENTION 
       [0002]    Various conventional approaches for increasing IPC (Instruction per cycle) crack instructions into a simpler set of unit of operations (Uops). However, with respect to instructions such as Mover Character (MVC) and Exclusive OR Character (XC) instructions, some conventional cracking methods only crack these instructions as MVC and XC cases. For example, MVC and XC instructions can have MVC Nbyte overlap an XC-exact cases, respectively. At execution time of these instructions, if the storage operands of the two instructions determined to destructively overlap, then the instructions are flushed and re-executed in slow manner at one byte at a time. Because these conventional methods can only identify the MVC Nbyte overlap and XC-exact cases at execution time they cannot crack the instructions based on these cases. This greatly reduces the performance of these instructions. 
       SUMMARY OF THE INVENTION 
       [0003]    In one embodiment, a method for managing computer executable instructions is disclosed. The method comprises receiving at least one machine instruction for execution. The at least one machine instruction is analyzed. Responsive to identifying the machine instruction as a predefined instruction for storing a variable length first operand in a first memory location, the first operand consisting of a first plurality of first blocks. A block is defined as one or more bytes. Responsive to this identification and based on fields of the machine instruction a relative location of a variable length second operand of the machine instruction with location of the first operand is determined. The variable length second operand consists of a second plurality of second blocks. Responsive to the relative location having the predefined relationship, a first cracking operation is performed. The first cracking operation cracks the machine instruction into a first set of micro-ops (Uops) to be executed in parallel. The second set of Uops is for storing the first plurality of first blocks in the first operand. Each of said first block to be stored are identical. The first set Uops are executed. 
         [0004]    In another embodiment, an information processing system for managing computer executable instructions is disclosed. The information processing system comprises a memory and a processor communicatively coupled to the memory. The processor comprises at least an instruction decode unit, an operand overlap determining module, and an instruction cracking unit. The instruction decode unit is configured to receive at least one machine instruction to be executed and to analyze the at least one instruction. Responsive to identifying the machine instruction as a predefined instruction for storing a variable length first operand in a first memory location, the first operand consisting of a first plurality of first blocks, the operand overlap determining module is configured to determine a relative location of a variable length second operand of the machine instruction with location of the first operand. This relative location is determined also based on fields of the machine instruction. The variable length second operand consists of a second plurality of second blocks. Responsive to the relative location having the predefined relationship, the cracking unit is configured to perform a first cracking operation. The first cracking operation cracks the machine instruction into a first set of micro-ops (Uops) to be executed in parallel. The second set of Uops is for storing the first plurality of first blocks in the first operand. Each of said first block to be stored are identical. The first set Uops are executed. 
         [0005]    In yet another embodiment, a computer program product for managing computer executable instructions is disclosed. The computer program product comprises a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method comprises receiving at least one machine instruction for execution. The at least one machine instruction is analyzed. Responsive to identifying the machine instruction as a predefined instruction for storing a variable length first operand in a first memory location, the first operand consisting of a first plurality of first blocks. Responsive to this identification and based on fields of the machine instruction a relative location of a variable length second operand of the machine instruction with location of the first operand is determined. The variable length second operand consists of a second plurality of second blocks. Responsive to the relative location having the predefined relationship, a first cracking operation is performed. The first cracking operation cracks the machine instruction into a first set of micro-ops (Uops) to be executed in parallel. The second set of Uops is for storing the first plurality of first blocks in the first operand. Each of said first block to be stored are identical. The first set Uops are executed. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The accompanying figures where like reference numerals refer to identical or functionally similar elements throughout the separate views, and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention, in which: 
           [0007]      FIG. 1  illustrates one example of an operating environment according to one embodiment of the present invention; 
           [0008]      FIG. 2  illustrates a detailed view of a processing core according to one embodiment of the present invention; 
           [0009]      FIG. 3  shows an example of an MVC instruction format; 
           [0010]      FIG. 4  shows an example of an XC instruction format; 
           [0011]      FIG. 5  illustrates an MVC-1 byte situation; 
           [0012]      FIG. 6  shows Uops created based on detecting an MVC-1 byte situation at decode time according to one or more embodiments of the present invention; 
           [0013]      FIG. 7  shows Uops created based on detecting an XC-exact situation at decode time according to one or more embodiments of the present invention; 
           [0014]      FIG. 8  is an operational flow diagram illustrating one example of cracking a variable length instruction based on its displacement value and base register numbers according to one or more embodiments of the present invention; 
           [0015]      FIG. 9  is an operational flow diagram illustrating one examples of cracking a variable length instruction based on its displacement value and base register numbers according to one or more embodiments of the present invention; and 
           [0016]      FIGS. 10-12  show various examples of Uops created based on the size of one or more operands in variable operand length instructions with non-overlapping operands according to one or more embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely examples of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriately detailed structure and function. Further, the terms and phrases used herein are not intended to be limiting; but rather, to provide an understandable description of the invention. 
         [0018]    The terms “a” or “an”, as used herein, are defined as one or more than one. The term plurality, as used herein, is defined as two or more than two. The term another, as used herein, is defined as at least a second or more. The terms including and/or having, as used herein, are defined as comprising (i.e., open language). The term coupled, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Plural and singular terms are the same unless expressly stated otherwise. 
         [0019]    Operating Environment 
         [0020]      FIG. 1  shows an exemplary operating environment applicable to various embodiments of the present invention. In particular,  FIG. 1  shows a parallel-distributed processing system in which one embodiment of the present invention is implemented. In this embodiment, the parallel-distributed processing system  100  operates in an SMP computing environment. In an SMP computing environment, parallel applications can have several tasks (processes) that execute on the various processors on the same processing node. The parallel-distributed processing system  100  executes on a plurality of processing nodes  102  and  104  coupled to one another node via a plurality of network adapters  106  and  108 . Each processing node  102  and  104  is an independent computer with its own operating system image  110  and  112 , channel controller  114  and  116 , memory  118  and  120 , and processor(s)  122  and  124  on a system memory bus  126  and  128 . A system input/output bus  130  and  132  couples I/O adapters  134  and  136  and communication adapter  106  and  108 . Although only one processor  122  and  124  is shown in each processing node  102  and  104  for simplicity, each processing node  102  and  104  can have more than one processor. The communication adapters are linked together via a network switch  138 . 
         [0021]    Also, one or more of the nodes  102 ,  104  comprises mass storage interface  140 . The mass storage interface  140  is used to connect mass storage devices  142  to the node  102 . One specific type of data storage device is a computer readable medium such as a Compact Disc (“CD”) drive, which may be used to store data to and read data from a CD  144  or DVD. Another type of data storage device is a hard disk configured to support, for example, JFS type file system operations. In some embodiments, the various processing nodes  102  and  104  are able to be part of a processing cluster. The present invention is not limited to an SMP environment. Other architectures are applicable as well, and further embodiments of the present invention can also operate within a single system. 
         [0022]    Processor Core 
         [0023]    According to one embodiment,  FIG. 2  illustrates one example of a processor core  200  within a processor  122 ,  124  for cracking MVC and XC instructions based on operand displacement values and base register numbers. It should be noted that the configuration shown in  FIG. 2  is only one example applicable to the presently claimed invention. In particular,  FIG. 2  shows a processing core  200 . The processor core  200 , in one embodiment, comprises a bus interface unit  202  that couples the processor core  200  to other processors and peripherals. The bus interface unit  202  also connects L1 Dcache  204 , which reads and stores data values, L1 Icache  206 , which reads program instructions, and a cache interface unit  208  to external memory, processor, and other devices. 
         [0024]    The L1 Icache  206  provides loading of instruction streams in conjunction with an instruction fetch unit IFU  210 , which prefetches instructions and may include speculative loading and branch prediction capabilities. These fetched instruction codes are decoded by an IDU  212  into instruction processing data. Once decoded, the instructions are dispatched to an instruction sequencer unit (ISU)  214 . The ISU  214  controls sequencing of instructions issued to various execution units such as one or more fixed point units (FXU)  216  for executing general operations and one or more floating point units (FPU)  218  for executing floating point operations. The floating point unit(s)  218  can be a binary point floating unit  220 , a decimal point floating unit  221 , and/or the like. It should be noted that the FXU(s)  216 , in one embodiment, comprises multiple FXU pipelines, which are copies of each other. The ISU  214  is also coupled to one or more load/store units (LSU)  230  via multiple LSU pipelines. These multiple LSU pipelines are treated as execution units for performing loads and stores and address generation for branches. 
         [0025]    A set of global completion tables (GCT)  222  residing within the ISU  214  track the instructions issued by ISU  214  via tags until the particular execution unit targeted by the instruction indicates the instructions have completed execution. The FXU  216  and FPU  218  are coupled to various resources such as general-purpose registers (GPR)  224  and floating point registers (FPR)  226 . The GPR  224  and FPR  226  provide data value storage for data values loaded and stored from the L1 Dcache  204  by a load store unit (LSU)  230 . 
         [0026]    In addition, to the configuration of the processor core  200  discussed above, in one embodiment, the LSU  230  comprises a load queue (LDQ)  232 , a store queue (STQ)  234 , and a store buffer (STB)  236 . The LDQ  232  and the STQ  234  each comprise entries  238 ,  240 , respectively, that track additional information associated with outstanding load and store instructions. For example, the entries  238  of the LDQ  232  comprise the starting address and ending address of a corresponding load instruction. The entries  240  of the STQ  234  comprise the starting address and the ending address of corresponding store data. The STB  236  comprises entries  242  where a corresponding store instruction saves its data prior to writing the data back the cache  204 . 
         [0027]    In one embodiment, the IDU  212  comprises a cracking unit  244 . The cracking unit  244  organizes/breaks a complex instruction into simpler units. Stated differently, the cracking unit  244  organizes an instruction such as an STM instruction into a set of units of operation (Uops) that can be handled in parallel paths. The cracking unit  244  is discussed in greater detail below. In one embodiment, the IDU  212  also comprises an operand overlap determining module  246  that determines the overlap of the instruction operands. For example, for an MVC instruction the operand overlap determining module  246  determines if the operands are overlapped by N bytes. For an XC instruction, the operand overlap determining module  246  determine if the operands have an exact overlap. This determination is used to crack an MVC and an XC instruction, respectively, into a given number of Uops for optimizing the rate of instruction processing; increasing the throughput of data; and reducing OSC (operand store compare) hazards. 
         [0028]    Cracking Variable Length Instructions—Overlap Case 
         [0029]    A move character (MVC) instruction and an exclusive OR character (XC) instruction are both storage-to-storage (SS) instructions. One type of an MVC instruction is an MVC Nbytes overlap (replicate N bytes of memory where a typical N value is 1 to 8) instruction. One type of an XC instruction is an XC-exact (clear 1 to 256 bytes in storage to value of 0&#39;s) instruction. Both of these instructions (MVC Nbytes and XC-exact) are performance critical and require fast processing and execution. Some previous generation microprocessor designs that implemented in-order execution identified these scenarios post-dispatch and added special hardware at execution time to optimize their performance. Since these microprocessor designs design were “in-order” instruction issuing would stop as long as there is a long running instruction still executing. Therefore, the MVC-Nbyte and XC-exact scenarios were detected post-dispatch and executed faster than a normal MVC or XC instruction. With respect to out-of-order microprocessor designs, the intention is to eliminate issue stalls by working around long running instructions or by cracking complex instructions into simpler Uops where the Uops can be issued and executed in parallel and out-of-order with respect to other instructions. However, conventional out-of-order microprocessor designs generally fail to improve optimize store-load hazards, bottlenecks, and queue/buffer assignments. 
         [0030]    Therefore, in addition to the general processing mechanisms discussed above with respect to  FIG. 1 , one or more of the following embodiments identify MVC-Nbyte and XC-exact instructions at decode time. One or more embodiments then crack these long running instructions into multiple Uops based on opcode, base register numbers, and displacement value. This cracking of MVC-Nbyte and XC-exact instructions allows store-load bypassing from and into these cracked instructions; removes the execution bottle neck for long running operands; and simplifies the load queue, store queue, and store buffer assignment. 
         [0031]    Cracking MVC-Nbyte and XC-exact instructions based on opcode, base register numbers, and displacement value allows the instruction to be cracked into simpler Uops that can be issued and executed in parallel with other instructions and that can fit mapper resources. Store Uops are uniquely identified and a store queue entry is assigned for each one so store data can be bypassed to longer loads. Also, load Uops are uniquely identified so a store from an older instruction can be bypassed into the load Uop. 
         [0032]    In one embodiment, the IFU  210  fetches an instruction from the I-cache  206  and sends the instruction into the pipeline for decoding by the IDU  212 . The IDU  212  decodes the instruction and determines that the instruction is an MVC or an XC instruction. Upon further analysis by the operand overlap determining module  246 , which is discussed in greater detail below, the IDU  212  determines that the MVC or XC instruction is an MVC-Nbyte or an XC-exact instruction, respectively. The IDU  212  analyzes the MVC-Nbyte or XC-exact instruction to determine the opcode, base register numbers, and displacement value. The cracking unit  246  then cracks this instruction based on the opcode, base register numbers, and displacement value. 
         [0033]      FIGS. 3-4  illustrate examples of an MVC and XC instruction. In particular,  FIG. 3  illustrates an MVC instruction format and  FIG. 4  illustrates an XC instruction format. As can be seen from  FIGS. 3 and 4 , the MVC and XC instruction formats  300 ,  400  comprise a set of instruction text bits  0 : 7 . These instruction text bits are the instruction opcode. Instruction text bits  8 : 15  equal the operand lengths (L), e.g., L value of 0 to 255 is equivalent to 1-256 bytes in memory. Instruction text bits  16 : 19  (B 1 ) comprise the base register number for the first operand. Instruction text bits  20 : 31  (D 1 ) comprise the displacement value for the first operand. Instruction text bits  32 : 35  (B 2 ) comprise the base register number for the second operand. Instruction text bits  36 : 47  (D 2 ) comprise the displacement value for the second operand. The first operand data is at memory location (GPR-B 1 +D 1 ) to (GPR-B 1 +D 1 +L) for a total of L+1 bytes. The second operand data is at memory location (GPR-B 2 +D 2 ) to (GPR-B 2 +D 2 +L) for a total of L+1 bytes. The MVC instruction moves the second operand data to the first operand from left (staring address) to right byte at a time. The XC instruction performs the exclusive logic OR function between the two operands and stores the result back at first operand. Bytes are processed left (byte at the starting address) to right. 
         [0034]    With respect to an XC instruction, for i=0 to L (total of L+1 bytes) then op 1 (i)&lt;=op 1 (i) XOR op 2 (i). An XOR operation is performed byte per byte from op 1  and op 2 . The result is stored back at op 1 . If op 1  address=op 2  address then the result will be all 0&#39;s. Therefore, the instruction looks like it is clearing to zeros a range of bytes in memory at the op 1  address. With respect to an MVC instruction, for i=0 to L (total of L+1 bytes) then op 1 (i)&lt;=op 2 (i). Therefore, if op 1  address=op 2  address+N then the MVC instruction looks as if it is replicating the first N bytes of op 2  to op 1 . More specifically, in one embodiment, for N=1, the most significant byte of op 2  is copied or replicated to all the bytes of op 1 , and the MVC with 1 Byte overlap is equivalent to a single byte padding. 
         [0035]      FIG. 5  shows an example of how an MVC-1 byte instruction is executed. In an MVC-1 byte instruction the first operand (op 1 ) is 1 byte away from the second operand (op 2 ) (i.e., the operands only differ by a 1 byte location). In order to execute this instruction the first byte  502  is read from op 2  and moved to op 1  as shown by the first arrow  504 . Then, the second byte  506  is read from op 2 , but second byte  506  of op 2  is the first byte of op 1  which was just moved. Therefore, the byte that was just read is the byte that was just stored. So the instruction looks as if it is taking the most significant byte (e.g., AA) of op 2  and replicating it across op 1  (e.g., final operand data is AA AA AA AA AA . . . AA). This process is referred to as padding. 
         [0036]    Returning to the IDU  212 , once the IDU  212  receives the instruction from the IFU  210 , the IDU  212  decodes the instruction and identifies the opcode as indicated by bits  0  to  7 . In the current example, the IDU  212  identifies the instruction as either an MVC or an XC instruction. The operand overlap determining module  246  then analyzes the base registers and the displace fields of the operands for the received instruction to identify the overlap between the operands. An MVC instruction is identified by the IDU  212  as an MVC-1 byte instruction when the overlap determining module  246  determines that B 1 ==B 2  and D 2 +1==D 1 ). When software wants to perform 1 byte padding the software uses the same base register. So base  1  (B 1 ) is equal to base  2  (B 2 ) and the displacement of op 1  is one more than op 2 . Therefore, B  1 +D 1  is 1 greater than B 2 +D 2 . It should be noted that although the examples used throughout this discussion are directed to 1 byte padding, the present invention is also applicable to other types of padding such as 2 byte to 8 byte padding. 
         [0037]    An XC instruction is identified by the IDU  212  as an XC exact instruction when the overlap determining module  246  determines that B 1 ==B 2  and D 1 ==D 2 . When software application wants to clear certain bytes in memory by using the XC instruction in almost all cases the B 1  and B 2  fields are the same. This is because only one general purpose register (GPR) is used to represent the base and displacement field is changed to be the same at compile time. Therefore, an XC instruction is an XC exact instruction when B 1 =B 2  and D 1 =D 2 . 
         [0038]    Upon detecting a 1 byte (or N bytes with typical N is from 1 to 8) in an MVC instruction, the cracking unit  244  of the IDU  212  cracks the instruction regardless of operand length to optimize the execution performance. The instruction is also cracked to have each Uop to be in a simple pipelinable to optimize the issue bandwidth and to allow bypassing into and from the MVC operands. The cracking unit  244  breaks/organizes the MVC instruction into a group of Uops based on the identified opcode, base register values, and displacement field. These opcodes are then sent to the ISU  214  for issuing to the execution units. In one example, the MVC instruction is cracked into 3 Uops. The cracking is performed during decode and instruction grouping cycles. Each Uop has its own logical register assignments, Condition Code read/write conditions, load queue, store queue, and store buffer allocation and usage, etc. 
         [0039]      FIG. 6  shows an example of how the cracking unit  244  cracks the MVC-1 byte instruction into multiple Uops. As can be seen from  FIG. 6 , the cracking unit  244  has broken the MVC-1 byte instruction into a set of Uops ranging from Uop  1  to Uop 3 . Once the cracking unit  244  has formed the Uops, the IDU  244  sends the Uops to the ISU  214 . Uop 1  performs a load from op 2 , e.g., reads a single byte or pads a blank byte from op 2 . Therefore, an LDQ entry is allocated for op 2 , a STQ entry is allocated to Uop 1 , and one STB is allocated for op 1  data to be saved into regardless of the operand length. These allocations are performed in order at dispatch time of the Uops. It should be noted that although up to 256 bytes can be stored and would normally require assignments of 32 store buffers each containing 8 bytes of storage data, this embodiment only allocates a single store buffer populated with eight replicated bytes at execution time. The same storage buffer entry is referenced over and over again when the data is written back to the cache. Therefore, a large number of resources in the storage buffer are saved. This is achieved, in one embodiment, by pinning the store buffer read pointers to the single entry that pertains to the MVC- 1 B. This store buffer entry is read as many times as necessary to populate the up to 256 bytes of storage. 
         [0040]    Uop 1   602  is a load instruction that fetches a single byte from the op 2  and places this data into a scratch GR. Uop 2 , in this embodiment, is a dual issue Uop. For example, the first issue is an LSU issue, where Uop 2  calculates the storage address (op 1  address) and performs pretesting to check for any potential exception related to this storage access at this particular address. The second issue is a FXU issue where Uop 2  reads the data from the scratch GR, replicates the byte that has just been read, and sends the data to the STB. Uop 3  is optional and pretests the ending address of op 1  to check for any potential exceptions. Because op 1  is able to span over two cache lines, Uop 3  ensures that all storage cache lines are tested for an exception when storage data crosses a cache line boundary. It should be noted that Uop 3  is optional depending on the hardware being implemented 
         [0041]    Returning to the XC-exact instruction, the operand overlap determining module  246  compares base 1  (B 1 ) and base 2  (B 2 ) of the instruction and also displacement 1  (D 1 ) and displacement 2  (D 2 ). If B 1 +D 1 =B 2 +D 2  then the address of both operands (op 1  and op 2 ) overlap exactly. Since this instruction clears out the memory, data is not fetched from memory. Upon detecting an exact operand overlap for an XC instruction, the cracking unit  244  of the IDU  212  cracks the instruction regardless of length to optimize the execution performance, to use minimum hardware resources and to allow operand store compare bypassing. The cracking unit  244  breaks/organizes the XC instruction into a group of Uops based on the identified opcode, base register values, and displacement field. These opcodes are then sent to the ISU  214  for issuing to the execution units. In one example, the XC instruction is cracked into 2 Uops. The cracking is performed during decode and instruction grouping cycles. Each Uop has its own logical register assignments, Condition Code read/write conditions, load queue, store queue, and store buffer allocation and usage, etc. 
         [0042]      FIG. 7  shows the Uops for an XC-exact overlap instruction. As can be seen from  FIG. 7 , the cracking unit  244  has broken the XC instruction into a set of Uops ranging from Uop  1  to Uop 2 . Once the cracking unit  244  has formed the Uops, the IDU  244  sends the Uops to the ISU  214 . Uop 1  is similar to a store instruction that stores all zeros as its data. Uop 1  is a dual issued Uop, however, in other embodiments, Uop 1  can be single issued where the op 1  address is generated since the storage data is know to be zeros. The first issue is an LSU issue where Uop 1  forms the operand address and tests the cache address for any store related exceptions. The second issue is a FXU issue where Uop 1  is an FXU issue. This second issue sends all 0&#39;s as a databeat to the STB to be stored. Uop 1  also allocates only one STQ and one STB regardless of the operand length. Uop 2  performs a pretest on the ending address of op 1  for any potential exceptions. Because op 1  is able to span over two cache pages, Uop 2  ensures that all storage cache lines are tested for an exception when storage data crosses a cache page boundary. Uop 2  is added to the cracking sequence since existing hardware implementations generally cannot test two different cache lines in one Uop since they may span a memory page. It should be also noted that although up to 256 bytes can be stored and would normally require assignments of 32 store buffers each containing 8 bytes of storage data, this embodiment only allocates a single store buffer populated with eight replicated bytes at execution time. The same storage buffer entry is referenced over and over again when the data is written back to the cache. Therefore, a large number of resources in the storage buffer are saved. This is an XC-exact scenario. This store buffer entry is read as many times as necessary to populate the up to 256 bytes of storage. 
         [0043]    Operational Flow Diagrams—Overlap Case and Non-Overlap cases 
         [0044]      FIG. 8  is an operational flow diagram illustrating one example of managing MVC-1 byte instructions. The operational flow diagram of  FIG. 8  beings at step  802  and flows directly into step  804 . The IDU  214 , at step  804 , receives an instruction. The IDU  214 , at step  806 , analyzes the instruction. The IDU  214 , at step  808 , determines that the instruction is an MVC instruction based on the analyzing. The IDU  214 , via the operand overlap determining module  246 , at step  810 , compares the base register values and the displacement fields of the operands. 
         [0045]    Based on this comparison, the IDU  214 , at step  812 , determines if the base register (B 1 ) of the first operand is equal to the base register (B 2 ) of the second operand and if the displacement value (D 2 ) of the second operand plus N, such as N=1 when testing for 1 byte overlap, is equal to the displacement value (D 1 ) of the first operand. If the result of this determination is negative, the instruction is a normal MVC instruction and the control flow goes to step  824  where length based cracking is performed. The IDU  214 , at step  824 , determines if the length satisfies a given threshold for the identified instruction type, e.g., is the length equal to 1 to 8 bytes, as will be discussed below with respect to  FIGS. 10-12  in the non-overlap case. If the result of this determination is negative, the IDU  214 , at step  826 , issues the instruction as a sequenced op. The control flow then exits at step  828 . If the result of this determination is positive, the IDU  214 , at step  830 , organizes the instruction into a set of unit of operations that can be executed in parallel based on the length of the instruction. This organization or cracking has been discussed above in more detail with respect to  FIGS. 10-12 . The IDU  214 , at step  832 , executes the set of unit of operations. The control flow then exits at step  834 . For more information on this non-overlap case, see commonly owned U.S. patent application Ser. No. 12/707,163 entitled “Instruction Length Based Cracking For Instruction Of Variable Length Storage Operands”, which is hereby incorporated by reference in its entirety. Continuing with the overlap case, if the result of this determination is positive, the IDU  214 , at step  816 , identifies this instruction as an MVC-1 byte instruction. The IDU  214 , at step  818 , organizes the instruction into a set of unit of operations that can be executed in parallel based on the base registers and displacement values. This organization or cracking has been discussed above in more detail with respect to  FIG. 6 . The IDU  214 , at step  820 , executes the set of unit of operations. The control flow then exits at step  822 . 
         [0046]      FIG. 9  is an operational flow diagram illustrating one example of managing XC-exact instructions. The operational flow diagram of  FIG. 9  beings at step  902  and flows directly into step  904 . The IDU  214 , at step  904 , receives an instruction. The IDU  214 , at step  906 , analyzes the instruction. The IDU  214 , at step  908 , determines that the instruction is an MVC instruction based on the analyzing. The IDU  214 , via the operand overlap determining module  246 , at step  910 , compares the base register values and the displacement fields of the operands. 
         [0047]    Based on this comparison, the IDU  214 , at step  912 , determines if the base register (B 2 ) of the second operand is equal to the base register (B 1 ) of the first operand and if the displacement value (D 1 ) of the first operand is equal to the displacement value (D 2 ) of the second operand. If the result of this determination is negative, the instruction is a normal XC instruction and the control flow exits at step  924  where length based cracking is performed. The IDU  214 , at step  924 , determines if the length satisfies a given threshold for the identified instruction type, e.g., is the length equal to 1 to 8 bytes, as will be discussed below with respect to  FIGS. 10-12  in the non-overlap case. If the result of this determination is negative, the IDU  214 , at step  926 , issues the instruction as a sequenced op. The control flow then exits at step  928 . If the result of this determination is positive, the IDU  214 , at step  930 , organizes the instruction into a set of unit of operations that can be executed in parallel based on the length of the instruction. This organization or cracking has been discussed above in more detail with respect to  FIGS. 10-12 . The IDU  214 , at step  932 , executes the set of unit of operations. The control flow then exits at step  934 . For more information on this non-overlap case, Returning to the overlap case, if the result of this determination is positive, the IDU  214 , at step  916 , identifies this instruction as an XC-exact instruction. The IDU  214 , at step  918 , organizes the instruction into a set of unit of operations that can be executed in parallel based on the base registers and displacement values. This organization or cracking has been discussed above in more detail with respect to  FIG. 7 . The IDU  214 , at step  920 , executes the set of unit of operations. The control flow then exits at step  922 . 
         [0048]    Cracking Non-Overlap Instructions 
         [0049]    One or more of the following embodiments crack variable operands length instructions, (e.g., MVC, XC) based on opcode and the length of the operands. Cracking improves the issue bandwidth, store-load data bypassing, and removes hardware complexity from execution units, among other things. Cracking long running instruction based on opcode and length(s) fields to many Uops allows store-load bypassing from and into these cracked instructions; removes the execution bottle neck for long running ops, and simplifies the load queue, store queue and store buffer assignment. 
         [0050]    Cracking variable operands length instructions, such as MVC and XC based on opcode and the length of the operands allows the instruction to be cracked into simpler Uops that can be issued and executed in parallel and that can fit mapper resources. Store Uops are uniquely identified and a store queue entry is assigned for each one so store data can be bypassed to longer loads. Also, load Uops are uniquely identified so a store from an older instruction can be bypassed into the load Uop. 
         [0051]    In one embodiment, the IFU  210  fetches an instruction from the I-cache  206  and sends the instruction into the pipeline for decoding by the IDU  212 . The IDU  212  decodes the instruction and determines that the instruction has variable operands length. The IDU  212  analyzes the instruction to determine the opcode and an operand length determining module (not shown) determines the length(s) of operands. The cracking unit  244  then cracks this instruction based on the opcode and the length(s). 
         [0052]      FIGS. 10-12  show various examples how the cracking unit  244  cracks variable operands lengths instructions such as SS-logical and SS-decimal instructions into multiple Uops.  FIGS. 10-12  show an example of Uops for an MVC instruction that has operands length value ranging from 0 to 15 (1 to 16 bytes). The MVC instruction moves a specified number of bytes from op 1  to op 2 . In particular,  FIG. 10  shows the Uops for an MVC instruction that is 1 to 8 bytes (L value is 0 to 7) in operands length and FIG. D shows the Uops when the MVC instruction is 9 to 16 bytes (L value is 8 to 15) in operands length. It should be noted that various embodiments of the present invention are not limited to only cracking an MVC instruction (or any other instruction) with operands length from 0 to 15 (1 to 16 bytes), as instructions with greater operands lengths can also be cracked as well. 
         [0053]    As can be seen from  FIG. 10 , the cracking unit  244  has broken the MVC instruction into a set of Uops ranging from Uop  1  to Uop 2  when the operand length of the MVC instruction is 0 to 7 (1 to 8 bytes). Once the cracking unit  244  has formed the Uops, the IDU  244  sends the Uops to the ISU  214 . Uop 1   1002  performs a load from op 2 , e.g., reads 1 to 8 bytes from op 2 . Therefore, an LDQ entry is allocated for op 2 , a STQ entry is allocated to Uop 1   1002  (STQ entry could have allocated with the dispatch of Uop 2   1104 ), and a STB is allocated for op 1  data to be saved into. These allocations are performed in order at dispatch time. Uop 1   1002  fetches (loads) 1 to 8 bytes of op 2  from memory and places this data into a scratch GR. Uop 2   1004 , in this embodiment, is a dual issue Uop. For example, the first issue is an LSU issue, where Uop 2   1004  calculates the storage addresses (op 1  to op 1 +L) and performs pretesting to check for any potential exception related to this storage access at this particular address. The second issue is a FXU issue where Uop 2   1004  reads the data from the scratch GR and sends the data to the STB. 
         [0054]      FIG. 11  show that the cracking unit  244  has broken the MVC instruction into a set of Uops ranging from Uop  1  to Uop 4  ( 2  loads followed by 2 stores) when the operand length of the MVC instruction is 8 to 15 (9 to 16 bytes). Once the cracking unit  244  has formed the Uops, the IDU  244  sends the Uops to the ISU  214 . An LDQ entry is allocated for op 2 , a STQ entry is allocated to Uop 1   1102  (STQ entry could have allocated with the dispatch of Uop 2   1104 ), and a STB is allocated for op 1  data to be saved into. These allocations are performed in order at dispatch time. Uop 1   1102  loads 8 bytes of op 2  (op 2  to op 2 +7) from memory and places this data into a scratch GR. Uop 2   1104 , in this embodiment, is a dual issue Uop. For example, the first issue is an LSU issue, where Uop 2   1104  calculates the storage address (op 1  to op 1 +7) and performs pretesting to check for any potential exception related to this storage access at this particular address. The second issue is a FXU issue where Uop 2   1104  reads the data from placed in the scratch GR by Upo 1  and sends the data to the STB. 
         [0055]    Uop 3   1106  fetches the remaining op 2  data (op 2 +8 to op 2 +L) from memory, i.e., the next potential 8 bytes after the data loaded by Uop 1 , and places this data into a scratch GR. Uop 4   1108 , in this embodiment, is a dual issue Uop. For example, the first issue is an LSU issue, where Uop 4   1108  calculates the storage addresses where the data is going to be stored (op 1 +8 to op 1 +L) and performs pretesting to check for any potential exception related to this storage access at this particular address. The second issue is a FXU issue where Uop 4   1108  reads the data placed in the scratch GR by Upo 3  and sends the data to the STB. It should be noted that if the operands length of the MVC instruction is greater than 16 bytes (L is greater than 16) the MVC instruction is issued to the LSU  230  as a sequenced op with an allocated LDQ and STQ and the LSU cannot execute any other instructions until the MVC instruction has completed. 
         [0056]      FIG. 12  shows the Uops for an XC instruction. As can be seen from  FIG. 12 , the cracking unit  244  has broken the XC instruction into a set of Uops ranging from Uop 1  to Uop 2  when the operands lengths of the XC instruction ranges from 0 to 7 (1 to 8 bytes). Once the cracking unit  244  has formed the Uops, the IDU  244  sends the Uops to the ISU  214 . There is an LDQ entry, an STQ and STB entry allocated for op 1 , and an LDQ entry is allocated for op 2 . Uop 1   1202  loads 1 to 8 bytes of op 2  data from memory and places this data into a scratch GR. Uop 2   1204 , in this embodiment, is a dual issue Uop. For example, the first issue is an LSU issue, where Uop 2   1204  calculates the storage address for fetching up to 8 bytes from op 1  and performs pretesting to check for any potential exception related to this storage access at this particular address. The second issue is a FXU issue where Uop 2   1204  brings the fetched data from op 1  to the FXU  216 . The FXU  216  performs an Xor operation between the op 2  data in the scratch GR and the op 1  data bytes fetched by Uop 2 . The result of the Xor operation is sent back to the LSU for storing in the STB, and the condition code is set based on the result value. It should be noted that if the operands lengths of the XC instruction is greater than 8 bytes (L is greater than 8) the XC instruction is issued to the LSU  230  as a sequenced op with an two allocated LDQs, one allocated STQ, and one allocated STB and the LSU cannot execute any other instructions until the XC instruction has completed. 
       NON-LIMITING EXAMPLES  
       [0057]    Although specific embodiments of the invention have been disclosed, those having ordinary skill in the art will understand that changes can be made to the specific embodiments without departing from the spirit and scope of the invention. The scope of the invention is not to be restricted, therefore, to the specific embodiments, and it is intended that the appended claims cover any and all such applications, modifications, and embodiments within the scope of the present invention. 
         [0058]    Although various example embodiments of the present invention have been discussed in the context of a fully functional computer system, those of ordinary skill in the art will appreciate that various embodiments are capable of being distributed as a program product via CD or DVD, e.g. CD, CD ROM, or other form of recordable media, or via any type of electronic transmission mechanism.