Apparatus and Method for Improving Instruction Fusion, Fracture, and Binary Translation

An electronic, digital data processor is adapted dynamically to develop for selected instructions received for execution in a pipelined execution unit a predetermined transform of the selected instructions. Depending on predetermined static or dynamic conditions that may exist in the pipelined execution unit, execution of the transform may be allowed or suppressed. The transform may be a fusion, a fracture or a binary transformation. A method is also disclosed for implementing this selective suppression of developed transforms.

FIELD OF THE INVENTION

The present invention relates to the field of computer processors. More particularly, it relates to improved fusion, fracture, and binary translation methods and apparatus in an electronic, digital data processor, where the processor consists of a general-purpose data processor, a digital-signal processor, a single instruction multiple data processor, a vector processor, a graphics processor, a VLIW processor, or other type of microprocessor which executes instructions.

BACKGROUND

In general, in the descriptions that follow, the first occurrence of each special term of art that should be familiar to those skilled in the art of integrated circuits (“ICs”) and systems will be italicized. In addition, when a term that may be new or that may be used in a context that may be new, that term will be set forth in bold and at least one appropriate definition for that term will be provided. In addition, throughout this description, the terms assert and negate may be used when referring to the rendering of a signal, signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively, and the term toggle to indicate the logical inversion of a signal from one logical state to the other. Alternatively, the mutually exclusive boolean states may be referred to as logic_0 and logic_1. Of course, as is well known, consistent system operation can be obtained by reversing the logic sense of all such signals, such that signals described herein as logically true become logically false and vice versa. Furthermore, it is of no relevance in such systems which specific voltage levels are selected to represent each of the logic states.

Hereinafter, reference to a facility shall mean a circuit or an associated set of circuits adapted to perform a particular function regardless of the physical layout of an embodiment thereof. Thus, the electronic elements comprising a given facility may be instantiated in the form of a hard macro adapted to be placed as a physically contiguous module, or in the form of a soft macro the elements of which may be distributed in any appropriate way that meets speed path requirements. In general, electronic systems comprise many different types of facilities, each adapted to perform specific functions in accordance with the intended capabilities of each system. Depending on the intended system application, the several facilities comprising the hardware platform may be integrated onto a single IC, or distributed across multiple ICs. Depending on cost and other known considerations, the electronic components, including the facility-instantiating IC(s), may be embodied in one or more single- or multi-chip packages. However, unless expressly stated to the contrary, the form of instantiation of any facility shall be considered as being purely a matter of design choice.

Instruction fusion, instruction fracture, and binary translation are known to be potentially useful techniques for enhancing the performance and power efficiency of modern processors:

In all of the above cases, the effectiveness of these transforms tends to be contextual and transitory, e.g., a static implementation of a fusion-capable instruction decoder sometimes experiences lower performance as a result of unpredictable dynamic conditions in the execution pipeline, which, of course, tends to reduce the overall benefit. For example, performance analysis of SpecCPU 2006 has shown a theoretical benefit for fusion, while in reported implementations the net effect is much lower than the theoretical.

After careful study, I have concluded that failing to take into account dynamic pipeline events when effecting transforms often negatively impacts the potential effectiveness of those transforms. My analysis has convinced me that facilitating visibility of a transform-capable decoder of at least some of the more important dynamic pipeline events will allow the decoder to make better cycle-by-cycle decisions with respect to effecting, or not, possible transformations, thereby potentially improving the performance and power benefits of transforms. What is needed, I submit, is a transform-capable decoder having visibility of important dynamic pipeline events such that all instruction transforms can be applied more effectively.

BRIEF SUMMARY OF THE INVENTION

In one embodiment, an electronic, digital data processor comprises: a pipelined central processing unit comprising: an instruction fetch facility adapted to: fetch a stream of instructions; and output said fetched instructions in a predetermined order; an instruction decode facility, coupled to the instruction fetch facility, and adapted to: receive the fetched instructions output from the instruction fetch facility; decode simultaneously M of said received fetched instructions; receive dynamically an instruction transform comprising at least one decoded transform instruction; receive dynamically an instruction transform select signal having a selected one of first and second states; and either: output said decoded instructions in response to receiving said instruction transform select signal in said first state; or: output said instruction transform in response to receiving said instruction transform select signal in said second state; and an instruction execution facility comprising an instruction execution pipeline, coupled to the instruction decode facility, and adapted to: receive the decoded instructions output from the instruction decode facility; execute said decoded instructions in the instruction execution pipeline; detect a predetermined pipeline event in the instruction execution pipeline; and either: output a pipeline event signal in a third state if said predetermined dynamic condition in the instruction execution pipeline is not detected; or: output the pipeline event signal in a fourth state if said predetermined dynamic condition in the instruction execution pipeline is detected; and an instruction transform facility, coupled to the instruction decode facility and to the instruction execution facility, and adapted to: receive the decoded instructions output from the instruction decode facility; detect in the received decoded instructions a first predetermined sequence of N of said received decoded instructions, where N is greater than 1 and no greater than M; develop said instruction transform of said first predetermined sequence of N of said received decoded instructions; receive the pipeline event signal output from the instruction execution facility; and either: output said instruction transform signal in said first state in response to receiving said pipeline event signal in said third state; or: output said instruction transform signal in said second state in response to receiving said pipeline event signal in said fourth state.

In one other embodiment, an electronic, digital data processor comprises an pipeline execution unit and is adapted to: decode an instruction; develop a predetermined instruction transform of said instruction; and perform a selected one of: executing said instruction transform in response a predetermined event in said pipeline execution unit; and executing said instruction otherwise.

In yet another embodiment, a method for use in an electronic, digital data processor comprising a pipelined execution unit, the method comprising the steps of: fetching a stream of instructions; decoding at least one of the instructions; developing dynamically an instruction transform of at least one of the decoded instructions; and performing a selected one of: executing said instruction transform in response a predetermined event in said pipeline execution unit; and executing said instruction otherwise.

In still another embodiment, a method for use in an electronic, digital data processor comprising a pipelined execution unit, the method comprising the steps of: fetching a stream of instructions; decoding at least one of the instructions; developing dynamically an instruction transform of at least one of the decoded instructions; and depending on a predetermined condition that may exist in the pipelined execution unit, selectively suppressing execution of the transform.

In all embodiments, the instruction transforms comprise at least a selected one of: fusion; fracture; and binary transformation.

DETAILED DESCRIPTION

The following description provides different embodiments for implementing aspects of the present invention. Specific examples of components and arrangements are described below to simplify the explanation. These are merely examples and are not intended to be limiting. For example, the description of a first component coupled to a second component includes embodiments in which the two components are directly connected, as well as embodiments in which an additional component is disposed between the first and second components. In addition, the present disclosure repeats reference numerals in various examples. This repetition is for the purpose of clarity and does not in itself require an identical relationship between the embodiments.

FIG. 1 illustrates, in block diagram form, a typical general-purpose computer system 100 according to some embodiments. The general-purpose computer system 100 is adapted to utilize the apparatus and methods disclosed herein, specifically the instruction fusion, fracture, and binary translation apparatus and methods. The general-purpose computer system 100 includes at least one processor 102 as well as random access memory 104 (“RAM”) and other components. The processor 102 is operable to communicate with RAM 104 via bus 106 as well as communicate with other components of the general-purpose computer system 100.

FIG. 2 illustrates, in block diagram form, a typical integrated system 200 comprising, inter alia, at least a single central process unit 202 (“CPU”) according to some embodiments. The CPU 202 is adapted to execute and utilize the fusion, fracture, and binary translation apparatus and methods described herein. The typical integrated system 200 also may include instruction memory 204, data memory 206, along with other peripheral units and various analog units.

FIG. 3 illustrates, in block diagram form, one embodiment of an instruction processing pipeline facility 300 which is included in CPU 202 of FIG. 2. Pipeline 300 includes an instruction fetch facility 302, an instruction decode facility 304, and an instruction dispatch facility 306. In the illustrated embodiment, I have adapted the decode facility 304 to include the fusion, fracture, and binary translation apparatus and methods described herein. As one of ordinary skill in this art would understand, the illustrated instruction processing facilities may vary in size and implementation according to known factors, e.g., the processor's design instruction set architecture, the micro-architecture of the processor, etc.

For convenience of reference, I have used in FIG. 3 the following abbreviations:

In the Fetch facility 302:

IA
Instruction Address register

ICache
Instruction Cache

BPU
Branch Prediction Unit

In the Decode facility 304:

RFL
Register Free List

RAT
Register Alias Table

ART
Architectural Register Table

ROB
Reorder Buffer

SB
Score Board

In the Execute facility 306:

PRF
Physical Register File

DISP
Dispatch

RCU
Read Control Unit

DA
Data Address register

Downstream of the Execute facility 306:

DCache
Data Cache

BIU
Bus Interface Unit

FIG. 4 illustrates, in a more detailed block diagram form, one possible embodiment of the transform facility of FIG. 3. In accordance with this embodiment, an N-wide instruction decoder 402 decodes the instructions, and passes an abbreviated version of the N-wide function bits to a UID hash generator 404, where N could be 64b. I recognize that the selection of the hashing function is a matter of design choice; and is generally determined, during design, by the properties of the instruction sequences originally selected as candidates for fusion. In the case of the Pearson hash, which I prefer, the contents of the randomization table are created to ensure there is no overlap or false hits for the supported fusable sequences.

In this embodiment, the output of the UID generator 404 is an 8-bit wide value used to index into a UID lookup facility 406. The UID lookup 406 determines whether the calculated hash has a known fusion transform, and, if so, the UID of that fusion transform is output, simultaneous with a hit signal, to a fusion transform selector 408. In response to receiving both the UID and the hit signal, the fusion transform selector 408 converts the received UID into: an event selector signal; a fusion transform selector signal; and a instruction selector signal. The function of the fusion transform selector 408 is to facilitate a many-to-one mapping of the UID to event and transform selector values.

In response to receiving an event selector signal, an event selector mux 410 will select for output to the fusion transform facility 412 one or more of the pipeline event signals generated by the pipeline facility 300 (see, FIG. 3). I recognize, however, that the event selector mux 410 is just one possible implementation; one possible alternative would be to route ALL important pipeline events directly to the fusion transform facility 412.

In response to receiving the instruction selector and transform selector signals, my fusion transform facility 412, performs the transformation of the input decoded instructions to the fused version. However, in accordance with my invention, in response to receiving the pipeline event signals output by the event selector mux 410, my fusion transform 412 takes the received event signals into consideration when deciding whether to fuse or not fuse the function group instructions—I have depicted this decision, conceptually, as the fusion selection decision facility 414.

Finally, a fuse/unfused select mux 416 selects either the unmodified instructions or the fused version for output to the down-stream pipeline facility 300.

Terminology

For the purposes of the present disclosure, I intend that the following terminology include all environments and alternate technologies that provide the same functionality described herein.

Fusion Group

Below is an example of a pre-defined 2-instruction Fusion Group.

Consider first this assembly source code sequence:

In accordance with my invention, I develop for this particular code sequence a corresponding Fusion Group having a pre-calculated Fusion Group hash equal to 0x6941—I shall refer to this number below.

UID
Mnemonic
Operands

As I have already noted, the Fusion Groups are predefined and implemented directly into the RTL and so are a static representation. I expect the exact format of this representation to be adapted to the needs of the RTL.

Transform Enable Register

In my preferred embodiment, illustrated in FIG. 5, I define the bits comprising the TER as follows:

In the process of selecting Fusion Groups for implementation in the RTL, I assign each Fusion Group a corresponding page assignment and enable bit in the TER. In the event that I decide to implement more than 28 Fusion Groups, I must implement additional TERs, each implementing an additional 28 group enable bits but having a unique combination of page select bits.

Fusion Window

Conceptually, my Fusion Window facility comprises a sliding window that I use to match incoming instructions against the predefined Fusion Groups. In FIG. 6, I have illustrated my invented terminology.

The instruction decoder design sets the maximum number of simultaneously available decoded instructions. The maximum scan size and moving scan window are design choices based on the lengths of the predefined Fusion Groups. In the simplest implementation, the two scan window sizes can be the same length, thereby eliminating the need for a moving window.

Using an assumption of a maximum scan size of 4 and a maximum Fusion Group length of 2, a high-level view of one implementation using Fusion Group hashes is illustrated in FIG. 7. During normal operation, the hash of each of the decoded instruction opcodes (or a hash of some conveniently defined extra field in the decoded instruction) is dynamically generated, then matched in the PRI Select facilities against the precalculated hashes of the predefined Fusion Groups. Hit signals from the PRI Selects are gated by the corresponding bits in the TER.

Selecting when there are multiple hits is straight forward. If the Fusion Groups are organized with the longest group on the right and PRI Select inputs put the oldest instructions on the right. Selecting the right most PRI and right most of A/B/C will automatically select the longest match of the oldest instructions.

Translation

The Fusion Transform Selector facility 408 (see, FIG. 4) converts the incoming hash to a set of narrow width fields. These fields are the Event Selector, the Transform Selector and the Instruction Selector. This translation enables many to one mappings of incoming hash to selector values. which enables reuse of transforms and event mux outputs. I believe it to be possible, using Fusion Group #1, without loss of generality, to choose 0x1 for all three selector values.

Fusion Transform

The fusion transform function is performed in two steps. There is a constraints satisfaction step followed by the actual transform.

Fusion Transform Constraints

A fusion transform is performed on the input instructions if the constraints are met. If the constraints are not met the target instructions are not unmodified. Roughly two classes of constraints are identified, static and dynamic.

Static Constraints

A common static constraint is defined by the number of register file ports available in the target slice. A minimum viable read/write port limit for fusion is 1 write and 2 reads. Fusion effectiveness is improved by increasing the number of register files ports with 2wr/4rd a sweet spot between effectiveness and complexity in the PRF design.

There are more constraints depending on the micro-architecture of the processor and relate to the combinations of instructions and operands within the Fusion Group.

A walk-through of static constraints checking for register file ports:

This is the example input assembly source text, repeated from a previous section. The example continues assuming 1wr/2rd on the target register file.

This example shows an operand set which causes the Fusion Group to be rejected for fusion. Given the extremely limited WR/RD ports in this contrived example, this sequence would not meet the static constraints,

Dynamic Constraints

Dynamic constraints are an important part of this disclosure. By making events in the pipeline visible to the fusion logic the application of fused operations is more effective. Past implementations of fusion suffer from lack of adaptability to pipeline behavior.

Dynamic constraints are checked in parallel with the static constraints. The difference is the transient nature of the inputs for dynamic constraints.

The pipeline events mux plus selector is one possible embodiment. It is also possible to simply route all pipeline events directly to the fusion module and each individual block of logic for the fusion transforms. Regardless, the concept is the same, a limited set of events are used by the transform logic for a given Fusion Group.

In my preferred embodiment, the pipeline events that I choose to identify comprise:

The pipeline events are conditioned prior to presentation to the Fusion Transform facility 412 (see, FIG. 4). This typically will require adding pipe stages to filter transient status (e.g., counting stalls rather than directly reporting the stall state so that only significant stalls impact fusion, etc). However, as will be clear to those familiar with this art, the conditioning of pipeline events is mutable. Possible variations include, among others, the implementation details of the processor, e.g., number of pipe-stages, wire length for signals transporting the events, clock rate, power savings mode, etc. Further, the conditioning of pipeline events is also dependent on the source of the event, e.g., the amount of staging required for transporting a signal from the BIU (FIG. 3) to the Fusion Transform facility 412 (FIG. 4) vs the amount of staging required from the BPU (FIG. 3). Indeed, in some processor designs there may be no conditioning required at all due to the implementation characteristics of that processor.

These events allow the fusion logic to make decisions on full fusion, partial fusion, or pass the instructions unmodified. Full fusion or pass through use similar mechanics to the static constraints process.

Partial fusion of a Fusion Group is most easily implemented by providing alternative versions of the Fusion Group rather than dynamically making this decision. I recognize that this may result in some redundancy, but it may reduce complexity.

The three Fusion Groups depicted below are related: 1.A includes a trailing branch; 1.B eliminates the trailing branch; and 1.C is defined such that it can be fused in a branch related group (italicized) and an ancillary group (underlined). These are the important optimizations that can be made when pipeline events and state are available to the fusion capable decoder.

Final Fusion Transform

If the constraints are satisfied, the actual transform operation is a mapping of decoded instructions from one form to the other. This mapping is guided by the implementation and the structures in the implementation for maintaining decode instructions. Also, I believe it that fusion will interact favorably with trace caches and uop caches.

In some implementations, it is likely the operand decoding would remain the same and the principal transformation would be the generation of an opcode for the fused operation. For example, I have identified a particular fusion group comprising 5 opcodes that may be translated to a single opcode, with an out-of-band flag bit and an opcode based on the UID created earlier. In this example, the flag bit serves to identify the fused opcode as the result of a fusion operation.

Fracture Operations

As will be clear to those skilled in this art, fusion often results in fewer operations submitted for dispatch. In contrast, fracture tends to perform the opposite, creating multiple micro-ops from a single complex instruction. Therefore, considerations are required to assess the pipeline's ability efficiently to absorb the additional micro-ops and resolve the new dependencies introduced by the fracture operation. Fracture also benefits from visibility of the pipeline state for similar reasons as fusion, since pipeline events allow for dynamic choices in the fracture operation.

The opportunities for fracture in the RISC-V ISA are more commonly found in the ISA extensions, rather than the main ISA instruction groups. In general, the atomic instructions are candidates for fracture analysis. For example, the compare-and-swap instruction, AMOSWAP.W/D., can be broken into a load-modify instruction and a separate store instruction. This is also true of the other AMO based instructions.

Other candidates include floating point operations, in particular those operations which are emulating the primary operation or those where emulation is used to support wider operations than the hardware has implemented.

Binary Translation

Binary translation is the term generally used when both fusion and fracture are used to restructure instruction sequences. For example, Crypto instructions in the Zkg extension would benefit from a mixture of fusion and fracture.

By way of explanation, consider the following example code, which is a typical loop using the GHASH instruction as part of Galois field calculations:

# - a0: Points to the input data block

# - a1: Points to the GHASH key

# - a3: Number of bytes in the input data block

# Load a 128-bit block of input data

# Perform GHASH multiplication can be fractured into separate operations which may

#give opportunities in optimizing the schedule of the new micro-ops

# Update pointers and loop counter

# Final result is in vector register v1

Impact of Dynamic Constraints

One key element of my invention is that with the availability of pipeline events, also described above as dynamic constraints, my Transform facility (see, FIG. 3) now has the information necessary for dynamic selection of transforms. Insofar as I am presently aware, this capability is not present in current designs. With this visibility of pipeline events/dynamic constraints, my transform process may be used with any combination of fusion, fracture, translation or pass through.

Fusion Group Examples from ARM ISA

The discussion so far has focused primarily on the RISC-V ISA. However, the concepts discussed herein are not limited to RISC-V. What follows is a summary of some fusable operations I have found in the ARM ISA. I expect equivalents exist in almost all ISAs, particularly those with roots in RISC architecture concepts.

What follows is a brief categorization of classes of fusion options in the ARM ISA. This is not exhaustive. The benefits to visibility of pipe events translates directly, independent of RISC-V vs ARM ISAs.

Pipeline Events

Let us now consider three examples of common pipeline events:

Example #1: availability of the required computation site.

Example #2: output of the BPU for a branch in the target sequence.

Example #3: a combination of multiple pipeline events: LSU stalls/busy state; potential target address D-Cache hit; and potential hit in load/store pending buffers.

Additional Pipe Events

In the following, the abbreviations can be found above.

Entries remaining

Max retire rate

Number of slots for each, RAT/RFL/ART

Number of renames slots available

Total write ports available

Total read ports available

Write port usage scheduled/predicted

Read port usage scheduled/predicted

Completion estimation times for pending integer instructions

Completion estimation times for pending floating point instructions

Completion estimation times for pending load/store instructions

Number of pending transactions

BIU transaction buffer entries remaining

PREDICTED

PREDICTED

PREDICTED

I-side prefetcher state cycles remaining to phase completion

D-side prefetcher state cycles remaining to phase completion

L2 prefetcher state cycles remaining to phase completion

LSU num LD transactions available

LSU num ST transactions available

LSU num atomic transactions inflight

LSU num atomic transactions active

LD buffer number of entries remaining

ST buffer number of entries remaining

Victim buffer entries available

Predicted victim buffer hit/miss

Predicted store buffer hit/miss

Replay active

SLICE A side stall, B side stall

SLICE computation site available

SLICE computation site predict busy

SLICE computation site remaining latency

(Here, I will assume that the BPU develops 4 predictions per cycle)

Forward branch predicted taken/not taken

Backward branch predicted taken/not taken

Branch predicted speculative

Method of Transform Control

In FIG. 8, I have illustrated, in flow diagram form, one embodiment of a method for controlling execution of developed transforms. In accordance with one embodiment of my invention in an electronic, digital data processor comprising a pipelined execution unit, a stream of instructions are fetched and decoded; and, for at least some selected instructions or instruction sequences, a predetermined transform is developed. Then, depending on predetermined static or dynamic conditions that may exist in the pipelined execution unit, execution of the transform may be allowed or suppressed. As I have noted above, the transform may be a fusion, a fracture or a binary transformation.

Embodiments

The integrated circuitry employed to implement the units shown herein may be expressed in various forms including as a netlist which takes the form of a listing of the electronic components in a circuit and the list of nodes to which each component is connected. Such a netlist may be provided via an article of manufacture as described below.

In other embodiments, the units shown in the block diagrams of the various figures can be implemented as software representations, for example in a hardware description language (such as for example Verilog) that describes the functions performed by the units described herein at a Register Transfer Level (RTL) type description. The software representations can be implemented employing computer-executable instructions, such as those included in program modules and/or code segments, being executed in a computing system on a target real or virtual processor. Generally, program modules and code segments include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The program modules and/or code segments may be obtained from another computer system, such as via the Internet, by downloading the program modules from the other computer system for execution on one or more different computer systems. The functionality of the program modules and/or code segments may be combined or split between program modules/segments as desired in various embodiments. Computer-executable instructions for program modules and/or code segments may be executed within a local or distributed computing system. The computer-executable instructions, which may include data, instructions, and configuration parameters, may be provided via an article of manufacture including a non-transitory computer readable medium, which provides content that represents instructions that can be executed. A computer readable medium may also include a storage or database from which content can be downloaded. A computer readable medium may also include a device or product having content stored thereon at a time of sale or delivery. Thus, delivering a device with stored content, or offering content for download over a communication medium may be understood as providing an article of manufacture with such content described herein.

The aforementioned implementations of software executed on a general-purpose, or special purpose, computing system may take the form of a computer-implemented method for implementing a microprocessor, and also as a computer program product for implementing a microprocessor, where the computer program product is stored on a non-transitory computer readable storage medium and includes instructions for causing the computer system to execute a method. The aforementioned program modules and/or code segments may be executed on suitable computing system to perform the functions disclosed herein. Such a computing system will typically include one or more processing units, memory and non-transitory storage to execute computer-executable instructions.

The foregoing explanation described features of several embodiments so that those skilled in the art may better understand the scope of the invention. Those skilled in the art will appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments herein. Such equivalent constructions do not depart from the spirit and scope of the present disclosure. Numerous changes, substitutions and alterations may be made without departing from the spirit and scope of the present invention.

Although illustrative embodiments of the invention have been described in detail with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be affected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Apparatus, methods and systems according to embodiments of the disclosure are described. Although specific embodiments are illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purposes can be substituted for the specific embodiments shown. This application is intended to cover any adaptations or variations of the embodiments and disclosure. For example, although described in terminology and terms common to the field of art, exemplary embodiments, systems, methods and apparatus described herein, one of ordinary skill in the art will appreciate that implementations can be made for other fields of art, systems, apparatus or methods that provide the required functions. The invention should therefore not be limited by the above-described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the invention.

In particular, one of ordinary skill in the art will readily appreciate that the names of the methods and apparatus are not intended to limit embodiments or the disclosure. Furthermore, additional methods, steps, and apparatus can be added to the components, functions can be rearranged among the components, and new components to correspond to future enhancements and physical devices used in embodiments can be introduced without departing from the scope of embodiments and the disclosure. One of skill in the art will readily recognize that embodiments are applicable to future systems, future apparatus, future methods, and different materials.

All methods described herein can be performed in a suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”), is intended merely to better illustrate the disclosure and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure as used herein.

PRI DETAILS

Following is one possible embodiment of a PRI Select facility:

1.
// A common interface for all decoded instructions

13.
 // A common interface for all transform groups no matter the length.

15.
 // The width and number of fields in this structure can change with

16.
 // any design. These are examples are one implementation

19.
   //This is a common structure, the mask indicates which of the

23.
   //Each transform group has a length field, this is the pre-encoded

24.
   //version of count_ones of mask

27.
   //Each transform group is assigned a page and a bit in the TER

31.
   //Each transform group is assigned a event group select value

33.
   //This is driven to the event select mux

36.
   //Each transform group is assigned a transform select value

38.
   //This is driven to the transform select mux

41.
   //Each transform group is assigned an instruction select value

43.
   //can also include the pre-transformed instruction as transform_out

46.
   // A transform group can encompass any number of comparisons.

47.
   // This example has max 4, but the max can be anything.

52.
   // match_i{0,3} contain the fields which are compared to the incoming

53.
   // instructions for operand constrained transforms. The match_ix versions

54.
   // contain the don′t care or explicit values used in the comparison

65.
 module transform

67.
   //The number of decoded_inst_t ports is the width of the instruction

74.
   //The number of transform_group_t ports is equal to the number

75.
   //of transform groups implemented in hardware. This shows a simple

84.
   //Output of the UID/hit/miss/translation blocks

90.
   //This is also output in this block in this example

91.
   //but could be down stream given instruction_selector is

96.
 // This select sets the output regs

99.
 // Create the transform enable register wires

103.
    // Create the transform group enables for each group

104.
    // Both page and bit select must be enabled.

117.
    // Create the transform group enables

165.
    // Module that performs hash compares and PRI select of figure 4

166.
    // in the disclosure

179.
    // Intermediate variables to hold the max length and corresponding

184.
      // Initialize with a minimum value and no group selected