Programmable control of processor resources

Abstract

Various example embodiments of a processor are presented. Various example embodiments of the processor may be configured to support split programmability of resources of a processor front end of the processor. Various example embodiments of the processor are configured to support split programmability of resources of a processor front end of the processor in a manner that enables assignment of split programmable resources of the front end of the processor to control blocks of a program being executed by the processor. Various example embodiments of the processor are configured to support split programmability of micro-operation (UOP) cache (UC) resources of the front end of the processor (which may subsequently be referred to as a split programmable (SP) UC (SP‑UC), where it may be referred to as “split” because there are multiple UCs, and may be referred to as “programmable” because selection of an active UC from a set of multiple UCs is controllable by a program executed by the processor).

Description

Technical Field

[0001] Various example embodiments relate generally to processors and, more particularly, but not exclusively, to processor caches for processors. Background Art

[0002] In general, processors can be based on various architectures and can be configured for various purposes. For example, a common type of processor is a central processing unit (CPU), which is the component within a computer that executes programs. When a CPU is contained on a single chip, it is often referred to as a microprocessor. Microprocessors can be based on various architectures, often referred to as instruction set architectures (ISAs), and can be configured for various purposes, such as general processing, network packet forwarding, graphics processing, and the like. Summary of the invention

[0003] Various example embodiments of the processor may be configured to support the programmability of the processor front-end resources of the processor. In at least some example embodiments, the processor includes a back end, a front end with front-end resources, and an instruction set architecture (ISA). The processor may be configured to execute a program. The front end may be configured to decode the instructions of the program to provide a micro-operation set to the back end. The back end may be configured to receive micro-operations from the front end and execute micro-operations. The ISA may be configured to support the programmability of the front-end resource set of the front end by the program. The processor front-end resources may include micro-operation (UOP) cache (UC) resources, branch prediction unit (BPU) resources, branch target buffer (BTB) resources, etc. and various combinations thereof. In at least some embodiments, a device may include a processor configured to support the programmability of the UC resources of the processor, wherein the processor includes a set of at least two micro-operation caches, which are configured to store micro-operations decoded from the instructions of the program to be executed by the processor. In at least some example embodiments, a non-transitory computer-readable storage medium stores instructions configured to cause a processor to decode an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation and store the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, a method includes: decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and storing the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, a device includes a processor including a component for decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and a component for storing the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, a device includes a component for decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and a component for storing the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some embodiments, an apparatus may include a processor configured to support programmability of UC resources of the processor, wherein the processor includes an ISA configured to support programmability of a set of two or more micro-operation caches of the processor by a program executed by the processor. In at least some example embodiments, a non-transitory computer-readable storage medium stores instructions configured to cause the processor to execute a program including an instruction set, and the ISA of the processor supports programmability of the set of two or more micro-operation caches of the processor based on execution of the program. In at least some example embodiments, a method includes executing a program including an instruction set by a processor, and the ISA of the processor supports programmability of the set of two or more micro-operation caches of the processor based on execution of the program.In at least some example embodiments, an apparatus includes a processor including means for executing a program including an instruction set, and means for supporting programmability of a set of two or more micro-operation caches of the processor by an ISA of the processor based on execution of the program. In at least some example embodiments, an apparatus includes means for executing a program including an instruction set by the processor, and means for supporting programmability of a set of two or more micro-operation caches of the processor by an ISA of the processor based on execution of the program.

[0004] In at least some example embodiments, a device includes a processor including a set of at least two micro-operation caches configured to store micro-operations decoded from instructions of a program to be executed by the processor. In at least some example embodiments, the processor is configured to activate only a micro-operation cache from the set of at least two micro-operation caches at any time during the execution of the program by the processor for storage or access of micro-operations. In at least some example embodiments, the processor includes a set of instruction decoders, wherein during the decoding of one of the instructions of the program, the set of instruction decoders stores the micro-operation into an active micro-operation cache in the micro-operation cache. In at least some example embodiments, the processor is configured to perform a lookup operation in the active micro-operation cache in the micro-operation cache while obtaining an instruction pointer (IP) of the instruction of the program. In at least some example embodiments, the processor is configured to support the selection of one of the micro-operation caches in the micro-operation cache as the active micro-operation cache based on a micro-operation cache switching instruction. In at least some example embodiments, the micro-operation cache switching instruction is an instruction specifically configured for selecting one of the micro-operation caches in the micro-operation cache as the active micro-operation cache. In at least some example embodiments, the micro-operation cache switching instruction is an instruction configured to provide a program control function of the program and is also configured to support selecting one of the micro-operation caches in the micro-operation cache as an active micro-operation cache. In at least some example embodiments, the ISA of the processor supports the micro-operation cache switching instruction. In at least some example embodiments, the processor is configured to select a first micro-operation cache in the micro-operation cache as the active micro-operation cache, wherein the micro-operation cache switching instruction includes an identifier of a second micro-operation cache in the micro-operation cache, wherein the decoding of the micro-operation cache switching instruction causes the active micro-operation cache to switch from the first micro-operation cache in the micro-operation cache to the second micro-operation cache in the micro-operation cache. In at least some example embodiments, the processor is configured to decode the micro-operation cache switching instruction of the program so as to select the first micro-operation cache in the micro-operation cache as the active micro-operation cache, wherein the micro-operations decoded from one or more subsequent instructions of the program are stored in the first micro-operation cache in the micro-operation cache until the next micro-operation cache switching instruction is decoded to change the active micro-operation cache to the second micro-operation cache in the micro-operation cache. In at least some example embodiments, the processor is configured to select a first micro-operation cache in the micro-operation caches as an active micro-operation cache, wherein the processor is configured to switch the active micro-operation cache to the second micro-operation cache in the micro-operation caches before decoding a next instruction of a program associated with the second micro-operation cache in the micro-operation caches.In at least some example embodiments, the processor is configured to select a first micro-operation cache in the micro-operation cache as an active micro-operation cache, wherein the processor is configured to switch the active micro-operation cache to a second micro-operation cache in the micro-operation cache based on the micro-operation cache switching instruction before executing a micro-operation decoded based on the micro-operation cache switching instruction. In at least some example embodiments, the processor is configured to perform the switch based on determining that the micro-operation cache switching instruction exists in the first micro-operation cache in the micro-operation cache. In at least some example embodiments, the processor is configured to perform the switch during the decoding and storage of the micro-operation cache switching instruction based on determining that the micro-operation cache switching instruction does not exist in the first micro-operation cache in the micro-operation cache. In at least some example embodiments, the processor includes an ISA configured to support programmability of a set of micro-operation caches by a program. In at least some example embodiments, a non-transitory computer-readable storage medium stores instructions that are configured to cause the processor to decode the instructions of the program through a decoding block of a processor having at least two micro-operation caches to form a micro-operation and store the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, a method includes: decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and storing the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, an apparatus includes a processor, the processor including components for decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and components for storing the micro-operation in an active micro-operation cache in the micro-operation cache. In at least some example embodiments, an apparatus includes components for decoding an instruction of a program by a decode block of a processor having at least two micro-operation caches to form a micro-operation, and components for storing the micro-operation in an active micro-operation cache in the micro-operation cache.

[0005] In at least some example embodiments, a device includes a processor, the processor includes an instruction set architecture (ISA), the ISA is configured to support the programmability of a set of two or more micro-operation caches of the processor by a program executed by the processor. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support the association of a control block of the program with one of the micro-operation caches. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support the sharing of one of the micro-operation caches by two or more control blocks of the program. In at least some example embodiments, the processor is configured to keep two or more control blocks of the program as spatially collocated in a program memory. In at least some example embodiments, the program includes a set of control blocks, wherein, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support the distribution of the control blocks of the program by the program on at least a portion of the micro-operation cache. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support instructions configured to switch the active micro-operation caches in the micro-operation caches. In at least some example embodiments, the instruction configured to switch the active micro-operation cache in the micro-operation cache includes a micro-cache identifier indicating that one of the micro-operation caches will be made the active micro-operation cache in the micro-operation cache. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support an instruction type specifically configured for selecting one of the micro-operation caches in the micro-operation cache as the active micro-operation cache. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support an instruction type that is configured to provide a program control function of the program and is also configured to support selecting one of the micro-operation caches in the micro-operation cache as the active micro-operation cache. In at least some example embodiments, in order to support the programmability of the set of micro-operation caches by the program, the ISA is configured to support fixing the control block of the program to one of the micro-operation caches in the micro-operation cache, so that the micro-operation decoded based on the instruction of the control block is accessed from one of the micro-operation caches in the micro-operation cache, or stored in one of the micro-operation caches in the micro-operation cache. In at least some example embodiments, first and second control blocks of a program are associated with respective first and second micro-operation caches, wherein the ISA is configured to support a micro-operation cache switching instruction that, when called by the program with an identifier of the second control block before transferring control from the first control block to the second control block, causes an active micro-operation cache to be switched from a first micro-operation cache in the micro-operation cache to a second micro-operation cache in the micro-operation cache.In at least some example embodiments, a non-transitory computer-readable storage medium stores instructions configured to cause a processor to execute a program including an instruction set, and the ISA of the processor supports programmability of a set of two or more micro-operation caches of the processor based on the execution of the program. In at least some example embodiments, a method includes executing a program including an instruction set by a processor, and the ISA of the processor supports programmability of a set of two or more micro-operation caches of the processor based on the execution of the program. In at least some example embodiments, an apparatus includes a processor including components for executing a program including an instruction set, and components for supporting programmability of a set of two or more micro-operation caches of the processor based on the execution of the program by the ISA of the processor. In at least some example embodiments, an apparatus includes components for executing a program including an instruction set by a processor, and components for supporting programmability of a set of two or more micro-operation caches of the processor based on the execution of the program by the ISA of the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The teachings herein may be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

[0007] Figure 1 An example embodiment of a processor including a partitioned programmable micro-operation cache is depicted;

[0008] Figure 2 An example embodiment of a processor front end capable of supporting partitioned programmability of processor front end resources is depicted;

[0009] Figure 3 An example embodiment of a processor front end capable of supporting split programmability and operating a single micro-op cache is depicted;

[0010] Figure 4 An example embodiment of a logical organization of an instruction cache (IC) of a processor front end is depicted;

[0011] Figure 5 Depicted is an example embodiment of partitioning for mapping instruction blocks from memory to an instruction pointer (IP) of an IC of a processor front end;

[0012] Figure 6 An example embodiment of a micro-operation cache employing an N-way associative cache is depicted;

[0013] Figure 7 depicts an example embodiment of a processor front end showing a micro-op cache in conjunction with an IC, the embodiment being configured to operate in a streaming mode;

[0014] Figure 8An example embodiment of a UC row structure is depicted, wherein a UOP slot is configured to store a UOP, the embodiment being configured for Figure 7 in the micro-operation cache;

[0015] Fig. 9 An example embodiment of the structure of a basic block within an IC row that can be decoded and mapped to a UC based on the IP of the first instruction of the block is depicted, the embodiment being configured for Figure 7 in the micro-operation cache;

[0016] Fig.10 depicts an example embodiment of a processor front end showing a micro-op cache in conjunction with an IC, the embodiment being configured to operate in a build mode;

[0017] Fig.11 An example embodiment of a UC row structure is depicted, wherein a UOP slot is configured to store a UOP, the embodiment being configured for Fig.10 in the micro-op cache of the , and in the construction of the UC row after decoding the basic blocks in the IC row;

[0018] Fig.12 An example embodiment is depicted in which a field in an IC row that identifies an IP of a basic block is translated into an IP field of a UC row that is used by a UC to store IP mapped from a basic block. Fig.10 in the micro-operation cache;

[0019] Fig.13 An example embodiment of a program for illustrating structural components of a program, such as subroutines and branches, that result in a set of control flows within the program is depicted;

[0020] Fig.14 An example embodiment of a program memory implemented as a two-dimensional region in memory divided into cache line units of a particular cache for illustrating a working set of cache lines for a particular set of control flows of a program is depicted;

[0021] Fig.15 An example embodiment of a simplified structure of a network packet processing program configured to be executed by a processor is depicted;

[0022] Fig.16 Depicts a method for executing a Fig.15 Example embodiments of the control flow of a network packet processing program and the structure of the resulting control blocks;

[0023] Fig.17 An example embodiment of a processor front end configured to support split programmability and including a split programmable micro-op cache is depicted;

[0024] Fig.18 An example embodiment of encoding of an x86 instruction set architecture instruction is depicted for illustrating encoding of a color switching instruction configured to support partitioning and programmability of processor front-end resources;

[0025] Fig.19 Depicting an example embodiment of a "Color Switch Type-1" instruction implemented using the x86 instruction set architecture;

[0026] Fig. 20 An example embodiment of an x86 instruction sequence is depicted, which includes a "color switch type-1" instruction;

[0027] Fig.21 Depicting an example embodiment of a "Color Switch Type-2" instruction implemented using the x86 instruction set architecture;

[0028] Fig. 22 Depicting an example embodiment of a "Color Switch UOP" generated based on decoding of a "Color Switch" instruction;

[0029] Fig.23 depicts an example embodiment of decoding a "color switch type-1" instruction;

[0030] Fig.24 depicts an example embodiment of decoding a "color switch type-2" instruction;

[0031] Fig.25 An example embodiment of a processor front end is depicted for illustrating a microarchitecture configured for implementing a split programmable micro-op cache;

[0032] Fig.26 An example embodiment of a processor front end is depicted showing a partitioned programmable micro-op cache in conjunction with an IC, the embodiment being configured to operate in a build mode;

[0033] Fig. 27 An example embodiment of a processor front end is depicted for illustrating a microarchitecture for implementing a split programmable micro-op cache, the embodiment being configured to support mode selection for switching between non-programmable and programmable modes of operation;

[0034] Fig.28 Describes the use of a split programmable micro-operation cache to execute Fig.15 Example embodiments of the control flow of a network packet processing program and the structure of the resulting control blocks;

[0035] Fig.29 An example embodiment of a processor configured to support partitioned programmability of processor front-end resources of the processor is depicted;

[0036] Fig.30 An example embodiment of a method for use by a processor to support programmability of micro-operation cache resources of the processor is depicted;

[0037] Fig.31 An example embodiment of a method for use by a processor to support programmability of micro-operation cache resources of the processor is depicted;

[0038] Fig.32 An example embodiment of a method for use by a processor to support programmability of processor front-end resources is depicted; and

[0039] Fig.33 An example embodiment of a computer that can utilize the various functionality presented herein is depicted.

[0040] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. DETAILED DESCRIPTION

[0041] Various example embodiments of a processor are presented. Various example embodiments of the processor are configured to support split programmability of resources of a processor front end of the processor. Various example embodiments of the processor are configured to support split programmability of resources of a processor front end of the processor in a manner that enables split programmable resources of the processor front end to be assigned to control blocks of a program being executed by the processor. Various example embodiments of the processor are configured to support split programmability of micro-operation (UOP) cache (UC) resources of the processor front end (which may subsequently be referred to as a split programmable (SP) UC (SP-UC), where it may be referred to as "split" because there are multiple UCs, and it may be referred to as "programmable" because the selection of an active UC from a set of multiple UCs is controllable by a program executed by the processor). Various example embodiments of the processor are configured to support split programmability of UC resources of the processor by providing a processor including a set of at least two UCs, the UC being configured to store micro-operations decoded from instructions of a program to be executed by the processor. Various example embodiments of the processor are configured to support split programmability of UC resources of the processor by providing a processor including an instruction set architecture (ISA), the ISA being configured to support programmability of a set of two or more UCs of the processor by a program executed by the processor. Various example embodiments of the processor are configured to support split programmability of UC resources of the processor by providing a processor including a set of at least two UCs and an ISA, the UC being configured to store micro-operations decoded from instructions of a program to be executed by the processor, the ISA being configured to support programmability of a set of two or more UCs of the processor by a program executed by the processor. Various example embodiments of the processor are configured with processor operation in a non-programmable operating mode (e.g., where the UC resources are non-programmable) and a programmable operating mode (e.g., where the UC resources are programmable), and associated switching of the processor between the two. Various example embodiments of the processor are configured to support split programmability of various other resource types of the processor front end. It will be understood that the advantages or potential advantages of these and various other example embodiments and such processors and associated SP-UCs can be further understood by reference to various drawings, which will be further discussed below.

[0042] Figure 1 An example embodiment of a processor including a partitioned programmable micro-op cache is depicted.

[0043] The processor 100 includes a front end 110, a back end 120, and a memory 130. The front end 110 includes an ISA instruction decoder 111 and an SP-UC 112, which are configured to support the various functions discussed herein. The memory 130 is configured to store program ISA instructions 131 and program data 132 for programs to be executed by the processor 100. By first considering various more general aspects of the processor and the associated processor architecture and microarchitecture, it can be further understood that the processor 100 is a processor that is used to execute programs. Figure 1 The operation of the processor 100.

[0044] In general, processors (such as processor 100) can be based on various architectures and can be configured for various purposes. For example, a common type of processor is a central processing unit (CPU), which is a component in a computer that executes programs. When a CPU is contained on a single chip, it is generally referred to as a microprocessor. A microprocessor can be based on various architectures, generally referred to as ISAs, and can be configured for various purposes, such as general processing, network packet processing, graphics processing, and the like.

[0045] In general, a superscalar processor is a processor that implements a form of parallelization called instruction-level parallelism within a processor core. A single-core processor has only one core, while a multi-core processor has multiple cores. It will be understood that the term "processor core" may be used herein to represent a core in any of these types of processors. Compared to the core in a scalar processor that can execute at most one instruction per clock cycle, the core in a superscalar processor can execute more than one instruction during a clock cycle, usually by dispatching multiple instructions to different execution units on the core at the same time. The processor core executes instructions in an order controlled by the availability of input data and execution units rather than their original order in the program. By doing so, the processor core can avoid being idle while waiting for the previous instruction to complete, and at the same time can process the next instruction that can run immediately and independently. This method of executing instructions (which is called "out-of-order" execution) allows greater throughput than the throughput that is otherwise possible at a given clock rate (e.g., the number of instructions that can be executed in one time unit). It will be understood that most superscalar processors follow out-of-order execution.

[0046] In general, ISA can be considered as a model of a processor and is often referred to as the architecture of a processor. ISA defines the supported data types, memory models and registers and their semantics (such as memory consistency and addressing modes for data operands), instruction sets, and input / output models. Microarchitecture is the way a given ISA is implemented in a processor. Microarchitecture consists of building blocks and electrical circuits to implement the logic required for the building blocks. A given ISA can be implemented using different microarchitectures that can differ in performance, physical size, overhead, power consumption, etc. Therefore, ISA acts as an interface between programs and processors. Programs written for ISA can be executed on different microarchitectures that implement the same ISA. This makes program compatibility between different generations of processors for a specific ISA easy to achieve.

[0047] In general, the instructions supported by the processor can be constructed in various ways. For example, in some processors (such as out-of-order superscalar processors), instructions have variable lengths. Such instructions are capable of performing complex tasks so that a single instruction can be decomposed into multiple simpler tasks. These categories of processors are also called complex instruction set computers (CISC). For example, an instruction may be to add a register to memory, which means "add the value in register R1 to the value in memory location M, and then store the result back in memory location M". The instruction is then decomposed into loading the value from memory M to local register R2, adding the values ​​in R1 and R2 and storing the result in R2, and storing the value in R2 to memory location M. x86 is such an ISA implemented in processors provided by various vendors. The length of x86 instructions can range from 1B to 15B, where the simplest instructions can be encoded using one byte, while instructions involving complex operations can be encoded using multiple bytes.

[0048] In general, CISC processors offer many advantages. For example, CISC processors can provide greater instruction density, which can improve the static size of the program (e.g., the amount of storage used for a given program). This is particularly important for embedded systems because it can account for a large portion of the system overhead and can affect the physical size of the system (which can affect suitability for purpose and manufacturing overhead). For example, CISC processors can also improve the dynamic size of the code (i.e., the instruction set in the program executed by the processor) and reduce the amount of bandwidth used to obtain instructions (from both memory and cache). This can reduce overhead and energy use, and can improve performance. For a given hit rate, a smaller dynamic code size also reduces the size of the cache; a smaller cache can use less energy and less chip area, and can have a lower access latency. For example, in a CISC processor with variable-length instructions, larger constants can be encoded in the instruction. Using the encoded constants, rather than loading constants from the data memory, takes advantage of spatial locality, provides the value to be executed earlier, avoids additional instructions, and removes data cache access. In other words, a wider access is simpler than multiple accesses of the same total size. For example, in CISC processors, it is generally easier to extend the ISA to allow for support for variable length instructions, and additional information can be included by using very long instructions.

[0049] As described above, using variable length instructions of an ISA can provide many advantages. However, the microarchitecture of a processor is generally not capable of executing variable length instructions of an ISA in its native form. At the microarchitecture level of a processor, instructions are represented by simpler micro-operations of fixed length (e.g., often referred to as "micro ops" and abbreviated as "OPs" or "UOPs"). Variable length instructions are decomposed into fixed length sequences of UOPs. UOPs perform basic operations on data stored in one or more registers, including transferring data between registers or between registers and an external bus, and performing arithmetic and logical operations on registers. For example, the previously described instruction to add a register to a memory is decomposed into separate sequences of load, addition, and storage UOPs. Instructions are dynamically decoded into UOPs by the front end of the processor. After being decoded into UOPs, the back end of the processor issues and executes the UOPs. This dynamic decoding also provides a clearer separation of "stable" and "standardized" ISAs (e.g., x86) from the underlying microarchitecture of the processor that can define its own set of UOPs. For example, Haswell and Skylake are two different micro-architectures that Intel supports X86 ISA, but each micro-architecture can define its own native UOP set. These architectures enjoy the dual advantages of a versatile backward compatible CISC front end and a simple, cost-effective back end. In addition, additional indirect levels support seamless optimization of internal UOPs behind the scenes without any changes to the programmer interface. It will be understood that, unless otherwise indicated herein, the term "instruction" refers to the variable length instructions of the ISA supported by the processor (e.g., x86). Note that decoding the instructions of UOPs is not limited to ISAs with only variable length instructions, but is also applicable to ISAs that support fixed length simpler instructions. These categories of processors are referred to as reduced instruction set computers (RISC). Examples of such ISAs include MIPS, ARM, etc.

[0050] In an out-of-order superscalar processor, instructions are usually executed through multiple stages. These stages are called the pipeline of the processor. The first part of the pipeline of the processor is responsible for obtaining instructions from the instruction library (illustratively, obtaining ISA program instructions 131 from the memory 130 of the processor 100). The stage from obtaining instructions to dynamically decoding instructions to form UOPs is called the "front end" of the processor (illustratively, the front end 110 of the processor 100). The remaining stages in the pipeline of the processor (e.g., renaming, execution, and exit), which are processed in units of UOPs provided by the front end, are called the "back end" of the processor (illustratively, the back end 120 of the processor 100). Note that the back end of the out-of-order superscalar processor can execute multiple UOPs per clock cycle, so the effective front end of the out-of-order superscalar processor (e.g., the efficiency of decoding instructions into UOPs and its sufficient supply to the back end with low latency and high bandwidth) can improve the overall performance of the processor.

[0051] Based on the above, the operation of the processor 100 in executing the program is now further described. The front end 110 reads the program ISA instructions of the program from the memory 130 (which is based on the ISA supported by the processor 100). The ISA instruction decoder 111 of the front end 110 receives the program ISA instructions 131, decodes the program ISA instructions 131 to form a set of UOPs, and stores the UOPs in the SP-UC 112. The front end 110 provides the UOPs to the back end 120. The back end 120 receives the UOPs from the front end 110 and executes the UOPs to provide the functions requested by the program ISA instructions 131 of the program to be executed by the processor 100. The ISA of the processor 100 is configured to provide programmable control of the SP-UC resources in the SP-UC 112 of the front end 110, and therefore the UOPs are transferred from the front end 110 to the back end 120 for processing by the back end 120 to provide the functions requested by the program ISA instructions 131 of the program executed by the processor 100.

[0052] It will be appreciated that the operation of the processor 100 based on the use of the ISA of the processor 100 is configured to provide programmable control of the SP-UC resources in the SP-UC 112 of the front end 110 of the processor 100, which can be achieved by referring to Figure 2 be further understood.

[0053] Figure 2 An example embodiment of a processor front end capable of supporting partitioned programmability of processor front end resources is depicted. It will be appreciated that Figure 2 The front end 200 can be used as Figure 1 The front end 110 of the processor 100 .

[0054] Figure 2 The front end 200 includes a level 1 (L1) instruction cache (L1-IC) 210, an instruction fetch unit (IFU) 220, a branch prediction unit (BPU) 230, an instruction length decoder (ILD) 240, an instruction queue (IQ) 250, an instruction decoder (ID) 260, a UOP cache (UC) 270 and an instruction decoder queue (IDQ) 280.

[0055] L1-IC 210 is part of the cache hierarchy of the associated processor and can be further understood by considering the cache hierarchy processor more generally. In general, a cache is a smaller, faster memory, closer to the processor, which stores copies of program data or program instructions from frequently used memory locations to reduce average access overhead (time or energy). Data or program instructions are stored in a cache by blocks of contiguous memory locations, usually referred to as cache lines, where each cache line is indexed in the cache by the first memory address in the cache line. The cache benefits from the temporal and spatial locality of the memory access pattern in the program, where spatial locality refers to the use of relatively close memory locations (i.e., within a cache line), and temporal locality refers to the reuse of a specific cache line within a relatively small duration. Many processors use multi-level caches. For example, common processor architectures can utilize at least three levels (L) of cache, which are usually referred to as L1, L2, and L3. The L1 cache is the smallest and closest to the processor, and is therefore faster than other cache levels. Typically, the L1 cache is divided into two parts: an L1 instruction cache (e.g., 32KB in size, although other sizes may be used) that only stores program instructions and an L1 data cache (e.g., 32KB in size, although other sizes may be used) that only stores program data. The L2 cache (e.g., 256KB in size, although other sizes may be used) and the L3 cache (e.g., 2MB in size, although other sizes may be used) are subsequent levels that are typically unified caches (meaning they store both instructions and program data). The L3 cache is typically common to the processor cores in a multi-core processor and is therefore located outside the processor core. It will be understood that cache size and access latency grow according to level. If the cache line corresponding to the memory address being searched is missing in the L1 cache, the processor searches in the caches of subsequent levels (e.g., L2 cache, then L3 cache, and so on). If the memory address is missing in all available cache levels, the processor may access the main memory to retrieve the instruction or data at the memory address. Therefore, the main memory is accessed only when the memory address is missing in all caches. Once the missing block is located, it is brought into the cache line in the L1 cache.

[0056] The IFU 220 is responsible for feeding the processor with instructions to be executed and is therefore the first component to process instructions. The IFU 220 primarily includes the logic required to calculate the next fetch address and then fetch instructions from the L1-IC 210. Instructions are fetched from the L1-IC 210 by the IFU 220 in the form of a raw byte stream.

[0057] The BPU 230 is configured to predict the next fetch address for the IFU 220 because otherwise branch instructions (including conditional branches, jumps, subroutine calls and subroutine returns, etc.) introduce a significant additional level of complexity in the fetch instruction stream because the correct fetch address cannot be calculated until the branch instruction itself is executed. Generally speaking, there are two parts in this prediction. The first part is to predict the branch direction, i.e., taken or not taken. The second part is to predict the target address of the branch for the predicted direction.

[0058] ILD 240 provides a pre-decoding stage. ILD 240 separates the raw byte stream from IFU 220 into valid instruction sequences and passes them to IQ 250. For example, as described above, the length of x86 instructions can vary between 1B and 15B and can reside in any byte address in the program memory, so it is necessary to separate the raw byte stream into variable-length instructions. Decoding the length of several instructions in each cycle increases the complexity level because the starting address must be determined speculatively. That is, the fact that the starting address of the second instruction is not known before the first instruction is decoded and its length is calculated brings about the serialization of the length decoding process, and parallelizing it requires determining the length of each instruction before decoding it. ILD 240 provides complex logic based on many parallel and speculative calculations to help achieve this parallelization (although this is at the expense of increased power consumption). Note that RISC processors can not use ILD 240 because the length of the instruction is fixed, so the instruction will start at a fixed memory boundary.

[0059] IQ 250 queues instructions for the instruction decode stage. After ILD 240 separates the instructions from the raw byte stream, IQ 250 queues the instructions for use by ID 260 in the instruction decode stage.

[0060] ID 260 provides the instruction decoding stage (which may also be referred to as the dynamic translation stage). In this stage, instructions are read from IQ 205 and translated into subsequent functionally equivalent UOPs. The translation is performed by one of several decoders in a group of decoders 261, which includes a complex decoder 261-C and three simple decoders 261-S1 to 261-S3 (although it will be understood that fewer or more instruction decoders may be used). The ID 260 including the group of decoders 261 may also be referred to as a microinstruction translation engine (MITE). The resulting UOPs are passed to IDQ 280 by ID 260, and then the UOPs may enter the back end of the processor through IDQ 280. For example, in an x86-based processor, a simple instruction may be translated into 1-4 UOPs, and a complex instruction may be translated into 5 or more UOPs. It will be understood that for processors based on other ISAs, instructions may be translated into other numbers of UOPs.

[0061] In general, UC 270 is a UOP cache that is configured to cache UOPs of instructions previously decoded by a MITE, thereby eliminating the need for the MITE to re-decode instructions previously decoded by the MITE to obtain the associated UOP (i.e., avoiding the L1-IC->IFU->ILD->MITE decoding path). This type of cache may be referred to as an L0 instruction cache (L0-IC), which may store instruction blocks decoded into UOPs in units of UC lines. The UOP cache benefits from the temporary locality of control flow in the program, so previously executed instructions are executed again. Before obtaining the instruction address from L1-IC 210, the instruction address is first looked up in the L0-IC. If the corresponding UC line exists in the L0-IC (meaning a hit), the associated UOP is directly provided to IDQ 280 for further execution, thereby completely avoiding the L1-IC->IFU->ILD->MITE decoding path. If the corresponding UC row does not exist in the L0-IC (implying a miss), the instruction will complete the entire complex decode cycle through the L1-IC->IFU->ILD->MITE decode path. The ability to avoid the L1-IC->IFU->ILD->MITE decode path in this way provides a significant advantage because the decoding process from instructions to UOPs (especially for high-performance processors) can be expensive in terms of circuits, power consumption, and time, especially where a single complex instruction may perform several operations. It will be appreciated that since the back end of a superscalar processor may execute several UOPs per clock cycle (e.g., 6 UOPs per cycle), the rate at which UOPs are provided from the front end of the processor to the back end of the processor is a key element of the performance that can be achieved through a high hit rate in UC 270. UC 270 can be implemented within the front end 200 using a single UC (e.g., an embodiment of which is described with reference to FIG. 1 ). Figure 3-16), or may be implemented in the front end 200 as a split programmable UC (SP-UC) including a plurality of UC sets (e.g., its embodiments refer to Figure 17-31 Rendering).

[0062] IDQ 280 queues UOPs to be provided to the processor back end. UOPs queued by IDQ 280 may include UOPs decoded by ID 260 (MITE) and UOPs passed from UC 270.

[0063] As described above, the front end 200 is configured to support split programmability of various resource types of the front end 200, including UC resources of the UC 270. It will be appreciated that by first considering the operation of the front end 200 using a single UC (e.g., as described with reference to Figure 3-16 ), the operation of the front end 200 using the segmented programmability of UC resources can be further understood (e.g., as shown in reference to Figure 17-31 presented).

[0064] Figure 3 An example embodiment of a processor front end capable of supporting split programmability and operating a single micro-op cache is depicted.

[0065] Figure 3 The front end 300 of FIG. 1 includes L1-IC 310, IFU 320, BPU 330, ILD 340, IQ 350, ID 360, UC 370 (which is a single UC and is therefore not split programmable), and IDQ 380. It will be understood that, in general, unless otherwise indicated, Figure 3 The operation of the components of the front end 300 can be respectively Figure 2 The operations of the corresponding components of the front end 200 are similar.

[0066] As described above, front end 300 is configured to support split programmability of various resource types of front end 200, but supports only a single UC (illustratively, UC 370). It will be appreciated that by first considering the operation of L1-IC 310 (as described with reference to Figure 4-5 ), the operation of a single UC 370 (as shown in Figure 6-12 as presented), and based on reference Figure 4-5 The operation of the L1-IC 310 presented and as referenced Figure 6-12 The use of the processor of the single UC 370 operation presented is to support the execution of the program (as shown in reference Figure 13-16 ), the operation of the front end 300 using the segmented programmability of UC resources can be further understood (e.g., as shown in reference to Figure 17-31 presented).

[0067] As this article refers to Figure 4 and Figure 5 Further discussion, the L1-IC of the processor front end (e.g., Figure 3 The micro-architecture of the L1-IC 310 of the front end 300 may have an effect on the UC (e.g., Figure 3 Design considerations of the UC 370 of the front end 300 have some implications.

[0068] In general, the cache that stores program instructions is called an instruction cache (IC), and the address in the instruction memory is called an instruction pointer (IP). The IC stores raw byte blocks from the instruction memory in units of "IC rows". It will be understood that instructions have not yet been decoded when entering the IC, so in general the IC does not understand the instructions. It will also be understood that since instructions can start at any byte position, instructions can be partially stored in an IC row and can therefore also overflow into another IC row. In the IC, an IC row is identified by its IP, which is the IP of the first byte in the stored block. Figure 4 The logical organization of the IC is depicted in Figure 5 The IP division of the IC is depicted in Figure 2.

[0069] like Figure 4 As shown, IC 400 includes two main building blocks: tag array 410 and data array 420. Data array 420 stores IC rows, while tag array 410 is used to match IPs to data array entries. Data array 420 is logically organized into groups of S sets, where each set includes N IC rows. The number of IC rows in a set is called the "associativity" of the IC. It can also be said that a cache with associativity N is an N-way associative cache, where each way is an IC row. A block is first mapped into set Si by its IP, and then placed into any IC row Nj in set Si. In order to map a block into IC 400, as shown in FIG. Figure 5 As shown, IP is divided into three fields.

[0070] like Figure 5 As shown, IP 500 is divided into IP tag (IP-Tag) field 510, IP index (IP-Index) field 520 and IP offset (IP-Offset) field 530. The K least significant bits of IP 500 are used to identify which bytes inside the IC row are to be accessed. This part of the address is called the block offset. Assuming that the size of the IC row is Q bytes, there are K=log2(Q) bits in the offset field. Figure 4 As shown, these K bits are denoted herein as the IP offset (indicated by the IP offset field 530). The next portion of the IP 500 is called the index. As the name indicates, the index is used to identify the set Si in the IC. For an IC consisting of S sets, M = log2 (S) bits are used in the index field. Figure 5As shown, this document represents these M bits as the IP index (indicated by the IP index field 520). The remaining bits of IP 500 are the label field. Figure 5 As shown, these M bits are represented herein as an IP label (indicated by IP label field 510).

[0071] Now refer to Figure 4 and Figure 5 , note that since different IC rows can map to the same set Si in IC 400 (due to the overlapping M bits, they have the same IP index), a mechanism can be used to reversely map the IP index to the IP. Tag array 410 is used for this purpose. Tag array 410 has the same logical organization as data array 420 (same number of sets S and associativity N). For each IC row in data array 420, the corresponding position in tag array 410 holds some metadata: the IP tag bit and the state of the IC row (valid, etc.).

[0072] Refer again Figure 4 and Figure 5 , the lookup of the IP 500 in the IC 400 can be performed as follows. To look up the IP, the set Si in both the data array 420 and the tag array 410 is accessed using the IP index portion; however, in order to know whether the IC row within the set corresponds to a given IP, the IP tag bits generally need to match the entries in the set Si in the tag array 410. If the IP tag bits of the j-th entry in the set Si match, the correct data is in the j-th IC row of the corresponding data array 420 in the set Si (this is called a cache hit). If no IP tag in the set Si matches in the tag array 410, the requested IC row does not reside in the L1-IC (this is a cache miss). In the case of such a cache miss, a request is made to a higher level of the memory hierarchy, and it is necessary to wait for the IC row to be installed in the L1-IC before access can be made. This can be further understood with reference to the following example. That is, consider an 8-way associative cache with 64 sets and a cache line size of 64B. Then, each cache line will hold a 64B instruction block. Here, K=6 and M=6. If the processor attempts to access an instruction at IP 0xf045 (tag = 0x1e, index = 0x1, offset = 0x5), it looks for a cache line with tag 0x1e in set 1. If the IC line is found, the fifth byte in the IC line is retrieved.

[0073] like Figure 5 As shown, access to the tag array 410 and the data array 420 can be performed serially or in parallel. Figure 5In [the above], while accessing the tag array 410, the entire set is read from the data array 420. This address is compared with the IP tag entry to find in which IC row of the set the data being searched for resides. This information is fed to the multiplexer (way multiplexer) at the output of the data array 420, which selects one of the IC rows of the set. Finally, the offset portion of the address is used to extract the appropriate byte from the selected IC row (this process is called data alignment). The number of bits in the IP offset field determines the size of the IC row, i.e., the size of the IC row is log2(number of bits in the IP offset field). The set in the IC is selected based on the IP index, and the IC rows within the set (i.e., the ways in the set) are tagged using the IP tag. In Figure 5 In [the above], the IP offset is 4 bits, the IP index is 4 bits, and the IP tag is 8 bits. Thus, for an exemplary IC row, IP tag = 0xFF and IP index = 0x0. Thus, the IC row is tagged with 0xFF in set 0. Clearly, all the instructions within the IC row share the same IP tag and IP index. This also means that the addresses of all the basic blocks within the IC row (i.e., the instruction sequences excluding control instructions - this will be explained in detail later) share the same IP tag and IP index. When P frequently accessed IC rows map to the same set Si and the cache associativity N is < P, the IC 400 suffers a conflict miss. In this case, one of the valid IC rows in set Si is evicted to accommodate the newer IC row. It will be understood that (1) the higher the associativity, the fewer conflict misses the IC 400 will suffer, and (2) on the other hand, the more ways the IC 400 has, the larger the way multiplexer becomes, and this may affect the cycle time of the processor. Note that some L1-ICs can be organized as 64 sets × 8 ways × 64B per IC row, resulting in a maximum capacity of 32KB of instructions (although it will be understood that other arrangements can be used, other capacities can be supported, etc.).

[0074] As referred to herein Figure 6-12 and further discussed, by first considering the operation of the front end that uses only a single UC and the associated microarchitecture of such a UC (e.g., Figure 3 the UC 370), the split programmability of the UC resources (e.g., as presented with reference to Figure 17-31 ) can be further understood.

[0075] Referring again to Figure 2 and Figure 3 , it will be understood that Figure 2 the front end 200 of Figure 3 and Figure 6-9 the front end 300 of

[0076] are configured to support a streaming operation mode that supports obtaining UOPs from the UC, as presented herein and further discussed below Figure 6-9 in

[0076] Figure 6 An example embodiment of a micro-op cache employing an N-way associative cache is depicted.

[0077] exist Figure 6 In , UC 600 includes UC tag array 610 and UC data array 620. The set in UC tag array 610 consists of N-way UC-tags. The set in UC data array 620 consists of N-way UC rows. The UC tag consists of a tuple {IP tag, IP offset} of the first instruction stored in the corresponding UC row and auxiliary data. Figure 6 These are labeled in the UC tag entry as "tag", "off" and "aux" (auxiliary data). The input to UC 600 is the IP for which the UC row search is being performed, and if there is a hit, the output is that UC row.

[0078] exist Figure 6 In the UC 600, the UC tag array 610 and the UC data array 620 are accessed serially. The UC lookup can perform the UC tag lookup in the first cycle. Even if the UC tag match record hits, the UC data acquisition may be delayed to a later clock cycle. This UC design ensures that the UC data is only read from one way that causes the UC tag match; the other ways in the UC data array will be completely disabled. Further energy saving is achieved by disabling non-matching ways from outputting data. Figure 6 As shown, serialization of access to the UC-tag array 610 and the UC data array 620 is achieved through the use of delay elements. The delay elements can be single-cycle delay elements or multi-cycle delay elements (e.g., a cascaded series of latches that provide a delay path). Depending on the application in which the delay elements are to be used, the delay elements can be adjusted to a longer or shorter delay. For simplicity, the UC 500 is presented herein as employing a single-cycle delay element on the access path between the UC tag array 610 and the UC data array 620 (which means that a UC lookup requires two cycles); however, it will be understood that multi-cycle delay elements can be used on the access path between the UC tag array 610 and the UC data array 620. Figure 6 In the example, for simplicity, the logic and interconnection are only extended for Way 0. It will be understood that similar logic also applies to the other ways (ie, Way 1 to Way N-1).

[0079] exist Figure 6 In the UC 600 of the embodiment of the present invention, the UC lookup may perform a UC tag lookup in a first cycle, and if there is a hit in the first cycle, a UC data fetch may be performed in a second cycle. As discussed further below, these operations may be further understood by considering an example embodiment of the UC 600 in conjunction with an IC of a processor front end configured to operate in a streaming mode, such as Figure 7 As shown. It will be understood that Figure 7 can be considered as Figure 6 An extended view of the front-end where related components and UC are abstracted away. More specifically, Figure 7 The front end 700 illustrates specific functions performed in the context of a first cycle (eg, processing hit / miss outputs from the UC 600 , etc.) and a second cycle (eg, processing UC data outputs, etc.) of a UC lookup at the UC 600 .

[0080] exist Figure 6 In UC 600, each set in the UC contains a number of UC rows (as the number of ways, i.e., Way 0 ... Way N-1), and each UC row contains a fixed number of UOP slots. Some slots contain active UOPs, while other slots may remain empty. Figure 8 An example embodiment of a structure configured for use in a UC row in UC 600 having four UOP slots configured to store UOPs is presented in FIG. Figure 8 UC row 800 shows that at most four consecutive UOPs can be stored in UC row 800. As an example, if the size of a UOP is 4B, the size of a UC row is 32B, and thus the bandwidth obtained from a UC hit is 4 UOPs per clock cycle.

[0081] exist Figure 6 In the UC 600 of , UC 600 stores "basic blocks" of instructions pre-decoded as UOPs. A "basic block" is a sequence of instructions within an IC line that is fetched by the processor during a certain program control flow. A basic block terminates when a control instruction (such as a conditional branch or an unconditional branch) changes the execution sequence. In this article, the term basic block sometimes refers to a basic instruction block in an IC line, and sometimes refers to a sequence of UOPs derived from such an instruction sequence. The intention will be clear from the context. Fig. 9 An example embodiment of the structure of a basic block is presented in , which is located within an IC row that can be mapped into UC 600 based on the IP of the first instruction of the block. For clarity, the size of IC row 900 is depicted as 16B; however, it will be understood that IC rows can be smaller or larger (e.g., 64B or larger). Fig. 9In the example, IC line 900 contains instructions in the memory address range 0xFF00-0xFF0F. Here, it is assumed that in a certain program control flow, the fetch unit jumps to address 0xFF03 and fetches instructions I1, I2, I3, and I4 of length 2B, 3B, 1B, and 2B, respectively. Note that I4 is a conditional branch instruction (JE = jump when equal), and it is assumed that the branch predictor (BPU) predicts a jump after I4. Then, after fetching I4, the fetch unit jumps to the target memory address indicated by I4. In this case, the memory address range 0xFF03-0xFF0A containing instructions I1-I4 constitutes a basic block, which is decoded and stored in UC. According to the IP of the first instruction in the block (i.e. Fig. 9 0xFF03 in 0xFF04) to map the basic block into the UC. The UC uses the same three-part structure of the IP (e.g., as used for Figure 5 The IC in the UC is used to store basic blocks. The UOPs generated from a basic block can span one or more UC lines, depending on the number of UOPs generated thereby. Access to the UC is accomplished using the IP of the first instruction stored in the UC line. The set in the UC of a basic block is selected based on the IP index, so all UC lines of a basic block are stored in different ways within the same set. Such UC lines will carry the same IP tag, so in order to distinguish UC lines, the IP offset of the first instruction in the UC line is also stored as the tag of the UC line. In this regard, the tag in the UC is a tuple {IP tag, IP offset}, which is slightly different from the tag in the IC (which only stores the IP tag). The tag is stored in the corresponding entry in the UC tag array. In addition, each UC line stores auxiliary data, which contains the number of valid UOPs stored in the UC line and the total length of the ISA instruction that initiates the UOP in the UC line. This auxiliary data is stored with the UC tag array and is accessed during UC lookup.

[0082] Refer again Figure 6 and Figure 7 , the IP lookup can be performed as follows (where Figure 6 and Figure 7 The various inputs and outputs along the signal flow are labeled inside.

[0083] The lookup of the IP may consist of various steps performed in one or two cycles. In the first cycle (which may be denoted as cycle 1), a UC tag lookup is performed (as discussed in steps 1-8 below), a calculation of the next IP for the UC is performed (as discussed in steps 9-11 below), and a L1-IC lookup is performed (as discussed in step 12 below). In the second cycle (which may be denoted as cycle 2), which is performed only if there is a hit in the UC tag array in the first cycle, a UC data fetch is performed (as discussed in steps 13-17 below), and the next UC tag lookup is performed (as discussed in steps 18-19 below). It will be appreciated that these steps describe a cross-over operation. Figure 6 The signal flow of the UC 600.

[0084] In cycle 1 of the IP lookup, the UC label lookup may be performed as follows (as discussed in steps 1-8 below):

[0085] 1. The IP index (A) from the input IP is sent to the address decoder in the UC tag array (A.1).

[0086] 2. The address decoder in the UC tag array selects / activates the set indexed by the IP index. As a result, each way in the set sends out its stored {tag, offset, auxiliary data} (B).

[0087] 3. For each road in the UC tag array, the following operations are performed.

[0088] 3.1.First compare the "label" (C.2) with the input IP label (C.1). If they match, the result is 1, otherwise 0.

[0089] 3.2. The output from step 3.1 is fed to a selector (C.3) of two three-state logic gates that control the inputs from IP offset and "off" respectively. If the input to the selector is 1, the three-state logic gate will allow its input to switch to output, otherwise it blocks the output. Therefore, if the IP tag does not match "tag" in step 3.1, then the selector will block further outputs of IP offset and "off" respectively, otherwise it will allow these outputs.

[0090] 3.3. Compare the IP offset and the "off" output (C.4) from the tri-state gate. If they match, the result (C.6) is 1, otherwise the result is 0.

[0091] 3.4. Send "aux" to the N-way multiplexer (C.5).

[0092] 3.5. The results (C.6) from step 3.3 for each path are sent to the following:

[0093] 3.5.1. As input to the OR gate that produces the final hit / miss output from UC(D) (C.6.1).

[0094] 3.5.2. As input to Delay Element 2 (C.6.2). In the next cycle, if the way is a hit, Delay Element 2 generates the necessary signals to retrieve the way from the UC data array.

[0095] 3.5.3. As a selector (C.6.3) to the N-way multiplexer (mentioned in step 3.4), if this way is a hit, the selector selects the "aux" input (C.5).

[0096] 4. The signals C.6.1 from each way are logically ORed together to generate the final hit / miss output (D) from the UC. If there is a hit, at least one way sends signal C.6.1 as 1.

[0097] 5. Based on the selector input C.6.3 from each way, the N-way multiplexer will select one "aux" way (C.5) as output. If there is a hit, at least one way will send the input as 1 in C.6.3, and the way multiplexer will select the corresponding "aux" row as output (F).

[0098] 6. The IP index (A) from the input IP is also sent to the tri-state logic gate (A.2). At the end of the cycle, the hit / miss output (D) from the UC is fed to this tri-state logic gate as the selector input (D.1). Therefore, if there is a hit in this cycle, the tri-state logic gate allows the IP index as the input of delay element 1. In the next cycle, delay element-1 sends the IP index to the address decoder in the UC-data array.

[0099] 7. The hit / miss output (D) from the UC is sent to the IFU (D.1), ILD (D.2), IQ (D.3), and MITE (D.4), which disable the corresponding units if there is a hit. This step is as follows Figure 7 shown.

[0100] 8. The hit / miss output (D) from the UC is sent to the delay element (D.5). In the next cycle, this row acts as the selector input to the 2-to-1 multiplexer that selects between the decode path and the UC to send the UOP to the IDQ. This step is shown in Figure 7 shown.

[0101] In cycle-1 of IP lookup, the calculation of the Next-IP for the SP-UC (as discussed in steps 9-11 below) may be performed as follows:

[0102] 9. The IP is also sent in parallel as input (G.1) to the branch predictor (BPU) to check if the execution sequence is to branch after this IP if it is a hit in the UC, i.e., the UC row for this IP contains the control / branch instruction predicted to be taken. At the end of this cycle, the BPU generates two signals - Hit / Miss (H), which generates 1 if it is a hit and 0 if it is a miss, and generates the next IP (I.1) if it is a hit. This step is as follows: Figure 7 shown.

[0103] 10. If the BPU misses, the IP is also sent in parallel as an input (G.2) to the adder to calculate the next IP. In this case, the next IP will be the IP of the next UC row in the sequence. At the end of this cycle, if the UC is a hit for the current IP, the ByteLen (byte length) from the "aux" output (F) is fed to the adder as another input (F.1). The adder then generates the next IP to be looked up in the UC (I.2). This step is as follows Figure 7 shown.

[0104] 11. Signals I.1 and I.2 are inputs to a 2-to-1 multiplexer with a selector input (H) for the hit / miss line from the BPU. If the BPU indicates a hit, I.1 (i.e., the next IP from the branch) is generated as output (I) from the multiplexer, otherwise I.2 (i.e., the next IP in the sequence) is generated as output (I). This step is as follows: Figure 6 shown.

[0105] In cycle-1 of IP lookup, L1-IC lookup may be performed as follows (as discussed in step 12 below):

[0106] 12. The IP is also sent in parallel to the L1-IC (G.3) for looking up instructions starting from this IP, so that if the lookup in the UC-tag array results in a miss, the instruction is fed from the L1-IC. This step is as follows Figure 7 shown.

[0107] In cycle-2 of IP lookup, UC-data acquisition (as discussed in steps 13-17 below) may be performed as follows:

[0108] 13. Delay Element-1 sends the IP Index to the Address Decoder in the UC-Data Array (A.3). The Address Decoder selects the Set(s) in the UC-Data Array mapped by the IP Index.

[0109] 14. Delay element-2 (C.6.2) on each path sends the input to:

[0110] 14.1.UC - The corresponding path row in the data array (W).

[0111] 14.2. As a selector to the N-way multiplexer, the multiplexer selects a UC-data row from the UC-data array based on the selector.

[0112] 15. In step 14.1, only the hit way will send W as 1. This will activate only that way in the UC-Data array. Therefore, starting from steps 10-11, the UC-Data array will only send out UC-Data (J) from the hit way in set S.

[0113] 16. In step 14.2, only the hit way will send the selector as 1. Therefore, the N-way multiplexer outputs the UC-data from step 12 as the final output (E) from UC.

[0114] 17. The UC-data (E) output from step 16 is sent as input (E.1) to the 2-to-1 multiplexer that selects between the UC and decoding paths. Since there is a hit, the selector (D.6) to the multiplexer is set to 1, which outputs the UC-data to the IDQ. This step is as follows Figure 7 shown.

[0115] In cycle-2 of IP lookup, the next UC-label lookup (as discussed in steps 18-19 below) may be performed as follows:

[0116] 18. Since there was a hit in the UC-Tag lookup in the previous cycle, the 'enable' line input (en) to the IP is set, which updates the IP with the input (I) received from step 11. This step is as follows Figure 7 shown.

[0117] 19. Repeat steps 1-12 for the new IP.

[0118] It will be understood that the foregoing step numbers are provided for clarity of description of example embodiments and do not necessarily imply an order in which the steps may be performed (e.g., at least some steps may be performed in a different order, at least some steps may be performed simultaneously, etc., as well as various combinations thereof).

[0119] It will be appreciated that the lookup of the IP may consist of various other steps performed in various other cycles.

[0120] Refer again Figure 2 and Figure 3 , will understand, Figure 2 The front end 200 and Figure 3The front end 300 is configured to support a build-to-operate mode that supports fetching and decoding instructions through the path L1-IC->IFU->ILD->IQ->MITE and storing them in parallel to the UC to provide to the IDQ, as discussed further below in this document Figure 10-12 As presented in .

[0121] It will be appreciated that when moving between flow-mode and build-mode, the mode switch occurs in the front end (e.g. Figure 2 Front-end 200 or Figure 3 For example, when the front end is in flow-mode and the UC-tag lookup results in a miss, the front end will switch to build-mode.

[0122] Refer again Figure 6 ,exist Figure 6 In the UC 600 of the embodiment, the UC lookup may perform a UC-tag lookup in the first cycle, and if there is a miss in the first cycle, the instruction fetch and decode may be performed through the path L1-IC->IFU->ILD->IQ->MITE, and they may be stored in parallel to the UC to be provided to the IDQ. As discussed further below, these operations may be further understood by considering an example embodiment of the UC 600 in conjunction with an IC of a processor front end configured to operate in build-mode, such as Fig.10 As shown. It will be understood that Fig.10 can be considered as Figure 6 , which only shows the components and signal flows used in build-mode. More specifically, Fig.10 The front end 1000 of FIG. 1 shows the specific functions performed by the block builder, which is configured to observe the decoded UOP output from the MITE and build a UC line for storage in the UC. In this way, if the control flow of the program returns to an IP that caused a UC miss, that IP will instead cause a hit. The process, which can be a single cycle or a multi-cycle process, includes the following steps described below (it will be understood that it describes a cross- Fig.10 signal flow at the front end).

[0123] 1. When the UOP decoded from the MITE is provided to the backend (K.1), the UOP is also sent in parallel to the UC fill buffer in the block builder (K.2).

[0124] 2. In the block builder, UOPs from consecutive instructions are packed together to fill a UC line. After a UC line is built (L), it is ready to be stored in the UC.

[0125] 3. Send {IP, ByteLen} of the UC row to the IP update logic (L.1). The IP update logic reads the IP register (M) to check if the IP (L.1) of the UC row is the same as the IP from M, which is the IP that missed earlier in the UC. If not, the UC row is discarded.

[0126] 4. The UE row is now stored in the UC (L.2).

[0127] 5. While the UC rows are being stored in parallel in the UC (L.2), the IP Update Logic sends the Byte Len (byte length) (N) of the UC row to calculate the next IP in the sequence. The signal N is sent as input to the 2-to-1 multiplexer, which takes the other input from the Byte Len from the "aux" output (F) of the UC. The selector of the multiplexer is the hit / miss (D) output from the UC. In build-mode, D sends a miss, so the multiplexer connects the signal from M as output (F.1).

[0128] 6. The rest of the signal flow for updating the next IP (using BPU and signal F.1) is the same as described for stream-mode.

[0129] It will be understood that the foregoing step numbers are provided for clarity of description of example embodiments and do not necessarily imply an order in which the steps may be performed (e.g., at least some steps may be performed in a different order, at least some steps may be performed simultaneously, etc., as well as various combinations thereof).

[0130] Note that in build-mode, the five pipeline stages through L1-IC->IFU->ILD->IQ->MITE are very expensive in terms of circuitry and processing, and take at least 6 times the cycle time of stream-mode. Therefore, a miss in the UC increases the number of cycles required to complete instruction execution. These five pipeline stages in the front end are extremely power hungry and consume about 28% of the processor power. For example, if a UC row consists of 6 UOP slots, and if the UC hits, the UC can provide 6 UOPs / cycle to the back end; however, if the UC misses, the build mode can provide no more than 4 UOPs / cycle, which will reduce the UOP supply to the back end by at least 33%.

[0131] Fig.11 An example embodiment of a UC row structure is depicted, wherein a UOP slot is configured to store a UOP configured for Fig.10 More specifically, Fig.11 An example of an IC row to UC row mapping 1100 is depicted, which maps basic blocks from IC rows (e.g., Figure 8The presented IC lines are mapped to UC lines. In this example, the UC lines are described as consisting of 4 UOP slots.

[0132] In Fig.11 's example, five different instructions with variable instruction lengths from the same IC line are translated into UOPs. The resulting UOPs are stored in several UC lines in the UC set corresponding to the IP index. Each instruction and its UOP are marked with the same gray-level color.

[0133] In Fig.11 's example, there are two basic blocks in the same IC line: (1) BB_1 consisting of instructions I1 - I4 (I4 is a JE, conditional branch instruction) and (2) BB_2 consisting of a single RET instruction. BB_1 spans two UC lines labeled UCL1 and UCL2. The last UOP slot in UCL1 remains empty because the next sequence of instructions (I3) requires 3 UOPs and cannot fit entirely in the first line. The last line (UCL3) ending the basic block has only 3 UOPs, leaving the last UOP slot empty.

[0134] As Fig.11 's example shows, UC lines are not always fully utilized. There may be several empty slots in the last UC line of a basic block. Additionally, the policy of forcing all UOPs of the same instruction to share the same UC line may also leave empty UOP slots in other UC lines (e.g., UCL1 in the example). Moreover, the UC may suffer from a certain level of duplication (e.g., this may occur when the control flow leads to an instruction already in the UC but not as the first instruction in its UC line). In any case, this UC design approach attempts to (1) map basic instruction blocks to UC lines with maximum line utilization and (2) store enough UOPs in each line to ensure sufficient bandwidth. These goals may conflict because intuitively, goal (1) would push for shorter lines while goal (2) would push for longer lines.

[0135] As Figure 6 's example shows, when P frequently accessed cache blocks are mapped to the same cache set and the cache associativity N < P, the UC (like the Figure 4 IC) may suffer from conflict misses. In this case, one of the valid UC lines is evicted to accommodate a newer basic block. In this regard, it will be understood that the higher the associativity of the sets in the UC, the fewer conflict misses the UC lines will suffer. On the other hand, the more ways the set has, the larger the way multiplexer becomes, which may affect the processor's cycle time.

[0136] Fig.12An example embodiment depicting the difference between L1-IC and UC on fields within an IP, where the IP is the first instruction of a basic block from the L1-IC that is mapped to Fig.10 More specifically, Fig.12 IP 1200 shows that the number of sets of L1-C can be twice the number of sets in a single UC, so the UC discounts one bit from the IP index to select the corresponding set in the UC, and also overflows the discounted bit into the IP label.

[0137] As this article refers to Figure 13-16 As further discussed, the partitioning programmability of UC resources (e.g., as described in reference Figure 17-31 ) can be further understood by first considering the use of a processor, based on reference to Figure 4-5 The operation of the L1-IC 310 presented and the operation of the front end using only a single UC and as referenced Figure 6-12 The UC presented (e.g. Figure 3 UC 370) associated micro-architecture to support program execution (as referenced Figure 13-16 presented).

[0138] In general, there are two structural components of a program: (1) subroutines and (2) branches, which change the execution sequence of its instructions. A subroutine is a sequence of program instructions that performs a specific task, packaged as a unit. This unit can then be used in any program that should perform that task. A subroutine behaves in much the same way as a program used as a step in a larger program or another subroutine. Note that these components are better understood when described within the context of a specific processor architecture such as the x86. During one execution of a program, a subroutine can be called (e.g., via a call (CALL) instruction in x86) multiple times and from several locations, including from other subroutines, and then once the task that the subroutine is performing is completed, it branches back (e.g., via a RET instruction in x86) to the next instruction after the CALL. Subroutines use a call stack, which is a stack data structure in memory that stores information about the active subroutines of a computer program. In x86, each CALL instruction pushes a stack frame onto the call stack. The stack frame has multiple uses, such as passing parameters to subroutines, local variables used by subroutines, etc., but its main purpose is to track the point to which each active subroutine should return control when it executes RET. For this reason, the address (return address) following the CALL instruction is pushed into the stack frame together with each CALL. Therefore, the RET instruction reads the return address in the latest stack frame stored in the call stack, pops up the stack frame, and transfers control to the address. Note that the transfer of control to the return address generally occurs during the instruction acquisition in the front end, which occurs before the back end executes the RET instruction, i.e., when the return address is read from the stack frame in the memory. Therefore, the return address for the call stack is often reserved in the register of the processor, which is called "return address stack" (RAS). Some processors also keep the address of the RET instruction in the BPU (branch predictor) and use their respective return addresses as prediction targets. For simplicity, the term RAS can be used in this article to refer to any hardware-assisted method for the front end to transfer control to the return address. Fig.13 An example of such a program is presented in .

[0139] Fig.13 An exemplary embodiment of a program for illustrating structural components of the program, such as subroutines and branches, is depicted.

[0140] The program 1300 is a program to be executed by a processor. As described above, the program 1300 includes structural components, subroutines, and branches.

[0141] The processor executes the instructions in MAIN (main program) sequentially until the instruction CALL sub1. The CALL instruction transfers control to the subroutine specified with CALL (which is in Fig.13sub1 in MAIN). The instructions in sub1 are then executed. While sub1 is executing, it also calls subroutine sub2 in the instruction CALL sub2. This is an example of nested subroutine calls, i.e. MAIN->sub1->sub2. Finally, after the instructions in sub1 are completed, the processor executes a RET instruction to return to the next instruction in MAIN after CALL sub1.

[0142] Within a program (e.g., MAIN) or a subroutine (e.g., Sub1 or Sub2), the sequential execution of instructions can be interrupted by a branch instruction. A branch may cause the processor to begin executing a different sequence of instructions within the current subroutine, deviating from its default behavior of executing instructions sequentially. A branch instruction can be either (1) a conditional branch (e.g., the JE / Jump-if-Equity instruction in x86), which may or may not result in a branch depending on whether the condition is true or false, or (2) an unconditional branch that will result in a branch (e.g., JUMP in x86). Fig.13 In the MAIN program, JE j1 is a conditional branch instruction. JE j1 conditionally switches execution to the code sequence starting at label j1. The label used in this example is a mnemonic for the memory address of the first instruction of a particular code sequence. After executing the sequence in j1, it uses an unconditional JUMP instruction to merge back to a point m1 in the original instruction sequence that called JE j1. While the instruction sequence of j1 is executing, it encounters another conditional branch instruction JE j2. The same process applies to JE j2, which conditionally switches execution to the code sequence starting at label j2. This is an example of nested branches. Similarly, a conditional branch JE j3 is included within the subroutine sub1.

[0143] It will be appreciated that for the purpose of clearly describing various embodiments in which a processor is configured to support the execution of program instructions, the following terminology may be used herein. Instructions that switch or interrupt the sequential execution of instructions are referred to herein as "control instructions" (e.g., in x86, such as Fig.13 In the example of , instructions such as CALL, RET, JE, JUMP, etc. are control instructions). The target instruction sequence of control instructions is referred to herein as a "control block" (e.g., in x86, such as Fig.13 In the example, sub1, sub2, j1, m1, j2, m2, j3, m3 are control blocks), and thus, the execution order of instructions in a program is a specific chain of control blocks, where a control block may include nested control blocks. The execution order of control blocks in a program is referred to herein as "control flow" (i.e., the flow of control), and it will be understood that conditional branches (e.g., in x86, such as Fig.13In the example of JE), multiple control flows can be generated in the program. Since each such branch is a fork, execution can go either way on the fork based on the conditions of the fork. The term "working set" is used to refer to the set of control blocks across "a certain control flow set" in the program. Note that from the perspective of L1-IC or UC, the working set is the corresponding cache line in the working set. By referring to Fig.14 , you can further understand the working set.

[0144] Fig.14 An example embodiment of a program memory is depicted, implemented as a two-dimensional region in memory that is partitioned into units of cache lines of a particular cache to illustrate a working set of cache lines for a particular set of control flows of a program. Fig.14 In the program memory 1400 of FIG. 1 , the working sets for specific control flow sets in the program are marked with "W". During the execution of these control flows, only the marked cache lines are brought into the cache, and the remaining cache lines are not accessed. If the program has no control flow (which is usually very rare), the size of the program is equal to the size of the working set.

[0145] Thus, across control flow, the processor jumps between control blocks starting from arbitrary addresses in program memory, which has an impact on the hit rate L1-IC and UC. The hit rate on L1-IC and UC affects the performance and power efficiency of the program. The hit rate in these caches is affected by the following three types of misses that can occur in set associative cache microarchitectures (e.g., such as Figure 4 In the presented set associative cache microarchitecture): (1) force miss, (2) capacity miss, and (3) conflict miss, each of which is discussed further below.

[0146] A forced miss is a miss the first time a cache line is accessed, because the cache line generally needs to be brought into cache. This is also called a cold start miss or a first reference miss. A forced miss is unavoidable, and since it is a one-time miss, it does not affect the ongoing performance of the program.

[0147] A conflict miss occurs when the number of cache lines P competing for a set is greater than the number of ways N in the set. This means that P cache lines carry the same IP index value, which is used to map to the specified set. Therefore, in order to accommodate the new cache line, one or more existing cache lines may be evicted from the set. The term "thrashing" may be used herein to refer to the eviction of cache lines due to conflicts in a set.

[0148] A capacity miss occurs when a cache line is evicted from the cache because the cache cannot contain all the cache lines needed by the program (for example, in cases where the size of the program is much larger than the total capacity of the cache). To eliminate capacity misses in a set-associative cache, the size of the program generally needs to be less than or equal to the size of the cache. This also means that if the size of the working set is smaller than the size of the program (for example, Fig.14 ), the cache is underutilized, which is the least likely case (since it is very rare to have a program with no control flow). Note that in this case, there are no conflict misses either.

[0149] If the size of the program is larger than the capacity of the cache, it is more likely to hit a conflict miss due to its control flow before hitting a capacity miss, because control flow increases the probability that P control blocks share the same IP index. Therefore, in a set-associative cache, the hit rate of the working set is mainly driven by the conflict miss rate.

[0150] In general, there are two categories of very high performance programs (applications) that generally experience no conflict misses in L1-C or tolerable conflict misses in L1-C. The data accessed by these programs fits in L1-DC (i.e., L1-data cache) because the data is efficiently packed, so no capacity or conflict misses will occur in L1-DC. Therefore, the performance of these programs generally depends on the peak performance of the much smaller UC. The two categories of programs are defined as follows: (1) Class A programs are programs that fit completely in L1-IC, so that there are no capacity or conflict misses in L1-IC, but are larger than the capacity of UC; and (2) Class B programs are programs that are larger than L1-C and therefore experience conflict misses in L1-C.

[0151] The performance of these high-performance programs depends on the continuous provision of the largest portion of the working set from the UC (e.g., ideal UC utilization % = (((UC capacity) / (working set size)) x 100)%. However, more realistically, the effective UC utilization is much lower than the ideal UC utilization due to the conflict misses caused by its control flow in the UC. For example, if the size of the working set is equal to the capacity of the UC, the ideal UC utilization should be 100%, but in the worst case of conflict misses, the effective utilization is 20%. The proof of the severity of conflict misses in a single UC microarchitecture can be understood as follows. The size of the UC is generally much smaller than that of the L1-IC to achieve minimal access latency and lower power consumption. For example, the UC can be organized as 32 sets per UC row × 8 ways × 6 UOPs, with a total maximum capacity of 1536 UOPs, where the size of each UOP is 4B (i.e., the total size of the UC is 6KB). For example, the L1-IC can be organized as 64 sets per IC row x 8 ways x 6 UOPs. 64B, the total maximum instruction capacity is 32KB. In this example, although each set of L1-IC and UC has the same number of ways, the number of sets of L1-IC is twice that of UC. Therefore, each time a 32B boundary is crossed in an IC row, a new UC row will be started, that is, at least one new UC row is used for every 1 / 2 IC row. In addition, Figure 7 In the IC-to-UC mapping example presented in , the 9B instruction from the IC line is mapped to 3 UC lines, where each UC line can accommodate up to 4 UOPs. Therefore, in this example, for a UC line that accommodates up to 6 UOPs, the 9B instruction will use 2.5 UC lines. In addition, it can be inferred that the 32B alignment block on the IC line will be mapped to 2.5×32 / 9=8.88~8 UC lines, which is almost the entire set in the UC. Therefore, the 64B IC line will be mapped to 16 UC lines, so in this example, the UC has a 16 times higher conflict miss probability than in the L1-IC.

[0152] As described above, ultra-high performance applications of class A or class B may be used in a variety of contexts. For example, one such ultra-high performance application of class A or class B is network packet processing by a processor implementing the forwarding plane of a network function virtualization (NFV) router. The NFV router function may be implemented in a general-purpose CISC server processor such as an x86. A simplified structure of such a network packet processing program is shown in Fig.15 Presented in.

[0153] Fig.15 An example embodiment of a simplified structure of a network packet processing program configured for execution by a processor is depicted.

[0154] The network packet processing program 1500 (referred to herein as the NET_PROC program) can be executed by a processor for supporting packet processing. The processor repeatedly executes the NET_PROC program for each incoming packet. The NET_PROC program receives the incoming packet on the input port, processes the packet, and then sends the packet out on the output port. Within the NET_PROC, the packet is processed by a subroutine chain that includes two top-level subroutines associated with the packet inlet (represented as ING 1510) and the packet outlet (represented as EGR1520).

[0155] The ING 1510 subroutine can be configured to perform packet incoming functions, such as decapsulation of packets, classification of packets based on various headers on the packets, determination of next hop forwarding context based on the classification of the packets, performance of a forwarding table lookup associated with the corresponding forwarding context, and setting associated input parameters for the EGR 1520, and the like, and various combinations thereof.

[0156] The EGR 1520 subroutine can be configured to perform packet egress functions, such as identifying a packet forwarding context based on input parameters from ING 1410, performing a table lookup associated with the forwarding context, adding or modifying appropriate encapsulation on the forwarding context, sending the packet to an appropriate output port, and the like, and various combinations thereof.

[0157] Fig.16 Describes the process used to perform Fig.15 The structure of the control flow of the network packet processing program.

[0158] like Fig.16 As shown in the control flow structure 1600, the processor sequentially executes the instructions in NET_PROC until the instruction CALL ING. The CALL ING instruction interrupts the NET_PROC flow by passing control to the subroutine specified after CALL (i.e., ING). The instructions in ING are then executed. After completing the execution of the instructions in ING, the processor executes the RET instruction to return to the next instruction after the CALL ING instruction in NET_PROC. The processor then sequentially executes the instructions in NET_PROC until the instruction CALL EGR. The CALL EGR instruction interrupts the NET_PROC flow by passing control to the subroutine specified after CALL (i.e., EGR). The instructions in EGR are then executed. After completing the execution of the instructions in EGR, the processor executes the RET instruction to return to the next instruction after the CALL EGR instruction in NET_PROC. The processor repeats the above process for each incoming packet.

[0159] like Fig.16As shown, within NET_PROC, ING, and EGR, the sequential execution of instructions can be interrupted by branch instructions. Within ING, the processor executes instructions sequentially until it hits the JE ipv6_1 instruction. If the packet is an IPv6 packet, this JE instruction switches the execution sequence to a control block marked as ipv6_1. After executing the sequence in the ipv6_1 control block, it uses a JUMP instruction to merge back to the main instruction sequence at the instruction marked as ipv6_m_1. The sequence is executed until it hits the JE mpls instruction. If the packet is an MPLS packet, the JE instruction switches the execution to a control block marked as mpls. After executing the sequence in the mpls control block, it uses a JUMP instruction to merge back to the main instruction sequence at the instruction marked as mpls_m. The sequence is executed until the JE ipv6_2 instruction. If the packet is an IPv6 packet, the JE instruction switches the execution sequence to a control block marked as ipv6_2. After executing the sequence in the ipv6_2 control block, it uses a JUMP instruction to merge back into the main instruction sequence at the instruction labeled ipv6_m_2. It will be appreciated that although Fig.16 Only two top-level conditional branches in ING for handling IPv6 packets are described (for clarity), but there may be multiple such branches for the same condition (e.g., IPv6, MPLS, etc.), and further, there may be nested branches within the top-level conditional branches. It will also be understood that similar control flows may also exist within EGR (again, for clarity, from Fig.16 omitted).

[0160] Note that the above control flow pattern in NET_PROC may lead to severe conflict misses in UC. For example, in Fig.16In Figure 1, to process the incoming packet, the instructions in NET_PROC start at IP=3ffe:10:20 (read in the format of IP label:IP index:IP offset). The instructions in NET_PROC are fetched, decoded, stored in the UC, and executed sequentially until CALLING. So far, the subset of instructions in NET_PROC that share the same IP index 0x10 are stored in set 0x10 in the UC. CALL ING switches the instruction sequence to ING starting at IP=6abb:10:0a, which carries the same IP index 0x10. The instructions in ING are fetched, decoded, and stored in the same set of UCs that also store the instructions from NET_PROC. In order to store the instructions of ING, some or all UC lines occupied by instructions from NET_PROC may be evicted due to the unavailability of free UC lines in the set. For example, assume that the packet type is IPv6. Then, within ING, the JE ipv6_1 instruction switches the instruction sequence to control block ipv6_1 starting at IP=14ab:10:3e. The instructions in control block ipv6_1 are fetched, decoded, and stored in the same UC sets that have been occupied so far by the instructions in ING. Some or all UC lines in those sets may be evicted in order to store the instructions in the ipv6_1 control block. After executing the sequence in the ipv6_1 control block, the JUMP instruction merges back to execution at the instruction marked as ipv6_m_1 (which is at IP=72a1:10:0x31). Therefore, subsequent instructions are stored in the same UC set that also stores instructions in the ipv6_1 control block. In order to store the instructions of ipv6_m1, some or all UC lines in the common set occupied by instructions from ipv6_1 may be evicted. Similar thrashing behavior can be observed when the control flow of this IPv6 packet jumps back and forth between control blocks ipv6_2 and ipv6_m2. Subsequently, when NET_PROC calls EGR, the same thrashing pattern may occur in UC.

[0161] In view of the above, it will be appreciated that most of the instructions in the control blocks NET_PROC, ING, EGR, ipv6_1, ipv6_m1, ipv6_2, ipv6_m2, mpls, mpls_m, etc. may have to be fetched again from the L1-IC, decoded, and stored in the UC while processing each incoming packet. The location of the control blocks in the program memory depends on the structure of the program, which is independent of the underlying microarchitecture of the processor, especially because the microarchitecture implementation of the UC is not visible to the program. For example, the number of bits in the IP tag, IP index, and IP offset fields for a UC may vary between microarchitectures, which changes the runtime footprint of the working set in the UC between the corresponding microarchitectures. On the other hand, modifications in the program code may relocate the address of the control blocks, which may change the runtime footprint of the working set in a particular UC. Note that in the context of NET_PROC, a conflict miss in a UC may affect the NET_PROC program in the following ways: (1) increase the number of cycles in processing instructions, which increases the latency of packets in the router; (2) increase power consumption (e.g., by 28%), which increases the operating overhead in terms of power; and (3) reduce instruction fetch throughput (e.g., by 33%), which reduces packet processing throughput (e.g., by 33%).

[0162] It will be understood that the forwarding plane of a high-performance NFV router is generally required to consistently process and forward packets with minimum latency and minimum power consumption in order to meet the optimal operating overhead per bit. Therefore, the forwarding plane of such a high-performance NFV router must generally extract the peak performance of the processor running the forwarding plane of the high-performance NFV router. As further discussed below, based on the use of a processor configured to provide programmable control to ultra-high-performance programs in a manner that is used to reduce or even minimize conflict misses caused by interference between control blocks of programs being executed by the processor (e.g., based on the use of an SP-UC comprising multiple UCs, and associated control capabilities that support the use of such an SP-UC comprising multiple UCs), the various example embodiments presented herein can be configured to support improved performance of a high-performance NFV router.

[0163] Various example embodiments of the processor may be configured to support split programmability of processor resources. Various example embodiments of the processor may be configured to support split programmability of resources of a processor front end of the processor. Various example embodiments of the processor may be configured to support split programmability of resources of a processor front end of the processor in a manner that enables split programmable resources of the front end of the processor to be assigned to control blocks of a program being executed by the processor.

[0164] Various example embodiments of the processor may be configured to support split programmability of processor resources. Various example embodiments of the processor may be configured to support split programmability of processor resources for ultra-high performance applications of class A or class B in a manner for reducing or even eliminating conflict misses between critical control blocks in a working set. Various example embodiments of the processor may be configured to support split programmability of processor resources based on a paradigm for employing UC in the processor to minimize such conflict misses between critical control blocks. Various example embodiments of the processor may be configured to support split programmability of processor resources based on techniques in the architecture (i.e., ISA) and microarchitecture to implement a paradigm for employing UC in the processor to minimize such conflict misses between critical control blocks. For ultra-high performance applications, these techniques can improve and guarantee the performance of the processor front end while also saving more power in the processor front end.

[0165] As described above, various example embodiments of the processor may be configured to support split programmability of UCs of the processor front end. Various example embodiments of the processor may be configured to support split programmability of UCs of the processor front end based on the use of a UC library containing multiple UCs, wherein each UC in the library is uniquely identifiable (e.g., identified by a digital identifier), and is therefore programmable by a program that can be executed by the processor. For example, if there are P UCs in the library, the UCs may be assigned identifiers of 0, 1…, (P-1). At any time during program execution, only one UC in the library is active, i.e., for storing or accessing UOPs. For example, if UC-1 is the currently active UC in the UC library, the decoder only stores the UOPs to UC-1. While acquiring the IP, UC-1 only looks for matching UC rows. The active UC in the set is selected by a special instruction in the program, which encodes the identifier of the UC set to be active. The special instruction may be a dedicated instruction for switching the active UC, or may be an existing control instruction enhanced to encode the identifier of the UC. Any of these special instructions may be referred to as a "UC switching instruction" included in the instruction set of the ISA of the processor. When the UC switch instruction is decoded or accessed in UC-K, it switches the active UC from UC-K to UC-M, where UC-M is the UC identifier encoded in the UC switch instruction. Subsequent instructions fetched after the UC switch instruction are stored and accessed in UC-M until another UC switch instruction switches the active UC again. Note that the switch of the active UC from UC-K to UC-M occurs before the subsequent instructions are fetched, which also means that the back end of the processor has not yet executed the UC switch instruction. Therefore, when the UC switch instruction is a hit in UC-K, or during the decoding stage of the UC switch instruction (i.e., the UC switch instruction is a miss in UC-K, so it is fetched and stored in UC-K through the L1-IC->IFU->ILD->IQ->MITE path), the switch of the active UC can occur, so that the subsequent instructions fetched are stored or accessed in UC-M. This paradigm of UC is referred to herein as a split programmable micro-op cache (SP-UC), where it is considered "split" because there are multiple UCs and it is considered "programmable" because the selection of the active UC is controllable by a program executed by the processor.

[0166] As described above, various example embodiments of the processor can be configured to support the split programmability of the UC of the processor front end based on SP-UC. In general, SP-UC enables the program to pin a specific control block to a specific UC-M. Once fixed, the instructions in the control block will be accessed or stored in UC-M. For example, assume that before the control is transferred to the control block, the active UC is UC-K. Then, while the control is transferred to the control block, the program calls the UC switch instruction encoded with UC-M, which changes the active UC from UC-K to UC-M. Subsequently, all instructions in the control block are pinned to UC-M. When the execution of the control block is completed, the active UC can be restored from UC-M back to UC-K, while the control is transferred to the original sequence in the parent program. In this way, the program can pin performance-critical control blocks to mutually exclusive UCs in the library, thereby eliminating conflict misses caused by interference between them. This method also increases the spatial locality of the working set in each UC, because the control block is a sequence of instructions in a narrower area in the program memory. In a set-associative cache, the conflict miss rate is inversely proportional to the spatial locality of the working set of the cache. If the number of critical control blocks in the SP-UC is higher than the number of UCs, multiple control blocks can be fixed to share a specific UC. Such control blocks are called "affinity groups", and it will be understood that conflict misses may occur due to interference between sibling control blocks within an affinity group, but should not occur between control blocks that are not part of an affinity group. The program can spatially collocate sibling control blocks in an affinity group in program memory, which minimizes interference between blocks, thereby further reducing or eliminating conflict misses. The method provides absolute control over the program to assign its control blocks between UCs in a way that achieves improved or even optimal program performance.

[0167] It will be appreciated that these and various other embodiments and advantages of split programmability may be further appreciated by considering a front end of a processor configured to support split programmability and including a split programmable micro-op cache, such as Fig.17 What is presented.

[0168] Fig.17 An example embodiment of a front end of a processor configured to support split programmability and including a split programmable micro-op cache is depicted.

[0169] Fig.17 The front end 1700 includes L1-IC 1710, IFU 1720, BPU 1730, ILD 1740, IQ 1750, ID 1760, split programmable (SP) UC (SP-UC) 1770 (including a collection or library of UCs 1771-1-1771-(P-1), which may be collectively referred to as UC 1771) and IDQ 1780. It will be understood that, in general, Fig.17 The operations of the components of the front end 1700 may be respectively similar to Figure 2 Operation of the corresponding components of the front end 200, unless otherwise indicated (e.g., to support segmented programmability of UC resources).

[0170] As described above, front end 1700 is configured to support split programmability of various resource types of front end 200, including supporting split programmable UCs (illustratively, SP-UCs 1770). It will be appreciated that by first considering the operation of L1-IC 210 (as described with reference to FIG. Figure 4-5 ), the operation of a single UC 370 (as shown in Figure 6-12 as presented), and based on reference Figure 4-5 The operation of the L1-IC 310 presented and as referenced Figure 6-12 The use of the processor of the single UC 370 operation presented is to support the execution of the program (as shown in reference Figure 13-16 ), the operation of the front end 200 using the segmented programmability of UC resources can be further understood (e.g., as shown in reference to Figure 17-31 presented).

[0171] For SP-UC based (such as Fig.17 Various embodiments of the SP-UC 1770 of the front end 1700 supporting processor operations are configured to support UC switching instructions. The UC switching instructions may be supported in the architecture of the processor (e.g., the instruction set of the ISA of the processor). The UC switching instructions may be configured to encode the UC index to be switched to the active UC. The UC switching instructions may be implemented using dedicated UC switching instructions or existing control instructions of the ISA of the enhanced processor.

[0172] In at least some embodiments, a UC switch instruction may be implemented using a dedicated UC switch instruction. A dedicated UC switch instruction switches the active UC without changing the execution sequence. This means that subsequent instructions will be stored and / or accessed in the UC (e.g., one of UC 271) selected by the UC switch instruction. This type of instruction is denoted herein as "UC switch type-1".

[0173] In at least some embodiments, the UC switching instruction can be implemented using the existing control instructions of the ISA of the processor. The existing control instructions of the ISA of the processor can be enhanced with the UC switching function. The existing control instructions of the ISA of the processor switch the UC while jumping the execution sequence to the control block. Therefore, the existing control instructions (e.g., in x86, such as instructions such as JUMP, JE, CALL, etc.) that jump the execution sequence to the control block can be used for this purpose. This type of instruction is represented as "UC Switch Type-2" herein.

[0174] As discussed herein, the SP-UC is a component of the micro-architecture of the processor, and the UC switching instructions are part of the processor architecture / ISA. Therefore, the UC switching instructions described herein are not necessarily limited to controlling the partitioning and programmability of the UC to provide the associated switching between the SP-UC and the UC of the SP-UC; instead, these UC switching instructions can be used to control the partitioning and programmability of other types of processor resources and the associated switching between the parts of these other types of processor resources. In addition to the UC resources, these other resources can also include other processor front-end resources, such as branch predictors, branch target buffers, etc. It will also be understood that various combinations of such processor front-end resources can be partitioned and programmed according to the various embodiments presented herein. Therefore, the UC switching instructions provided to support the partitioning and programmability of the UC resources of the processor front end can be generalized as "resource switching instructions" or "color switching instructions", which represent the more general ability to control the partitioning and programmability of various processor front-end resource types used by the control block of the program executed by the processor, and therefore also have the ability for the program being executed to attribute a "color" to the control block, so that the control block can then use the resources of that color (i.e., for any one of the one or more resource types that support partitioning and programmability, the corresponding part of the corresponding resource type with that color). In such an embodiment, instead of encoding a UC index identifying the UC of the control block within the instruction, a color index identifying the color of the control block (and the processor front-end resources associated therewith) is encoded within the instruction. In this way, from the perspective of the processor architecture, the color provides the concept of a resource pool within the processor, so that when the program assigns a color to the control block, the control block is allocated with resources of that color (e.g., UC resources in the form of UCs of SP-UCs, branch predictor resources of branch predictors, branch target buffer resources of branch target buffers, etc. and various combinations thereof). It will be understood that multiple control blocks of a program can share colors (and can be referred to as affinity groups) so that each of the multiple control blocks is assigned a set of resources of the assigned color. In the context of SP-UC, the color index is mapped 1:1 to the UC index (i.e., the SP-UC is a UC pool in which each UC is assigned a color index). It will be understood that a more general version of the UC switching instruction can also be introduced, taking into account the generalization of the partitioning and programmability of UC resources based on color to other types of resources. That is, in order to support the partitioning and programmability of various processor front-end resource types, the color switching instruction can be defined to include a "color switch type-1" instruction (e.g., a more general version of the "UC switch type-1" instruction) and a "color switch type-2" instruction (e.g., a more general version of the "UC switch type-2" instruction).It will be appreciated that in the case of color-based partitioning and programmability of various resource types, where the partitioned resource is a UC providing an SP-UC, the color switch instruction can then act as the UC switch instruction initially introduced above (e.g., where the color value indicates a UC index in the SP-UC). It will be appreciated that the color switch instruction can be implemented using various processor ISAs; however, in order to clearly describe various embodiments of color-based partitioning and programmability of processor front-end resources, the color switch instruction (including implementing the color switch instruction as a UC switch instruction for supporting SP-UC) is primarily described in the context of a specific ISA (i.e., x86). It will be appreciated that, as. Fig.18 As shown, the encoding of color switching instructions in x86 can be further understood by first considering the encoding of x86 instructions in general.

[0175] Fig.18 An encoding of an x86 instruction set architecture instruction is depicted to illustrate the encoding of a color switching instruction configured to support partitioning and programmability of processor front end resources.

[0176] like Fig.18 As shown, instruction 1800 includes a plurality of fields, including an instruction prefix field, an opcode field, a ModR / M field, a SIB field, a displacement field, and an immediate field.

[0177] The opcode field is a single byte that represents the basic operation of the instruction. Therefore, this field is mandatory, allowing up to 256 primary opcode mappings. For example, 0x74 is the opcode for the JE instruction for a short jump (i.e., a conditional jump to a location within the relative offset of 0x7f in program memory). Alternate opcode mappings are defined using escape sequences, which require 2-3 bytes in the opcode field. For example, the escape sequence is encoded as [0f <opcode>] 2-byte opcode. Here 0f identifies an alternative opcode mapping. For example, 0f 84 is the opcode for the JE instruction for a near jump (i.e., a conditional jump to a location that is too far to reach for a short jump).

[0178] The ModR / M field is a 1-byte optional field with the semantics of Mode-Register-Memory. If the instruction has operands (i.e., opcode-based), this field specifies the operand(s) and their addressing mode. The bits in this field are divided into the following sections:

[0179] Mod: Bits 6-7 describe the 4 addressing modes for the memory operand as shown below, in the context of the MOV instruction. The following MOV instruction transfers data between memory and register EAX.

[0180]

[0181] Reg: Bits 3-5 specify the source or destination register. This allows encoding of 8 general purpose registers in the x86 architecture.

[0182] R / M: Bits 0-2, in conjunction with the Mod field, specify either the second operand in a two-operand instruction or the only operand in a single-operand instruction (e.g., NOT or NEG). In the case of a two-operand instruction, this field will encode the ESI register in the case that register EAX will be encoded in the Reg field.

[0183]

[0184] The SIB field is a 1-byte optional field with the semantics of Scale-Index-Base. This field is used for scale index addressing mode (specified in Mod), as shown in the following example:

[0185]

[0186] Here, scale = 4 (scaling factor), index = EBX (register containing the index part), and reference = EDX (register containing the reference part).

[0187] The displacement field is a variable length field of 1, 2, or 4 bytes. It has multiple use cases, such as: (1) in the example described for the SIB, this field contains a non-zero offset value of 8 or (2) in a control instruction, it contains the address of the control block in program memory, in the form of either (a) an absolute value (i.e., a reference added to the program memory address) or (b) a relative value (i.e., an offset relative to the address of the control instruction).

[0188] The immediate field is a variable length field that contains a constant operand of an instruction. For example, in an instruction that adds 8 to register EAX (i.e., the instruction "MOV EAX, 8"), the immediate field will contain the value 8.

[0189] The instruction prefix field is a variable length optional field that can contain up to 4 prefixes, each of which is a 1-byte field. This field changes the default operation of the x86 instruction. For example, 66h is an "operand override" prefix that changes the data size expected by the default instruction mode (e.g., from 64 bits to 16 bits). It will be appreciated that the x86 ISA currently supports the following prefixes:

[0190] Prefix Group 1

[0191] ο0xF0: LOCK prefix

[0192] ο0xF2: REPNE / REPNZ prefix

[0193] ο0xF3: REP or REPE / REPZ prefix

[0194] Prefix Group 2

[0195] ο0x2E: CS segment coverage

[0196] ο0x36: SS segment coverage

[0197] ο0x3E: DS segment coverage

[0198] ο0x26: ES segment coverage

[0199] ο0x64: FS segment overwrite

[0200] ο0x65: GS segment coverage

[0201] ο0x2E: Branch not taken

[0202] ο0x3E: Take branch

[0203] Prefix Group 3

[0204] ο0x66: operand size override prefix

[0205] Prefix Group 4

[0206] ο0x67: Address size override prefix

[0207] The "Color Switch Type-1" instruction can be used to control the partitioning and programmability of processor front-end resources, and the associated switching between portions of these processor front-end resources. The "Color Switch Type-1" instruction can be considered a more general version of the "UC Switch Type-1" instruction (which is specific to the partitioning and programmability of the UC resources of the processor front-end), and can therefore be configured to switch active processor front-end resources without changing the execution sequence. The "Color Switch Type-1" instruction can be implemented using dedicated switching instructions, like the "UC Switch Type-1" instruction. The "Color Switch Type-1" instruction can be used in various ISAs such as x86 and others, like the "UC Switch Type-1". Fig.19 An example implementation of the "color switch type-1" instruction in the x86 ISA is presented.

[0208] Fig.19 An example embodiment of a "color switch type-1" instruction implemented using the x86 instruction set architecture is depicted. Fig.19 As shown, the "Color Switch Type-1" instruction 1900 includes only an opcode and an immediate field. It will be appreciated that since this is a new instruction, a currently unassigned value from the existing opcode map may be assigned to indicate the "Color Switch Type-1" instruction. The 1-byte immediate field is encoded with the index of the color to be switched to active. The "Color Switch Type-1" instruction may be represented by a mnemonic (e.g., "CLCHG" or another suitable value) to indicate that the instruction is a "Color Switch Type-1" instruction. Fig. 20 An example of a "color switch type-1" instruction in x86 instruction sequence 2000 is presented in .

[0209] The "Color Switch Type-2" instruction can be used to control the segmentation and programmability of processor front-end resources, as well as the associated switching between the various parts of these processor front-end resources. The "Color Switch Type-2" instruction can be considered to be a more general version of the "UC Switch Type-2" instruction (which is specific to the segmentation and programmability of the UC resources of the processor front-end), and can therefore be configured to switch active processor front-end resources while the execution sequence is jumped to the control block. The "Color Switch Type-2" instruction can be implemented by enhancing the existing control instructions of the ISA of the processor with resource switching function, like the "UC Switch Type-2" instruction. The "Color Switch Type-2" instruction can be used in various ISAs such as x86 and others, like the "UC Switch Type-2" instruction. An example implementation of the "Color Switch Type-2" instruction in the x86 ISA will be further discussed below.

[0210] As described above, the implementation of the "color switch type-2" instruction in the x86 ISA can be based on the enhancement of the existing x86 ISA control instructions for the functionality of the "color switch type-2" instruction. For example, a new instruction prefix group can be defined as follows (although it will be understood that other prefix group definitions can be used): Prefix Group 6 (0x80: Colored-Segment-Prefix-Base + <Color Index> = Colored-Segment-Prefix). Here, the active processor front-end resources (e.g., UCs of SP-UC) are identified by the color-segment-prefix value. For example, assuming that the processor supports 8 UCs in SP-UC, the value 0x80 indicates UC-0, the value 0x87 indicates UC-8, and so on. In x86, when a control instruction is encoded as a "color switch type-2" instruction, then the mnemonic of the instruction is prepended with an indicator (e.g., "C" or another suitable value) to indicate that the control instruction is a "color switch type-2" instruction. For example, a JUMP instruction encoded as a "color switch type-2" instruction would be represented using the mnemonic CJUMP using "C" as the prepended indicator. Similarly, RET is CRET, JE is CJE, JLE is CJLE, CALL is CCALL, and so on. Fig.21 An example of a "color switch type-2" instruction in an x86 instruction sequence 2100 is presented in (which shows a program starting with a "main" control block).

[0211] A processor that supports color-based segmentation and programmability of processor front-end resources can be configured to provide an indication of the number of colors supported to a program to be executed by the processor. This will enable the program to dynamically assign colors to its control block based on the number of colors supported. The processor can notify the program of the number of colors supported in a variety of ways, such as by advertising the number of colors so that the program can find this information, responding to color number requests from the program, etc. and various combinations thereof. It will be understood that the way the processor notifies the program of the number of colors supported can be different on different ISAs. For example, in the x86 ISA, the CPUID (CPU identification) instruction that allows software to discover processor details can be enhanced for this purpose. The CPUID instruction does not take parameters because the CPUID implicitly uses the EAX register in the x86 to determine the main information category returned (sometimes called the CPUID leaf). The CPUID can be called first with EAX=0 because this will return the highest EAX call parameter (leaf) supported by the processor in the EAX register. The existing CPUID paradigm can be extended by adding the number of colors supported as a new leaf. It will be understood that the way the processor notifies the program of the number of colors supported can be different for other ISAs.

[0212] The decoding of the color-switch instruction results in the generation of a color-switch UOP, an example of which is presented as Fig. 22 2200 in the color switching UOP. It will be appreciated that the exact structure of the fields in the color switching UOP depends on the underlying micro-architecture of the processor. Therefore, the exact structure of its fields is not defined herein, but can be defined based on the underlying micro-architecture of the processor. However, this paper provides rules for encoding the next valid color in the color switching UOP. For example, in at least some embodiments, a color index field and a branch-bit (B-bit) field (these two fields are in Fig. 22 ) encodes the next active color in the color switching UOP. The color index field is a k-bit field that encodes the index of the next valid color, where the number k depends on the number of colors supported by the processor (e.g., the number of UCs in the SP-UC). For example, if the SP-UC contains 8 UCs, then k=3, because 8 different UCs can be uniquely identified using a 3-bit field. The B-bit field is configured to provide an indication of whether the active color is switched or whether the active color is switched only when the execution sequence branches to another control block after the UOP (e.g., "1" can be used to indicate that the active color is switched to the color index only when the execution sequence branches to another control block after the UOP, and "0" can be used to indicate that the active color is unconditionally switched to the color index, or vice versa).

[0213] As described above, the decoding of the color switch instruction results in the generation of a color switch UOP. The "color switch type-1" instruction is decoded into a color switch UOP. The "color switch type-1" instruction can be decoded as Fig.23 Decoding a "color switch type-1" instruction into a color switch UOP in x86 may be performed as follows: (1) when the decoder sees the opcode as a color switch type-1, it generates a color switch UOP, (2) the decoder copies the immediate value (color index) field from the instruction to the color index bits in the UOP, and (3) the decoder sets the B-bit to 0.

[0214] As mentioned above, decoding of a color-switch instruction results in the generation of a color-switch UOP. When a "color-switch type-2" instruction is decoded, it generates a color-switch UOP in addition to the UOPs generated by the underlying (non-color version) control instruction. During decoding, the B-bit in the color-switch UOP is set to 1 (because the next active color is only switched when branching to the control block after fetching this instruction), and the color-switch UOP is the last UOP in the decoded UOPs. Fig.24 As shown, a "color switch type-2" instruction can be decoded into a color switch UOP and one or more other instructions. Decoding of a "color switch type-2" instruction in x86 can be performed as follows: (1) if the opcode is one of the control instructions, the decoder decodes the control instruction to generate a UOP, (2) if the instruction contains a color-segment-prefix, the decoder adds the color switch UOP to the list of already decoded UOPs, (3) the decoder sets the color index in the color switch UOP to = color-segment-prefix - color-segment-prefix-base, and (4) the decoder sets the B-bit to 0.

[0215] The processor may be configured with a micro-architecture configured to support partitioning and programmability of processor front-end resources and associated switching between portions of such processor front-end resources. For clarity, the micro-architecture of the processor is primarily presented herein in the context of using generic color switching instructions for implementing SP-UCs, the micro-architecture of the processor being configured to support partitioning and programmability of processor front-end resources and associated switching between portions of such processor front-end resources (so that it will be understood that references to color switching instructions may be considered references to UC switching instructions of a UC that may be specific to an SP-UC). Fig.25 An example embodiment of a micro-architecture for implementing SP-UC is presented in .

[0216] Fig.25 An example embodiment of a micro-architecture for implementing a SP-UC is depicted. As previously described, the SP-UC includes a UC library and circuitry for managing the inputs and outputs of individual UCs within the UC library. The UC library consists of K UCs (which are denoted UC-0 to UC-K-1). Next, each UC is implemented using an N-way set associative UC-tag and UC-data array, similar to Figure 6 The microarchitecture presented in (for clarity, Fig.25 However, in Fig.25 The SP-UC, UC-Tag and UC-Data (i.e., UC row) entries may have the following additional rules:

[0217] Rule 1: A color-switch instruction (i.e., a "color-switch type-1" instruction or a "color-switch type-2" instruction) terminates a basic block. This means that there can only be one color-switch-uOP in a UC-row. This rule enables UC switch operations to be processed at UC-row granularity.

[0218] Rule 2: The auxiliary data in the UC-Tag additionally stores the UC switch information as follows: UC-Switch-Info = {UC-Index, B-Bit, Valid-Bit}. If the UC-row corresponding to the UC-Tag contains a Color-Switch-UOP, the Valid-Bit is set to 1. The UC-Index and B-Bit are copied from the Color-Switch-UOP in the UC-row, respectively.

[0219] Note that these additional rules are expected to lead to a significant simplification and efficiency of the microarchitecture of SP-UC.

[0220] like Fig.25 As shown, SP-UC can be configured to provide improved IP lookup. IP lookup based on SP-UC can have various SP-UC inputs and outputs associated therewith. The input of SP-UC is IP and active UC. The active UC register contains the UC index of the current IP. The output of SP-UC is hit / miss status, UC-data and auxiliary data. IP lookup in SP-UC can be composed of various steps performed in one or two cycles. In the first cycle (which can be expressed as cycle-1), UC-tag lookup (as discussed in steps 1-12 below) is performed, L1-IC lookup (as discussed in step 13 below) is performed, the calculation of the next IP of SP-UC is performed (as discussed in steps 14-17 below), and the calculation of the next active UC of SP-UC is performed (as discussed in steps 18-20). In the second cycle (which may be denoted as cycle-2), which is executed only if there is a hit in the UC-tag array in the first cycle (i.e., if a hit / miss from the SP-UC results in a hit), the SP-UC data fetch is performed (as discussed in steps 21-23 below), and the next UC-tag lookup is performed (as discussed in steps 24-26 below). It will be appreciated that these steps describe a process that spans Fig.25 The signal flow of the front-end 2500 SP-UC.

[0221] In cycle-1 of the IP lookup, the UC-label lookup in the SP-UC may be performed (as discussed in steps 1-12 below):

[0222] 1. The IP to be looked up (1) is sent as input (1.1) to the K-way IP demultiplexer. The output of each way of the demultiplexer is connected to the IP input (3) of the UC. The demultiplexer activates the output of the only way corresponding to the currently active UC based on the selector input (2.1) received from the active UC register. Therefore, the IP is finally sent only to the currently active UC.

[0223] 2. The UC-Tag array in each UC generates output row-hit / miss (4) and auxiliary data (5). The auxiliary data consists of UOP number, byte length, and UC-switch-information.

[0224] 3. The hit / miss row from each UC is connected as input (5.1) to the K-way hit / miss multiplexer. Based on the UC selected by the selector input (4.1), the multiplexer connects the hit / miss row from the selected UC as output.

[0225] 4. The auxiliary data lines from each UC are connected as input (6.1) to a K-way auxiliary multiplexer. Based on the UC selected by the selector input (5.1), the multiplexer connects the auxiliary data lines from the selected UC as output.

[0226] 5. The active UC register value is also sent as a selector (2.2) to a K-way selector demultiplexer which generates a selector row (4) to control the output from the UC.

[0227] 6. The selector row (4) from step 5 is fed as selector input (4.1) to the K-way hit / miss multiplexer (as described in step 3). This multiplexer thus connects the hit / miss row from the active UC as output (7).

[0228] 7. The selector row (4) from step 5 is fed as selector input (4.2) to a K-way auxiliary multiplexer (as described in step 4). This multiplexer thus connects the auxiliary data rows from the active UC as output (8).

[0229] 8. As is evident from steps 1-7, the IP only does a lookup in the UC-Tag array of the currently active UC. At the end of the cycle, steps 6-7 generate the hit / miss and auxiliary data outputs from the active UC.

[0230] 9. If there is a hit in the SP-UC, the UC-Tag in the active UC sends an activation signal to the delay element (15) to read out the corresponding UC-Data entry in the next cycle. This is described in the context of UC-0, regardless of whether it is the active UC or not.

[0231] 10. The selector row (4) from step 5 is fed to the delay element (4.3) to control the K-way UC-data in the next cycle.

[0232] 11. The hit / miss output (7) from the SP-UC is sent to the IFU (7.1), ILD (7.2), IQ (7.3) and MITE (7.4), which disable the corresponding units if there is a hit.

[0233] 12. The hit / miss output (7) from the SP-UC is sent to the delay element (7.5). In the next cycle, this row acts as the selector input to the 2-to-1 multiplexer that selects between the decode path and the SP-UC to send the UOP to the IDQ.

[0234] In cycle-1 of the IP lookup, an L1-IC lookup is performed (as discussed in step 13 below):

[0235] 13. The IP is also sent in parallel to the L1-IC for a lookup of instructions starting from that IP so that if the lookup in the SP-UC results in a miss, instructions are fed from the L1-IC.

[0236] In cycle-1 of IP lookup, the calculation of the next IP for the SP-UC (as discussed in steps 14-17 below) may be performed as follows:

[0237] 14. The IP is also sent in parallel to the branch predictor unit (BPU) (1.2). At the end of this cycle, the BPU determines whether the execution sequence branches to another control block after the UC line of the current IP, which is indicated in the hit / miss output (10). If there is a hit, the next IP (i.e., the IP of the next control block) is indicated in its output (11).

[0238] 15. The IP is also sent in parallel to an adder (1.3) where it is added to the byte length in the auxiliary data (8.1) output from the SP-UC at the end of the cycle. This addition produces the next IP in the sequence (13).

[0239] 16. The next IP calculated from steps 10 and 11 is fed into a 2 to 1 way multiplexer where the way is selected by the hit / miss (10) from the BPU. If a hit, the multiplexer sends 11 to the output (14), otherwise it sends 13 to the output (14).

[0240] 17. The hit / miss output (7) from the SP-UC is input to the 'enable' line of the IP which is synchronized with the clock.

[0241] In cycle-1 of IP lookup, the calculation of the next active UC for the SP-UC may be performed as follows (as discussed in steps 18-20 below):

[0242] 18. The UC index from the UC-Switch-Info is sent as data input (8.2) to the active UC register.

[0243] 19. The B-bit (8.3) from the UC-Switch-Info and the hit / miss (10.1) from the BPU are input to an XNOR gate. The output of this gate is 1 if the active UC is to be switched to the UC index in the UC-Switch-Info.

[0244] 20. The valid-bit from the UC-Switch-Info, the hit / miss from the SP-UC and the output from step 15 are input to an AND gate. The output of the AND gate is input as the 'enable' line to the active UC register synchronized with the clock. If the UC-Switch-Info is valid and the UC is to be switched to the UC index in the UC-Switch-Info, the enable line will be set to 1.

[0245] In cycle-2 of IP lookup, SP-UC data acquisition (as discussed in steps 21-23 below) may be performed as follows:

[0246] 21. In the currently active UC, the activation signal from the matching UC-Tag sent by the delay element (in step 9) activates the corresponding UC-Data entry (16). This is described in UC-0, whether it is the currently active UC or not.

[0247] 22. The UC-data lines from each UC are connected as input (17.1) to a K-way UC-data multiplexer. The output of the multiplexer is controlled by the selector input (4.3) sent through the delay element (at step 10). Based on the selector input from the active UC, the multiplexer connects the UC-data lines from the active UC as output (9).

[0248] 23. The UC-Data (9) output from step 22 is sent as input (9.1) to the 2 to 1 multiplexer that selects between the SP-UC and the decoding path. Since there is a hit, the selector to the multiplexer (7.6) is set to 1, which outputs the UC-Data to the IDQ.

[0249] In cycle-2 of IP lookup, the next UC-label lookup (as discussed in steps 24-26 below) may be performed as follows:

[0250] 24. Since there was a hit in the UC-Tag lookup in the previous cycle, the 'enable' row (en) input to the IP is set, which updates the IP with the input (14) received from step 14.

[0251] 25. If the enable line in the active UC register is set to 1, the active UC register is updated with the value received in 8.2.

[0252] 26. Repeat steps 1-20 for the current IP and active UC register.

[0253] It will be understood that the foregoing step numbers are provided for clarity of description of example embodiments, but do not necessarily imply an order in which the steps may be performed (e.g., at least some steps may be performed in a different order, at least some steps may be performed simultaneously, etc., as well as various combinations thereof).

[0254] It will be appreciated that IP lookup may consist of various other steps performed in various other cycles.

[0255] Note that, for simplicity, Fig.25 There is no indication of how to switch active UCs while providing UOPs via the instruction decode path (i.e., build mode when IP misses SP-UC), thus fetching instructions from L1-IC along the IFU->ILD->IQ->MITE path. As discussed further below, refer to Fig.26 The front end 2600 presents Fig.25 An extension of , which demonstrates UC switching while providing UOPs through build-mode.

[0256] Refer again Figure 2 and 17 , will understand, Figure 2 The front end 200 and Fig.17 The front end 1700 is configured to support build-mode operation, which supports fetching and decoding instructions through the path L1-IC->IFU->ILD->IQ->MITE, and storing them in parallel to SP-UC to provide to IDQ.

[0257] It will be appreciated that when moving between flow-mode and build-mode, mode switching is done at the front end (e.g. Figure 2 Front-end 200 or Fig.17 For example, when the front end is in flow-mode and the UC-tag lookup results in a miss, the front end will switch to build-mode.

[0258] Refer again Fig.25 ,exist Fig.25 In the SP-UC of , the UC lookup can perform a UC-tag lookup in the first cycle, and if there is a miss in the first cycle, it can perform instruction fetch and decode through the path L1-IC->IFU->ILD->IQ->MITE and store them in parallel to the SP-UC to provide to the IDQ. As discussed further below, it can be done by Fig.25 To further understand these operations, an example embodiment of the SP-UC is combined with an IC of a front end of a processor configured to operate in build-mode, such as Fig.26 As shown. It will be understood that Fig.26 can be considered as Fig.25 A generalized view of an FPGA that shows only the components and signal flows used in build-mode.

[0259] exist Fig.26 In the example, the block builder is configured to observe the decoded UOPs output from the MITE and build UC lines for storage in the SP-UC. In this way, if program flow returns to an IP that caused a miss at the SP-UC, that IP will instead cause a hit. The process, which can be a single cycle or multi-cycle process, includes the following steps described below (it will be understood that it describes the steps of Fig.26 The signal flow of the front end):

[0260] 1. When the decoded UOP from MITE is provided to the backend (1.1), the UOP is also sent in parallel to the UC fill buffer in the block builder (1.2).

[0261] 2. In the block builder, UOPs from consecutive instructions are packed together to fill a UC line. After a UC line is built (2), it is ready to be stored in the SP-UC.

[0262] 3. Send {IP, ByteLen} of UCL to IP Update Logic (2.3). IP Update Logic reads IP Register (15) to check if the IP (2.3) of the UC row is the same as the IP from 15, which is the IP that missed earlier in UC. If not, the UC row is discarded.

[0263] 4. Before a UC row is stored in the SP-UC, it determines where its active UC should be stored and updates the active UC register accordingly. This determination is made by the active UC update logic, which performs the following steps:

[0264] 4.1. From the last UC row stored in SP-UC, it records the tuple {IP, ByteLen, UC-Switch-Info} into a local register. This register is read (8) to complete steps up to 4.4. If the UC-Switch-Info is invalid (i.e., the valid-bit is set to 0), go to step 4.5.

[0265] 4.2. If the UC-Switch-Info contains the B-bit set to 0, check if IP+ByteLen (of the previous UC row) is equal to the IP of the current UC row.

[0266] 4.2.1. If yes, it means that the current UC row contains subsequent UOPs in the sequence, which will be stored in the UC specified by the UC-index in the UC-switch-info. Then go to step 4.4.

[0267] 4.2.2. If no, go to step 4.5.

[0268] 4.3. If the UC-Switch-Info contains the B-bit set to 1, check if IP+ByteLen (of the previous UC row) is not equal to the IP of the current UC row.

[0269] 4.3.1. If yes, this means that the current UC line is the start of a control block to branch to, which is stored in the UC specified by the UC-index in the UC-Switch-Info. Then go to step 4.4.

[0270] 4.3.2. If no, go to step 4.5.

[0271] 4.4. Update the value in the active UC register with the UC index from the UC-switch-info (4). Return the UC index from the UC-switch-info stored in the local register as the active UC for the UC row (7). Go to step 4.6.

[0272] 4.5. Read the existing value in the active UC register (6) and return the value as the active UC for the UC row (7).

[0273] 4.6. From the current UC row, record the tuple {IP, ByteLen, UC-Switch-Info} into the local register (9). While executing steps 4.1-4.4 for the next UC row, the local register will be referenced again.

[0274] 5. The UC row is now stored in SP-UC (2.1).

[0275] 6. While the UC row is being stored in the SP-UC (2.1), in parallel, the IP update logic sends the byte length of the UC row (16) to calculate the next IP in the sequence. Signal 16 is sent as input to a 2-to-1 multiplexer, which gets its other input from the byte length of the "aux" output of the SP-UC. The selector of the multiplexer is the hit / miss output from the UC. In build mode, hit / miss sends a miss, so the multiplexer connects the signal from 16 as output (8.1). The remaining signal flow for updating the next IP (using the BPU and signal 8.1) is the same as described in flow mode.

[0276] It will be understood that the foregoing step numbers are provided for clarity of description of example embodiments, but do not necessarily imply an order in which the steps may be performed (e.g., at least some steps may be performed in a different order, at least some steps may be performed simultaneously, etc., as well as various combinations thereof).

[0277] will understand that in Fig.25 and 26 In the SP-UC microarchitecture, the lookup in SP-UC is performed in two clock cycles, that is, in Figure 6 The cycle time and power consumption of a SP-UC may be affected by the surface area it consumes on the chip. The implementation of an SP-UC may consider several methods of organization of the UC-library to provide power-performance characteristics comparable to or even better than a single UC microarchitecture. For example, in the case where an SP-UC is manufactured using the same density as a single UC (e.g., a 22nm semiconductor device manufacturing node, etc.), an SP-UC with K UCs may consume a surface area equal to that of a single UC case, which can be achieved by keeping the size of each UC in the SP-UC equal to or approximately equal to the UC size in the single UC case divided by the number of UCs (K). For example, in the case where an SP-UC is manufactured using a higher density technology than a single UC case, the size of the UC within the SP-UC may be kept equal to or greater than the UC size in the single UC case (e.g., using a 14nm manufacturing node, a 12nm manufacturing node, etc.).

[0278] It will be appreciated that a processor configured to support split programmability may be configured to support two operating modes: (1) a unified mode, in which the split programmability capability is not used although it is supported, and (2) a split mode, in which the split programmability capability is used. For example, in the case of SP-UC, a processor that supports SP-UC may also support the option of operating the SP-UC as a single non-programmable UC. This provides backward compatibility for programs that do not support the use of split programmability capabilities (e.g., programs that do not support the use of color switching instructions to virtualize processor front-end resources). In a unified operating mode, which may be set as the default mode in a processor for backward compatibility, a collection of resources that would otherwise be shareable and programmable may be bundled together to act as a non-programmable whole resource (e.g., in the case of SP-UC, the individual UCs in the UC library of the SP-UC are bundled together to operate as a non-programmable whole UC). In the split operating mode, which may be entered from a unified operating mode (where the unified operating mode is the default mode), a collection of resources is shareable and programmable using color switching instructions (e.g., in the case of SP-UC, the individual UCs in the UC library of the SP-UC are operated as a group to support sharing and programmability). By reference to Fig. 27 , the use of mode selection for switching between unified mode and split mode can be further understood.

[0279] Fig. 27 An example embodiment of a micro-architecture for implementing a separate programmable micro-operation cache in a processor configured to support a mode selection for switching between non-programmable and programmable operating modes is depicted. It will be appreciated that Fig. 27 The microarchitecture is Fig.25 The microarchitecture of the MCU includes additional logic for mode selection, and the details of the SP-UC are omitted for clarity. Fig. 27 As shown in the front end 2700 of the computer system, a register called "mode selector" (18) is a register that sets the operating mode of the SP-UC. For example, the value of the "mode selector" register can be set to 1 to indicate that the processor will operate in split mode, and if the processor will operate in unified mode, it is set to 0 (or vice versa, where 0 can be used for split mode and 1 can be used for unified mode). The setting of the "mode selector" register can be completed during boot time through the BIOS setup of the computer system. The mode selection operation based on the "mode selector" register can be performed as follows.

[0280] As described above, the "mode selector" register is configured to support operation of the processor in unified mode. To describe the operation of the processor in unified mode, assume that each UC in the SP-UC contains S sets and each set has N ways. While operating in unified mode, the SP-UC acts as a single UC with (S x K) sets, each with N ways. For example, UC-0 contains sets 0 to S-1, UC-1 contains sets S to 2S-1, and so on. To achieve this functionality, the IP is first automatically mapped to a specific UC and then to sets within that UC. The UC is selected by stealing log2(K) bits from the IP label, i.e., the value of the stolen bits is the UC index. Then, as referenced Fig.15 As discussed, the IP index, IP offset, and remaining bits in the IP label are used to look up the UC row within the UC. Extracting these bits from the IP label is performed by the "IP label adjustment" logic. The logic is enabled (en) by the input (18.1) from the mode selector register (18). In unified mode, the input (18.1) value is 1, so the logic is enabled. The extracted log2(K) bits are sent as input (19) to the "2 to 1 UC index" multiplexer. The "2 to 1 UC index" multiplexer obtains another input (2) from the active UC register. The "2 to 1 UC index" multiplexer outputs either input based on the selector (18.2), which is fed from the mode selector register (18). In unified mode, the selector (18.2) value is 1, so the multiplexer outputs input 19 containing the log2(K) bits stolen from the IP label.

[0281] As mentioned above, the "Mode Selector" register is also configured to support operation of the processor in Split Mode. While operating in Split Mode, the Mode Selector (18) is set to a value of 0. Therefore, the IP tag adjustment logic is disabled and the entire bit in the IP tag is sent to the SP-UC. The selector (18.2) value to the 2 to 1 UC index multiplexer is 0, so the multiplexer outputs input 2 from the active UC register.

[0282] It will be appreciated that support for mode selection for switching between non-programmable and programmable operating modes of the processor may be supported in other ways.

[0283] As discussed herein, the processor may be used to support execution of programs for various purposes, such as general purpose processing, network packet forwarding processing (e.g., NFV), graphics processing, etc. Various example embodiments of the partitioning programmability of UC resources for the processor front end may be configured to support NFV. Fig.15 and 16 An example of a network packet processing program and associated control flow structures is presented. Fig.28 An example embodiment is presented that illustrates executing a network packet processing program 1500 based on the use of a processor with a SP-UC. Fig.28 Describes the use of a split programmable micro-operation cache to perform Fig.15 The control flow of the network packet processing program and the structure of the resulting control block. Fig.28 As shown in control flow structure 2800, the processor executes the instructions in NET_PROC. Fig.28 The UC lock in SP-UC is also shown. At the start of NET_PROC, UC-0 is set as the active UC by a dedicated UC switch instruction, such as Fig.28 ING UC-1. The purpose is to fix all instructions in ING to UC-0. When NET_PROC calls subroutine ING with instruction CALL ING UC-1, the CALL instruction is enhanced to perform a UC switch, where it encodes UC-1 as the active UC. Therefore, all instructions in ING are fixed to UC-1. After ING is executed, the RET instruction "automatically" switches the active UC to UC-0, that is, to the UC that was active before CALL ING UC-1. Note that the RET instruction is not encoded with a UC index, because a subroutine can call a subroutine from many different locations, and each such call location can have its own fixed UC. Therefore, when the CALL instruction is called, it also pushes the fixed UC of the calling context into the RAS and the call stack. When RET is obtained, it reads the fixed UC of the calling context from the RAS and switches back to UC. Similarly, when NET_PROC calls subroutine EGR with instruction CALL EGR UC-2, all instructions within EGR are fixed to UC-2. Therefore, the footprints of NET_PROC, ING, and EGR in SP-UC are mutually exclusive working sets. Within ING, all IPv6-related conditional control blocks (i.e., ipv6_1 and ipv6_2) are bundled into an affinity group fixed to UC-3. Fig.28 As shown, the program spatially juxtaposes the two control blocks to eliminate conflict misses between them. In this context, the JE instruction is enhanced to perform a UC switch, where it encodes UC-3 as the active UC. Upon completion of execution of the control block, the JUMP instruction switches the UC back to UC-1. In this context, the JUMP instruction is enhanced to perform a UC switch, where it encodes UC-1 as the next active UC. Similarly, the MPLS-related control block, mpls_1, is pinned to UC-4. IPv4-related processing is performed by the default execution sequence of ING (i.e., non-IPv6 and non-MPLS), which is pinned to UC-1. Control blocks within EGR can be pinned in the same manner, i.e., the IPv6 control block is pinned in UC-3, the MPLS control block is pinned in UC-4, and so on. Therefore, the footprints of the IPv4, IPv6, and MPLS packet processing working sets in SP-UC are mutually exclusive.

[0284] Various example embodiments of the processor are configured to support partitioned programmability of processor front-end resources of the processor. Fig.29 A processor configured to support partitioned programmability of processor front-end resources of the processor is presented. Fig.29 As shown, the processor 2900 includes an ISA 2901 and processor front-end resources 2902. The ISA 2901 is configured to support interaction between software on the processor 2900 and the underlying hardware of the processor 2900. The ISA 2901 is configured to support split programmability of the processor front-end resources 2902 (e.g., based on the use of various instructions, such as color switching instructions, etc.). The processor front-end resources 2902 may include UC resources (e.g., thereby providing SP-UC for the processor 2900), branch prediction unit resources (e.g., thereby providing SP-BPU for the processor 2900), etc. and various combinations thereof.

[0285] Such as Fig.29 Various example embodiments of the processor of the processor 2900 can be configured to support the programmability of the processor front-end resources of the processor. In at least some embodiments, the processor includes a back end, a front end with front-end resources, and an instruction set architecture (ISA). The processor is configured to execute a program. The front end is configured to decode the instructions of the program to provide a set of micro-operations to the back end. The back end is configured to receive micro-operations from the front end and execute micro-operations. The ISA is configured to support the program's programmability to the front-end resource set of the front end.

[0286] Such as Fig.29 Various example embodiments of the processor 2900 of the processor may be configured to support split programmability of UC resources of the processor by providing a processor including a set of at least two micro-operation caches configured to store micro-operations decoded from instructions of a program to be executed by the processor.

[0287] Such as Fig.29 Various example embodiments of the processor 2900 may be configured to support partitioned programmability of UC resources of the processor by providing a processor including an instruction set architecture (ISA) configured to support programmability of a set of two or more UCs of the processor by a program executed by the processor.

[0288] Such as Fig.29 Various example embodiments of the processor 2900 may be configured to support partitioned programmability of UC resources of the processor by providing a processor comprising a set of at least two UCs and an ISA, wherein the UC is configured to store micro-operations decoded from instructions of a program to be executed by the processor, and the ISA is configured to support programmability of the set of two or more UCs of the processor by a program executed by the processor.

[0289] Fig.30 An example embodiment of a method for use by a processor to support programmability of a micro-operation cache resource of the processor is depicted. It will be understood that although primarily presented as being performed serially, at least a portion of the functionality of method 3000 may be performed simultaneously or in a different order than referenced. Fig.30 In block 3001, method 3000 begins. In block 3010, instructions of a program are decoded by a decode block of a processor having at least two micro-operation caches to form micro-operations. In block 3020, the micro-operations are stored in an active micro-operation cache in the micro-operation cache. In block 3099, method 3000 ends.

[0290] Fig.31 An example embodiment of a method for use by a processor to support programmability of a micro-operation cache resource of the processor is depicted. It will be understood that although primarily presented as being performed serially, at least a portion of the functionality of method 3100 may be performed simultaneously or in a different order than referenced. Fig.31 In block 3101, method 3100 begins. In block 3110, a program including an instruction set is executed by a processor. In block 3120, programmability of a set of two or more micro-operation caches of the processor is supported based on the execution of the program by an instruction set architecture (ISA) of the processor. In block 3199, method 3100 ends.

[0291] Fig.32 An example embodiment of a method for use by a processor to support programmability of processor front-end resources is depicted. It will be understood that although primarily presented as being performed serially, at least a portion of the functionality of method 3200 may be performed simultaneously or in a different order than referenced. Fig.32 In block 3201, method 3200 begins. In block 3210, a program including an instruction set is executed by a processor. In block 3220, programmability of a processor front-end resource set of the processor is supported by an instruction set architecture (ISA) of the processor based on execution of the program. In block 3299, method 3200 ends.

[0292] It will be understood that while this document is primarily presented in the context of particular types of processors (e.g., CISC, superscalar, etc.) supporting particular types of processor architectures (e.g., x86) and microarchitectures, the various example embodiments presented herein may be provided in the context of various other types of processors (e.g., RISC, etc.), may be provided in the context of processors supporting various other processor architectures (e.g., ARM, MIPS, etc.), may be provided in the context of processors supporting various other processor microarchitectures, and the like, as well as various combinations thereof.

[0293] It will be appreciated that, although this document is primarily presented in the context of a processor described without reference to a processor core (e.g., a single-core processor), the various example embodiments presented herein may be provided in the context of a multi-core processor. It will be appreciated that in at least some such multi-core processors, some or all of the processor cores may have a front end and a back end, respectively. Thus, in at least some embodiments, references to a "processor" herein may be considered to refer to individual "processor cores" of a multi-core processor (and thus support split programmability of front-end resources of individual processor cores of a processor).

[0294] Various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may provide various advantages or potential advantages. For example, various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may improve the throughput from the front end of the processor to the back end of the processor. For example, various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may reduce or minimize power consumption by a decoding circuit of the processor front end. For example, various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may support more stringent processor performance requirements. For example, various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may support improved or optimized packet throughput and power efficiency of a processor that implements an NFV solution. Various example embodiments of the partitioned programmability of resources for supporting the processor front end of a processor may provide various other advantages or potential advantages.

[0295] Fig.33 An example embodiment of a computer that can utilize the various functionality presented herein is depicted.

[0296] Computer 3300 includes processor 3302 (eg, central processing unit, processor, processor having a collection of processor cores, processor cores of processors, etc.) and memory 3304 (eg, random access memory, read-only memory, etc.). Processor 3302 and memory 3304 may be communicatively connected.

[0297] The computer 3300 may also include a cooperating element 3305. The cooperating element 3305 may be a hardware device. The cooperating element 3305 may be a process that may be loaded into the memory 3304 and executed by the processor 3302 to implement the functionality discussed herein (in which case the cooperating element 3305 (including associated data structures) may be stored on a non-transitory computer-readable storage medium, such as a storage device or other storage element (e.g., a magnetic drive, an optical drive, etc.)).

[0298] The computer 3300 may also include one or more input / output devices 3306. The input / output devices 3306 may include one or more user input devices (e.g., keyboard, keypad, mouse, microphone, camera, etc.), user output devices (e.g., display, speaker, etc.), one or more network communication devices or elements (e.g., input ports, output ports, receivers, transmitters, transceivers, etc.), one or more storage devices (e.g., tape drive, floppy disk drive, hard disk drive, compact disk drive, etc.), etc., and various combinations thereof.

[0299] It will be appreciated that the computer 3300 may represent general architecture and functionality suitable for implementing the functional elements described herein, portions of the functional elements described herein, etc., and various combinations thereof. For example, the computer 3300 may provide general architecture and functionality suitable for implementing or using the processors presented herein.

[0300] It will be understood that at least some of the functionality presented herein may be implemented in software (e.g., via software implementation on one or more processors for execution on a general purpose computer (e.g., via execution by one or more processors to provide a special purpose computer, etc.) and / or may be implemented in hardware (e.g., using a general purpose computer, one or more application specific integrated circuits and / or any other hardware equivalents).

[0301] It will be appreciated that at least some of the functionality presented herein may be implemented in hardware, e.g., as circuits that cooperate with a processor to perform various functions. Portions of the functionality / elements described herein may be implemented as a computer program product, wherein computer instructions, when processed by a computer, adapt the operation of the computer so that the methods and / or techniques described herein are invoked or otherwise provided. Instructions for invoking various methods may be stored in fixed or removable media (e.g., non-transient computer-readable media), transmitted via a data stream in a broadcast or other signal-bearing medium, and / or stored in a memory within a computing device that operates according to the instructions.

[0302] It will be understood that the term "or" as used herein refers to a non-exclusive "or" unless otherwise indicated (eg, using "or otherwise" or "in the alternative").

[0303] It will be appreciated that although various embodiments that incorporate the teachings presented herein have been shown and described in detail herein, those skilled in the art can readily devise numerous other varied embodiments that still incorporate these teachings.< / opcode>

Claims

1. A device for programmable control, comprising: A processor comprising a set of at least two micro-op caches configured to store micro-ops decoded from instructions of a program to be executed by the processor; wherein the processor is configured to support selection of one of the micro-operation caches as an active micro-operation cache based on a micro-operation cache switching instruction; as well as The micro-operation cache switching instruction includes a micro-operation cache identifier, and the micro-operation cache identifier indicates one of the micro-operation caches as the active micro-operation cache among the micro-operation caches.

2. The device according to claim 1, wherein: The processor is configured to activate only one micro-operation cache from the set of at least two micro-operation caches for storing or accessing micro-operations at any time during execution of the program by the processor.

3. The apparatus of claim 1 , wherein the processor comprises a set of instruction decoders, wherein during decoding of one of the instructions of the program, the set of instruction decoders stores a micro-operation into an active micro-operation cache in the micro-operation cache. 4 . The apparatus according to claim 1 , wherein the processor is configured to perform a lookup operation in an active micro-operation cache of the micro-operation cache while obtaining an instruction pointer IP of an instruction of the program.

5. The apparatus of claim 1 , wherein the processor is configured to select a first micro-operation cache in the micro-operation caches as an active micro-operation cache, wherein the micro-operation cache switching instruction includes an identifier of a second micro-operation cache in the micro-operation caches, wherein decoding of the micro-operation cache switching instruction causes the active micro-operation cache to switch from the first micro-operation cache in the micro-operation caches to the second micro-operation cache in the micro-operation caches.

6. The apparatus of claim 1 , wherein the processor is configured to decode a micro-operation cache switching instruction of the program so that a first micro-operation cache in the micro-operation caches is selected as an active micro-operation cache, wherein micro-operations decoded from one or more subsequent instructions of the program are stored in the first micro-operation cache in the micro-operation caches until a next micro-operation cache switching instruction is decoded to change the active micro-operation cache to a second micro-operation cache in the micro-operation caches.

7. The apparatus of claim 1 , wherein the processor is configured to select a first micro-operation cache among the micro-operation caches as an active micro-operation cache, wherein the processor is configured to switch the active micro-operation cache to the second micro-operation cache among the micro-operation caches before decoding a next instruction of the program associated with the second micro-operation cache among the micro-operation caches.

8. The apparatus of claim 1 , wherein the processor is configured to select a first micro-operation cache in the micro-operation caches as an active micro-operation cache, wherein the processor is configured to switch the active micro-operation cache to a second micro-operation cache in the micro-operation caches based on the micro-operation cache switching instruction before executing micro-operations decoded based on the micro-operation cache switching instruction.

9. The apparatus of claim 1, wherein the processor comprises an instruction set architecture (ISA) configured to support programmability of the set of micro-operation caches by the program.

10. The apparatus of claim 1, wherein the processor comprises: An instruction set architecture (ISA) is configured to support programmability of a set of two or more micro-operation caches of the processor by a program executed by the processor.

11. The apparatus of claim 10, wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support association of a control block of the program with one of the micro-operation caches.

12. The apparatus of claim 10, wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support sharing of one of the micro-operation caches by two or more control blocks of the program.

13. The apparatus of claim 10 , wherein the program includes a set of control blocks, wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support distribution of the control blocks of the program over at least a portion of the micro-operation caches by the program.

14. The apparatus of claim 10, wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support instructions configured to switch an active one of the micro-operation caches.

15. The apparatus of claim 10, wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support instruction types specifically configured for selecting one of the micro-operation caches as the active micro-operation cache.

16. The apparatus of claim 10 , wherein to support programmability of the set of micro-operation caches by the program, the ISA is configured to support an instruction type configured to provide program control functionality of the program and further configured to support selection of one of the micro-operation caches as the active micro-operation cache.

17. The apparatus of claim 10 , wherein in order to support programmability of the set of micro-operation caches by the program, the ISA is configured to support pinning a control block of the program to one of the micro-operation caches, such that micro-operations decoded based on instructions of the control block are accessed from or stored in the one of the micro-operation caches.

18. The apparatus of claim 10 , wherein a first control block and a second control block of the program are associated with a first micro-operation cache and a second micro-operation cache of the corresponding micro-operation caches, wherein the ISA is configured to support a micro-operation cache switching instruction, which, before transferring control from the first control block to the second control block, causes the active micro-operation cache to switch from the first micro-operation cache of the micro-operation cache to the second micro-operation cache of the micro-operation cache when called by the program with an identifier of the second control block.

19. The apparatus of claim 1, wherein the processor comprises a back end, a front end having front end resources, and an instruction set architecture (ISA), wherein the processor is configured to execute a program; wherein the front end is configured to decode instructions of the program to provide a set of micro-operations to the back end; wherein the back end is configured to receive the micro-operation from the front end and execute the micro-operation; Wherein the ISA is configured to support programmability of the set of front-end resources of the front-end by the program.

20. A method for programmable control, comprising: selecting, by a processor having at least two micro-operation caches, one of the micro-operation caches as an active micro-operation cache based on a micro-operation cache switching instruction, the at least two micro-operation caches being configured to store micro-operations decoded from instructions of a program to be executed by the processor, wherein the micro-operation cache switching instruction comprises a micro-operation cache identifier, the micro-operation cache identifier indicating one of the micro-operation caches as the active micro-operation cache among the micro-operation caches; Decoding the instructions of the program by a decoding block of the processor to form micro-operations; as well as The micro-operations are stored in the active micro-operation buffer.

21. The method according to claim 20, comprising: executing a program comprising a set of instructions by a processor; as well as Programmability of a set of two or more micro-operation caches of the processor is supported by an instruction set architecture ISA of the processor based on execution of the program.

Images