Patent Publication Number: US-2022214884-A1

Title: Issuing instructions based on resource conflict constraints in microprocessor

Description:
RELATED U.S. APPLICATION 
     This application is a continuation of the application with Ser. No. 15/875,611, entitled “Issuing Instructions Based on Resource Conflict Constraints in Microprocessor,” by D. Carlson, filed Jan. 19, 2018, and hereby incorporated by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     Embodiments of the present invention are related to the field of microprocessors, and in particular, to instruction issue mechanisms in microprocessors. 
     BACKGROUND OF THE INVENTION 
     Superscalar processors offer enhanced execution parallelism as multiple scalar instructions can be executed by functional units independently and concurrently in a single clock cycle. The resources required to execute an instruction usually include operands of the instruction and execution hardware resources. Instructions having such required resources available are said to be ready for execution, or “issue-ready” herein. An issue-ready instruction could be issued in isolation without any data dependency or control dependency problem. However, due to hardware resource constraints in a superscalar processor, some instructions (even with different opcodes) share the same hardware used in the execution stage, such as register files, register file ports, and execution units, etc. Issuing more than one instruction at one time may cause conflict if the instructions compete for execution resources, even though each of them is ready to issue individually. 
     To avoid execution resource conflicts among issued instructions, one existing solution is to provide enough register file bandwidth needed by each functional unit. Each functional unit has an instruction queue and the oldest instruction in the queue is issued each time. In this way, the dependency among the functional units is eliminated and each functional unit can execute independently of each other. However, to achieve enough register file bandwidth, extra register file ports are usually needed, which undesirably increases logic complexity and manufacturing cost of the processor. 
     Another approach is to first pick the oldest issue-ready instruction in an instruction queue. The next oldest instruction that is compatible with the first-pick is then picked. For example, if the oldest in the queue is a “shift” instruction, the queue is then searched for an instruction that does not use the only shifter functional unit. In the same manner, following that, the third oldest instruction compatible with the first two picks are picked, and so on. This can guarantee compatibility among a resultant collection of picked instructions for parallel execution, but unfortunately requires complex logic and long latency. More specifically, finding the oldest instruction is typically implemented using “find-first” logic which basically has the latency of a single “add” circuit, whereas finding the second-oldest instruction can be implemented using “find-second” logic which has the latency of two “add” circuits operating in serial. Thus, it typically requires twice as long time to compute the second instruction as to compute the first one. As a result, the overall latency adds up and causes a bottleneck of the processor performance. 
     SUMMARY OF THE INVENTION 
     Accordingly, disclosed herein is directed to a high-speed mechanism of discovering a collection of compatible issue-ready instructions for parallel execution in a superscalar processor for a given clock cycle. 
     Embodiments of the present disclosure provide instruction issue logic in a processor operable to determine a collection of compatible issue-ready instructions based on several predefined scenarios, each scenario including a set of predefined groups (or “picks” herein) of instructions, more specifically, instruction opcodes. The configurations of the picks and the scenarios take into account all possible conflicts among all instructions for purposes of parallel execution, e.g., conflicts in access to register files, register file ports, and/or functional units. 
     A collection of compatible instruction can be determined through an identification stage and a selection stage. In the identification stage and concurrently for all the picks of the several scenarios, an instruction queue storing issue-ready instructions is accessed to identify a respective instruction comprised both in the queue and each pick. The identification operations (or “picking” operations herein) may be performed by parallel finding circuits configured for the respective picks. In this manner, a set of instructions can be identified from the instruction queue in parallel, e.g., one instruction being identified for one pick. The instructions included in the picks and scenarios, and correspondingly the respective finding logic, are configured such that a set of identified instructions within each scenario are compatible with each other. Each finding circuit can operate independently regardless of the identification result from any other finding circuit. 
     Further, the issue logic includes selection logic configured to, in the selection stage, select one or more scenarios according to predefined policies. As a result, the identified instructions resulting from the identification stage of the selected scenarios are supplied for parallel execution by the functional units. More specifically, the issue logic may include a first type of scenarios, each scenario having a first pick and a second pick and associated with a different priority level. In each first type scenario, each instruction in its first pick (or “first pick instruction) is compatible with any instruction in its second pick (or “second pick instruction)”. In some embodiments, the finding logic configured for the first or the second pick may identify an instruction from the instruction queue by using a find-first process in the identification stage. In the selection stage, a first type scenario is selected provided that a first pick instruction thereof is identified from the instruction queue and no first pick instruction of any other scenarios of a higher priority is identified from the queue. Once a first type scenario is selected in the selection stage, the instruction identified for the second pick of the scenario is issued and executed together with the first pick instruction. 
     In some embodiments, an instruction may be included in both the first and the second picks of the same scenario. To prevent identifying the same instruction for both picks, the finding logic for the first pick may implement a find-first process, whereas the second pick may implement a different finding process, e.g., a find-last process. 
     Preferably, the instruction issue logic ensures forward progress so that there is always at least one instruction being issued for a given clock cycle. A default scenario may be defined and is associated with the lowest priority among the first type of scenarios. In the selection stage, even if no instruction of any first pick (e.g., including the first pick of the default scenario) is identified in the identification stage, the default scenario is selected and the identified instructions thereof are issued for parallel execution. In some embodiments, every possible integer instruction is included in one of the first picks (which have priority over the corresponding second picks), and every possible floating-point instruction is included in the default scenario. This advantageously prioritizes integer instruction executions as well as ensures forward progress. 
     Moreover, a first type scenario may also include a third pick, a fourth pick and a fifth pick, where the third pick specifies an instruction that is incompatible with an instruction in the fourth pick, whereas each instruction in the third pick is compatible with any instruction of the fifth pick. In the selection stage, if the instruction in the third pick is identified from the instruction queue (regardless of whether this instruction is selected in the resultant collection) and if this first type scenario is a selected scenario, the identified instruction from the fourth pick is not selected while the identified instruction from fifth pick is selected. For instance, if it is determined that an instruction from the third pick exists in the instruction queue, then, in the selection stage, the fifth pick (instead of the fourth pick) is selected to supply its identified instruction (if any) for the resultant collection. However, if no instruction from the third pick exists in the instruction queue, then, in the selection stage, the fourth pick (instead of the fifth pick) is selected to supply its identified instruction (if any) for the resultant collection. 
     The issue logic may also include a second type of scenarios, where each second type scenario includes a sixth pick and a seventh pick containing a group of instructions that are incompatible with the instruction in the sixth pick. If any instruction in the seventh pick is identified from the instruction queue, regardless whether it is selected in the resultant collection, the sixth pick instruction is disallowed and will not be include in the resultant collection. That is, the second type scenario is not selected. On the other hand, if no instruction in the seventh pick is identified from the queue, the selection logic selects this second type scenario, along with a selected first type scenario, and accordingly the sixth-pick instruction is issued for parallel execution. For instance, if no instruction from the seventh pick exists in the queue, then, in the selection stage, the sixth pick is selected to supply its identified instruction (if any) for the resultant collection. On the other hand, if an instruction from the seventh pick exists in the queue, then, in the selection stage, the sixth pick is not selected to supply its identified instruction (even if any) for the resultant collection. 
     According to embodiments of the present disclosure, a collection of two or more issue-ready instructions can be obtained for a given clock cycle based on predetermined scenarios. The pre-arrangements of the scenarios and groups, as well as the corresponding policies of selecting a set of issue-ready instructions within each scenario, advantageously ensure compatibility among the selected instructions and forward progress in each cycle. Moreover, the pre-arrangements and the selection policies allow the picking operations for all the picks across the scenarios to be performed independently of each other, and therefore can be performed in parallel (e.g., each through a single find-first process). The parallel operations advantageously result in substantial processing speed enhancement, since deciding which scenario(s) to use can be even faster, e.g., through a zero-detect process. 
     This summary contains, by necessity, simplifications, generalizations and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the present invention will be better understood from a reading of the following detailed description, taken in conjunction with the accompanying figures, in which like reference characters designate like elements. 
         FIG. 1  illustrates the configuration of an exemplary issue unit configured to determine a collection of compatible issue-ready instructions based on predefined scenarios in accordance with an embodiment of the present disclosure. 
         FIG. 2  is a flowchart depicting an exemplary process of determining a set of compatible issue-ready instructions for parallel execution by functional units in a superscalar processor in accordance with an embodiment of the present disclosure. 
         FIGS. 3A-3B  show the instruction opcodes compositions of exemplary picks and scenarios predefined for a superscalar processor in accordance with an embodiment of the present disclosure. 
         FIG. 4A  is a flowchart depicting an exemplary process of selecting a first type of scenarios based on instruction identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B  in accordance with an embodiment of the present disclosure. 
         FIG. 4B  is a flowchart depicting an exemplary process of selecting between Pick  3   a  and Pick  3   b  and between Pick  4   a  and Pick  4   b  for Scenario  1  based on instruction identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B  in accordance with an embodiment of the present disclosure. 
         FIG. 4C  is a flowchart depicting an exemplary process of selecting a second type of scenarios based on instruction identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B  in accordance with an embodiment of the present disclosure. 
         FIG. 5  illustrates the configuration of an exemplary issue unit capable of selecting a collection of compatible instructions by using the predefined picks and scenarios shown in  FIGS. 3A and 3B  in accordance with an embodiment of the present disclosure. 
         FIG. 6  is a block diagram illustrating an exemplary superscalar processor that is capable of issuing instructions according to predefined scenarios in accordance with an embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments of the present invention. The drawings showing embodiments of the invention are semi-diagrammatic and not to scale and, particularly, some of the dimensions are for the clarity of presentation and are shown exaggerated in the figures. Similarly, although the views in the drawings for the ease of description generally show similar orientations, this depiction in the figures is arbitrary for the most part. Generally, the invention can be operated in any orientation. 
     Issuing Instructions Based on Resource Conflict Constraints in Microprocessor 
     Overall, embodiments of the present disclosure provide a mechanism of selecting a collection of compatible issue-ready instructions for parallel execution by functional units in a superscalar processor for a given clock cycle. All possible instructions, particularly instruction opcodes, to be executed by the functional units are arranged into several scenarios, each scenario including multiple groups of instructions. The scenarios and the groups are predetermined based on potential conflicts among the instructions. During operation, concurrently for all the groups, an issue-ready instruction is identified for each group based on group-specific selection policies, e.g., from an instruction queue. Further, based on the identified instructions, predefined policies are applied to select one or more scenarios and select among the picks of the selected scenarios. 
       FIG. 1  illustrates the configuration of an exemplary issue unit  100  configured to determine a collection of compatible issue-ready instructions based on predefined scenarios in accordance with an embodiment of the present disclosure. The issue unit  100  is coupled to multiple functional units  161 - 164  and an instruction queue  150  that stores or otherwise maintains currently issue-ready instructions. The instruction queue can be implemented as an instruction buffer or any other suitable manner that is well known in the art. Each instruction in the queue  150  is ready to be issued without any data dependency or control dependency problem if it is issued in isolation. However, there may be potential conflicts among the instructions in the queue due to execution resource constraints. The issue unit  100  operates to select a collection of compatible instructions (e.g.,  143 - 144 ) from the queue  150  and supply them to the functional units  161 - 164  for parallel execution in a single clock cycle. 
     According to embodiments of the present disclosure, several scenarios are predefined, each scenario including a set of predefined groups (or “picks” herein) of instructions, more specifically, instruction opcodes to be executed by the functional units  161 - 164 . The compositions and arrangements of the picks and the scenarios take into account all possible conflicts among all instructions for purposes of parallel execution, e.g., conflicts in access to register files, register file ports, and/or functional units. As illustrated in  FIG. 1 , Scenario  1  includes Pick  0 , Pick  1 , . . . , and Pick i; and Scenario M includes Pick  0 , Pick  1 , . . . , and Pick Y. 
     In the illustrated example, a collection of compatible instruction can be determined through a picking stage (or “identification stage” herein) and a selection stage by using a picking module  120  and a selection module respectively, the selection module having a selection control module  110  and a multiplexer (MUX)  130  for example. Corresponding to each pick, the picking module  120  includes respective finding logic (e.g.,  121 , . . . ,  126 ) configured to identify an instruction that is encompassed in the pick from the instruction queue  150 . 
     It will be appreciated that the present disclosure is not limited to any specific technique, configuration or algorithm used to implement the finding logic that can identify an instruction that is encompassed both in the instruction queue and in a pick. For example, the finding logic can include a find-first circuit operable to finding the first entry in the queue that is encompassed in the pick, or a find-oldest circuit for finding the oldest entry in the queue that is encompassed in the pick. The finding logic for different picks may be implemented in different algorithms, for instance, some using find-first while some others using find-last. 
     In the identification stage, the finding logic in the picking module  120  operates in parallel with respect to all the picks. The finding logic identifies an instruction from the queue  150  for each pick independently and without regard to the identification result from any other pick. As illustrated, for instance, the Pick  0  finding logic  121  identifies instruction Ins_P 0 _ 51  that is included in both the queue  150  and the Pick  0  of Scenario  1 ; the Pick  1  finding logic  125  identifies instruction Ins_P 1 _SM that is included in both the queue  150  and the Pick  1  of Scenario M. A set of instructions  141  are identified for Scenario  1 , and a set of instructions  142  are identified for Scenario M. 
     In the selection stage, the selection control module  110  and the MUX  130  select one or more scenarios according to predefined policies and based on the identification results. The policies may be pick-specific, as described in greater detail below. As a result, the identified instructions of the selected scenarios are issued for parallel execution by the functional units  161 - 164 . In this example, Scenario  1  is selected and its identified instructions  143  are issued to functional units  161 - 163  respectively. Also selected is instruction Ins_P 2   a _Sa of Scenario A (not explicitly shown) which is issued to functional unit  164  contemporaneously with instructions  143 . The selection control module  110  may use zero-detect logic to detect the identification results of the picks, based on which the scenario selection decision can be made. Thus, according to the present disclosure, finding a collection of compatible instructions may only consume the timing of a find-first plus the latency of the MUX. The resultant latency is advantageously and substantially lower than the existent approaches as noted above. 
       FIG. 2  is a flowchart depicting an exemplary process  200  of determining a collection of compatible issue-ready instructions for parallel execution by functional units in a superscalar processor in accordance with an embodiment of the present disclosure. Process  200  may occur in the instruction-issue window and may be performed by the decoding and issue logic in the processor. The issue logic may be implemented in a similar configuration as shown in  FIG. 1 . However, process  200  may be performed by any other suitable logic without departing from the scope of the present disclosure. 
     At  201 , an issue-ready instruction in the instruction queue is classified into a pick in a scenario based on the predefined instruction composition in the pick. For example, the decoding logic may associate the instruction with a compatibility vector corresponding to the pick, as described in greater detail with reference to  FIG. 5  below. 
     At  202 , concurrently for multiple picks (e.g., all the picks or selected picks) across various scenarios, an instruction is identified from the instruction queue for each pick. If the instruction queue contains multiple instructions belonging to the same pick, the oldest one, the first one or the last one among them may be selected as the identified instruction. However, any other suitable process that is well known in the art may also be used to select an instruction from the queue. Further, in some other embodiments, more than one instruction may be identified for one pick without potential conflict. 
     At  203 , one or more scenarios are selected according to predefined selection policies. The selection policies may also specify which of the identified instructions in a selected scenario may or may not be included in the resultant collection of compatible instructions, as described in greater detail with reference to  FIGS. 4A-4C . Accordingly, at  204 , some or all of the identified instructions of the selected scenarios resulting from  202  are issued to the corresponding functional units for parallel execution in one clock cycle. 
       FIGS. 3A-3B  show the predefined opcodes compositions of exemplary picks and scenarios a superscalar processor in accordance with an embodiment of the present disclosure. There are first type scenarios, Scenarios  1 - 3 , and second type scenarios, Scenarios a-c, shown in  FIG. 3B . The associated issue logic can determine up to 4 compatible instructions for a given clock cycle. However, it will be appreciated various other viable arrangements and compositions of instruction picks and scenarios, as well as the priority levels and selection policies associated therewith, can be used without departing from the scope of the present disclosure. 
     It will be appreciated that the present disclosure is not limited by encoding or decoding mechanisms or instruction type. In this example, the prefix “f” at the beginning of each instruction denotes that it is a floating-point instruction; and the affix “_number” denotes the number of operands or result destinations of the instruction, with the default number being 1. For example, “alu_2d” represents an “alu” operation producing two result destinations; and “fmul_3s” represents a floating-point multiplication operation requiring 3 input operands. “itof” represents an integer-to-floating point conversion, or vice versa. The meanings of the instruction opcodes in  FIGS. 3A and 3B  are self-explanatory and detailed explanation is omitted for the sake of brevity. 
     Scenarios  1 - 3  each have a Pick  0  and a Pick  1 . In each of Scenarios  1  and  2 , all instructions in Pick  0  are compatible with the all the instructions in Pick  1 . Scenarios  1 - 3  are attached with different priority levels, namely Scenario  1 &gt;Scenario  2 &gt;Scenario  3 . Scenario  3  is set as the default scenario. 
     In the selection stage, one of these scenarios is selected provided that a Pick  0  instruction thereof is identified from the instruction queue and no Pick  0  instruction of any other scenarios of a higher priority is identified from the queue. Particularly, if a Pick  0  instruction of Scenario  1  is issue-ready and identified from the issue-ready queue, then Scenario  1  is selected, regardless of whether a Pick  0  instruction of Scenario  2  or  3  is identified from the queue; else if a Pick  0  instruction of Scenario  2  is identified from the queue, then Scenario  2  is selected; else Scenario  3  is selected. Even if no Pick  0  instruction of any scenario is issue-ready (e.g., including Pick  0  of the default scenario), Scenario  3  is selected by default and the identified instructions thereof can be issued for parallel execution. In this case, the resultant collection of instructions may include only Pick  3  and Pick  4  instructions of Scenario  3 . 
     In this embodiment, every possible integer instruction is included in one of the Pick  0   s  (which have priority over the corresponding second picks), and every possible floating-point instruction is included in the default scenario. This advantageously prioritizes integer instruction executions as well as ensure forward progress such that at least one issue-ready instruction is issued for a given execution cycle. 
     In this embodiment, the instruction “a1u2” is included in both Pick  0  and Pick  1  in Scenario  3 . To prevent identifying the same instruction for both picks, the finding logic for the Pick  0  may implement a find-first process whereas the Pick  1  may implement a reversed finding process, namely a find-last process. 
     Scenario  1  includes a set of picks subject to a different selection policy than Pick  0  and Pick  1 , namely Pick  3   se   1  and Pick  3   a  and Pick  3   b.  Pick  3   se   1  specifies an instruction that is incompatible with an instruction in Pick  3   a,  whereas each instruction in Pick  3   b  is compatible with the Pick  3   se   1  instruction. Pick  3   a  and Pick  3   b  have the same group of instructions except the one that is incompatible with the Pick  3   se   1  instruction. With such arrangements, the finding logic of Pick  3   se   1  and Pick  3   a  and Pick  3   b  can operate in parallel and independently of each other. The identified instructions from the picks are then selected without requiring complicated logic. 
     During operation, if Scenario  1  is the selected scenario and if the Pick  3   se   1  instruction is issue-ready and identified from the queue, an identified Pick  3   b  instruction is selected in the resultant collection for parallel execution, along with the identified Pick  0  and Pick  1  instructions of Scenario  1 . Otherwise, an identified Pick  3   a  instruction is selected, and the identified Pick  3   b  instruction is not. In either case, the Pick  3   se   1  instruction is not necessarily the identified instruction for Pick  0 . 
     In this example, Pick  3   se   1  specifies the instruction “fstore” for a floating-point store operation. Due to the particular functional unit configurations, “fstore” conflicts with any multiplication operation “fmul_3s” that requires  3  operands which is included in Pick  3   a.  Thus, if an “fstore” instruction is issue-ready, Pick  3   b  is selected and Pick  3   a  is not. 
     Similarly, Scenario  1  includes Pick  4   se   1  and Pick  4   a  and Pick  4   b,  where Pick  4   se   1  specifies a group of instructions that is incompatible with the instruction “merge  2   d ” that is included in Pick  4   a.  Pick  4   b  has the same group of instructions as Pick  4   a  except without instruction “merge  2   d .” During operation, if Scenario  1  is the selected scenario and if any of the Pick  4   se   1  instructions is issue-ready and identified from the queue, an identified Pick  4   b  instruction is selected in the resultant collection for parallel execution. Otherwise, an identified Pick  4   a  instruction is selected, instead of the identified Pick  4   b  instruction. Pick  4   se   1  and Pick  4   a  and Pick  4   b  in Scenario  2  have the similar relationship. 
     One or more second type of scenarios may be selected in addition to a first type scenario, where each second type scenario includes a pair of picks, one pick containing a group of instructions that conflict with and thus disallow the instruction in the other. Referring to  FIG. 3B . For example, if the Pick  2   a  instruction is identified from the queue, Scenarios a is selected only if none of the instructions in the “Pick  2   a  disallowed by” pick is issue-ready. The picks in Scenarios b and c have the similar relationship. 
     A second type scenario may serve to produce an instruction and make efficient use of an extra register file port or other resource whenever it is not used by other higher-priority instructions as those specified in the “disallowed by” pick. However, a second type scenario may be configured for any other purposes without departing from the scope of the present disclosure. 
     According to embodiments of the present disclosure, a collection of two or more issue-ready instructions can be obtained for parallel execution at a given cycle based on predetermined scenarios. The pre-arrangements of the scenarios and picks, as well as the corresponding policies of selecting scenario(s) and selecting instructions advantageously ensure compatibility among the resultant collection of instructions and forward progress in each issue window. Moreover, the pre-arrangements and the selection policies allow the identification operations for all the picks across the scenarios to be performed independently of each other, and therefore can be performed in parallel, e.g., each through a single find-first process. The parallel operations advantageously result in substantial processing speed enhancement, since deciding which scenario(s) to use can be even faster, e.g., through a zero-detect process. 
       FIG. 4A  is a flowchart depicting an exemplary process  400  of selecting a first type scenario based on instruction identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B  in accordance with an embodiment of the present disclosure. Process  400  may be performed by the selection control module  110  in  FIG. 1  for example. Scenarios  1 - 3  are first type scenarios and have different priority levels. Assuming, for each pick, the finding logic has identified an issue-ready instruction from the instruction queue that belongs to the pick. At  401 , it is determined whether a Pick  0  instruction of Scenario  1  has been identified from the queue. If yes, Scenario  1  is selected at  405 . Therefore, the identified instructions of Pick  0 , Pick  1 , Pick  3   a  or Pick  3   b,  and Pick  4   a  or Pick  4   b  are output from the multiplexer (MUX  130  in  FIG. 1 ) and supplied to the functional units for parallel execution. 
     If, at  401 , it is determined that no Pick  0  instruction of Scenario  1  has been identified from the queue, then at  402  it is further determined whether a Pick  0  instruction of Scenario  2  has been identified from the queue. If yes, Scenario  2  is selected at  404 . Therefore, the identified instructions of Pick  0 , Pick  1 , Pick  3 , and Pick  4   a  or Pick  4   b  are output from the multiplexer (MUX  130  in  FIG. 1 ) and supplied to the functional units for parallel execution. If not, Scenario  3  is selected as the default for supplying the identified instructions at  403 . 
       FIG. 4B  is a flowchart depicting an exemplary process  450  of selecting between Pick  3   a  and Pick  3   b  and between Pick  4   a  and Pick  4   b  for Scenario  1  based on identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B  in accordance with an embodiment of the present disclosure. Process  450  may be performed by the selection control module  110  in  FIG. 1  for example. Once the selection control module determines (at  451 ) to select Scenario  1  because its Pick  0  finding logic identifies an instruction from the queue, it further determines (at  452 ) whether the Pick  3   se   1 /Scenario  1  instruction has been identified from the queue. If yes, Pick  3   b /Scenario  1  is selected to supply the identified instruction at  454 ; if not, Pick  3   a /Scenario  1  is selected to supply the identified instruction at  455 . Similarly, if the Pick  4   se   1 /Scenario  1  instruction has been identified from the queue as determined in  453 , Pick  4   b /Scenario  1  is selected to supply the identified instruction at  456 ; if not, Pick  4   a /Scenario  1  is selected to supply the identified instruction at  457 . 
       FIG. 4C  is a flowchart depicting an exemplary process  470  of selecting a second type of scenarios based on instruction identification results given the predefined picks and scenarios shown in  FIGS. 3A-3B . At  471 , the selection control module determines whether any instruction in the “Pick  2   a  disallowed by” pick has identified. If yes, Scenario a is not selected; else, Scenario a, and so the Pick  2   a  instruction is selected. Similar process can be used to select Scenarios b and c. 
     In some embodiments, the selection control module includes zero-detect logic and operates to select a scenario responsive to non-zero detection of one or more particular picks. The zero-detect logic can detect whether an instruction has been identified from the queue for a pick by the finding logic. For example, in response to non-zero detection of the Pick  0 /Scenario  1  finding logic output, Scenario  1  is selected. Scenario  2  is selected in response to non-zero detection of the Pick  0 /Scenario  2  finding logic output and zero detection of the Pick  0 /Scenario  1 . Scenario a is selected in response to non-zero detection of the “Pick  2   a  disallowed by” pick finding logic output. As a result, the selection control module sends select signals to the multiplexer to output the selected instructions. 
       FIG. 5  illustrates the configuration of an exemplary issue unit  500  capable of selecting a collection of compatible instructions by using the predefined picks and scenarios shown in  FIGS. 3A and 3B  in accordance with an embodiment of the present disclosure. The issue unit  500  is coupled to the decoding unit  560  used for decoding fetched instructions and coupled to the instruction queue  560  used to list issue-ready instructions, e.g., Ins  1  and Ins  2 . The instruction picking module  520  in the issue unit is configured in accordance with the predefined  19  picks and  6  scenarios  521 - 526  as defined in  FIGS. 3A and 3B . 
       FIGS. 3A and 3B  show that each pick is associated with a compatibility vector “Compat”, such as Pick  0 /Scenario  1  associated with vector Compat [ 0 ], Pick  2   a /Scenario a associated with vector Compat[ 12 ], “Pick  2   b  disallowed by” /Scenario b associated with vector Compat[ 15 ]. The decoding unit maintains an N×19 compatibility matrix  540 , where each row corresponds to one of the N positions in the queue  550 , and each column corresponds to one of the  19  picks as well as the compatibility vector associated with the pick. For an issue-ready instruction placed in the kth position of the queue, the decoding unit classifies it into a pick, e.g., Pick j (with Compat[j]), and make the element (k, j) in the matrix become “1.” In the identification stage, the finding logic for each pick uses the compatibility matrix  540  to identify an instruction from the instructions present in the queue and associated with the pick. As described with reference to  FIGS. 3A-4C , the finding logic is specific to the instruction compositions of the picks and therefore performs different identification processes, such as find-first, find-oldest, find-last, etc. For example, the Pick j finding logic  531  finds the first instruction associated with column j of the matrix and outputs it as the identified instruction for Pick j. In some embodiments, instructions in the instruction queue are arranged and maintained in entrance order, e.g., by using a collapsing queue. In this configuration, finding the first instruction is equivalent to finding the oldest in the queue. In some other embodiments, the instructions are arranged out of order and thus the queue location of an instruction does not directly correspond to its age. In this case, finding the first instruction is not equivalent to finding the oldest in the queue. However, this discussion is merely exemplary. The finding logic and the instruction queue used in embodiments of the present disclosure can be implemented in any suitable manner that is well known in the art. 
     The finding logic operates concurrently for all the picks. However, in some other embodiments, the picks may be divided into groups, and the finding logic may operate concurrently for each group, but one group after another. It will be appreciated that the present disclosure is not limited to any specific algorithm or circuitry logic used to implement the instruction picking module that can concurrently identify instructions from the queue for multiple picks. 
     The identified instructions for all the picks are then supplied to the selection module  510 . Based on these identification results, the selection control module  511  applies predefined policies and selects one or more scenarios and the picks as described in greater detail with reference to  FIGS. 3A-4C . The selection control module  511  generates select signals to the MUX  512  and MUX  513  to output the identified instructions of the selected picks and selected scenarios. For instance, the selected instructions include  3  instructions identified according to Scenario  2   522  and  1  instruction identified according to Scenario b  525 . The output instructions are then issued to corresponding functional units for parallel processing. 
     A superscalar processor according to embodiments of the present disclosure may be used as a processor in a wide range of computing systems, such as general-purposes computer, network controllers, routers, firewalls, servers, game consoles, smart phones, etc.  FIG. 6  is a block diagram illustrating an exemplary superscalar processor  600  capable of issuing compatible instructions according to predefined scenarios in accordance with an embodiment of the present disclosure. Processor  600  includes an instruction cache  610 , a fetch unit  620 , a decoding  630 , an issue unit  660 , functional units  640  (e.g., arithmetic logic units (ALUs)) and register files  650 . The issue unit  660  includes scheduling logic  661  configured to use predefined scenarios to schedule a collection of compatible instructions for parallel execution by the functional units  640  in a single execution cycle. 
     Processor  600  includes an instruction cache  610  for temporarily storing instructions prior to their dispatch to the downstream components. During operation, instruction code may be provided to instruction cache  610  by prefetching instructions from a main memory through a prefetch/predecode unit (not shown). The fetch unit  620  can fetch multiple instructions from the cache  610  for each clock cycle and place them into a queue. The decoding unit  630  decodes the fetched instructions, identifies control-flow changing branch instructions to provide quick feedback to the fetch stage and determines data dependencies of the instructions. 
     The issue unit  660  checks whether an instruction&#39;s operands are available yet. Any instruction whose operands are available is a candidate for issue and the issue unit will check whether the requested functional unit is available. If the required functional unit, register file and data are all available to an instruction, it is placed in the issue-ready instruction queue. 
     The decoding unit  630  classifies each issue-ready instruction into a predefined pick, e.g., by maintaining a compatibility matrix. The issue unit  660  includes scheduling logic  661  that can determine a collection of compatible issue-ready instructions based on predefined the scenarios and picks according to an embodiment of the present disclosure, as described in greater detail with reference to  FIGS. 1-5 . The compatible instructions are simultaneously issued to the functional units  640  for parallel execution in a single clock cycle. The functional units have write and read ports coupled to the register file  650 , and output the execution results to the register file  650 . A superscalar processor according to an embodiment of the present disclosure may include various other functional components are well known in the art. 
     Although certain preferred embodiments and methods have been disclosed herein, it will be apparent from the foregoing disclosure to those skilled in the art that variations and modifications of such embodiments and methods may be made without departing from the spirit and scope of the invention. It is intended that the invention shall be limited only to the extent required by the appended claims and the rules and principles of applicable law. Any claimed embodiment of the invention does not necessarily include all of the objects or embodiments of the disclosure.