Processor and processor architecture thereof

Abstract

Embodiments of an invention a processor architecture are disclosed. In an embodiment, a processor includes a decoder, an execution unit, a coherent cache, and an interconnect. The decoder is to decode an instruction to zero a cache line. The execution unit is to issue a write command to initiate a cache line sized write of zeros. The coherent cache is to receive the write command, to determine whether there is a hit in the coherent cache and whether a cache coherency protocol state of the hit cache line is a modified state or an exclusive state, to configure a cache line to indicate all zeros, and to issue the write command toward the interconnect. The interconnect is to, responsive to receipt of the write command, issue a snoop to each of a plurality of other coherent caches for which it must be determined if there is a hit.

Description

[Technical Field]

[0001] The field of the present invention generally relates to computers, and more specifically to processor architecture. [Previous Technology]

[0002] A processor comprises a number of interconnected circuits and structures that work together to execute instructions and process information. These circuits and structures, and the features they provide, can be included in a processor in many different configurations and combinations. [Summary of the Invention]

[0003] and

Implementation Method

[0071] Numerous specific details are set forth in the following description. However, it should be understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques are not shown in detail in order to avoid hindering the understanding of this specification.

[0072] References to "an embodiment," "embodiment," "exemplary embodiment," etc., in the specification indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment need not necessarily include specific features, structures, or characteristics. Furthermore, such terms do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, it is considered that, within the knowledge of those skilled in the art, such features, structures, or characteristics can be incorporated into other embodiments.

[0073] An apparatus for processing information (such as a computer) may include one or more processor cores. Each processor core may include various circuitry, hardware, architecture, and other features, wherein each individually or in any combination thereof may be referred to as a feature. Features may be implemented and / or configured in various ways, employ various techniques, and may participate in various methods to attempt to implement desired levels of performance, power consumption, and / or other characteristics in various combinations (e.g., improving performance, reducing power consumption and implementing power-saving features, and improving fairness, minimum performance guarantees, throughput, instructions per clock cycle (IPC), instructions per unit time, quality of service, time and / or memory efficiency, to name only a few applicable criteria). Embodiments of the invention may include one or more features described herein. Some examples of the architecture and systems that may embody the invention are provided in the drawings and description herein.

[0074] It can be embodied that the processor core of the present invention can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such a core may include: 1) a general-purpose ordered core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core primarily intended for graphics and scientific (throughput) computing. Implementations in different processors may include: 1) a central processing unit (CPU) including one or more general-purpose ordered cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor including one or more special-purpose cores primarily intended for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate die from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (in this case, such a coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and / or scientific (throughput) logic, or a special purpose core); and 4) a system-on-a-chip (SoC) (sometimes referred to as an application core or application processor) on the same die as the described CPU, the above coprocessors, and additional functionality.

[0075] Next, an exemplary core architecture is described, followed by an exemplary processor and computer architecture. Each processor may include one or more cores, wherein each core and / or combination of cores may be architectureized and designed to execute one or more threads, processes, or other sequences of instructions at various times. Core architecture and design techniques provide and / or support parallel execution of multiple threads according to any type of scheme called synchronous (or symmetric) multithreading (SMT) or any other scheme. Thus, processor cores that may embody the present invention, including those examples described below, may include various novel features architectureized and designed to support SMT and / or modified in various novel ways to support various known features of SMT, as described below. For ease of description, the term SMT in this specification may include a combination of SMT with any other method of multithreading (e.g., time truncation).

[0076] As mentioned above and explained more specifically below, embodiments of the present invention may be desirable for various reasons, including, for example, improved performance, reduced power consumption and implementation of power-saving features, and improved fairness, minimum performance guarantees, throughput, instructions per clock cycle (IPC), instructions per unit time, quality of service, time and / or memory efficiency, to name only a few applicable criteria. The criteria listed above and described herein are exemplary; as explained herein, the present invention may be desirable for any individual or combination of the reasons listed above, and may be further desirable for other reasons not specifically listed above.

[0077] Furthermore, as explained more specifically below as mentioned above, embodiments of the present invention are applicable to any type of processor or processing element, including general-purpose processors, server processors or processing elements for server environments, coprocessors (e.g., security coprocessors), high-throughput MIC processors, GPGPUs, accelerators (such as, for example, graphics accelerators or digital signal processing (DSP) units, cryptographic accelerators, fixed-function accelerators, machine learning accelerators, network accelerators, or computer vision accelerators), field-programmable gate arrays, or any other processor or processing device. The processor or processors may be implemented on one or more wafers. The processor or processors 3600 may be part of one or more substrates using any number of processing technologies (such as BiCMOS, CMOS, or NMOS) and / or may be implemented on one or more substrates using any number of processing technologies (such as BiCMOS, CMOS, or NMOS). The processors and processing devices listed above and described herein are exemplary; as explained herein, the present invention is applicable to any processor or processing device.

[0078] Furthermore, as mentioned above and described in detail below, embodiments of the present invention can be applied to processors or processing elements using various instruction sets and instruction set architectures, including, for example, the x86 instruction set (selectively including extensions that have been updated to newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sun Valley, California; the ARM instruction set of ARM Holdings, Inc., Sun Valley, California (with selective additional extensions, such as NEON); IBM's "Power" instruction set or any other instruction set, including both RISC and CISC instruction sets. The instruction sets and instruction set architectures listed above and described herein are exemplary; as explained herein, the present invention is applicable to any instruction set or instruction set architecture. Core Architecture Examples: Ordered and Out-of-Order Core Block Diagrams

[0079] Figure 1A illustrates a block diagram of an exemplary ordered pipeline and an exemplary register renaming and out-of-order issuance / execution pipeline according to an embodiment of the present invention. Figure 1B illustrates a block diagram of an exemplary embodiment of an ordered architecture core included in a processor and an exemplary register renaming and out-of-order issuance / execution architecture core according to an embodiment of the present invention. Solid lines in Figures 1A-B represent ordered pipelines and ordered cores, while selective addition of dashed lines represents register renaming, out-of-order issuance / execution pipelines and cores. The out-of-order state will be described assuming that the ordered state is a subset of the out-of-order state.

[0080] In Figure 1A, the processor pipeline 100 includes an extraction phase 102, a length decoding phase 104, a decoding phase 106, a configuration phase 108, a renaming phase 110, a scheduling (also known as scheduling or issuing) phase 112, a register read / memory read phase 114, an execution phase 116, a write-back / memory write phase 118, an exception handling phase 122, and a determination phase 124.

[0081] Figure 1B shows that processor core 190 includes a front-end unit 130 coupled to an execution engine unit 150, and both are coupled to a memory unit 170. Core 190 may be a Reduced Instruction Set Computing (RISC) core, a Complex Instruction Set Computing (CISC) core, a Very Long Instruction Word (VLIW) core, or a hybrid or other core type. Alternatively, core 190 may be a special-purpose core, such as a networking or communications core, a compression engine, a coprocessor core, a general-purpose graphics processing unit (GPGPU) core, or a graphics core. For example, as explained above, core 190 may include a general-purpose processor, server processor or processing element for server environments, a coprocessor (e.g., a security coprocessor), a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or digital signal processing (DSP) unit, a cryptographic accelerator, a fixed-function accelerator, a machine learning accelerator, a network accelerator or a computer vision accelerator), a field-programmable gate array, or any other processor or processing device.

[0082] Front-end unit 130 includes a branch prediction unit 132 coupled to micro-op cache 133 and instruction cache unit 134. Instruction cache unit 134 is coupled to instruction translation back buffer (TLB) 136, instruction translation back buffer (TLB) 136 is coupled to instruction fetch unit 138, and instruction fetch unit 138 is coupled to a decoding unit 140. Decoding unit 140 (or decoder) can decode instructions and generate one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as outputs, which are decoded from the original instructions, or otherwise reflected or derived from the original instructions. Micro-operations, microcode entry points, microinstructions, etc., can be stored at least in micro-op cache 133. Decoding unit 140 can be implemented using a variety of different mechanisms. Suitable embodiments of mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), etc. In one embodiment, core 190 includes a microcode ROM or other media for storing microcode for some macro instructions (e.g., within decoding unit 140 or otherwise within front-end unit 130). Micro-op cache 133 and decoding unit 140 are coupled to renaming / configurer unit 152 in execution engine unit 150. In various embodiments, micro-op caches such as 133 may also be referred to as op-cache, u-op cache, uop-cache, or μop-cache; and micro-operations may be referred to as micro-op, u-op, uop, and µop.

[0083] The execution engine unit 150 includes a renaming / configurer unit 152, which is coupled to a set of one or more scheduler units 156. The scheduler units 156 represent any number of different schedulers, including reserved stations, central command windows, etc. The scheduler units 156 are coupled to physical register file units 158. Each physical register file unit 158 ​​represents one or more physical register files, the differences of which store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer which is the address of the next instruction to be executed), etc. In one embodiment, the physical register file unit 158 ​​includes vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. Physical register file unit 158 ​​is overlapped by revocation unit 154 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer and revoking register files; using a future file, a history buffer, and revoking register files; using a register mapping table and a collection of registers, etc.). Revocation unit 154 and physical register file unit 158 ​​are coupled to execution cluster 160. Execution cluster 160 includes one or more sets of execution units 162 and one or more sets of memory access units 164. Execution units 162 can perform various operations (e.g., shift, addition, subtraction, multiplication) on various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only one or more execution units, all of which together perform all functions. Scheduler unit 156, physical register file unit 158, and execution cluster 160 are shown as possibly numerous because some embodiments generate separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines each have their own scheduler unit, physical register file unit, and / or execution cluster, and in the case of separate memory access pipelines, some embodiments are implemented in which only the execution cluster of this pipeline has memory access unit 164). It should also be understood that when using separate pipelines, one or more of these pipelines may be out-of-order issued / executed while the rest are ordered.

[0084] The memory access unit 164 is coupled to the memory unit 170, which includes a data TLB unit 172 coupled to a data cache unit 174 coupled to a level 2 (L2) cache unit 176. In an exemplary embodiment, the memory access unit 164 may include a load unit, a storage address unit, and a storage data unit, each unit being coupled to the data TLB unit 172 in the memory unit 170. The instruction cache unit 134 is further coupled to the level 2 (L2) cache unit 176 in the memory unit 170. The L2 cache unit 176 is coupled to one or more other level caches and ultimately coupled to main memory.

[0085] For example, the exemplary register renaming, out-of-order issuance / execution core architecture can implement the pipeline 100 as follows: 1) Instruction fetch 138 performs fetch and length decoding stages 102 and 104; 2) Decoding unit 140 performs decoding stage 106; 3) Rename / configurator unit 152 performs configuration stage 108 and rename stage 110; 4) Scheduler unit 156 performs scheduling stage 112; 5) Physical register file unit 158 ​​and memory unit 170 perform register read / memory read stage 114; execution cluster 160 performs execution stage 116; 6) Memory unit 170 and physical register file unit 158 ​​perform write-back / memory write stage 118; 7) Each unit may involve exception handling stage 122; and 8) Recall unit 154 and physical register file unit 158 ​​perform determination stage 124.

[0086] Core 190 may support one or more instruction sets including those described herein (e.g., the x86 instruction set including both RISC and CISC instruction sets (some extensions have been updated to include newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sun Valley, California; the ARM instruction set of ARM Holdings, Inc., Sun Valley, California (with optional additional extensions, such as NEON), IBM's "Power" instruction set, or any other instruction set). In one embodiment, core 190 includes support for compressed data instruction set extensions (e.g., AVX, AVX2, AVX-512), thereby allowing operations used by many multimedia applications to be performed using compressed data.

[0087] It should be understood that the core can support multithreading (execution of two or more parallel operations or sets of threads) and can achieve this support in a variety of ways, including time-triggered multithreading, SMT (e.g., a single physical core providing a logical core for each thread of synchronous multithreading), or a combination thereof (e.g., time-triggered extraction and decoding, and subsequent SMT, such as Intel® Hyperthreading technology).

[0088] Although register renaming is described in an out-of-order execution context, it should be understood that register renaming can be used in ordered architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units 134 / 174 and a shared L2 cache unit 176, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a level 1 (L1) internal cache, or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be located outside the core and / or processor. Specific exemplary core architecture

[0089] Figures 2A-B show block diagrams of a more specific exemplary core architecture, which will be one of several logic blocks in the chip (including other cores of the same and / or different categories). Depending on the application, the logic block communicates with certain fixed-function logic, memory I / O interfaces, and other required I / O logic through a high-bandwidth interconnect network (e.g., a ring network).

[0090] Figure 2A is a block diagram of a single processor core according to an embodiment of the present invention, together with a block diagram of its connection to the on-die interconnect 202 and a local subset thereof of the Level 2 (L2) cache 204. In one embodiment, the instruction decoder 200 supports the x86 instruction set with compressed data instruction set extensions. The L1 cache 206 allows low-latency access to cache memory to scalar and vector units. Although in one embodiment (for design simplification), scalar units 208 and vector units 210 use separate sets of registers (scalar register 212 and vector register 214, respectively), where data transferred between them is written to memory and then read back from the Level 1 (L1) cache 206, alternative embodiments of the present invention may use different methods (e.g., using a single set of registers or including a communication path that allows data to be transferred between two register files without being written and read back).

[0091] The local subset of L2 cache 204 is a general L2 cache portion, divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of L2 cache 204. Data read by a processor core is stored in its L2 cache subset 204 and can be accessed quickly alongside other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 204 and refreshed from other subsets if necessary. The ring network ensures synchronization of shared data. The ring network is bidirectional to allow intermediaries such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0092] Figure 2B is an expanded view of the processor core portion in Figure 2A according to an embodiment of the present invention. Figure 2B includes the L1 data cache 206A portion of the L1 cache 204, and further details regarding the vector unit 210 and the vector register 214. Specifically, the vector unit 210 is a 16-wide vector processing unit (VPU) (refer to 16-wide ALU 228), which executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports mixing register inputs with a mixing unit 220, performing numerical conversion with value conversion units 222A-B, and copying memory inputs with a copy unit 224. A write mask register 226 allows the writing of predicted vectors. Specific exemplary out-of-order core architecture

[0093] FIG3 is a block diagram of an illustrative out-of-order issuance / execution processor core that may be included in a processor according to an embodiment of the present invention. In FIG3, processor core 300 includes a front-end unit 310, an integer unit 320, an FP unit 330, a load-to-store unit 340, and a level 2 (L2) cache unit 350. FIG3 is provided for illustrative purposes and thus illustrates various units that may be configured and named according to many schemes according to embodiments of the present invention. Any one or more embodiments may be illustrated in one or more ways. Each unit shown in FIG3 may include circuitry and / or structures that may be included in other units in other representations of the embodiments. For example, front-end unit 310 may additionally or alternatively be shown and described as including fetch units (such as fetch unit 400 in FIG4) and decoding units (such as decoding unit 500 in FIG5); any or all of integer units 320, FP units 330, load-to-store units 340 may additionally or alternatively be shown and described (separately or collectively) as one or more execution units; and so on. Furthermore, the various units within the core 300 can be coupled in various ways; therefore, for convenience, different diagrams can be displayed in units within different large units; for example, a particular unit can be displayed in the first large unit in the first diagram and in the second large unit in the second diagram.

[0094] In FIG. 3, the front-end unit 310 includes a branch prediction unit 311, a micro-operation cache (op-cache) unit 312, an instruction cache (i-cache) unit 313, a decoding unit 314, and a micro-operation (micro-op) queue unit 315. The branch prediction unit 311 includes branch prediction circuitry (such as a branch target buffer (BTB)) for reducing average branch latency and is coupled to the op-cache unit 312 and the i-cache unit 313. The op-cache unit 312 includes an op-cache for caching micro-ops associated with instructions. The i-cache unit 313 includes, in embodiments, an i-cache that may cache 64K of instructions in a quad i-cache configuration. The i-cache unit 313 is coupled to the decoding unit 314 to provide cached instructions for decoding. The decoding unit 314 includes decoding circuitry, such as an instruction decoder for decoding instructions. In one embodiment, the front-end unit 310 can fetch and the decoding unit 314 can decode up to four instructions per clock cycle. The op-caching unit 312 and the decoding unit 314 are each coupled to the micro-op queue unit 315 to provide two paths for loading micro-ops into the micro-op queue unit 315. The micro-op queue unit 315 includes a micro-op queue, which in one embodiment can schedule six micro-ops to one or more execution units per cycle.

[0095] Also in Figure 3, the integer unit 320 includes an integer renaming unit 321; integer scheduler units 322A, 322B, 322C, 322D, 322E, and 322F (collectively referred to as integer scheduler unit 322); an integer entity temporary register file 323; arithmetic logic units (ALUs) 324A, 324B, 324C, and 324D (collectively referred to as ALU 324); and address generation units (AGUs) 325A and 325B (collectively referred to as AGU 325). The integer renaming unit 321 is coupled to the micro-op queue unit 315 to receive one or more micro-ops that will be fully or partially executed by one or more ALUs 324 and / or AGUs 325. Integer renaming unit 321 includes register renaming circuitry and is also coupled to integer scheduler unit 322, which is in turn coupled to integer physical register file 323 to provide integer register renaming. Integer scheduler unit 322 includes scheduler circuitry for scheduling micro-operations fully or partially executed by one or more ALUs 324 and / or AGUs 325. Integer physical register file 323 includes a file of physical integer registers, which in one embodiment may include 168 physical integer registers. Each ALU 324 and AGU 325 is coupled to physical register file 323 to receive values ​​to be used as inputs in the execution of the micro-operation and / or to provide values ​​as outputs of the micro-operation.

[0096] Also in Figure 3, the FP unit 330 includes an FP renaming unit 331, an FP scheduler unit 332, an FP register file 333, FP multipliers 334A and 334B (collectively referred to as FP multipliers 334), and FP adders 335A and 335B (collectively referred to as FP adders 335). The FP renaming unit 331 is coupled to the micro-op queue unit 315 to receive one or more micro-ops to be fully or partially executed by one or more FP multipliers 334 and / or FP adders 335. The FP renaming unit 331 includes register renaming circuitry and is also coupled to the FP scheduler unit 332, which is in turn coupled to the FP register file 333 to provide FP register renaming. The FP scheduler unit 332 includes scheduler circuitry for scheduling micro-operations (MOPs) that are fully or partially executed by one or more FP multipliers 334 and / or FP adders 335. Each FP multiplier 334 and FP adder 335 is coupled to an FP register file 333 to receive values ​​to be used as inputs to the execution of the MOP and / or to provide values ​​as outputs of the MOP's execution.

[0097] Also in FIG3, the load storage unit 340 includes a load storage queue unit 341 and a data cache (d-cache) unit 342. The load storage queue unit 341 may include any number of load and / or store queues coupled to the AGU 325 (in one embodiment, two loads and one store are provided for each clock cycle) to receive memory addresses for load and / or store operations. The d-cache unit 342 includes a d-cache, which in one embodiment may be a 32K, eight-way level 1 (L1) d-cache coupled to the integer entity register file 323, the FP register file 333 and the load storage queue unit 341 for caching data, to receive and provide data generated by the execution of the micro-op and used for the execution of the micro-op.

[0098] Also in Figure 3, the L2 cache unit 350 includes an L2 cache, which in one embodiment may be a 512K, eight-way cache in which instructions and data are cached.

[0099] FIG4 is a block diagram of an illustrative extraction unit according to an embodiment of the present invention. The extraction unit may be included in a processor core such as core 300 of FIG3 and / or a processor. In FIG4, the extraction unit 400 includes a next program counter (PC) unit 410, a transform backstop buffer (TLB) unit 420, a hash sensing unit 430, a BTB return stack indirect target array (ITA) unit 440, an entity request queue unit 450, a microtag unit 460, and an i-caching unit 470.

[0100] FIG5 is a block diagram of an illustrative decoding unit according to an embodiment of the present invention. The decoding unit may be included in a processor core such as core 300 of FIG3 and / or a processor. In FIG5, the decoding unit 500 includes an instruction byte buffer unit 510, a pickup unit 520, a decoding unit 530, an op-cache unit 540, a micro-op queue unit 550, a microcode read-only memory (ROM) unit 560, a stack engine memory file (memfile) unit 570, and a scheduling unit 580.

[0101] FIG6 is an illustrative block diagram of an integer execution unit according to an embodiment of the present invention. The integer execution unit may be included in a processor core such as core 300 of FIG3 and / or a processor. In FIG6, the integer execution unit 600 includes a mapping unit 610; a recall queue unit 620; arithmetic logic queue (ALQ) units 630A, 630B, 630C and 630D (collectively referred to as ALQ 630); address generation queue (AGQ) units 640A and 640B (collectively referred to as AGQ 640); a physical register file unit 650; a forwarding multiplexer (mux) unit 660; ALUs 670A, 670B, 670C and 670D (collectively referred to as ALU 670); AGUs 680A and 680B (collectively referred to as AGU 680); and a load memory unit 690.

[0102] FIG7 is a block diagram of an illustrative FP execution unit according to an embodiment of the present invention. The FP execution unit may be included in a processor core such as core 300 of FIG3 or a processor. In FIG7, the FP execution unit 700 includes a non-schedulable micro-op queue unit 710, a scheduleable micro-op queue unit 720, a reschedulable queue unit 730, an FP conversion unit 740, an FP entity register file 750, a forwarding mux unit 760, FP multipliers 770A and 770B (collectively referred to as FP multiplier 770), and FP adders 780A and 780B (collectively referred to as FP adder 780).

[0103] FIG8 is an illustrative block diagram of a load / store unit according to an embodiment of the present invention. The load / store unit may be included in a processor core such as core 300 of FIG3 or a processor. In FIG8, the load / store unit 800 includes a load queue unit 810, load pipeline pickup units 811A and 811B (collectively referred to as load pickup unit 811), TLB units 812A and 812B (collectively referred to as TLB unit 812), data pipeline units 813A and 813B (collectively referred to as data pipeline unit 813), a store queue unit 820, a prefetch unit 821, a store pipeline pickup unit 822, a store pipeline unit 823, a store commit unit 824, an L1 / L2 TLB and data cache tag array 830, an L1 data cache 840, a memory address buffer 850, and a write combination buffer 860.

[0104] FIG9 is an illustrative block diagram of an out-of-order signature / execution processor core such as the core 300 of FIG3 that supports SMT in a processor according to an embodiment of the present invention. In FIG9, the processor core 900 includes a front-end unit 910, an integer unit 920, an FP unit 930, a load-to-store unit 940, an L2 cache unit 950, and a rollback unit 960. The front-end unit 910 includes a branch prediction unit 911, an op-cache unit 912, an i-cache unit 913, a decoding unit 914, a micro-op-query unit 915, and an instruction TLB unit 916. The integer unit 920 includes an integer renaming unit 921, an integer scheduler unit 922, an integer entity temporary register file 923, an ALU 924, and an AGU 925. FP unit 930 includes an FP renaming unit 931, an FP scheduler unit 932, an FP temporary register file 933, FP multipliers 934A and 934B (collectively referred to as FP multipliers 934), and FP adders 935A and 935B (collectively referred to as FP adders 935). Load-to-store unit 940 includes a load queue unit 941A and a store queue unit 941B (collectively referred to as load-to-store queue unit 941), a data cache (d-cache) unit 942, and a TLB unit 943. Undo unit 960 includes an undo queue. SMT features

[0105] The processor core according to embodiments of the present invention may include various features supporting SMT. Several such features are described separately below using non-limiting examples, but embodiments may include any combination of such features. Static partitioning of resources

[0106] The processor core may support the SMT static partitioning feature according to some exemplary embodiments. Threads may be allocated to available resources, which are statically shared in a synchronous multi-threaded pipeline. In some embodiments, threads may be allocated to available resources based on an algorithm using methods such as patterned counting to improve performance and efficiency. In some embodiments, this feature may improve the computer system by providing more efficient resource sharing among threads used for statically sharing resources. It may also utilize available resources that would otherwise remain unused due to SMT static partitioning.

[0107] For example, resources in the pipeline can be statically shared (e.g., 50%-50%) between two threads to provide equal resources to both threads. In some embodiments, a different percentage of available resources can be allocated to each thread, for example, based on workload patterns. For example, if one thread is stalled for a longer time than another thread and there are empty entries available for the other thread, the available entries can be allocated to the stalled thread instead of leaving them empty in the statically shared resources.

[0108] In some embodiments, more than one thread may have a similar configuration. In this case, a priority scheme can be used to allocate resources in the case of connections between threads. For example, connection interruption can be performed by random selection, selection of a thread with a lower number, selection of a thread with a higher number, and / or selection of an alternating thread.

[0109] Figure 10 is a block diagram illustrating an SMT static partitioning feature that may be included in a processor according to some embodiments. According to an exemplary embodiment, the SMT static partitioning feature may include a pattern detection block 1001. First and second resources may be statically allocated to threads T0 and T1. A lookup of the pattern base table can determine that thread T1 has a long pause time. The pattern detection block can then adjust the statically allocated resources based on pattern input. For example, a second resource statically allocated to T1 may be allocated to T0.

[0110] In some embodiments, dynamic partitioning can be applied to other static partitioning resources, such as instruction translation back buffer (ITLB).

[0111] Figure 11 is a flowchart illustrating a method for SMT static partitioning features that can be executed by a processor, according to some embodiments. In some embodiments, the method may include detecting patterns of thread pauses, such as those involving static shared resources in a pipeline, as shown in block CQB01. The method may also include adjusting the sharing (e.g., 50-50 sharing), as shown in block CQB02. The method adjustment may be based, for example, on the length of the pause or some other similar event. Summary of some embodiments

[0112] An embodiment may include a processor configured to detect the type of at least one of the first and second static partition resources; and adjust the allocation of at least one of the first and second static partition resources.

[0113] In some embodiments, one or more of the following apply. The first and second static partition resources of the pipeline may be resources of a synchronous multithreaded pipeline. The first and second static partition resources may be located between the first and second threads. The processor may be further configured to allocate the first and second resources based on a type-based algorithm. The processor may be further configured to allocate at least one of the first and second resources based on one or more workload types. The processor may be further configured to allocate at least one of the first and second resources based on a determination that at least one of the first and second threads has paused for a longer period than the other. The processor may be further configured to allocate at least one of the first and second resources based on a determination that there is an empty entry associated with at least one of the available first and second resources, and to allocate at least one of the first and second threads to at least one of the available first and second resources. The processor may be further configured to allocate at least one of the first and second resources based on a priority scheme. The processor may be further configured to determine whether a pause has occurred based on a lookup type base table. The first and second static partition resources may be resources of an instruction translation back buffer (ITLB).

[0114] An embodiment may include a method comprising detecting the type of at least one of the first and second static partition resources; and adjusting the allocation of at least one of the first and second static partition resources.

[0115] In some embodiments, one or more of the following apply. The first and second static partition resources may be resources of a synchronous multithreaded pipeline. The first and second static partition resources may be located between the first and second threads. The method may further include allocating the first and second resources based on a type-based algorithm. The method may further include allocating at least one of the first and second resources based on one or more workload types. The method may further include allocating at least one of the first and second resources based on a determination that at least one of the first and second threads has paused for a longer period than the other. The method may further include allocating at least one of the first and second resources based on a determination that there is an empty entry associated with at least one of the available first and second resources, and allocating at least one of the first and second threads to at least one of the available first and second resources. The method may further include allocating at least one of the first and second resources based on a priority scheme. The method may further include determining whether a pause has occurred based on a lookup type base table. The first and second static partition resources may be resources of an instruction translation back buffer (ITLB).

[0116] An embodiment may include a non-transitory machine-readable medium storing at least one instruction, which, when executed by a processor, causes the processor to execute a method, the method comprising detecting the type of at least one of first and second static partition resources; and adjusting the allocation of at least one of the first and second static partition resources.

[0117] In some embodiments, one or more of the following apply. The first and second static partition resources may be resources of a synchronous multithreaded pipeline. The first and second static partition resources may be located between the first and second threads. The method may further include allocating the first and second resources based on a type-based algorithm. The method may further include allocating at least one of the first and second resources based on one or more workload types. The method may further include allocating at least one of the first and second resources based on a determination that at least one of the first and second threads has paused for a longer period than the other. The method may further include allocating at least one of the first and second resources based on a determination that there is an empty entry associated with at least one of the available first and second resources, and allocating at least one of the first and second threads to at least one of the available first and second resources. The method may further include allocating at least one of the first and second resources based on a priority scheme. The method may further include determining whether a pause has occurred based on a lookup type base table. The first and second static partition resources may be resources of an instruction translation back buffer (ITLB).

[0118] An embodiment may include a system containing memory and a processor configured to detect the type of at least one of the first and second static partition resources; and adjust the allocation of at least one of the first and second static partition resources.

[0119] In some embodiments, one or more of the following apply. The first and second static partition resources may be resources of a synchronous multi-threaded pipeline. The first and second static partition resources may be located between the first and second threads. The processor may be further configured to allocate the first and second resources based on a type-based algorithm. The processor may be further configured to allocate at least one of the first and second resources based on one or more workload types. The processor may be further configured to allocate at least one of the first and second resources based on a determination that at least one of the first and second threads has paused for a longer period than the other. The processor may be further configured to allocate at least one of the first and second resources based on a determination that there is an empty entry associated with at least one of the available first and second resources, and allocate at least one of the first and second threads to at least one of the available first and second resources. The processor may be further configured to allocate at least one of the first and second resources based on a priority scheme. The processor may be further configured to determine whether a pause has occurred based on a lookup type base table. The first and second static partition resources may be resources of an instruction translation back buffer (ITLB). Resource contention and sharing.

[0120] The processor core may support SMT with contention-based resource sharing according to embodiments of the present invention. Circuitry, architecture, or other resources in the core may be shared by multiple threads based on a policy of contention for priority among the threads. In the embodiment of FIG9, each of the following resources may be shared between or within threads based on a contention policy: branch prediction unit 911, op-cache unit 912, i-cache unit 913, decoding unit 914, instruction TLB unit 916, integer renaming unit 921, integer scheduler unit 922, integer entity register file 923, ALU 924, AGU 925, FP renaming unit 931, FP scheduler unit 932, FP register file 933, FP multipliers 934A and 934B, FP adders 935A and 935B, load queue unit 941A, d-cache unit 942, and TLB unit 943.

[0121] Some of these resources (such as buffers in integer renaming unit 921, integer scheduler unit 922, FP renaming unit 931, FP scheduler unit 932, or load queue unit 941A) may have entries, subunits, or other portions that can be separately allocated to threads. For convenience, this type of resource may be referred to as a divisible resource, and this type of allocation may be referred to as a partial allocation. Furthermore, each individual ALU of ALU 924, each individual AGU of AGU 925, FP multiplier 934A, FP multiplier 934B, FP adder 935A, or FP adder 935B may be fully allocated only to a specific clock cycle, a set of consecutive clock cycles to complete an operation, or other time periods or durations of operations. For convenience, this type of resource may be referred to as an indivisible resource, and this type of allocation may be referred to as a full allocation.

[0122] FIG12 is a block diagram illustrating a resource allocator 1200 that may be included in a processor according to an embodiment of the present invention. The resource allocator 1200 may include circuitry, structures, and / or hardware for allocating core circuitry, structures, units, or resources, or any portion thereof, to a particular thread. In embodiments, the resource allocator 1200 may be implemented to allocate a single resource and / or multiple resources. In any case, the processor or processor core may include multiple instances of one or more embodiments of the resource allocator 1200, each instance allocating any one or more resources, each resource including any one or more blocks shown in FIG12, and each resource implementing any one or more resource allocation policies or combinations of resource allocation policies.

[0123] The resource allocator 1200 may include a tracker circuit 1210, a policy circuit 1220, a decision circuit 1230, and an allocator circuit 1240. The tracker circuit may include one or more of a performance history circuit 1212, a usage history circuit 1214, and a thread state circuit 1216. The policy circuit 1220 may include one or more of a power policy circuit 1222, a fairness policy circuit 1224, a performance guarantee policy circuit 1226, and a flux policy circuit 1228. Embodiments may include combining and / or implementing each of these circuits in various ways according to the type and quantity of resources to be allocated and the required policies.

[0124] The performance history circuit 1212 may include circuitry, structures, and / or hardware for monitoring, tracking, recording, and / or reporting the performance of threads in one or more ways. In one embodiment, the performance history circuit 1212 may include one or more hardware counters 1212A for each thread to calculate one or more performance measurements for each thread, such as instructions to withdraw at certain measurement times or durations. For example, the measurement time or duration may be a window of clock cycles, wherein the size of the window (e.g., represented by the letter "N") may be fixed (e.g., wired), configurable (e.g., by hardware or firmware), and / or programmable (e.g., by software). In one embodiment, N may be 1024.

[0125] The performance history circuit 1212 may also include one or more hardware comparators 1212B for comparing the performance of a thread (e.g., as measured by counter 1212A) with one or more other threads. For example, at the end of each window of N clock cycles, the hardware comparator 1212B may compare the number of instructions withdrawn by the first thread during the window period with the number of instructions withdrawn by the second thread during the window period, and the counter 1212A may be reset for the next window. During the next window period, the comparison result with the previous window may be used by the policy circuit 1220 and / or decision circuit 1230 as described below. In embodiments, the comparison result may be a ranking of threads (e.g., which thread withdraws more instructions), a ratio (e.g., a calculation or approximation of the ratio of the number of instructions withdrawn by the first thread to the number of instructions withdrawn by the second thread), and / or any other measurement or calculation.

[0126] Embodiments may include more than one counter per thread. For example, each thread may have two separate counters: a first counter to track instructions identified as "power-intensive" (e.g., those whose execution typically consumes more power than other instructions) and a second counter to count other (i.e., non-power-intensive) instructions. For example, AVX-512 FMA instructions (as defined below) may be identified as power-intensive and tracked using a separate counter (possibly along with other power-intensive instructions).

[0127] The usage history circuit 1214 may include circuitry, structures, and / or hardware used by threads to monitor, track, record, and / or report resource usage. In one embodiment, the usage history circuit 1214 may include one or more hardware counters 1214A for counting resource usage for each thread and one or more hardware comparators 1214B for comparing resource usage between threads. One or more results from the counters 1214A and / or the comparators 1214B may be used by the policy circuitry 1220 and / or the decision circuitry 1230 as described below.

[0128] For example, for a divisible resource such as a buffer, a counter may count the number of entries occupied by threads. The count used for further calculations and / or allocation decisions may be the current count reported or used directly at any point in time, and / or may be an average count averaged over a window (e.g., a window of size N as described above). For an indivisible resource, the count used for further calculations and / or allocation decisions may be a time-averaged or time-weighted count (e.g., the number of times a thread uses the resource within a time window, where the count is reset at the end of each time window, or the count is reset when it is right-shifted (divided by a power of two) at the end of each time window). The result based on any of these counts may be the count itself, the count's rank for each thread, and / or the count's thread-to-thread ratio.

[0129] The thread status circuit 1216 may include circuitry, structures, and / or hardware for monitoring, tracking, recording, and / or reporting the status of threads. For example, the thread status circuit 1216 may include reporting whether a thread is currently stalled, such as due to a long latency L2 / L3 or other thread loss.

[0130] The historical and current information reported by the tracker circuit 1210 can be used by the resource allocation calculation unit and decisions based on the policies specified by the policy circuit 1220. These policies may include any type of policy with any priority and in any combination, including considerations of power consumption, fairness, minimum efficiency guarantees, and flux.

[0131] The power policy circuit 1222 may include circuitry, architecture, and / or hardware for implementing one or more power policies and / or favoring or selecting threads based on such policies or such policies. These policies may include any type of power policy with any priority and in any combination. For example, threads that use less power-consuming instructions or threads that progress slowly may be favored or selected.

[0132] The fairness policy circuit 1224 may include circuitry, structures, and / or hardware for implementing one or more fairness policies and / or favoring or selecting execution threads based on such policies or such policies. For example, execution threads with lower recent performance, lower occupancy of divisible resources, and / or lower recent utilization of indivisible resources may be advantageous or selected.

[0133] The performance guarantee policy circuit 1226 may include circuitry, structures, and / or hardware for implementing one or more minimum performance guarantee policies and / or favoring or selecting threads based on such policies or such policies. For example, threads performing below certain minimum threshold values ​​may be favored or selected based on performance guarantee policies.

[0134] The flux policy circuit 1228 may include circuitry, structures, and / or hardware for implementing one or more flux policies and / or favoring or selecting one or more threads based on such policies or the policies. For example, a thread that progresses relatively more or faster than other threads may be favored or selected.

[0135] Any or all of the power policy circuits 1222, fairness policy circuit 1224, performance guarantee policy circuit 1226, flux policy circuit 1228, and / or any other policy circuit may include separate storage locations or registers for storing information and / or standards, enabling, modifying (e.g., strengthening or weakening the policy or the importance of one or more standards or measurements used by the policy) or otherwise dynamically influencing the policy. Embodiments may also or alternatively include a central or shared storage location or register for this information. Any or more separate or grouped storage locations are represented as policy registers 1220A. In embodiments, any such storage location or register may be configured (e.g., by hardware or firmware) or programmed (e.g., by software).

[0136] The decision circuit 1230 may include circuitry, structure, and / or hardware for receiving information, results, and / or signals from the tracker circuit 1210 and from the policy circuit 1220, to use, weight, prioritize, filter, compare, combine, replace, or otherwise process information to generate one or more indications or signals that may lead to the selection of threads for resource allocation and / or a decision. For example, in an embodiment that includes a throughput policy and a minimum performance guarantee, the throughput policy may favor a first thread, but the decision circuit 1230 may override that preference and select a second thread to help satisfy the minimum performance guarantee of the second thread. In an embodiment, the resource allocator 1200 may include multiple instances of one or more embodiments of the decision circuit 1230 (each for any resource or resource group) and each for implementing any one or more resource allocation policies or combinations of resource allocation policies, and each for implementing any one or more schemes or combinations of schemes described below, wherein each may be configured or programmed to select threads based on any scheme or combination of schemes (e.g., each may assign different weights to information received from each individual policy circuit in the policy circuit 1220).

[0137] In embodiments including indivisible resources, decision circuit 1230 can determine which thread has priority for the dynamic full allocation of indivisible resources. In embodiments including divisible resources, decision circuit 1230 can determine which thread has priority for the dynamic partial allocation of divisible resources and / or a portion of divisible resources, and / or how many (e.g., how many buffer entries) of divisible resources are allocated to the thread.

[0138] In one embodiment, the decision circuit 1230 may generate or provide one or more information, decision results, indicators and / or signals, for example by storing them in one or more storage locations accessible to the distributor circuit 1240, and / or sending them directly to the distributor circuit 1240, which may identify a single thread having a priority higher than any number of other threads, or may indicate the priority order of two or more threads.

[0139] Allocator circuit 1240 may include circuitry, structures, and / or hardware for receiving information, decision results, indicators, and / or signals from decision circuit 1230 to act on, complete, and / or implement resource allocation decisions. For example, in response to a decision from decision circuit 1230 that a first thread has priority over a second thread, one or more signals may be sent to allocate all or part of a resource (e.g., resource 1250) to the thread. To do this, allocator circuit 1240 may send one or more signals (e.g., a "go" signal 1240C) to scheduling or other circuitry that allows a particular thread to use an indivisible resource or to use one or more portions of a divisible resource.

[0140] In an embodiment, the allocator circuit 1240 may also receive one or more requests (e.g., requests 1240A and 1240B) to use resources. Requests may be signals and / or any other type of indicator from threads, resources, and / or from any type of scheduling circuitry associated with a thread or resource. In an embodiment, the allocator circuit 1240 may, for example, use information, decision results, indicators, and / or signals from the decision circuit 1230 to select or arbitrate thread requests between or among thread requests to determine which thread will be allocated resources.

[0141] In an embodiment, the allocator circuit 1240 may include circuitry, structures, and / or hardware for acting on allocation decisions from the decision circuit 1230, the allocation decisions being subject to or based on additional information or constraints. For example, the allocator circuit 1240 may include a set of fixed, configurable, or programmable storage locations or registers 1242 (one register per thread), the programmable storage locations or registers 1242 indicating how many portions of divisible resources (e.g., how many buffer entries) are dedicated to each thread, a set of counters 1244, one per thread, to track the amount of each portion of each thread currently in use, and a set of comparators 1246 (one per thread) to check whether a thread is using its full allocation. The allocator circuit 1240 may use the results from the comparators 1246 to accept or reject the allocation decision from the decision circuit 1230. Alternatively or additionally, embodiments may include a storage of indicators for each portion of a divisible resource (e.g., bits or fields of each entry in a buffer) to indicate which thread (or which threads) is allowed to use that portion of the resource, and allocator circuitry 1240 may use the stored indicators to accept or reject an allocation decision from decision circuitry 1230. Summary of some embodiments

[0142] Embodiments of the present invention may include a processor comprising a resource allocator and resources including a tracker circuit, a policy circuit, a decision circuit, and an allocater circuit. The tracker circuit may track at least one of the resource's performance history, resource usage history, and thread status. The policy circuit may provide policy information for implementing resource allocation policies. The decision circuit may select threads based on the output of the tracker circuit and the policy information. The allocater circuit may use the output of the decision circuit to allocate resources to threads. Resource sharing algorithmic contention.

[0143] The processor core may support the SMT (Simultaneous Threading Model) algorithm feature according to embodiments. In some embodiments, this feature addresses the problem of thread allocation to available resources that are contentiously shared in the pipeline. In some embodiments, this problem is solved using a priority algorithm. In some embodiments, branch prediction blocks in the pipeline may be contentiously shared and a priority algorithm may be used for efficient entry allocation. In some embodiments, the priority algorithm may be implemented in hardware and / or software. In some embodiments, thread allocation may be performed with two or more threads. In some embodiments, thread allocation may allocate the most efficient threads to available resources in the pipeline to implement the highest instructions per clock cycle (IPC) and / or pipeline throughput. In some embodiments, this feature may provide a known algorithm for prioritizing the best thread allocation to available resources. As the number of threads increases and / or the background switching between threads increases, this feature may provide further benefits by efficiently allocating resources.

[0144] Figure 13 is a block diagram illustrating algorithm SMT features that may be included in processor 1300 according to an embodiment. The priority algorithm hardware may include, for example, dynamic behavior-based management. The priority hardware may include at least one of event detection block 1301, performance counter flag block 1302, deadlock prevention block 1303, and instruction type / classification block 1304. Event detection block 1301 may, for example, detect one or more events, such as nuke, clear frequency (e.g., JEClear and CRClear), BR frequency, interrupts, and cache loss. Performance counter flag block 1302 may, for example, count one or more of the following: instruction revocation, code loss, L2 / L3 loss. Deadlock prevention block 1303 may prevent deadlock states. Instruction type / classification block 1304 may, for example, allow floating-point instruction revocation. In some embodiments, one or more of the foregoing may be implemented in software and / or firmware. Additionally, in some embodiments, the software may allow the operating system (OS) and / or virtual machine manager (VMM) to set priorities.

[0145] In some embodiments, the priority algorithm may have learning capabilities such as machine learning. These learning capabilities can provide intelligent thread selection and can adapt based on, for example, collected historical data and / or patterns.

[0146] In some embodiments, more than one thread may have similar events. In some embodiments, a priority scheme may be used where there is a connection between threads. For example, a connection interruption may be performed by randomly selecting, selecting a thread with a lower number, selecting a thread with a higher number, and / or selecting an alternating thread.

[0147] Figure 14 is a flowchart illustrating a method for algorithmic SMT features that can be executed by a processor according to an embodiment. The method may include determining whether a contentiously shared resource in the pipeline is available, as shown in 1401. The method may further include prioritizing threads, as shown in 1402. For example, threads are prioritized if more than one event occurs. The method may further include picking the highest priority event or flag, as shown in 1403. For example, the highest priority event or flag may be selected based on an allocation algorithm. The method may further include allocating resources to threads, as shown in 1404. For example, resources may be allocated to the most desirable thread based on a priority algorithm.

[0148] Figure 15 is a block diagram illustrating an algorithm SMT feature that may be included in a processor according to an embodiment. Figure 15 shows the allocation of threads (e.g., thread T0) to a contested shared resource based on an algorithm priority block. For example, the feature may determine that the contested shared resource 1501 is available, as shown in box 1401 in Figure 14. If there are more than one event (e.g., events Evt1 and Evt2 (e.g., according to box 1402 in Figure 14)), the algorithm priority block 1502 may prioritize them. The algorithm priority block 1502 may also pick the highest priority event or flag based on the allocation algorithm (e.g., according to box 1403 in Figure 14). The algorithm priority block 1502 may also allocate the resource (e.g., 1501) to the most forbidden thread (e.g., T0) based on the priority algorithm.

[0149] In some embodiments, the priority algorithm may include integer renaming and / or floating-point renaming algorithms. The priority algorithm may include event-based determination based on events such as kill, clear, and interrupt. The priority algorithm may include a performance counter that can count events that occur, such as revoked instructions and lost codes. The priority algorithm may include limiting physical registers, using deadlock prevention, and / or determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers, such as more floating-point word lines. The priority algorithm may include managing priorities through software. For example, the priority algorithm may allow the operating system and / or virtual machine manager to provide priorities. The priority algorithm may include hardware that manages priorities, such as based on dynamic behavior.

[0150] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the action of the branch target buffer (BTB) based on one or more of the following: the frequency of clearing (e.g., JEClears and CRClears), the frequency of branching (e.g., all, adopted, not adopted), and properties other than branching (e.g., withdrawn instructions, L2 / L3 loss). The priority algorithm may include prioritization managed through software. For example, the priority algorithm may allow the operating system and / or virtual machine manager to provide priorities. The priority algorithm may include hardware for managing priorities, such as based on dynamic behavior. FIG16 shows a block diagram of implementing a branch predictor priority algorithm according to an exemplary embodiment. Partition logic 1602 may receive input 1603, such as the frequency of clearing (e.g., JEClears and CRClears), the frequency of branching (e.g., all, adopted, not adopted), and properties other than branching (e.g., withdrawn instructions, L2 / L3 loss). Partition logic 1602 may allocate entries to the branch target buffer (BTB) 1601 based on input 1603. Summary of some embodiments

[0151] An embodiment may include a processor configured to identify available contention-shared resources; select execution threads based at least in part on a priority algorithm; and assign the selected execution threads to available contention-shared resources.

[0152] In some embodiments, one or more of the following apply. In some embodiments, the processor may be further configured to competitively share branch prediction and use a priority algorithm for entry allocation. In some embodiments, the processor may be further configured to assign a second thread based on a priority algorithm. In some embodiments, the processor may be further configured to assign the most efficient thread to available resources in the pipeline to increase at least one of per clock instruction (IPC) and pipeline throughput. In some embodiments, the processor may be further configured to provide a known algorithm for prioritizing thread allocation to available resources. In some embodiments, the processor may be further configured to prioritize when two or more events are detected. In some embodiments, the processor may be further configured to select at least one of a highest priority event and a flag based on a specified algorithm.

[0153] In some embodiments, the processor may include an event detection block, a performance counter flag block, a deadlock prevention block, and an instruction type / classification block. In some embodiments, the event detection block may detect at least one of kill frequency, clear frequency, BR frequency, interrupt, and cache loss. In some embodiments, the performance counter flag block may calculate at least one of instruction recall, code loss, and L2 / L3 loss. In some embodiments, the deadlock prevention block may prevent deadlock states. In some embodiments, the instruction type / classification block may allow floating-point instruction recall. In some embodiments, the processor may be further configured to allow at least one of the operating system (OS) and / or virtual machine manager (VMM) to set priorities. In some embodiments, the priority algorithm may have at least one learning capability. In some embodiments, the at least one learning capability may be adaptive based on at least one of historical data and workload patterns.

[0154] In some embodiments, the priority algorithm may include at least one of integer renaming and floating-point renaming algorithms. The priority algorithm may include event-based decision-making. Event-based decision-making may include one or more of kill, clear, and interrupt. The priority algorithm may include a performance counter. The performance counter may count events that occur. Events that occur may be one or more of instruction rollback and code loss. The priority algorithm may include one or more of limiting physical registers, using deadlock prevention, and determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers. Allocating registers may include allocating more floating-point word lines for floating-point registers. The priority algorithm may include prioritizing through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based on dynamic behavior.

[0155] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the operation of the branch target buffer (BTB) at least in part based on one or more of the following: the frequency of clearing, the frequency of branching, and properties other than branching. Clearing may include one or more of JEClears and CRClears. The frequency of branching may include one or more of all, adopted, and not adopted. Properties other than branching may include one or more of instruction withdrawal and L2 / L3 loss. The priority algorithm may include priority management through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be at least in part based on dynamic behavior. The priority algorithm may include using partitioning logic to receive input. The input may include one or more of the frequency of clearing, the frequency of branching, and properties other than branching. The partitioning logic may allocate entries in the branch target buffer (BTB) based on the input.

[0156] Embodiments may include a method comprising identifying available competitive shared resources; selecting execution threads based at least in part on a priority algorithm; and assigning the selected execution threads to the available competitive shared resources.

[0157] In some embodiments, one or more of the following may apply. In some embodiments, the method may further include competitively sharing branch prediction and using a priority algorithm for entry allocation. In some embodiments, the method may further include assigning a second thread based on a priority algorithm. In some embodiments, the method may further include assigning the most efficient thread to an available resource in the pipeline to increase at least one of per clock instruction (IPC) and pipeline throughput. In some embodiments, the method may further include providing a known algorithm for prioritizing thread allocation to an available resource. In some embodiments, the method may further include prioritizing when two or more events are detected. In some embodiments, the method may further include selecting at least one of a highest priority event and a flag based on a specified algorithm.

[0158] In some embodiments, the method may further include using an event detection block, a performance counter flag block, a deadlock prevention block, and an instruction type / classification block. In some embodiments, the method may further include using an event detection block to detect at least one of kill frequency, clear frequency, BR frequency, interrupt, and cache loss. In some embodiments, the method may further include using a performance counter flag block to calculate at least one of instruction recall, code loss, and L2 / L3 loss. In some embodiments, the method may further include using a deadlock prevention block to prevent deadlock states. In some embodiments, the method may further include using an instruction type / classification block to allow floating-point instruction recall. In some embodiments, the method may further include allowing at least one of the operating system (OS) and / or virtual machine manager (VMM) to set priorities. In some embodiments, the priority algorithm may have at least one learning capability. In some embodiments, the at least one learning capability may be adaptive based on at least one of historical data and workload patterns.

[0159] In some embodiments, the priority algorithm may include at least one of integer renaming and floating-point renaming algorithms. The priority algorithm may include event-based decision-making. Event-based decision-making may include one or more of kill, clear, and interrupt. The priority algorithm may include a performance counter. The performance counter may count events that occur. Events that occur may be one or more of instruction rollback and code loss. The priority algorithm may include one or more of limiting physical registers, using deadlock prevention, and determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers. Allocating registers may include allocating more floating-point word lines for floating-point registers. The priority algorithm may include prioritizing through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based on dynamic behavior.

[0160] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the action of the branch target buffer (BTB) at least in part based on one or more of the following: the frequency of clearing, the frequency of branching, and properties other than branching. Clearing may include JEClears. The frequency of branching may include one or more of all, adopted, and not adopted. Properties other than branching may include one or more of instruction withdrawal and L2 / L3 loss. The priority algorithm may include priority management through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be at least in part based on dynamic behavior. The priority algorithm may include using partitioning logic to receive input. The input may include one or more of the frequency of clearing, the frequency of branching, and properties other than branching. The partitioning logic may allocate entries in the branch target buffer (BTB) based on the input.

[0161] Embodiments may include a non-transitory machine-readable medium storing at least one instruction that, when executed by a processor, causes the processor to execute a method comprising identifying an available contention-shared resource; selecting an execution thread based at least in part on a priority algorithm; and assigning the selected execution thread to the available contention-shared resource.

[0162] In some embodiments, one or more of the following may apply. In some embodiments, the method may further include competitively sharing branch prediction and using a priority algorithm for entry allocation. In some embodiments, the method may further include assigning a second thread based on a priority algorithm. In some embodiments, the method may further include assigning the most efficient thread to an available resource in the pipeline to increase at least one of per clock instruction (IPC) and pipeline throughput. In some embodiments, the method may further include providing a known algorithm for prioritizing thread allocation to the available resource. In some embodiments, the method may further include prioritizing when two or more events are detected. In some embodiments, the method may further include selecting at least one of a highest priority event and a flag based on a specified algorithm.

[0163] In some embodiments, the method may further include using an event detection block, a performance counter flag block, a deadlock prevention block, and an instruction type / classification block. In some embodiments, the method may further include using an event detection block to detect at least one of kill frequency, clear frequency, BR frequency, interrupt, and cache loss. In some embodiments, the method may further include using a performance counter flag block to calculate at least one of instruction recall, code loss, and L2 / L3 loss. In some embodiments, the method may further include using a deadlock prevention block to prevent deadlock states. In some embodiments, the method may further include using an instruction type / classification block to allow floating-point instruction recall. In some embodiments, the method may further include allowing at least one of the operating system (OS) and / or virtual machine manager (VMM) to set priorities. In some embodiments, the priority algorithm may have at least one learning capability. In some embodiments, the at least one learning capability may be adaptive based on at least one of historical data and workload patterns.

[0164] In some embodiments, the priority algorithm may include at least one of integer renaming and floating-point renaming algorithms. The priority algorithm may include event-based decision-making. Event-based decision-making may include one or more of kill, clear, and interrupt. The priority algorithm may include a performance counter. The performance counter may count events that occur. Events that occur may be one or more of instruction rollback and code loss. The priority algorithm may include one or more of limiting physical registers, using deadlock prevention, and determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers. Allocating registers may include allocating more floating-point word lines for floating-point registers. The priority algorithm may include prioritizing through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based on dynamic behavior.

[0165] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the operation of the branch target buffer (BTB) at least in part based on one or more of the following: the frequency of clearing, the frequency of branching, and properties other than branching. Clearing may include one or more of JEClears and CRClears. The frequency of branching may include one or more of all, adopted, and not adopted. Properties other than branching may include one or more of instruction withdrawal and L2 / L3 loss. The priority algorithm may include priority management through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be at least in part based on dynamic behavior. The priority algorithm may include using partitioning logic to receive input. The input may include one or more of the frequency of clearing, the frequency of branching, and properties other than branching. The partitioning logic may allocate entries in the branch target buffer (BTB) based on the input.

[0166] Embodiments may include a system including memory and a processor, the processor being configured to identify available contention-shared resources; to select execution threads based at least in part on a priority algorithm; and to assign the selected execution threads to available contention-shared resources.

[0167] In some embodiments, the priority algorithm may include at least one of integer renaming and floating-point renaming algorithms. The priority algorithm may include event-based decision-making. Event-based decision-making may include one or more of kill, clear, and interrupt. The priority algorithm may include a performance counter. The performance counter may count events that occur. Events that occur may be one or more of instruction rollback and code loss. The priority algorithm may include one or more of limiting physical registers, using deadlock prevention, and determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers. Allocating registers may include allocating more floating-point word lines for floating-point registers. The priority algorithm may include prioritizing through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based on dynamic behavior.

[0168] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the operation of the branch target buffer (BTB) at least in part based on one or more of the following: the frequency of clearing, the frequency of branching, and properties other than branching. Clearing may include one or more of JEClears and CRClears. The frequency of branching may include one or more of all, adopted, and not adopted. Properties other than branching may include one or more of instruction withdrawal and L2 / L3 loss. The priority algorithm may include priority management through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be at least in part based on dynamic behavior. The priority algorithm may include using partitioning logic to receive input. Input may include one or more of the frequency of clearing, the frequency of branching, and properties other than branching. The partitioning logic may allocate entries in the branch target buffer (BTB) based on the input.

[0169] In some embodiments, one or more of the following apply. In some embodiments, the processor may be further configured to competitively share branch prediction and use a priority algorithm for entry allocation. In some embodiments, the processor may be further configured to assign a second thread based on a priority algorithm. In some embodiments, the processor may be further configured to assign the most efficient thread to available resources in the pipeline to increase at least one of per clock instruction (IPC) and pipeline throughput. In some embodiments, the processor may be further configured to provide a known algorithm for prioritizing thread allocation to available resources. In some embodiments, the processor may be further configured to prioritize when two or more events are detected. In some embodiments, the processor may be further configured to select at least one of a highest priority event and a flag based on a specified algorithm.

[0170] In some embodiments, the processor may include an event detection block, a performance counter flag block, a deadlock prevention block, and an instruction type / classification block. In some embodiments, the event detection block may detect at least one of kill frequency, clear frequency, BR frequency, interrupt, and cache loss. In some embodiments, the performance counter flag block may calculate at least one of instruction recall, code loss, and L2 / L3 loss. In some embodiments, the deadlock prevention block may prevent deadlock states. In some embodiments, the instruction type / classification block may allow floating-point instruction recall. In some embodiments, the processor may be further configured to allow at least one of the operating system (OS) and / or virtual machine manager (VMM) to set priorities. In some embodiments, the priority algorithm may have at least one learning capability. In some embodiments, the at least one learning capability may be adaptive based on at least one of historical data and workload patterns.

[0171] In some embodiments, the priority algorithm may include at least one of integer renaming and floating-point renaming algorithms. The priority algorithm may include event-based decision-making. Event-based decision-making may include one or more of kill, clear, and interrupt. The priority algorithm may include a performance counter. The performance counter may count events that occur. Events that occur may be one or more of instruction rollback and code loss. The priority algorithm may include one or more of limiting physical registers, using deadlock prevention, and determining cache loss. The priority algorithm may include determining instruction type and category. The priority algorithm may include allocating registers. Allocating registers may include allocating more floating-point word lines for floating-point registers. The priority algorithm may include prioritizing through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based on dynamic behavior.

[0172] In some embodiments, the priority algorithm may include a branch predictor algorithm. In some embodiments, the branch predictor algorithm may control the operation of the branch target buffer (BTB) based at least in part on one or more of the following: the frequency of clearing, the frequency of branching, and properties other than branching. Clearing may include one or more of JEClears and CRClears. The frequency of branching may include one or more of all, adopted, and not adopted. Properties other than branching may include one or more of instruction withdrawal and L2 / L3 loss. The priority algorithm may include priority management through software. The priority algorithm may allow one or more of the operating system and virtual machine manager to provide priorities. The priority algorithm may include hardware-managed priorities. Hardware-managed priorities may be based at least in part on dynamic behavior. The priority algorithm may include using partitioning logic to receive input. Input may include one or more of the frequency of clearing, the frequency of branching, and properties other than branching. The partitioning logic may allocate entries in the branch target buffer (BTB) based on the input. Thread switching

[0173] The processor core may support the SMT thread switching feature according to embodiments of the present invention. In a processor core implementing SMT with shared resources, SMT may involve selecting which of two or more threads to use at various stages in the processor issuance / execution pipeline. Embodiments of the present invention including the SMT thread switching feature may be intended to provide such selection to influence priorities among performance, fairness, and other factors (e.g., improving performance, reducing power consumption and implementing power-saving features, and improving fairness, minimum performance guarantee, throughput, instructions per clock cycle (IPC), instructions per unit time, quality of service, time and / or memory efficiency, to name just a few applicable criteria). For example, in the issue / execution pipeline of processor core 900, arbitration can be used to select the thread on which the branch predictor 911 will begin predicting, to find the predicted thread in i-TLB 916, to find the thread translated by i-TLB in i-cache 913, to decode the byte array from i-cache 913 in decoder 914, to read the thread from op-cache 912, to read the thread from micro-op queue 915, and so on.

[0174] FIG17 is a block diagram illustrating an arbitration circuit 1700 for an SMT thread switching feature that may be included in a processor, according to an embodiment of the present invention. The arbitration circuit 1700 may include circuitry, structures, and / or hardware for selecting which of two or more threads to proceed at any stage in the processor issuance / execution pipeline. The processor or processor core may include multiple instances of one or more embodiments of the arbitration circuit 1700, each instance for any one or more pipeline stages or resources, each resource including any one or more blocks shown in FIG17, and each resource implementing any one or more schemes or combinations of schemes described below. Furthermore, all or part of any instance of the arbitration circuit 1700 may be included, integrated, or incorporated into other circuitry, structures, and / or hardware of the processor or processor core, such as resource allocation, scheduling, or shared circuitry.

[0175] The arbitration circuit 1700 may include a simple loop circuit 1710, a high-throughput loop circuit 1720, a dynamic loop circuit 1730, and a software-controllable loop circuit 1740, as well as any other circuit that is desired to implement any other loop or other scheme.

[0176] The simple loop circuit 1710 may include circuitry, structure, and / or hardware for performing a simple loop scheme to select a thread. For example, it may implement a scheme in which the selection continuously alternates between options; i.e., thread 0, then thread 1, then thread 0, then thread 1, etc.; or thread 0, thread 1, thread 2, thread 0, thread 1, thread 2, etc.; etc.

[0177] The high-throughput loop circuit 1720 may include circuitry, construction, and / or hardware for implementing a modified looping scheme to select threads based on the expectation of prioritizing throughput over other possible factors (e.g., fairness). For example, it may implement a simple looping scheme (e.g., as described above) as long as each thread has available work at the thread switching point, otherwise selecting a thread with available work. In embodiments with more than two threads to choose from, it may exit any thread from the simple looping scheme if no work is available.

[0178] The dynamic loop circuit 1730 may include circuitry, architecture, and / or hardware for executing a dynamically modifiable loop scheme to select threads based on the dynamic behavior of the threads. The dynamic loop circuit 1730 may include and / or use a performance counter, other hardware counters, or other architectures (any of which represents 1732) to provide information as a basis for decision-making (e.g., probing). Indications supporting the ratio or other criteria for thread selection based on thread selection and which dynamic behavior measurements are used may be fixed (e.g., hardwired), configurable (e.g., by hardware or firmware), or programmable (e.g., by software). For example, a first thread may be favored or selected on a second thread at a ratio of 2:1 (e.g., thread 0, thread 0, thread 1, thread 0, thread 0, thread 1, etc.). Examples of factors or criteria for determining which thread is favored over another are: misprediction rate, instructions per cycle, cache miss rate, etc.

[0179] The software-controllable loop circuit 1740 may include circuitry, architecture, and / or hardware for executing modified loop schemes to select threads based on priorities provided by software (e.g., the operating system or virtual machine monitor), which may have more information about the desired system behavior than information available to the software. This instruction, along with the preferred ratio and / or any other information about which scheme to use or how to implement it (e.g., whether and how software-controllable loops are combined with dynamic and / or modifiable loops), may be provided within the arbitration circuit 1700 or in a programmable storage location or register 1742 accessible to the arbitration circuit 1700.

[0180] In embodiments, combinations of approaches are possible. For example, software may provide (e.g., circuitry and / or techniques for software-controllable loops) hints about which thread is favored, and hardware (e.g., circuitry or techniques for dynamic loops) may determine the favoring ratio based on thread behavior and / or probing. Summary of some embodiments

[0181] Embodiments of the present invention may include a processor, which includes an arbitration circuit. The arbitration circuit may include a first loop circuit and a second loop circuit. The first loop circuit may be used to implement a simple loop thread switching scheme. The second loop circuit may be used to implement a dynamically modified loop thread switching scheme. Deadlock avoidance

[0182] The processor core may support SMT deadlock avoidance features according to embodiments of the present invention. In some cases, resource sharing may cause threads to progress slowly due to a lack of one or more resources, to not progress due to inability to advance (e.g., instruction rollback), and / or any other deadlock-type situation. Therefore, the user experience may include significantly slower performance or errors, failures, or crashes. Embodiments of the present invention that include deadlock avoidance features may be expected to reduce deadlock-type situations and improve the user experience. Other benefits of these embodiments may include, for example, improved performance, reduced power consumption and implementation of power-saving features, and improved fairness, minimum performance guarantees, throughput, instructions per clock (IPC), instructions per unit time, quality of service, time and / or memory efficiency, to name just a few applicable criteria.

[0183] FIG18 is a block diagram illustrating deadlock avoidance hardware 1800 that may be included in a processor according to an embodiment of the present invention. Deadlock avoidance hardware 1800 may include circuitry, structures, and / or hardware for influencing the allocation and use of core circuitry, structures, units, and resources, and portions thereof, to reduce the occurrence of deadlock-type situations. In embodiments, deadlock avoidance hardware 1800 may be implemented to avoid deadlocks involving a single resource and / or multiple resources. In any case, the processor or processor core may include multiple instances of one or more embodiments of deadlock avoidance hardware 1800, each instance for any one or more resources, each resource including any one or more blocks shown in FIG18, and each resource implementing any one or more schemes or combinations of schemes described below. Furthermore, all or part of any instance of deadlock avoidance hardware 1800 may be included, integrated, or incorporated into other circuitry, structures, and / or hardware of the processor or processor core, such as resource allocation, scheduling, or shared circuitry.

[0184] Deadlock avoidance hardware 1800 may include allocator circuitry 1810, which may include circuitry, structures, and / or hardware for allocating resources to threads. Embodiments or examples of allocator circuitry 1810 may represent or correspond to embodiments or examples of allocator circuitry 1240 in FIG12.

[0185] The deadlock avoidance hardware 1800, the allocator circuit CGA10, and / or any other part of the processor or processor core may include circuitry, structures, and / or hardware for dynamically disabling, blocking, or otherwise preventing the allocator circuit CGA10 from allocating resources or a portion of divisible resources to any one or more specific threads. For example, in embodiments including any type of round-robin scheme, such as those described above, selecting or arbitrating between or among thread requests, preventing a specific thread from using resources, can be accomplished by temporarily removing the thread from the round-robin scheme. Embodiments may include an AND gate having a thread request signal (e.g., 1240A, 1240B) as an input and the complement of a thread blocking signal (e.g., generated by circuitry based on resource usage counter 1820, or any other information, status, or signal, as described below), such that the output of the AND gate can indicate whether a thread will be allocated resources or will be considered a candidate for resource allocation.

[0186] The deadlock avoidance hardware 1800 may further include a resource usage counter 1820. In an embodiment, the resource usage counter 1820 may be a per-thread hardware counter used to count the number (e.g., entries) of portions of a divisible resource (e.g., buffers, queues, schedulers, reservations) occupied or used by a particular thread. For a particular resource, an instance of the resource usage counter 1820 for a particular thread may increment in response to the allocator circuitry 1810 allocating an entry to a thread, decrement in response to an entry being deallocated or removed, and be cleared in response to a resource being refreshed. The allocator circuitry 1810 may dynamically disable or prevent (e.g., as described above) the allocation of entries to a thread in response to the thread count reaching or exceeding a threshold value.

[0187] A threshold value less than the total number of entries in the resource can be selected to prevent any single thread from using all entries simultaneously, which could lead to a deadlock-type situation. The threshold value can also be selected or adjusted based on other factors or criteria, including tolerances associated with approaching deadlock-type situations and / or measurements or factors that prioritize throughput or other performance. The threshold value can be fixed (e.g., hardwired), configurable (e.g., by hardware or firmware), or programmable (e.g., by software).

[0188] In one embodiment, the divisible resource can be logically partitioned for specific threads or groups of threads. For example, in a divisible resource with N groups of entries, a subgroup of N1 entries (where N1 is less than N) can be reserved for use only by the first thread, a subgroup of N2 entries (where N2 is less than N) can be reserved for use only by the second thread, and the remaining subgroup of N-(N1 + N2) entries can be allocated to any thread. In an embodiment, this scheme can be implemented by one or more instances of the allocator circuit 1810.

[0189] In embodiments where loading depends on the completion of data read from the cache, each cache entry may include bits indicating that the entry is locked by a thread that includes the load from that entry. Substitution of entries with the indicator byte may be prevented until bits associated with the completion of loading or a thread experiencing a pipeline refresh event (e.g., a mispredicted branch) are cleared. In embodiments, this scheme may be implemented by one or more instances of the allocator circuit 1810.

[0190] In one embodiment, the resource usage counter 1820 may be a per-thread hardware counter used to count the oldest entry in the withdrawal queue for a particular thread (a stalled thread) that has been waiting for a corresponding scheduling to an indivisible resource (this condition involves the withdrawal queue because the thread requires a scheduling slot and a write-back slot). In response to the count of stalled threads reaching or exceeding a threshold, the allocator circuit 1810 may dynamically disable or block the scheduler (e.g., as described above) from allocating operations from different threads to the indivisible resource. Alternatively, scheduling of any operation for an indivisible resource may be disabled or blocked for a given number of clock cycles.

[0191] These schemes can prevent deadlock-type situations using indivisible resources (such as execution units) that can perform different operations consuming a range of clock cycles. For example, it can allow operations that can be completed in a single cycle to use resources that may remain busy, thereby completing operations over multiple consecutive cycles.

[0192] The threshold value can be fixed (e.g., hardwired), configurable (e.g., by hardware or firmware), or programmable (e.g., by software). It can be selected and / or dynamically adjusted based on various factors or criteria, including those related to throughput and those related to fairness. For example, if fairness is prioritized, the threshold can be gradually decreased to more aggressively allow each thread to progress; if throughput is prioritized, it may be gradually increased to more aggressively allow ongoing threads to continue uninterrupted. Summary of some embodiments

[0193] Embodiments of the present invention may include a processor, which includes deadlock avoidance hardware and resources. The deadlock avoidance hardware may include an allocator circuit and a resource usage counter. The allocator circuit may determine whether to allocate resources to threads based on the output from the resource usage counter. Data path characteristics

[0194] The processor core according to embodiments of the present invention may include various features supporting an instruction set architecture (ISA) with a narrower data path than that provided by the ISA. Several such features are described separately below using non-limiting examples, but embodiments may include any combination of such features.

[0195] The processor core may support the feature of operating on larger operands by breaking these operations down into multiple micro-operations (μops) (e.g., load / store / arithmetic operations on 256-bit operands), where micro-operations (μops) operate on smaller operands (e.g., multiple μops operating on 128-bit values). This feature may be desirable for various reasons: for example, the processor may support instruction set architectures involving larger operand sizes, but may use micro-architectures based on smaller operand sizes. Alternatively, the processor may support instruction set architectures with larger operand sizes and have register files that include this larger size, but may include execution units that can process only smaller blocks of data. Alternatively, the processor may have larger register files, execution units, and load / store ports, but using smaller operands to perform μops may be desirable for purposes such as power saving or scheduling. Other potential benefits of processors including the features described below include, but are not limited to, improved performance, reduced power consumption and implementation of power-saving features, and improved fairness, minimum performance guarantees, throughput, instructions per clock cycle (IPC), instructions per unit time, quality of service, and time and / or memory efficiency, to name just a few applicable criteria. 256 to 128-bit data path loading and storage.

[0196] According to embodiments of the present invention, the processor core may support the feature of allowing 256-bit load and store using 128-bit micro-operations (µop). In some embodiments, the processor may support a 256-bit instruction set architecture but may use a 128-bit microarchitecture, including a 128-bit register file. In other embodiments, the processor may have a 256-bit instruction set architecture and a 256-bit register file, but may include load and / or store ports capable of processing data only in 128-bit blocks.

[0197] Figure 19 is a diagram illustrating, according to some embodiments, the loading of 256 bits into a 256-bit register file using a pair of 128-bit µops. Memory 1901 includes a series of 256-bit values, such as values ​​stored in memory location 1902. A first µop 1903 retrieves the lower half of the value stored in memory location 1902, and a second µop 1904 retrieves the upper half of the value stored in memory location 1902. The two halves of the value stored in memory location 1902 are combined (1905), and the result of the combination operation is placed in a 256-bit register file 1906.

[0198] Figure 20 is a flowchart illustrating the process described above with reference to Figure 19 according to some embodiments. During the decoding instruction (2001) process, if a 256-bit load is detected, three µops are generated, including a first load µop, a second load µop, and a mixed µop (block 2002). The µops are scheduled to be executed, and for each µop, the processor may wait until the data has been loaded / mixed (2003). When the first load µop is executed, the processor may retrieve the lower half of the value stored in memory location 1902, as shown in block 2004. When the second load µop is executed, the processor may retrieve the upper half of the value stored in memory location 1902, as shown in block 2004. When the mixed µop is executed, the two retrieved halves of the value stored in memory location 1902 are combined and placed in a 256-bit temporary register file, as shown in block 2004. Finally, the decoded instructions are withdrawn upon completion, as shown in box 2005.

[0199] In some embodiments, a value can be stored from a 256-bit register file to memory using a 128-bit µop. Figure 21 is a diagram illustrating this process. The 256-bit register file 2101 includes a 256-bit wide register (such as register 2102). A first storage µop 2103 retrieves the lower half of the value stored in register 2102 and stores it in the lower half of memory location 2104. A second storage µop 2105 retrieves the upper half of the value stored in register 2102 and stores it in the upper half of memory location 2104.

[0200] Figure 22 is a flowchart illustrating the process described above with reference to Figure 21 according to some embodiments. During the decoding instruction (2201) process, if 256-bit storage is detected, two µops are generated, including a first storage µop and a second storage µop (block 2202). The µops are scheduled to be executed, and for each µop, the processor may wait until the data has been stored (2203). When the first storage µop is executed, the processor may retrieve the lower half of the value stored in the register 2102, as shown in block 2204, and write it to the lower half of the memory location 2104. When the second storage µop is executed, the processor may retrieve the upper half of the value stored in the register 2102, as shown in block 2204, and write it to the upper half of the memory location 2104. Finally, the decoded instruction is withdrawn after completion, as shown in block 2205.

[0201] In some embodiments, the 256-bit load instruction can load a 256-bit value into two 128-bit registers by executing two µops. The first µop is used to load the lower half of the 256-bit value into the first 128-bit register, and the second µop is used to load the upper half of the 256-bit value into the second 128-bit register.

[0202] In some embodiments, loading is accomplished using a single μop, referred to as "dual-pumping"—that is, performed twice, once to load the lower half of the value from memory, and a second time to load the upper half of the value from memory. In some embodiments, storing is accomplished using a single μop, referred to as "dual-pumping"—that is, performed once to store the lower half of the register into memory and once to store the upper half of the register into memory. In some embodiments, the µops used to perform 256-bit loading and / or storing may be scheduled according to a vector scheduling algorithm. In some embodiments, group scheduling techniques may be used to schedule multiple µops for performing loading and / or storing on individual execution units.

[0203] The above-described load / save features are not limited to using memory, a load port, or any specific size of temporary file to perform load and / or save. For example, the above techniques can be used to perform 512-bit load and / or save using 256-bit underlying hardware in a single operation. Execution within a 256- to 128-bit data path channel.

[0204] According to embodiments of the present invention, the processor core may support the feature of allowing 256-bit arithmetic operations using 128-bit micro-operations (µops). In some embodiments, the processor may support a 256-bit instruction set architecture, but may use a 128-bit microarchitecture, including 128-bit register files. In other embodiments, the processor may have a 256-bit instruction set architecture and 256-bit register files, but may include execution units capable of processing data only in 128-bit blocks. In some embodiments, the processor may have 256-bit register files, execution units, and load / store ports, but for purposes such as power saving or scheduling, multiple 128-bit μops may be needed to perform 256-bit arithmetic operations.

[0205] Figure 23 illustrates this process according to some embodiments. A 256-bit instruction 2301 is decoded by splitting it into two 128-bit µops 2302 and 2303, and then independently scheduled for execution on one or more 128-bit execution units 2304, 2305. According to the embodiment shown in Figure 23, the first 128-bit µop 2302 can execute the instruction using the lower half of the 256-bit operands provided to the 256-bit arithmetic instruction, and the processor can then store the result in the lower half of the 256-bit destination register. The second 128-bit µop 2303 can execute the instruction using the upper half of the 256-bit operands provided to the 256-bit arithmetic instruction, and the processor can then store the result in the upper half of the 256-bit destination register.

[0206] According to some embodiments, a 256-bit instruction is partitioned into a pair of 128-bit µops, the lower half of the result being only based on the lower half of the operands of the 256-bit instruction, and the upper half of the result being entirely based on the upper half of the operands of the 256-bit instruction (i.e., "in-channel" operation). In these in-channel scenarios, the two 128-bit µops can be scheduled independently of each other because the result of the 256-bit instruction can be represented as two independent results of two independent 128-bit µops.

[0207] In some embodiments, each of the 128-bit μops represents the same instruction (e.g., an ADD instruction), and a single 128-bit μop can be used in a "dual-pump" manner to implement a 256-bit instruction—that is, to execute it twice, once for the lower half of the result and once for the upper half. In some embodiments, the 256-bit instruction can be "split" into two distinct μops, which are independently scheduled and executed on one or more execution units. In some embodiments, two execution units can be used to execute the 256-bit instruction simultaneously, with each execution unit executing a 128-bit μop (this process is sometimes referred to in the art as "combined scheduling").

[0208] The above-described in-channel execution characteristics are not limited to using memory values, load ports, execution units, or temporary files of any specific size to execute instructions. For example, the above techniques can be used to perform 512-bit operations using 256-bit underlying hardware in a single operation, or to perform 1024-bit operations using 512-bit underlying hardware in a single operation. 256 to 128-bit data path cross-channel execution.

[0209] In some embodiments, the 256-bit instruction to be executed cannot be divided into two completely independent 128-bit μops because the lower half of the result depends on the value stored in the upper half of the operand, and / or the upper half of the result depends on the value stored in the lower half of the operand (i.e., the "cross-channel" operation).

[0210] Cross-channel operations can be implemented using a temporary storage area to store partial results, which are then combined into a final result and stored in a destination register. Figure 24 illustrates this process according to some embodiments of this feature. The cross-channel 256-bit instruction QJA01 is decoded by splitting it into two 128-bit µops QJA02 and QJA03, which are then independently scheduled for execution on one or more 128-bit execution units QJA06, QJA07. The temporary storage area QJA04 can be used to store partial results generated by µops QJA02 and QJA03. These temporary results are used by a third µop (QJA05) to produce the final result.

[0211] In some embodiments, each of the 128-bit μops QJA02 and QJA03 represents the same instruction and can be executed using a single 128-bit μop in a "dual-pump" manner—that is, executed twice, once to compute a first portion of the result stored in temporary storage area QJA04, and once to compute a second portion of the result stored in temporary storage area QJA04. In some embodiments, the 256-bit instruction can be "split" into two distinct μops, which are independently scheduled and executed on one or more execution units, with a portion of the result of the μop stored in temporary storage area. In some embodiments, the 256-bit instruction can be executed simultaneously using two execution units, each executing a 128-bit μop (this process is sometimes referred to in the art as "combined scheduling"). In some embodiments, the 256-bit μop can be executed using a "special" execution unit with 256-bit capability, without requiring a temporary storage area (e.g., temporary storage area QJA04).

[0212] The cross-channel execution features described above are not limited to using memory values, load ports, execution units, or temporary files of any particular size to execute instructions. For example, the above techniques can be used to perform 512-bit operations using 256-bit underlying hardware at a time, or to perform 1024-bit operations using 512-bit underlying hardware at a time. Additional independent and composable features

[0213] The processor core according to embodiments of the present invention may include various additional features that support improved performance and / or reduced power consumption. Several such features are described separately below using non-limiting examples, but embodiments may include any combination of such features. Micro-op cache

[0214] The processor core may support cache features according to embodiments. In some embodiments, micro-op cache features may include allocation, replacement policies, and different architecture types (e.g., physical, virtual, etc.). Intelligent allocation in micro-op cache features may detect instructions such as loops with microcode sequencer (MS) streams or complex instructions, rather than simple instructions, and allocate accordingly. Micro-op cache features may also include adding victim caches for potential future reuse and / or determining how many micro-operations to allocate to each cache line. In some embodiments, micro-op caches may be used to store decoded instructions (micro-operations) in a micro-op buffer for reuse in instructions decoded later. In some embodiments, the use of micro-op buffers may shorten the pipeline by avoiding multiple (e.g., at least two) cycles of instruction cache lookup and decoding phases. It may also save power by using micro-ops that are already available and decoding them in a micro-op buffer. In some embodiments, there may be more than one thread with similar events (e.g., micro, micro-op decoding difficulty, micro-op usage pattern), and a priority scheme may be used to allocate resources among threads to the micro-op cache. In some embodiments, the micro-op cache feature can provide intelligent allocation, replacement policies, and / or configuration for the micro-op cache to achieve the highest IPC and / or instruction throughput in the pipeline.

[0215] Figure 25 is a block diagram illustrating a micro-op cache feature that may be included in a processor according to an embodiment. The micro-op cache feature may include one or more of the following: instruction decoder 2501, smart allocation and replacement block 2502, and micro-op cache 2503. The smart allocation and replacement block 2502 may receive instructions from the instruction decoder 2501. The instruction decoder 2501 may also be omitted, and the smart allocation and replacement block 2502 may receive already decoded instructions. The smart allocation and replacement block 2502 may arithmetically determine which types of instructions to allocate, such as complex instructions (e.g., those with MS streams), loop streams, etc. The smart allocation and replacement block 2502 may determine where to allocate the micro-op cache KQA03 and may allocate instructions at the determined location. In some embodiments, the smart allocation and replacement block 2502 may, for example, arithmetically determine which types of instructions to allocate based on one or more of the following: the instruction's historical usage pattern, usage frequency, decoding difficulty, and decoding time. The smart allocation and replacement block can determine where to store instructions in the micro-op cache based on one or more of the following parameters: least recently used instruction information, instruction's historical usage pattern, usage frequency, decoding difficulty, whether the instruction is part of a loop and whether other instructions from the loop are stored, and the time required to decode instructions stored in the micro-op cache. For example, these parameters can be stored in the smart allocation and replacement block, the micro-op cache, and / or elsewhere (e.g., in a separate table).

[0216] Figure 26 is a flowchart illustrating a method for a micro-op cache feature executable by a processor according to an embodiment. The method may include receiving instructions, as shown in block 2601. The method may further include arithmetically determining which types of instructions, such as complex instructions or loop streams, to allocate, as shown in block 2602. The method may further include determining the location in the micro-op cache where the instructions are allocated, as shown in block 2603. The method may further include allocating the instructions at the determined location in the micro-op cache, as shown in block 2604.

[0217] FIG27 is a block diagram illustrating a micro-op cache feature that may be included in a processor according to an embodiment. The micro-op cache feature may include one or more of the following: branch prediction unit (BPU) 2701, instruction cache tag 2702, micro-op tag 2703, instruction cache 2704, micro-op cache 2705, decoder 2706, and micro-op queue 2707. BPU 2701 may perform branch prediction (e.g., to determine whether to perform a conditional operation). As shown on the left side of FIG27, instruction cache tag 2702 may, for example, receive an instruction tag from BPU 2701 and determine the instruction associated with the instruction tag. The instruction may be retrieved from instruction cache 2704 and decoded by decoder 2706. Micro-op queue 2707 may then receive the decoded instruction from decoder 2706. As shown on the right side of FIG28, micro-op tag 2703 may, for example, receive an instruction tag from BPU 2701 and determine the instruction associated with the micro-op tag. The micro-op cache 2705 can then be checked to determine whether the micro-op associated with the micro-op tag is stored in the micro-op cache 2705 and to retrieve the micro-op from the micro-op cache 2705. For example, as described above in conjunction with Figures 25 and 26, the micro-op can be decoded and stored in the micro-op cache 2705. Micro-op cache features can be physical and / or virtual. Micro-op cache features can include shortened pipelines. For example, as shown in Figure 27, in the case where the micro-op has already been decoded and stored in the micro-op cache, the pipeline on the right is shorter than the pipeline on the left because the decoding operation may not need to be performed when the micro-op is already stored in the micro-op cache. Micro-op cache features can contain next-line predictions within the micro-op cache 2705. Micro-op cache features can store the MS stream in the micro-op cache 2705. Micro-op cache features can use replacement policies to determine which micro-ops to store in the cache and which micro-ops to replace with new micro-ops. The micro-op cache features can determine the type of instruction to be allocated to the micro-op cache 2705, such as loop streams and / or complex instructions. The micro-op cache features can prioritize micro-operations. The micro-op cache features may include a victim cache (not shown). The victim cache can store potentially reusable instructions, such as instructions that are difficult to decode.

[0218] Figure 28 is a block diagram illustrating a micro-op cache feature that may be included in a processor according to an embodiment. The micro-op cache feature may include one or more of a physical micro-op cache 2801 and a virtual micro-op cache 2802. The physical micro-op cache 2801 may, for example, store the micro-op in physical memory using a physical address space. The virtual micro-op cache may, for example, store the micro-op in virtual memory using a virtual address space. The physical micro-op cache 2801 and / or the virtual micro-op cache 2802 may be refreshed, for example, during context and / or mode switching. The physical micro-op cache 2801 and / or the virtual micro-op cache 2802 may be shared contentiously. Summary of some embodiments

[0219] An embodiment may include a processor configured to arithmetically determine the type of instruction to be allocated to the micro-op cache; determine the location to which the determined type of instruction will be allocated to the micro-op cache; and allocate the instruction to the determined location.

[0220] In some embodiments, one or more of the following apply. In some embodiments, the processor is further configured to cause intelligent allocation and replacement blocks to receive instructions from the instruction decoder. In some embodiments, the determined instruction type is at least one of complex instructions and loop streams. In some embodiments, the processor may include one or more of a branch prediction unit (BPU), instruction cache tag, micro-op tag, instruction cache, micro-op cache and decoder, and micro-op queue. In some embodiments, the micro-op cache may include next-line prediction. In some embodiments, the processor is configured to store MS streams in the micro-op cache. In some embodiments, the processor is configured to prioritize micro-operations. In some embodiments, the processor includes a victim cache. In some embodiments, the micro-op cache includes at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, at least one of a physical micro-op cache and a virtual micro-op cache may be shared competitively. In some embodiments, determining which type of instruction is allocated to the micro-op cache may be based at least in part on one or more of the following: historical usage patterns, usage frequency, decoding difficulty, and decoding time. In some embodiments, the determination of where to assign an instruction of the determined type to the micro-op cache may be based on one or more of the following: least recently used instruction information, instruction history usage patterns, usage frequency, decoding difficulty, loop state information, and the decoding time of instructions stored in the micro-op cache.

[0221] An embodiment may include a method comprising arithmetically determining the type of instruction to be allocated to the micro-op cache; determining the location to which the determined type of instruction will be allocated in the micro-op cache; and allocating the instruction to the determined location.

[0222] In some embodiments, one or more of the following apply. In some embodiments, the method may further include causing intelligent allocation and replacement blocks to receive instructions from the instruction decoder. In some embodiments, the determined instruction type is at least one of complex instructions and loop streams. In some embodiments, the method may further include using one or more of a branch prediction unit (BPU), instruction cache tag, micro-op tag, instruction cache, micro-op cache and decoder, and micro-op queue. In some embodiments, the micro-op cache may include next-line prediction. In some embodiments, the method may further include storing the MS stream in the micro-op cache. In some embodiments, the method may further include prioritizing micro-operations. In some embodiments, the method may further include using a victim cache. In some embodiments, using a micro-op cache includes using at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, the method may further include competitively sharing at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, determining which type of instruction is assigned to the micro-op cache may be based at least in part on one or more of the following: historical usage patterns, usage frequency, decoding difficulty, and decoding time. In some embodiments, the determination of where to assign an instruction of the determined type to the micro-op cache may be based on one or more of the following: least recently used instruction information, instruction history usage patterns, usage frequency, decoding difficulty, loop state information, and the decoding time of instructions stored in the micro-op cache.

[0223] An embodiment may include a non-transitory machine-readable medium storing at least one instruction, which, when executed by a processor, causes the processor to execute a method comprising arithmetically determining the type of instruction to be allocated to the micro-op cache; determining a location to allocate the determined type of instruction to the micro-op cache; and allocating the instruction to the determined location.

[0224] In some embodiments, one or more of the following apply. In some embodiments, the method may further include causing intelligent allocation and replacement blocks to receive instructions from the instruction decoder. In some embodiments, the determined instruction type is at least one of complex instructions and loop streams. In some embodiments, the method may further include using one or more of a branch prediction unit (BPU), instruction cache tag, micro-op tag, instruction cache, micro-op cache and decoder, and micro-op queue. In some embodiments, the micro-op cache may include next-line prediction. In some embodiments, the method may further include storing the MS stream in the micro-op cache. In some embodiments, the method may further include prioritizing micro-operations. In some embodiments, the method may further include using a victim cache. In some embodiments, using a micro-op cache includes using at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, the method may further include competitively sharing at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, determining which type of instruction is assigned to the micro-op cache may be based at least in part on one or more of the following: historical usage patterns, usage frequency, decoding difficulty, and decoding time. In some embodiments, the determination of where to assign an instruction of the determined type to the micro-op cache may be based on one or more of the following: least recently used instruction information, instruction history usage patterns, usage frequency, decoding difficulty, loop state information, and the decoding time of instructions stored in the micro-op cache.

[0225] An embodiment may include a system including memory and a processor, the processor being configured to arithmetically determine the type of instruction to be allocated to the micro-op cache; determine the location to which the determined type of instruction will be allocated to the micro-op cache; and allocate the instruction to the determined location.

[0226] In some embodiments, one or more of the following apply. In some embodiments, the processor is further configured to cause intelligent allocation and replacement blocks to receive instructions from the instruction decoder. In some embodiments, the determined instruction type is at least one of complex instructions and loop streams. In some embodiments, the processor may include one or more of a branch prediction unit (BPU), instruction cache tag, micro-op tag, instruction cache, micro-op cache and decoder, and micro-op queue. In some embodiments, the micro-op cache may include next-line prediction. In some embodiments, the processor is configured to store MS streams in the micro-op cache. In some embodiments, the processor is configured to prioritize micro-operations. In some embodiments, the processor includes a victim cache. In some embodiments, the micro-op cache includes at least one of a physical micro-op cache and a virtual micro-op cache. In some embodiments, at least one of a physical micro-op cache and a virtual micro-op cache may be shared competitively. In some embodiments, determining which type of instruction is allocated to the micro-op cache may be based at least in part on one or more of the following: historical usage patterns, usage frequency, decoding difficulty, and decoding time. In some embodiments, determining the location to assign an instruction of the determined type to the micro-op cache can be based on one or more of the following: least recently used instruction information, instruction history usage patterns, usage frequency, decoding difficulty, loop state information, and the decoding time of instructions stored in the micro-op cache. Move elimination

[0227] The processor core may support move elimination features according to embodiments of the present invention. For many processors, executing move instructions typically involves moving a value from one register to another, or immediately moving it to a register. Because of the frequency of such move instructions, processor performance may be increased if move instructions are processed efficiently.

[0228] Most instructions operate on several source operands and produce a result. They explicitly or indirectly name the source and destination locations from which values ​​are read or written. The names can be locations in logical (architectural) registers or memory.

[0229] Typically, the number of physical registers available to a processor exceeds the number of logical registers, so register renaming can be used to improve performance. In particular, for out-of-order processors, register renaming allows instructions to be executed in a sequence other than their original program order. Therefore, for many out-of-order processors, move instructions are renamed so that the logical registers specified in the original move instructions are renamed as physical registers.

[0230] Renaming a logical register involves mapping the logical register to a physical register. These mappings can be stored in a Register Alias ​​Table (RAT). The RAT maintains the latest mapping for each logical register. The RAT is indexed by logical registers and provides mappings to the corresponding physical registers.

[0231] Figure 29 illustrates the register renaming and the dependency tracking scheme involving three structures: RAT 2900, Active List (AL) 2902, and Free List (FL) 2904. For each logical register specified by the renaming instruction, an unused physical register from FL 2904 is allocated, and RAT 2900 is updated with this new mapping. Once a physical register is no longer referenced by an instruction in the current instruction window, the physical register can be freely reused (i.e., reclaimed).

[0232] Based on the data structure depicted in Figure 29, one method for register reclaiming is to reclaim the register only when an instruction evicts it from RAT 110 (i.e., an instruction that creates a new mapping to the entity register). As a result, whenever a new mapping updates RAT 2900, the evicted old mapping is pushed into AL 2902. (The AL entry is associated with each instruction in the instruction window.) When the instruction is revoked, the entity register of the old mapping recorded in AL 2902 (if any) is reclaimed and pushed into FL 2904. Figure 29 depicts this cycle.

[0233] For many instructions, one of the source registers is also used as the destination register. If the value stored in this source register is needed by a subsequent (in program order) instruction, a register shift instruction can be inserted before the subsequent instruction to copy the source operand in the source register to another logical location so that it can be accessed by a subsequent instruction.

[0234] Another reason for inserting a register move instruction is to set parameter values ​​in the appropriate register before the process call.

[0235] As a result, the number of register move instructions can be quite significant. Therefore, an efficient register renaming and reclamation scheme may be needed to provide efficient execution of register move instructions.

[0236] In Figure 1B, the register renaming function unit is indicated as rename / allocator unit 152, and the physical register is indicated as physical register file unit 158. In Figure 3, the register renaming function unit is indicated as integer renaming unit 321 and FP renaming unit 331, and the physical register is indicated by integer physical register file 323 and FP register file 333. Each logical register has a mapping to the physical register, wherein the mapping is stored in RAT 2900 as an entry. The entries in RAT 2900 are indexed by the logical register and contain pointers to the physical registers.

[0237] During instruction renaming, the current entry in the RAT provides the mapping required for the source logical register of the renaming instruction, and establishes a new mapping for the destination logical register of the instruction. This new mapping displaces the old mapping in the RAT, and the RAT is updated using the new mapping.

[0238] Table 1 shows an example of register renaming. In Table 1, the first row provides four instructions in the original program sequence. The renaming instructions are indicated in the second row. Next to each renaming instruction is the current entry in the RAT after the instruction is renamed. The last row provides the mappings removed by the instruction renaming. For simplicity, only three logical registers LRa, LRb, and LRb are considered. Physical registers are represented by PRi, where i is an integer. The first entry in Table 1 provides the current state of the RAT before the first listed instruction is renamed.

[0239] For example, in Table 1, the first instruction LRa + 2 à LRa (indicating that 2 is immediately added to the logical register LRa and the result is stored in the logical register LRa) is renamed PR1 + 2 à PR2, where the physical register PR2 is assumed to be available. For this instruction, a new mapping LRa à PR2 is created, and the old mapping LRa à PR1 is evicted from RAT.

[0240] Please note that the second and fourth instructions have a true dependency on the first instruction, and the third instruction has a true dependency on the second instruction. However, the register renaming has removed the output dependency between the second and fourth instructions, as well as the anti-dependency between the third and fourth instructions, so that the second, third, and fourth instructions can be executed out of order, as long as the execution order follows the various true dependencies.

[0241] The rename instruction is placed in the instruction window buffer. The entries in the instruction window buffer contain the opcode of the rename instruction, as well as other fields, which will be described later. In this embodiment, the result of the instruction is not stored in the instruction window buffer, but resides in the entity temporary register file.

[0242] The instruction window buffer allows instructions to be revoked in the original program order. For Complex Instruction Set Computer (CISC) architectures, the complex instruction is revoked when all the microinstructions constituting the complex instruction are revoked together. The instruction window buffer operates as a circular buffer, where a first index points to the next instruction to be revoked, and a second index points to the next available entry for the newly decoded instruction. The index is incremented in a modulo N operation, where N is the number of available entries in the buffer. When an instruction is revoked, the first index is incremented. For Reduced Instruction Set Computer (RISC) architectures, the index is incremented by one for each decoded instruction, and for CISC architectures, it can be incremented more than one.

[0243] For storage instructions that write their results to a memory location, the data cache is updated when the instruction is revoked. For instructions that write their results to a logical register, since there is no register specifically used as a logical register, it is not necessary to write them upon revocation. For this type of instruction, the physical register file contains the result of the revoked instruction in the physical register to which the destination logical register is mapped when the instruction is renamed.

[0244] The scheduler schedules instructions to execution units for execution. The scheduling function can be implemented, for example, by a reservation station implementing Tomasulo's algorithm (or a variation thereof). The execution unit can retrieve data from or send data to the data cache or physical register file depending on the instruction (or microinstruction) to be executed.

[0245] In other embodiments of the present invention, the information content contained in the data structure of the entity register file and the instruction window buffer can be implemented by different functional units. For example, a reordering buffer can replace the instruction window buffer and the entity register file, thereby storing the result in the reordering buffer. Furthermore, the registers in the register file are specifically used as logical registers. In this type of embodiment, when an instruction is withdrawn, the result of the instruction specified to be written to the logical register is written to the logical register.

[0246] We now distinguish between two types of move instructions: register-to-register move and immediate-to-register move. In a register-to-register move, the value is moved from one register, the source logic register, to another register, the destination logic register. In an immediate-to-register move, the immediate value is moved to the logic register.

[0247] In an embodiment of the present invention, a move instruction is executed by mapping more than one logical register to the same physical register. The execution of a register-to-register move instruction is achieved by mapping the destination logical register of the move instruction to a physical register mapped by the source logical register of the move instruction.

[0248] Execution of a move instruction to an immediate register can be performed by accessing a value-matching cache. Entries in the value-matching cache are indexed by values, where each cache entry associates a value with an entity register storing that value. The value-matching cache may have fewer entries than the number of entity registers. If a match occurs in the value-matching cache, the destination logical register of the move instruction is mapped to the entity register indicated by the value-matching cache. If no match occurs, the move execution follows the previous technical architecture, and the value-matching cache is updated.

[0249] The entity register file can provide value matching caching functionality itself, thus eliminating the need for a value matching caching mechanism. In this case, the register file does not require an additional port to perform parallel tag matching, where the tags are values ​​stored in the entity register.

[0250] As discussed above, register-to-register move instructions and immediate-to-register move instructions (provided there is a value matching cache hit in the latter type of move) are executed by establishing multiple mappings, where more than one logical register is mapped to the same physical register. In effect, such move instructions are "eliminated" in the sense that they are no longer executed by the execution unit. Instead, move elimination is performed during the renaming phase. These instructions remain in the instruction buffer window ready to be revoked. Because instructions that depend on such move instructions are directly dependent on the actual producer (dependencies are redirected), the dependency graph collapses. Requirements for physical registers may also be reduced, and there may be less writing to the register file.

[0251] Idiom elimination mechanisms similarly affect instruction operations without passing them to the traditional out-of-order pipeline. Idioms are instances of generic instructions encoded to perform specific effects, often in a more optimized way compared to explicit instructions. Move idioms include any instruction constructed to place the contents of a source register into a destination register without any other effect, such as R1 = ADD R0, #0. Zero idioms are similar to generic instructions encoded to set a register to zero, such as R0 = XOR R0, R0. No-ops (NOPs) are instructions defined as having no effect on the architecture state, including explicit NOP opcodes and NOP idioms, such as R0 = ADD R0, #0.

[0252] Embodiments of the present invention are expected to improve existing motion removal and idiom removal technologies by saving micro-operation renaming / allocation bandwidth, improving performance, reducing power consumption and implementing power-saving features, and improving fairness, minimum performance guarantee, throughput, instructions per clock cycle (IPC), instructions per unit time, quality of service, time and / or memory efficiency, and expanding the coverage of motion removal to more instruction types.

[0253] In an embodiment, the results of the instantaneous move elimination and idiom elimination operations on the instruction stream can be cached in the decoding micro-op cache, such as micro-op cache 133 or 312. Therefore, the rediscovery of necessary conditions and the repetition of the operation of eliminating the original instructions from the pipeline can be avoided.

[0254] Eliminated instructions can be replaced by metadata stored in the micro-op cache, achieving the same effect as the eliminated instructions. When writing to the micro-op cache, the results of move elimination or idiom elimination are converted into metadata, allowing micro-ops to be removed from the micro-op cache and thus optimized from the delivered micro-op stream. Since the immediate instruction elimination mechanism has already done the work of identifying opportunities, the micro-op cache build can be modified to scan for and remove affected micro-ops. Metadata includes information required to perform the renaming operation, relevant architectural information, such as the presence of event boundaries and the effect of performance monitoring counters. For example, metadata may indicate how many instructions were eliminated, and / or, for a CISC architecture, how many micro-ops were eliminated per instruction, and / or that macro instruction termination occurred after the instruction was eliminated. Before and / or after eliminating micro-ops, metadata can be stored in fields within the micro-op entries.

[0255] In one embodiment, move elimination can be extended to include zero expansion and sign expansion operations. For example, R0 = MOV.ZE R1 may be move eliminated, even though this is not a simple action.

[0256] In one embodiment, the RAT 3000 can be extended as shown in FIG30 to include zero idioms, symbolic extensions, and zero extensions. The RAT is extended with the following three bits: Z, when set, the rest of the RAT entry is ignored and the logical register is treated as zero; SE, when set, the value of the logical register is a symbolic extended version of the entity register file identifier (PRF ID) stored in the entry; and ZE, when set, the value of the logical register is a zero-extended version of the PRF ID stored in the entry.

[0257] Then, as shown in Figure 31, during register renaming, the Z, SE, and ZE bits can be read and passed down the pipeline via the micro-op of reading the register. These bits are interpreted before the operation of ALU 3120 to create the correct result. In Figure 31, the left source path is conceptually extended to include the interpretation of the Z, SE, and ZE bits by multiplexer 3110. Based on these bits, the source is used without modification in the bypass network or physical register file, replaced with zero, used after sign expansion, or used after zero expansion. Summary of some embodiments

[0258] Embodiments of the present invention may include a processor comprising a micro-operation cache, the micro-operation cache comprising a plurality of entry locations. At least one entry location may include a first field and a second field. The first field may be used to store a first micro-operation. The second field may be used to store metadata indicating that a second micro-operation to be eliminated from the micro-operation stream to be decoded from the instruction stream, wherein the second micro-operation is the result of decoding a move instruction.

[0259] Embodiments of the present invention may include a processor, the processor including a register alias table comprising a plurality of entries. At least one entry may include a field therein storing one of a zero indicator, a sign-extended indicator, and a zero-extended indicator. The zero indicator is used to indicate that the source operand will be replaced by zero. The sign-extended indicator is used to indicate that the source operand is used after sign-extended. The zero-extended indicator is used to indicate that the source operand is used after zero-extended. Virtual register renaming.

[0260] The processor core may support a virtual register renaming feature according to embodiments. In some embodiments, the 256-bit operand ymmi may be stored in a 128-bit register file. The upper half of the 256-bit operand may be stored in a 128-bit register file as the 128-bit operand ymmihigh. The lower half of the 256-bit operand may be stored in a 128-bit register file as the 128-bit operand xmmi(ymmilow) by virtually renaming the lower half of the 256-bit operand. In some embodiments, this feature advantageously allows for a wider ISA to be implemented on a smaller physical register by renaming the half of the instruction. In some embodiments, the use of a smaller physical register improves the computer system by providing greater flexibility, power saving, and better performance, because, for example, a portion of the instruction can be accessed individually. In some embodiments, other sizes of instructions and registers may be used (e.g., a 512-bit operand with a 256-bit register). In some embodiments, operands can be divided into smaller pieces, such as one-third, one-quarter, one-eighth, or one-sixteenth. For example, a virtual register renaming feature can be used to preserve 512-bit operands because eight parts are stored in a 64-bit register file.

[0261] Figure 32 is a block diagram illustrating a virtual register renaming feature that may be included in a processor according to an embodiment. The virtual register renaming feature may include an operand 3201 such as a 256-bit operand ymmi. The virtual register renaming feature may further include a 128-bit register file 3201. The 256-bit operand ymmi 3201 may be stored in the 128-bit register file 3202. The upper half of the 256-bit operand 3201 may be stored in the 128-bit register file 3202 as a 128-bit operand ymmihigh. The lower half of the 256-bit operand 3201 may be stored in the 128-bit register file 3202 as a 128-bit operand xmmi(ymmilow) by virtually renaming the lower half of the 256-bit operand.

[0262] Figure 33 is a flowchart illustrating a method for a virtual register renaming feature executable by a processor according to an embodiment. The method includes storing the lower half of an operand in a register file, as shown in 3301. The method further includes virtually renaming the upper half of the operand, as shown in 3302. The method further includes storing the virtually renamed upper half of the operand in the register file. In further embodiments, other modifications are possible. For example, the lower half of the operand may be virtually renamed instead of the upper half. Additionally, the operations may be performed in a different order. For example, the storage of the non-virtually renamed half may be performed before or after the virtual renaming and / or storage of the virtually renamed half. Alternatively, the virtually renamed half may be virtually renamed and then stored, or vice versa. Summary of some embodiments

[0263] An embodiment may include a processor configured to store a first half of an operand in a temporary register file; virtually rename a second half of the operand; and store the virtually renamed second half of the operand in a temporary register file. In some embodiments, one or more of the following may apply: The operand may be a 256-bit operand. The temporary register file may be a 128-bit temporary register file.

[0264] An embodiment may include a method comprising storing a first half of an operand in a temporary register file; virtually renaming a second half of the operand; and storing the virtually renamed second half of the operand in a temporary register file. In some embodiments, one or more of the following may apply: The operand may be a 256-bit operand. The temporary register file may be a 128-bit temporary register file.

[0265] Embodiments may include a non-transitory machine-readable medium storing at least one instruction, which, when executed by a processor, causes the processor to execute a method comprising: storing a first half of an operand in a temporary register file; virtually renaming a second half of the operand; and storing the virtually renamed second half of the operand in a temporary register file. In some embodiments, one or more of the following may apply: The operand may be a 256-bit operand. The temporary register file may be a 128-bit temporary register file.

[0266] An embodiment may include a system including memory and a processor configured to store a first half of an operand in a temporary register file; virtually rename a second half of the operand; and store the virtually renamed second half of the operand in a temporary register file. In some embodiments, one or more of the following may apply: The operand may be a 256-bit operand. The temporary register file may be a 128-bit temporary register file. FMA splitting and merging

[0267] According to embodiments of the present invention, the processor core may support the splitting and merging of multiply-accumulate instructions and operations. In various embodiments, the processor core may support an instruction set having any one or more of addition, multiplication, product-and-melt-add (FMAD) and / or product-and-accumulate (FMAC) instructions (wherein FMAD and / or FMAC may be referred to as FMA) to operate on FP values. Such a core may include any one or more of adder circuitry, multiplier circuitry, and / or FMA circuitry to perform FP addition, multiplication, and / or FMA operations in response to these instructions. Separate instructions and / or circuitry may be provided to operate on integer values ​​(e.g., FMAC) and FP values ​​(e.g., FMAD), and embodiments may be described with reference to one or the other (integer or FP); however, various embodiments of the present invention may include one or two.

[0268] Embodiments of the present invention provide the ability to convert FMA instructions / operations into pairs of addition and multiplication instructions / operations (split) and / or convert pairs of addition and multiplication instructions / operations into FMA instructions / operations (merge) between and / or within different stages of the instruction issuance / execution pipeline. This feature is often referred to as FMA splitting / merging or dynamic FMA splitting / merging.

[0269] Embodiments of the present invention including FMA splitting / merging may be desired for a number of reasons, including: providing the ability to execute FMA instructions and / or perform FMA operations in cores with adder and multiplier circuitry but without FMA circuitry; providing the ability to use FMA operations to execute multiplication and addition instructions to improve throughput through one or more core resources; providing the ability to dynamically split FMA instructions or operations into multiplication and addition operations to reduce critical paths in loops and increase instructions per loop; and providing the possibility of progressively optimizing pipelines with FMA capabilities in a combination of desired performance, complexity, and power (e.g., improved performance, reduced power consumption and implementation of power-saving features, and improved fairness, minimum performance guarantees, throughput, instructions per clock (IPC), instructions per unit time, quality of service, time and / or memory efficiency, to name just a few applicable criteria).

[0270] Figure 34 is a block diagram illustrating an issue / execution pipeline 3400 that can be implemented in a processor core supporting FMA split / fusion features according to an embodiment of the present invention. In Figure 34, pipeline 3400 includes an instruction fetch stage 3401, an instruction decode stage 3402, a renaming / assignment stage 3403, a scheduling stage 3404, an execution stage 3405, and a withdraw / commit stage 3406. Pipeline 3400 is provided for illustrative purposes, and pipeline 3400 can be implemented and / or modified in various ways in various embodiments of the present invention. Therefore, the following description of pipeline 3400 can be referenced to the various blocks shown in the other figures described in this specification.

[0271] For example, the instruction fetching stage 3401 may include using instruction fetching circuitry (e.g., 138, 400) to identify (e.g., using the next PC register 410) the fetched instruction or the memory location of the instruction and fetching the instruction from the i-cache (e.g., 134, 313, 470, 913) or other memory locations; the instruction decoding stage 3402 may include using instruction decoding circuitry (e.g., 140, 314, 500, 914) to decode (e.g., using decoder 530) the instruction; the renaming / allocation stage 3403 may include using renaming / allocator circuitry (e.g., 152, 331, 931) to rename register operands and / or allocate storage locations and / or tags for register renaming; the scheduling stage 3404 may include using scheduler circuitry (e.g., 1 The execution phase 3405 may include using execution circuitry (e.g., 162, 334, 335, 770, 780, 934, 935) to execute operations and / or micro-ops associated with the instructions (e.g., from decoders 140, 314, 530, or 614 or micro-op caches 133, 312, 540, or 912); and the withdrawal / commit phase 3406 may include using withdrawal circuitry (e.g., 154, 730, 960) to withdraw instructions and / or commit their results to physical register files (e.g., 158, 333, 750, 933) or memory. Each stage shown in Figure 34 may represent one or more stages and / or clock cycles in various embodiments.

[0272] Figure 34 also shows a fusion path 3410 and a separate path 3420, each representing an embodiment of a path through pipeline 3400. As described below using illustrative embodiments, the fusion path 3410 may include circuitry, structures, and / or hardware for processing, executing, and / or performing FMA instructions, operations, and / or micro-ops as fusion instructions, operations, and / or micro-ops. As described below using illustrative embodiments, the separate path 3420 may include circuitry, structures, and / or hardware for processing, executing, and / or performing multiplication and addition instructions, operations, and / or micro-ops as separate instructions, operations, and / or micro-ops. Furthermore, the separate path 3420 may include circuitry, structures, and / or hardware for processing, executing, and / or performing FMA instructions, operating and / or micro-ops as multiplication and addition instructions, operating and / or micro-ops; and the fusion path 3410 may include circuitry, structures, and / or hardware for processing, executing, and / or performing multiplication and addition instructions, operating and / or micro-ops as fusion instructions, operating and / or micro-ops.

[0273] Therefore, Figure 34 conceptually illustrates a set of core resources that can be used to process, execute, and / or perform fused and / or separated multiplication and addition instructions, operations, and micro-operations. Various embodiments may include various subsets of these resources to support a variety of capabilities, which will be further described below. Moreover, implementations may include various additional resources, not shown in Figure 34, that may be provided and / or configured for various embodiments of the invention.

[0274] Figure 34 also shows an FMA split / fusion controller 3430, which may represent a programmable, configurable, or hardwired controller or control structure including one or more control circuits and / or software-programmable or hardware-configurable registers to generate control signals to guide instructions, operations, micro-ops, arithmetic units, values, and / or other data through and / or between the fusion path 3410 and / or the split path 3420. These control signals may be provided through one or more paths of pipeline 3400, which include combinations of resources in the fusion path 3410 and the split path 3420. These control signals can provide dynamic FMA splitting / fusion by causing FMA instructions, operations and / or micro-ops to be processed, executed and / or executed in response to a first state as fusion instructions, operations and / or micro-ops and in response to a second state as separate multiplication and addition instructions, operations and / or micro-ops, and by causing separate multiplication and addition instructions, operations and / or micro-ops to be processed, executed and / or executed in response to a third state as fusion instructions, operations and / or micro-ops and in response to a fourth state as separate multiplication and addition instructions, operations and / or micro-ops.

[0275] For example, FMA instructions can be extracted by hardware in fusion path 3410, and controller 3430 can generate one or more control signals to route instructions to hardware in decoupling path 3420 to decode instructions into two separate micro-ops, multiple micro-ops, and additive micro-ops. Although shown as separate blocks in FIG34, in various embodiments controller 3430 may be integrated or included in another control structure in the processor core or may be omitted entirely (e.g., in embodiments where the core provides only one possible path, examples of which are described below).

[0276] In Figure 34, the fusion path 3410 includes an extractor 3411, a decoder 3412, a renamer 3413, a scheduler 3414, a multiplier-adder 3415, and a reorder buffer / recall queue (ROB / RQ) 3416; and the separation path 3420 includes an extractor 3421, a decoder 3422, a renamer 3423, a scheduler 3424, a multiplier 3425A, an adder 3425B, and a reorder buffer / recall queue (ROB / RQ) 3426.

[0277] Extractor 3411 may include instructions for extracting FMA instructions (e.g., AVX (as defined below) instructions, such as VFMADD132PS, VFMADD213PS, VFMADD231PS, VFMADD132PD, VFMADD213PD, VFMADD231PD, VFMADD132SS, VFMADD213SS, VFMADD231SS, VFMADD132SD, VFMADD213SD, VFMADD231SD, VFMSUB132PS, VFMSUB213PS, VFMSUB231PS, VFMSUB132PD, VFMSUB213PD, VFMSUB231PD, VFMSUB132SS, VFMSUB213SS, VFMSUB231SS, VFMSUB132SD, VFMSUB213SD, VF... MSUB231SD, VFNMADD132PS, VFNMADD213PS, VFNMADD231PS, VFNMADD132PD, VFNMADD213PD, VFNMADD231PD, VFNMADD132SS, VFNMADD213SS, VFNMADD231SS, VFNMADD132SD, VFNMADD213SD, VFNMADD2 31SD, VFNMSUB132PS, VFNMSUB213PS, VFNMSUB231PS, VFNMSUB132PD, VFNMSUB213PD, VFNMSUB231PD, VFNMSUB132SS, VFNMSUB213SS, VFNMSUB231SS, VFNMSUB132SD, VFNMSUB213SD, VFNMSUB231SD, Circuits and / or structures of VFMADDSUB132PS, VFMADDSUB213PS, VFMADDSUB231PS, VFMADDSUB132PD, VFMADDSUB213PD, VFMADDSUB231PD, VFMSUBADD132PS, VFMSUBADD213PS, VFMSUBADD231PS, VFMSUBADD132PD, VFMSUBADD213PD or VFMSUBADD231PD.

[0278] The FMA instruction extracted by extractor 3411 may have three operands. For example, the VFMADD231PS instruction may have a first operand (xmm1 or ymm1), a second operand (xmm2 or ymm2), and a third operand (xmm3 or ymm3), wherein the xmm and ymm registers specified by these operands are described below. These registers can store scalar or compressed values, and for ease of description of the embodiments, the letter "d" can be used to refer to the source / destination register or a portion of the register specified by the xmm1 operand and / or the value stored or stored in this register or a portion of this register; the letter "a" can be used to refer to the source register or a portion of the register specified by the xmm2 operand and / or the value stored or stored in this register or a portion of this register; and the letter "b" can be used to refer to the source register or a portion specified by the xmm3 operand and / or the value stored or stored in this register or a portion of this register. Therefore, the conceptual representation of the operation performed in response to the VFMADD231PS instruction (where a, b, and d can also be referred to as operands) is d = a * b + d. Furthermore, although this specification refers to operands as registers, embodiments may use memory locations instead of registers for any or all operands.

[0279] Extractor 3421 may include circuitry, structure, and / or hardware for extracting multiplication instructions (e.g., SSE (Streaming Single Instruction Multiple Data Extension) instructions such as MULPS, MULPD, MULSS, or MULSD) and addition instructions (e.g., SSE instructions such as ADDPS, ADDPD, ADDSS, or ADDSD), each having two operands. For example, the MULPS instruction may have a first operand (xmm1) and a second operand (xmm2), and the ADDPS instruction may have a first operand (xmm1) and a second operand (xmm2), wherein typically each MULPS xmm1, MULPS xmm2, ADDPS xmm1, and ADDPS xmm2 operand may be a different register. However, in embodiments of the invention, extractor 3421 may pair the MULPS instruction with the ADDPS instruction when it determines that the ADDPS instruction depends on the MULPS instruction (i.e., the MULPS result is the input to ADDPS). For example, with "a" as a MULPS xmm1 operand and "b" as a MULPS xmm2 operand, the corresponding multiplication operation is a = a * b. If "a" is then used as an ADDPS xmm2 operand and "d" as an ADDPS xmm1 operand, the corresponding addition operation is d = d + a. The extractor 3421 can pair MULPS and ADDPS instructions. In an embodiment, pairing and / or determining whether pairing conditions are met are performed in response to a control signal from the controller 3430.

[0280] Extractor 3411 may be coupled or connected to decoder 3412 as shown by arrow 3432A and / or coupled or connected to decoder 3422 as shown by arrow 3432B. Extractor 3421 may be coupled or connected to decoder 3412 as shown by arrow 3432C and / or coupled or connected to decoder 3422 as shown by arrow 3432D. In various embodiments, the coupling or connection and / or decoder operation may be static (e.g., hardwired) or dynamic (e.g., dependent on control signals from 3430).

[0281] Decoder 3412 may include circuitry, structure, and / or hardware for decoding FMA instructions received from extractor 3411 into FMA micro-ops with three operands (e.g., d, a, and b). Alternatively, decoder 3412 may include circuitry, structure, and / or hardware for decoding paired multiplication and addition instructions received from extractor 3421 into FMA micro-ops with three operands (e.g., d, a, and b).

[0282] Decoder 3422 may include circuitry, structures, and / or hardware for decoding FMA instructions received from extractor 3411 into multiplication micro-ops with two operands and addition micro-ops with two operands. Alternatively, decoder 3422 may include circuitry, structures, and / or hardware for decoding paired multiplication and addition instructions from extractor 3421 into multiplication micro-ops with two operands and addition micro-ops with two operands. For example, multiplication micro-ops may be represented as t = a * b, and addition micro-ops as d = d + t, where new operands "t" may be introduced as the destination of multiplication operations and the source of addition operations.

[0283] Decoder 3412 may be coupled or connected to renamer 3413 as shown by arrow 3433A and / or coupled or connected to renamer 3423 as shown by arrow 3433B. Decoder 3422 may be coupled or connected to renamer 3413 as shown by arrow 3433C and / or coupled or connected to renamer 3423 as shown by arrow 3433D. In various embodiments, the coupling or connection and / or renamer operation may be static (e.g., hardwired) or dynamic (e.g., dependent on control signals from 3430).

[0284] Renamers 3413 and / or 3423 may include circuitry, structures, and / or hardware (such as reorder buffers) for renaming register operands and / or for allocating storage locations and / or tags for register renaming (e.g., accommodating out-of-order processing). In embodiments, to eliminate register conflicts (e.g., for a, b, t, and / or d), renamer 3413 may rename operands for FMA operations (e.g., a', b', and / or d'); and / or renamer 3423 may rename operands for multiplication operations (e.g., as a' and / or b') and for addition operations (e.g., as t' and / or d').

[0285] Renamer 3413 may be coupled or connected to scheduler 3414 as shown by arrow 3434A and / or coupled or connected to scheduler 3424 as shown by arrow 3434B. Renamer 3423 may be coupled or connected to scheduler 3414 as shown by arrow 3434C and / or coupled or connected to scheduler 3424 as shown by arrow 3434D. In various embodiments, the coupling or connection and / or scheduler operation may be static (e.g., hardwired) or dynamic (e.g., dependent on control signals from 3430).

[0286] Schedulers 3414 and / or 3424 may include circuitry, structures, and / or hardware (such as reserved stations) for scheduling operations and / or micro-ops to be performed. In embodiments, scheduler 3414 may schedule FMA operations to be performed with operands a, b, and d in a reserved station for FP execution circuitry, and / or scheduler 3424 may schedule multiplier operations to be performed with operands a and b and addition operations to be performed with operands t and d in a reserved station for FP execution circuitry.

[0287] Scheduler 3414 may be coupled or connected to integrator 3415 as shown by arrow 3435A and / or coupled or connected to multiplier 3425A or both multiplier 3425A and adder 3425B as shown by arrow 3435B. Scheduler 3424 may be coupled or connected to integrator 3415 as shown by arrow 3434C and / or coupled or connected to multiplier 3425A or both multiplier 3425A and adder 3425B as shown by arrow 3434D. In various embodiments, the coupling or connection and / or scheduler operation may be static (e.g., hardwired) or dynamic (e.g., dependent on control signals from 3430).

[0288] The fusion multiplier / adder 3415, multiplier 3425A, and adder 3425B may include circuitry, structures, and / or hardware that respectively perform product and fusion operations, multiplication operations, and addition operations. In one embodiment, multiplier 3425A may be coupled to a reserved station to receive two inputs (e.g., a and b) for the addition operation and coupled to adder 3425B to provide its output (e.g., t) as one of the two inputs (e.g., t and d) for the addition operation. In this embodiment, the accuracy of the dedicated product and fusion adder (e.g., according to IEEE Standard 754) may be obtained by sending unused multiplication results to the adder. In another embodiment, multiplier 3425A may be coupled to a reserved station to receive two inputs (e.g., a and b) for the multiplication operation that produces the output (e.g., t), and adder 3425A may be coupled to a reserved station to receive two inputs (e.g., t and d) for the addition operation. In this embodiment, the accuracy of the dedicated integrator and melter can be achieved by increasing the width of the internal storage space for intermediate results (e.g., t) or by providing special handling using microcode assistance or traps.

[0289] The integrator 3415 may be coupled or connected to ROB / RQ 3416 as shown by arrow 3436A and / or coupled or connected to ROB / RQ 3426 as shown by arrow 3436B. Adder 3425B may be coupled or connected to ROB / RQ 3416 as shown by arrow 3436C, and / or both adder 3425B and multiplier 3425A and adder 3425B may be coupled or connected to ROB / RQ 3426 as shown by arrow 3436D. In various embodiments, the coupling or connection and / or scheduler operation may be static (e.g., hardwired) or dynamic (e.g., dependent on control signals from 3430).

[0290] ROB / RQ 3416 and / or ROB / RQ 3426 may include circuitry, structures, and / or hardware (such as reorder buffers and / or revocation queues) for withdrawing instructions and / or submitting results. In one embodiment, ROB / RQ 3416 may withdraw an FMA instruction and submit its result (e.g., xmm1). In one embodiment, ROB / RQ 3426 may withdraw multiplication and addition instructions and submit their results (MULPS xmm1, ADDPS xmm1, respectively). In one embodiment, ROB / RQ 3416 may submit the result of an FMA operation established by fusing separate multiplication and addition instructions, provided that the result of the separate multiplication operation is not expected (e.g., expected according to the instruction set architecture). In one embodiment, as a result of an FMA instruction, ROB / RQ 3426 may submit the result of an addition operation established by splitting an FMA instruction. In the processor core according to an embodiment of the present invention, the result of the addition instruction will be the same as the result of the corresponding FMA instruction.

[0291] As shown in Figure 34, embodiments can provide FMA splitting or merging at various stages of the issuance / execution pipeline. In one embodiment, splitting at the decoding stage 3402 can provide product and fusion instructions executed in the core without a product and fusion processor. In one embodiment, merging at the decoding stage 3402, renaming / assignment stage 3403, scheduling stage 3404, execution stage 3405, and / or rollback stage 3406 can provide greater throughput (one instruction / operation / micro-op instead of two instructions / operations / micro-ops) through hardware resources. In an embodiment, splitting at the renaming / assignment stage 3403 can provide reduced complexity in the renaming hardware by limiting the number of operands to two instead of three. In an embodiment, merging at the renaming / assignment stage 3403 and / or scheduling stage 3404 can provide fewer entries in the renaming, reordering, and / or scheduling store to allow for deeper out-of-order execution windows and / or larger instruction hierarchy parallel discovery. In one embodiment, splitting in scheduling phase 3404 can provide reduced hardware complexity by limiting the number of out-of-order wake-up sources to two instead of three per entry. In one embodiment, splitting in scheduling phase 3404 and / or execution phase 3405 can provide shortened latency by allowing different parts of the FMA operation to execute at different times, thus limiting the critical path to the critical path of the slowest part rather than the sum of both parts. In one embodiment, fusion in execution phase 3405 can provide increased performance, increased accuracy, and / or reduced power consumption by using a dedicated integrator and fusion mixer.

[0292] FIG35 is a flowchart illustrating a method for FMA splitting / merging that can be executed by a processor according to an embodiment of the present invention. In block 3510 of method 3500 of FIG35, instruction fetching circuitry (e.g., 138, 400) may fetch instructions from i-cache (e.g., 134, 313, 470, 913) or other memory locations. For example, the instruction may be an example of an FMA instruction having a first operand ("d"), a second operand ("a"), and a third operand ("b"), such as VFMADD231PS, which the processor responds to by performing an FMA operation (e.g., d = a * b + d).

[0293] In block 3520, a hardwired, configured, or programmed instruction decoding circuit or decoder (e.g., 140, 314, 500, 914) for executing the splitting of FMA instructions can decode the instruction into multiple individual micro-ops, multiplication micro-ops, and addition micro-ops. The decoder can select specific operands from the FMA instruction and / or from another micro-op, assign one or more of them to one or more individual micro-ops, and / or create new operands for one or more individual micro-ops. For example, the decoder can select the "a" and "b" operands of the FMA instruction as the source operands of the multiplication micro-op, and establish the "t" operand as the specified operand of the multiplication micro-op. The processor responds by executing the multiplication operation t = a * b. The decoder can also select the "d" operand of the FMA instruction and the "t" operand of the multiplication micro-op as the source operands of the addition micro-op, and select the "d" operand of the FMA instruction as the destination operand of the addition micro-op. The processor responds by executing the addition operation d = d * t.

[0294] In block 3530, the register renaming circuit (e.g., 152, 331, 931) can rename any operand used for register renaming (e.g., in a reordering buffer), allocate storage locations and / or tags, and / or implement the allocation of the output of the multiplication micro-op (e.g., "t") as input to the addition micro-op.

[0295] In block 3540, a scheduler circuit (e.g., 156, 332, 932) can schedule individual micro-ops for execution, for example, in a reservation station for FP cells. In one embodiment, multiple individual micro-ops decoded from the same instance of instructions (e.g., multiplication and addition micro-ops decoded from FMA instructions) can be scheduled in a reservation station for scheduling in a specified order (e.g., the addition micro-op can only be scheduled for scheduling after scheduling and / or completion of multiple micro-ops).

[0296] In block 3550, the execution circuitry (e.g., 162, 334, 770, 934) can perform one of the individual micro-operations. For example, FP multipliers 334A, 334B, 770A, 770B, 934A, or 934B can perform a multiplication micro-operation.

[0297] In block 3552, the execution circuitry (e.g., 162, 335, 780, 935) can perform other individual micro-operations. For example, FP adders 335A, 335B, 780A, 780B, 935A, or 935B can perform an addition micro-operation.

[0298] In block 3560, the retraction circuitry (e.g., 154, 730, 960) can retract an instruction and / or commit its result to a physical register file (e.g., 158, 333, 750, 933) or memory. In embodiments, block 3560 may include the retraction of only one of the individual micro-ops decoded from the instruction. For example, an FMA instruction can be retracted and / or its result committed by retracting the corresponding addition micro-op from the reordering buffer and committing its result (e.g., d). Summary of some embodiments

[0299] Embodiments of the present invention may include a processor comprising a plurality of circuits configured in a pipeline. The plurality of circuits may include a decoder for decoding multiplication and fusion instructions as at least two separate micro-operations. The plurality of circuits may also include a multiplier for the first operation in the two separate micro-operations and an adder for the second operation in the two separate micro-operations. Specific processor architecture

[0300] FIG36 is a block diagram of a processor 3600 according to an embodiment of the present invention. The processor 3600 may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid-line boxes in FIG36 illustrate a processor 3600 having a single core 3602A, a system agent 3610, and a set of one or more bus controller units 3616, while the selectively added dashed-line boxes illustrate another processor 3600 having multiple cores 3602A-N, one or more integrated memory controller units 3614 in the system agent unit 3610, and special purpose logic 3608.

[0301] Therefore, different implementations of processor 3600 may include: 1) a CPU having special purpose logic 3608 which is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and cores 3602A-N which are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose out-of-order cores, or a combination thereof); 2) a coprocessor having cores 3602A-N which are a large number of general-purpose cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor having cores 3602A-N which are a large number of general-purpose ordered cores. Therefore, processor 3600 may be a general-purpose processor, server processor or processing element for server environments, a coprocessor (e.g., a security coprocessor), a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or digital signal processing (DSP) unit, a cryptographic accelerator, a fixed-function accelerator, a machine learning accelerator, a network accelerator, or a computer vision accelerator), a field-programmable gate array, or any other processor or processing device. The processor may be implemented on one or more chips. The processor 3600 may be part of one or more substrates and / or may be implemented on one or more substrates using a variety of processing technologies such as BiCMOS, CMOS, or NMOS.

[0302] The memory hierarchy includes one or more cache hierarchies within the core, a collection of one or more shared cache units 3606, and external memory (not shown) coupled to a collection of integrated memory controller units 3614. The collection of shared cache units 3606 may include one or more intermediate caches, such as hierarchy 2 (L2), hierarchy 3 (L3), hierarchy 4 (L4), or other hierarchy caches, the lowest hierarchy cache (LLC), and / or combinations thereof. Although in one embodiment, a ring-based interconnect unit 3612 interconnects integrated graphics logic 3608 (integrated graphics logic 3608 is an example herein and is also referred to herein as dedicated logic), the collection of shared cache units 3606, and the system agent unit 3610 / integrated memory controller unit 3614, other embodiments may use any number of well-known techniques to interconnect these units. In one embodiment, one or more cache units 3606 maintain synchronization with the cores 3602A-N.

[0303] In some embodiments, one or more of the cores 3602A-N may be multi-threaded. System agent 3610 includes components that coordinate and operate the cores 3602A-N. System agent unit 3610 may include, for example, a power control unit (PCU) and a display unit. The power control unit (PCU) may be or include logic and components required to regulate the power state of the cores 3602A-N and integrated graphics logic 3608. The display unit is used to drive one or more externally connected displays.

[0304] Cores 3602A-N can be homogeneous or heterogeneous in terms of their instruction sets; in other words, two or more of the cores 3602A-N may be able to execute the same instruction set, while others may only be able to execute a subset of that instruction set or a different instruction set.

[0305] Figure 37 is a block diagram of an illustrative central processing unit (CPU) complex that may be included in a processor according to an embodiment of the present invention. In the embodiment, the L3 cache is an 8 MB 16-way cache, which is split by a quad-core module (referred to as a CPU complex or CCX) to provide 2 MB "slices" of the L3 cache for each core. However, the L3 cache slices implemented in the CCX make L3 a shared cache. Multiple CCXs may be included in a single processor (e.g., two CCXs form a 16 MB L3 cache). The 8 MB cache on each CCX is independent, so they can serve as the last-level cache for each quad-core module with appropriate hooks to insert other L3 caches to determine whether data is needed (the protocol involved in the L3 cache design allows each core to access the L3 cache of each other core). Therefore, these L1, L2, and L3 caches are homogeneous caches, wherein the L3 cache slices within and between CCXs are connected by cache homogeneous interconnects (also referred to as cache homogeneous structures).

[0306] FIG38 is a block diagram of an illustrative cache hierarchy that may be included in a processor according to an embodiment of the present invention. In FIG38, cache hierarchy 3800 includes L1 i-cache 3810A and L1 d-cache 3810B (collectively referred to as L1 cache 3810), L2 instruction and data cache 3820, and hierarchy 3 (L3) instruction and data cache 3830. In an embodiment, the two L1 caches 3810 and L2 cache 3820 are private / local write-back caches, while L3 cache 3830 is a victim cache. In an embodiment, L1 i-cache 3810A is a 64 KB 4-way cache, L1 d-cache 3810B is a 32 KB 8-way cache, L2 cache 3820 is a 512 KB 8-way cache, and hierarchy 3 (L3) cache 3830 is an 8 MB 16-way cache. Memory organization characteristics

[0307] The processor core, processor, and system according to embodiments of the present invention may include various features relating to memory organization and use. Several such features are described separately below using non-limiting examples, but embodiments may include any combination of such features. (Cache line zeroing)

[0308] Some embodiments include instructions whose execution results in a write of zero cache line size at a memory address. Such instructions may be referred to as cache line zeroing instructions, CLZERO instructions, CLZEROING instructions, cache line initialization instructions, CLINIT instructions, etc. In one embodiment, the cache line zeroing instruction is a macro instruction executed by a core such as core 190 and / or core 5300. Specifically, decoder 140 and / or decoder 5314 will be implemented to decode such macro instructions into one or more relatively low-level instructions or control signals (e.g., one or more microinstructions, micro-operations (micro-ops), microcode entry points, decoded instructions or control signals), which respectively cause memory access unit 164 and / or address generation unit 325 / load storage unit 340 to perform operations.

[0309] The advantage of the cache line zeroing instruction is that it zeroes the cache line more quickly and decisively because it does not require a request for ownership (RFO) operation, or at least not a data reply or return. An RFO operation is an operation in cache coherency protocols that combines a read and an invalidation broadcast (a read operation intended to write to a memory address), and thus causes all other coherent caches to set the state of such a cache line to an "invalid" cache coherency protocol state. For example, an RFO operation is typically issued by a processor attempting to write to a cache line in a shared (S) or invalid (I) state under the MESI protocol. The MESI protocol uses "modified," "excluded," "shared," and "invalid" cache coherency protocol states. In contrast, the implementation of the cache line zeroing instruction does not require reading the line and returning it to the issuing agent, as it zeroes the data; in fact, in some embodiments, the issuing agent does not need to own the data.

[0310] In different embodiments, cache line zeroing instructions can be implemented to indicate memory addresses in different ways. For example, a cache line zeroing instruction can be implemented to explicitly (e.g., via immediately, one or more fields), indirectly (e.g., by specifying one or more registers where address information is stored), and / or implicitly (e.g., one or more designated registers) indicate address information. Memory address information can be a memory address used to generate a memory address or information used in combination with other information (e.g., information from a segment register, etc.). Although in some embodiments, memory addresses are aligned on cache line boundaries, alternative embodiments may also support memory addresses between cache line boundaries and treat them as indicating cache lines between these boundaries. Address information can represent absolute memory address information or relative memory address information, which can indicate a memory location relative to a base memory address or other memory location. Additionally, different indirect memory addressing modes may be optionally used. As a concrete example, instructions may implicitly direct a temporary register (e.g., a general-purpose register) used to store relative memory address information, which may be combined with additional memory address information stored in another implicit register (e.g., a code, data, or extended fragment register) to produce a final memory address used to identify the memory address. This is just one example. Other forms of address information are also possible.

[0311] Different embodiments may implement different sizes of cache lines (e.g., 32-bit, 64-bit) and / or a given embodiment may implement more than one cache line size. For example, embodiments may support a cache line zeroing instruction that is: 1) implemented for a specified cache line size (and therefore does not require specifying the cache line size); 2) implemented to use the current cache size, wherein different types of cores have different cache line sizes (e.g., the current cache size may be indicated via a value in a register); or 3) implemented with a field indicating the cache line size. In some embodiments, the instruction allows an indication of a size parameter (i.e., a multiple of the cache line size) for one or more cache lines. In some embodiments, additionally or alternatively, a ZERO instruction is allowed that indicates a size parameter of the instruction that is not bound to the cache line size (e.g., only indicating the # of the byte), because this makes the software unaware of the cache line size (if the size is not a multiple of the cache line size (e.g., specified as 112 in the # of the byte and the byte, even if the cache line size is 64 bytes), the embodiment may also zero out the cache line or issue an RFO that is only for the remaining data in the last line).

[0312] In some embodiments, the cache line zeroing instruction is atomic. Therefore, the entire cache line will be stored, or not the entire cache line, not just a portion (i.e., atomicity is guaranteed). Atomicity also guarantees that zeros written by the cache line zeroing instruction will not be interleaved with other stored data. Atomicity may be related to other accesses, so any such access will observe that all stored data is completely stored, or not stored, not just a portion. Atomicity can also be related to power failures, system crashes, restarts, or other such events, such that even in the face of such events, all zeros are stored, or not zeros are stored, not just a portion. Such atomic operations have various possible uses. One example of this use is atomically updating data in a database. Another example of this use is atomically updating shared data in a multiprocessing environment. Yet another example of this use is atomically storing data to replace locks, flags, to update shared variables, for synchronization, for coordination, etc. Such atomic storage operations are expected to have other uses, which will be apparent to those skilled in the art and have the benefits of the present invention. Exemplary memory hierarchy

[0313] Figure 39 is a block diagram illustrating a memory hierarchy in which cache line zeroing instructions can be implemented according to an embodiment of the present invention. The memory hierarchy shown can be implemented in conjunction with various processor cores, core clusters, CCXs, processors, computer architectures, etc. By way of specific embodiments, the implementation of cache line zeroing instructions will be described with reference to the memory hierarchy of Figure 39 in conjunction with the cores / CCXs of Figures 3, 8, 38 and 37. This is for illustrative purposes, and cache line zeroing instructions can be implemented in different memory hierarchies and / or in conjunction with different cores, core clusters, etc.

[0314] Figure 39 illustrates the possibility of coherence agents 3900 and 3901, as well as other coherence agents indicated by "..." and coherence agent 3902 indicated by a dashed box. The memory hierarchy in Figure 39 includes a coherence cache 3904A, an interconnect 3920, and downstream memory 3930. Different embodiments may implement different numbers of caches and cache hierarchy as part of the coherence cache 3904A. The coherence agents and the coherence cache are part of a cache coherence domain in which cache coherence is maintained using cache coherence protocols (e.g., the MESI protocol with "modified", "excluded", "shared", and "invalid" cache coherence protocol states; the MESIF protocol with the "forwarded" cache coherence protocol state; the MOESI protocol with the "owned" cache coherence protocol state; and other such cache coherence protocols).

[0315] The coherence agent 3900 is coupled to the interconnect 3920 at lower levels of the cache hierarchy through one or more caches. The cache hierarchy includes the cache at the highest level of the cache hierarchy coupled to the coherence agent 3900, the cache at the lowest level of the cache hierarchy coupled to the interconnect 3920 (e.g., L3 cache 3915) (therefore, this cache is referred to as the lowest level cache or the final level cache (LLC)), and zero or more caches at intermediate levels of the cache hierarchy coupled to one of the highest level caches and one of the lowest level caches (e.g., L2 cache 3910) (e.g., Figure 39 shows the coherence agent 3900 coupled to L1 cache 3905, which is coupled to L2 cache 3910, which is coupled to L3 cache 3915, which is coupled to the interconnect 3920).

[0316] The coherence agent 3901 is coupled to the interconnect via one or more layers of caches. Figure 39 shows the coherence agent 3901 coupled to the selective L1 cache 3906, which is coupled to the selective L2 cache 3911, which is coupled to the L3 cache 3915. In addition, Figure 3902 also shows the selective coherence agent 3902 directly coupled to the interconnect 3920 (i.e., without any coherence cache).

[0317] In addition to or replacing connections including those of a coherence agent coupled to interconnect 3920 via a successive hierarchy of caches, some embodiments implement other connections to allow direct or more direct communication (e.g., directly coupling coherence agent 3900 to interconnect 3920, directly coupling coherence agent 3900 to L2 cache 3910, directly coupling L1 cache 3905 to interconnect 3920, and / or directly coupling L2 cache 3910 to interconnect 3920, as shown by dashed lines 3935, 3936, 3937 and 3938 respectively).

[0318] Interconnect 3920 is coupled to downstream memory 3930 (e.g., via a group of one or more memory controllers (not shown)). Downstream memory 3930 is a memory hierarchy at a lower level than the coherent cache 3904 and may include one or more types of memory and / or memory hierarchy (e.g., volatile memory and / or non-volatile memory, main memory, memory-mapped input / output (MMIO), memory-side cache, two-level memory (2LM), DRAM, flash, phase-change memory, 3D Xpoint™).

[0319] Interconnect 3920 (also known as cache sync interconnect, architecture, interconnect, non-core part, interconnect network, interconnect unit) includes a snoop controller 3925 for issuing snoops to sync cache 3904 and receiving any responses therefrom. Snoop controller 3925 includes a snoop generator 3926 for issuing snoops, and in some embodiments, a snoop responder 3927 for receiving any responses. Furthermore, in some embodiments, snoop controller 3925 includes a write generator 3929 (to effectively generate writes of all-zero cache line size) and / or a write converter QOS 28 (to effectively convert cache lines of data received in response to snooping to all zeros). Additionally, while in one embodiment interconnect 3920 is shown located between L3 cache 3915 and downstream memory 3930, alternative embodiments may implement interconnect 3920 at another location (e.g., between L2 cache and L3 cache) (e.g., between L2 cache and L3 cache, having a set of or more memory controllers remote from interconnect 3920 (e.g., as local agents) or between L3 cache 3915 and downstream memory 3930). Interconnect 3920 (e.g., as part of snoop controller 3925) may include other items such as snoop filters (not shown).

[0320] Different embodiments may be implemented using a different number of coherent agents as a general-purpose core (also known as a central processing unit (CPU)). For example, in some embodiments, coherent agent 3900 is the core, coherent agent 391 is the core, there are zero or more additional coherent agents as the core, and there are zero or more additional coherent agents that are other types of agents (e.g., general-purpose processors, server processors or processing elements for server environments, coprocessors (e.g., security coprocessors), high-throughput MIC processors, GPGPUs, accelerators (such as, for example, graphics accelerators or digital signal processing (DSP) units, cryptographic accelerators, fixed-function accelerators, machine learning accelerators, network accelerators or computer vision accelerators), field-programmable gate arrays or any other processor or processing device, to name just a few).

[0321] In some embodiments, the coherence agent and coherence cache 3904 are implemented as shown in Figures 38 and 37. For example, in a CCX, there are four coherence agents for a core, each core having a dedicated / local L1 cache, each core having a dedicated / local L2 cache, and a shared L3 cache; multiple CCXs can be coupled together in a single processor. The L1 and L2 caches are write-back caches, the L2 cache is a containment cache, and the L3 cache is a victim cache. Furthermore, the L3 cache 3915 is fragmented between multiple coherence agents within a module (CCX) (e.g., 2MB per core on four cores, totaling 8MB) and optionally between one or more such modules (e.g., two CCXs each with 8MB to form a 16MB L3 cache). Figure 39 illustrates the L3 cache 3916 of the coherent agent 3900 and the L3 cache 3917 of the coherent agent 3901. Interconnect 3920 can, for example, mean: 1) an interconnect within a CCX; 2) an interconnect within and between CCXs; 3) independent interconnects within different CCXs; and interconnects between CCXs. Different embodiments may implement interconnect 3920 differently, including one or more of rings, multiple rings, point-to-point links, shared buses, etc. In embodiments implementing home agents and cache agents, interconnect 3920 is considered to include cache agents.

[0322] One or more or all of the coherence agents in Figure 39 may be implemented to execute cache line zeroing instructions (see Possible cache line zeroing instruction issuing agent 3903 is identified as any one of coherence agents 3900, 3901, and 3902). The coherence agent currently executing the cache line zeroing instruction is the "issuing agent," "issuing coherence agent," or "first agent," and its cache is referred to as the issuing agent's Lx cache (where x can be 1, 2, or 3; and where the L3 cache is implemented on a chip, it is the issuing agent's L3 cache chip). In the discussion below, this will be coherence agent 3900. The co-location agent that is not currently executing the cache line zeroing instruction is called a "co-location but not issuing agent", "non-issuing agent", "non-issuing co-location agent", or "second agent" (as discussed above, there may be multiple second agents, but for simplicity, they will be discussed below), and its cache is called the second agent's Lx cache (where x can be 1, 2, or 3; and where the L3 cache is implemented on a chip, it is the second agent's L3 cache chip). In the discussion below, this will be co-location agent 391. Exemplary cache architecture

[0323] Figure 40 is a block diagram illustrating a cache in a processor implementing a cache line zeroing instruction according to an embodiment of the present invention. Figure 40 includes an Lx cache 4050, where x indicates a level in the cache hierarchy (e.g., 1, 2, 3). The Lx cache 4050 includes a cache controller 4051 for controlling the operation of the cache, including detecting hits / misses, causing writes / reads to cache lines, receiving snoops (and therefore, in some embodiments, the cache controller 4051 includes a snooping interface, and in some embodiments, a snooping controller 4043), etc. The cache controller includes a tag array 4055 having entries 4060 (which include what is sometimes referred to as "tag status"), and the Lx cache 4050 includes a data array 4056 having corresponding cache lines 4070. Each entry 4060 includes a tag field 4061 for storing a tag used to determine whether data in one of the corresponding cache lines 4070 is hit or missing for a given address. Additionally, each entry 4060 includes a set of one or more attribute fields 4062 (sometimes referred to as "tag status") for storing attributes of the data stored in the corresponding cache line 4070. Attribute fields 4062 include a cache coherence protocol status field 4065 for storing a value indicating the current cache coherence protocol status of the data stored in the corresponding cache line 4070. Attribute fields 4062 may optionally include other fields, such as a zero line field 4066, a poison field 4067, and an error correction code field (not shown). While Figure 40 shows attribute fields 4062 in a tag array, alternative embodiments may implement these fields in a separate state array (not shown). In one embodiment, a given cache line may have multiple toxicity indicators in the toxicity field 4067 (e.g., two 32-byte blocks for a 64-byte cache line). Although Figure 40 shows a single toxicity field 4067, alternative embodiments may encode the toxicity indicators into another field (e.g., an error correction code (ECC) field or a cache coherence protocol status field).

[0324] In response to a hit in the cache (e.g., based on a tag in tag field 4061), cache controller 4051 includes circuitry (e.g., cache synchronization state circuitry or other circuitry) responding to a cache synchronization state in cache synchronization state field 4056 (e.g., cache synchronization state field 4056 corresponding to a tag field 4061 whose tag is matched); this response varies between embodiments and based on various factors (e.g., whether a cache lookup is initiated in response to a write command, a read command, a snooping (and possible snooping types)). For example, in some embodiments, the response is determining whether the cache synchronization state is one of granting cache authorization to modify the cache line (e.g., a "modify" or "exclude" state) in response to a write command and / or certain types of snooping discussed in detail below. In some embodiments, the cache controller 4051 includes: 1) a hit-miss circuit (not shown) to determine whether a hit or miss exists in the cache in response to a command (e.g., a write command, a read command, a snoop command); 2) a snoop controller 4043 (not shown) coupled to a snoop interface for receiving snoops and transmitting response messages to the snoop; and 3) a cache line read circuit (not shown) and a cache line write circuit (not shown). The cache line is configured to indicate all zeros.

[0325] While some embodiments are implemented to configure the cache line to indicate all zeros by writing zeros into the cache line (first technique), alternative embodiments may configure the cache line to use other techniques to indicate all zeros (the second to fourth techniques described below are examples). Such other techniques may be implemented for various reasons, such as the cache line size being generally larger than the width of some buses / structures within the core (e.g., one or more intermediate buffers, such as load queue 810, storage queue 820, write combination buffer (WCB) 860) and / or using zeros to write zeros into the cache line would consume power and increase cache complexity.

[0326] The second technique is to invalidate the cache line by using the cache method where the cache line is currently residing, and to write the zero cache line into the cache in different ways.

[0327] The third and fourth techniques involve changing the tag state rather than the data in the data array 4056, and these can be used in one or more cache layers and / or in the interconnect. The third technique is to implement a field (referred to as a zero-line field 4066) for each cache line (e.g., in attribute field 4062), and the value in this field (which can be a single bit) indicates whether: 1) the cache line should be considered to have a value containing data stored in that cache line; or 2) the cache line should be considered all zeros (regardless of the actual data stored in that cache line). In this embodiment, reading (including eviction) of a cache line either passes the value of the zero-line field 4066 to another structure supporting such a zero-line field or converts the data to zero. The data is also converted before being used by one of the coherence agents on the read (e.g., coherence agent 3900). Although in some of these embodiments the data is converted before being written to downstream memory QO30, alternative embodiments also implement a zero-line field in downstream memory 3930 or an alternative memory structure managed by a memory controller.

[0328] The fourth technique is similar to the third technique, but instead of implementing a separate field, it implements new encoding in the existing attribute field (e.g., new encoding in the cache coherence agreement state field or correction code (ECC) symptom field).

[0329] Some embodiments may implement caching as part of configuring a cache line to indicate all zeros, modifying the cache line's cache coherency protocol status to "modified" or "owned" (or using a cache coherency status field to indicate a zero line, then to a zero line state), and causing any toxicity indications to be ignored (data is no longer poisoned) or cleared. Therefore, another advantage of the cache line zeroing instruction is that it can be used to consistently clear poisoned lines.

[0330] In the related description, the mechanism for forcing cache lines to zero may be implemented only in certain cache layers (e.g., a subset of L1, L2, and L3 caches, such as only in L1 cache and not in L2 or L3 cache), and a given cache layer lacking such a mechanism may be implemented to configure cache lines to indicate all zeros by sending cache lines to different cache layers that have such a mechanism (e.g., a higher cache layer (e.g., L1 cache) is implemented to configure cache lines to indicate all zeros by evicting data to a lower cache layer (e.g., L2 cache) that can perform zeroing; a lower cache layer (e.g., L2 cache) is implemented to configure cache lines to indicate all zeros by forwarding cache lines to a higher-level cache layer (e.g., L1 cache) that can perform zeroing). As described in more detail below, different embodiments may implement cache line zeroing in response to writes and / or snooping. In embodiments that implement cache line zeroing in response to both writes and snoops, a given cache level can be implemented to zero only in response to a write or a snoop (but not both), and data can be pushed / evicted or forwarded to a lower or higher cache level that can zero in response to the other of writes and snoops. Techniques for triggering cache to configure cache lines to indicate all zeros.

[0331] Regardless of the technique implemented in the cache to configure the cache line to indicate all zeros (see above), triggering the cache to configure the cache line to indicate all zeros can be in response to a message sent from the interconnect to one of the caches, sent by the issuing agent itself, or by the issuing agent in response to a message sent from the interconnect.

[0332] When an issuing agent (alone or in response to a message from an interconnect) triggers a cache to configure a cache line to indicate all zeros, different embodiments may use different techniques, including techniques that implement the cache line zeroing instruction atomically when the cache line is wider than the inherently supported data width (e.g., 32 bits, 64 bits, 128 bits, 256 bits, 512 bits, 1024 bits) of the issuing agent (e.g., 32 bytes, 64 bytes). The inherently supported data width may be represented in different ways in different embodiments. In some embodiments, the inherently supported data width may represent the bit width of the widest register set and / or the width of the operand to be operated by the instruction. In some embodiments, the inherently supported data width may represent the width of an arithmetic and / or logic execution unit (e.g., multiple portions of an operand do not pass through it sequentially when it has the same width as the operand indicated by the instruction (dual pumps or more)). In some embodiments, the inherently supported data width may represent the width of a bus (e.g., a load pipeline). The amount of data that can be stored atomically can be limited by the width of one or more internal structures (e.g., buses, intermediate buffers) of the issuing agent.

[0333] Therefore, in some embodiments where the issuing agent (independently or in response to a message from the interconnect) triggers (caching configuration cache lines to indicate all zeros), the issuing agent: 1) implements a zero-line field in other structures such as one or more intermediate buffers (e.g., storage queue 820 and write combination buffer (WCB) 860); or 2) implements a new command (e.g., micro-op, control signal, microinstruction) that does not carry a zero cache line but indicates a write of the zero cache line size, which can be done through an intermediate buffer (e.g., storage queue 820 and write combination buffer (WCB) 860). In this way, when the cache line size is wider than the data width inherently supported by the issuing agent (e.g., 32 bytes, 64 bytes), the zero cache line can be represented in these narrower structures. When a zero line (such as a zero line field or a new command / micro-op indicated) is sent to a lower memory level that does not support a zero line field or a new command, a zero line conversion is performed (e.g., a zero line conversion can be performed when a zero line is sent to data cache 840 (which can perform another of the techniques described above), sent from write combination buffer 8600, sent from L3 cache to the interconnect, or sent from the interconnect (e.g., via memory controller) to downstream memory).

[0334] As another example, in some embodiments where an issuing agent (alone or in response to a message from the interconnect) triggers (caching the cache line to indicate all zeros), the issuing agent sequentially writes smaller blocks (e.g., 16 bytes at a time, 32 bytes at a time) to an intermediate buffer (e.g., a storage queue 820, a write combination buffer (WCB) 860, and a separate stage buffer (not shown)), which does not respond to snooping (or does not respond to snooping while a block is being written), and is evicted in response to having written enough blocks to be equal to the size of the cache line (not earlier), such that blocks are written simultaneously; thereby atomically implementing the cache line zeroing instruction. Other states

[0335] Different embodiments may implement cache line zeroing instructions with different orders (e.g., weak sorting, strong sorting, sorting weaker than weak sorting, sorting stronger than strong sorting). In the case of a weakly sorted cache line zeroing instruction, the embodiment may implement the instruction to automatically evict it.

[0336] The cache line zeroing instruction can be implemented such that it does not configure the cache line to indicate all zeros before the instruction is withdrawn. In such an embodiment, there is a mechanism to ensure that the cache line zeroing instruction has been completed and the cache line is configured to indicate all zeros for all readers (e.g., fence instruction, lock instruction, schema serialization instruction, younger stores for GO (strongly ordered), younger loads for GO (more strict than strong ordered) or more).

[0337] The cache line zeroing instruction can be treated as storage, similar to a page table walkthrough (including virtual tables such as the Extended Page Table (EPT) where bits A and D will be updated), and will fail if it is not writable. Before using snooping, first attempt to write to the issuing agent's cache implementation.

[0338] Figure 41 is a flowchart illustrating an embodiment of the present invention in which an attempt is made to write to the cache of the issuing agent before using snooping. As discussed above, the first agent 3900 is used to decode and execute instructions that result in a write of zero cache line size at a memory address (block 4110). In response to the decoding and execution of the instructions, the first agent is used to issue a write command to one of the coherent caches coupled to the first agent (e.g., L1 cache 3905) to initiate a write of zero cache line size at the memory address (in this case, the first agent is also referred to as the issuing agent) (block 4112). In some embodiments, the first agent includes a decoding unit (e.g., decoder 140, decoder 314) for decoding instructions that will result in a write of zero cache line size at the memory address. The first agent also includes an execution unit (e.g., memory access unit 164, load storage unit 340) that responds to a command issued by the decoding unit to initiate a write of zero cache line size at a memory address.

[0339] When the cache line of the cache that issued the command (e.g., L1 cache 3905) hits (block 4114), and the cache line's cache sync status is to grant the cache permission to modify the cache line without broadcasting to other caches (e.g., "Modify" or "Exclude") (block 4116), the cache will configure the cache line to indicate all zeros and suppress snooping (block 4118). Different embodiments may implement caches to configure cache lines to indicate all zeros, as described in the preceding section entitled "Techniques for Configuring Cache Lines to Indicate All Zeros". In some embodiments, if there is a cache line hit (block 4114) to which the command was issued, the cache line remains zero for one or more other cache sync statuses (e.g., one or more of "Own", "Forward", or "Share"). For any state where this is completed, control is passed to block 4119; for any state where control is not completed, control is passed to block 4120. Therefore, in embodiments where control is passed to block 4119 for any state that is not "modified," "excluded," or "invalid," block 4120 is not executed; and vice versa. However, embodiments can be implemented where control is passed to either block 4119 or 4120 depending on the state. In block 4119, the cache is used to configure the cache line to indicate all zeros; from block 4119, control is passed to block 4122 (described in more detail below), where the cache will send a snoop to the interconnect (depending on the embodiment, to the next cache level or to the interconnect) to issue a snoop (e.g., write update snoop (also known as write zero snoop or write and zero snoop), write invalid snoop (also known as invalid even if modified snoop), or snoop indicating invalid and write back (also known as write back and invalid snoop)). The write command passed to the next cache level or interconnect may indicate a non-"modified" or "" The "Excluded" state line is configured to indicate all zeros. One use case for this modified write command is that if a "Shared" line is configured to all zeros and its state is changed to "Modified" or "Owned," a write update sniffer will not be issued. In this case, the interconnect can issue different sniffer types (e.g., write invalid sniffer or write back and invalid sniffer). In block 4120, the cache changes the cache synchronization protocol state of the cache line to "Invalid," and control is passed to block 4122. If a cache loss exists (block 4114), control is passed to block 4122.

[0340] Using a specific example of forwarding or ownership states, when the issuing agent's cache has cache lines in a forwarding or ownership state, the cache lines can be in other caches in a shared state. Thus, if a cache line is zeroed in block 4119, a snoop can be sent to invalidate those other cache lines in a shared state, or configured to indicate that all other cache lines in a shared state are zeroed. Alternatively, a cache line in a forwarding or ownership state can be invalidated (or evicted and invalidated) (block 4120), and a new line can be created that is modified and zeroed or owned and zeroed. A new line that has been zeroed out can be inserted (filled) into the same cache as a cache line found in a forwarding or owning state (e.g., in a different set or manner of that cache), or it can be inserted into a different cache (e.g., if a cache line is found in a forwarding or owning state in an L2 or L3 cache, the cache line can be invalidated, and a new line that has been modified and zeroed out or owned and zeroed out in an L1 cache).

[0341] In block 4122, the cache will issue a write command to the interconnect. This write command can be issued directly to the interconnect 3920, or it can be sent to one or more lower layers of the cache of the first agent. For example: 1) In some embodiments, the write command is issued directly to the interconnect (i.e., skipping any caches at lower levels of the cache hierarchy - for example, directly from L1 cache 3905 to interconnect 3920, skipping any lower-level caches (e.g., L2 cache OQA10, L3 cache OQA15) - in this case, the write command is used for the data L1 cache of the first agent, while snooping (described below) is used for the instruction L1 cache, L2 cache, and L3 cache of the first agent (more specifically, if L3 cache chip 3916 is implemented) and for the cache of the second agent); 2) In some embodiments, the write command is issued to L2 cache 3910, which repeats the above, and if it does not configure a cache line to indicate all zeros, the write command is issued directly to interconnect 3920. In this case, the write command is used for the L1 and L2 caches of the first agent, while the snoop (described in the next paragraph) is used for the L3 cache of the first agent (more specifically, if L3 cache chip 3916 is implemented) and the cache of the second agent; 3) In some embodiments, the write command is issued to the L2 cache 3910 as described above, and if it does not have a cache line configured to indicate all zeros, the write command is issued to the L3 cache 3915 (more specifically, if L3 cache chip 3916 is implemented), and if it does not have a cache line configured to indicate all zeros, the write command is issued to the interconnect 3920 - in this case, the write command is used for the cache of the first agent, while the snoop (described in the next paragraph) is used for the cache of the second agent. In some embodiments, the cache that issues the write command includes a cache controller implemented to determine, in response to the write command discussed above, whether a cache hit exists, configure the cache line to indicate all zeros (different embodiments may implement a cache to configure the cache line to indicate all zeros, as described earlier in the section titled "Techniques for Configuring a Cache Line to Indicate All Zeros"), and to issue a write command to the interconnect if the cache is lost. In one specific example, in response to a cache line hit, in an L2 cache 3910 that is modified, excluded, and / or owned (issuing agent), the L2 cache is implemented to configure the cache line to indicate all zeros by forwarding the task to the L1 cache.

[0342] In response to a write command, a snoop controller 3925 of the interconnect 3920 is implemented to initiate a snooping process (block 4190) to locate any caches that may store a cache line. To implement the snooping process 4190, the snoop controller 3925 is implemented (e.g., via snoop generator 3926) to snoop on those coherent caches that may store a cache line (block 4126) (in other words, if a hit exists, their coherent caches must be determined). In some embodiments, coherent caches that may store a cache line are those coherent caches that: 1) have not previously been issued a write command; and 2) in embodiments where a snoop filter (not shown) is implemented in the interconnect 3920, the snoop filter indicates that the cache may contain the line (i.e., the snoop filter does not suppress snooping). This may include coupling the second agent 3901 to one or more caches of the interconnect 3920 (e.g., L1 cache 3906, L2 cache 3911, L3 cache 3915); and coupling the first agent 3900 (the issuing agent) to any cache of the interconnect 3920 (e.g., L2 cache 3910, L3 cache 3915) that has not received a write command (i.e., a skipped cache), and in embodiments where a snooping filter (not shown) is implemented in the interconnect 3920, the snooping filter indicates that a line may be present (i.e., the snooping filter does not suppress snooping). In embodiments where snooping is issued to one or more caches that couple the first agent to the interconnect, each such snoop may also be referred to as a back snoop. As part of the snooping process 4190, different embodiments may be implemented to issue different types of snooping depending on the circumstances, or to issue only one type of snooping. Several possible snooping types are available (e.g., write-update snooping (also known as write-zero snooping or write-and-zero snooping), write-invalid snooping (also known as invalid even if modified snooping), snooping indicating invalidity and write-back (also known as write-back and invalid snooping), snooping that writes any hit but does not send data back to the first agent and does not cause data to be read from downstream memory, prior art snooping (e.g., RFO)), as discussed in more detail later herein. Specifically, in the case of using write-update snooping, snooping controller 3925 is also implemented to determine whether a write of cache line size is performed in response to one of the write-up snoopings (shown as dashed block 4128) as part of snooping process 4190; if so, the process completes (block 4130); otherwise, control is passed to block 4132. When other types of snooping are used in snooping process 4190, block 4128 is dashed because it is not used.

[0343] Write commands and snooping operations are used to handle cases where there are cache lines containing data to be zeroed in one or more caches. In response to a write command (as described above), a write of zero cache line size may have been performed by one of the caches, or in embodiments where a write update snoop is issued, as described in more detail below, in response to one of the caches of a write update snoop. If a write of zero cache line size is not performed by any cache, then in block 4132, the interconnect 3920 (e.g., via write generator 3929 of the snoop controller 3925) or the first agent (issuing agent) responds to a message from the interconnect 3920, causing cache lines in one or more coherent caches (e.g., L1 cache 3905, L2 cache 3910, L3 cache 3915) to be configured to indicate all zeros (as described in the preceding section entitled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or causing a write of zero cache line size to the downstream memory at the memory address. As noted above and below in more detail, in some embodiments, the snoop controller 3925 includes a snoop responder 3927 responsible for this action (and optionally a write converter 3928 and a write generator 3929). In some embodiments, a first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) performs its scrolling (if any) in this action. In an alternative embodiment, interconnect 3920 instructs the memory controller to write zeros to downstream memory.

[0344] As described above in the section titled "Triggering the cache to configure the cache line to indicate all zeros," different embodiments may implement the issuance of a proxy to cause the cache to be triggered to indicate all zeros (ensuring atomicity that the cache line is wider than the data width inherently supported by the issuing proxy (e.g., 32 bytes, 64 bytes), implementing a zero line field in other structures (e.g., intermediate buffers), implementing a write that can be made by a new command through the intermediate buffer (which does not carry the cache line of zeros but indicates the size of the cache line of zeros), or implementing the sequential writing (e.g., one 16-byte at a time, one 32-byte at a time) of smaller blocks of zeros in an intermediate buffer (e.g., storage queue 8200, write combination buffer (WCB) 8600, separate stage buffer (not shown)) that does not respond to snooping (or does not respond to snooping while a block is being written) and is evicted in response to enough blocks being written to the size of the cache line (not earlier) so that blocks are written simultaneously). Embodiments relying on snooping of the synchro cache.

[0345] Figure 42 is a flowchart illustrating an embodiment of the present invention that relies on snooping of the coherence cache (which does not first attempt to write to the issuing agent's cache). As discussed above, the first agent 3900 is configured to decode and execute instructions that result in a write of zero cache line size at a memory address (block 4210). In response to the decoding and execution of the instructions, the first agent is configured to issue a command to the interconnect 3920 to initiate a write of zero cache line size at the memory address (in this case, the first agent is also referred to as the issuing agent) (block 4212). In some embodiments, the first agent includes a decoding unit (e.g., decoder 140, decoder 314) for decoding instructions that will result in a write of zero cache line size at the memory address. The first agent also includes an execution unit (e.g., memory access unit 164, load storage unit 340) that responds to the decoding unit issuing a command to initiate a write of zero cache line size at the memory address.

[0346] A command from the first agent / issuing agent 3900 is issued to the interconnect 3920 (block 4212), and in response to the command, the interconnect 3920 is implemented to initiate a snooping process (block 4290) to locate any caches that may store cache lines. In order to implement the snooping process 4290, the interconnect 3920 (e.g., via snooping controller 3925) is implemented (e.g., via snooping generator 3926) to snoop on those homogeneous caches that may store cache lines (block 4226) (in other words, if a hit exists, their homogeneity caches must be determined). In some embodiments, the coherent cache that may store the cache line is those coherent caches that: 1) any coherent cache (e.g., L1 cache 3905, L2 cache 3910, L1 cache 3906, L2 cache 3911, L3 cache 3915) in embodiments where no snoop filter (not shown) is implemented in interconnect 3920; or 2) in embodiments where such a snoop filter (not shown) indicates that the coherent cache of the cache may contain the line (i.e., the snoop filter does not suppress snooping). In embodiments where snooping is issued to one or more caches that couple the first agent to the interconnect, each such snoop may also be referred to as a back snoop. As before, as part of the snooping process 4290, different embodiments issue different types of snooping depending on the situation, or issue only one type of snooping. Several possible snooping types are available (e.g., write-update snooping (also known as write-zero snooping or write-and-zero snooping), write-invalid snooping (also known as invalid even if modified snooping), snooping indicating invalid and write-back (also known as write-back and invalid snooping), snooping that writes any hit but does not send data back to the first agent and does not cause data to be read from downstream memory, prior art snooping (e.g., RFO), as discussed in more detail later herein). Specifically, in the case of using write-update snooping, snooping controller 3925 is also implemented to determine whether a write of the cache line size is performed in response to one of the caches (shown as dashed block 4228) of a write-up snooping as part of snooping process 4290; if so, the process completes (block 4230); otherwise, control is passed to block 4232. When other types of snooping are used in snooping process 4290, block 4228 is dashed because it is not used.

[0347] In an alternative embodiment, block 4212 is replaced by a first agent that is implemented to issue snooping commands to those that may store the homogeneous cache of the cache line (in this case, block 4226 does not exist, and the flow is passed to block 4228 in the embodiment using write update snooping, otherwise to block 4232).

[0348] A snooping operation is performed to handle cases where there are cache lines containing data to be zeroed in one or more caches. In embodiments where a write update snoop is issued, a write of zero cache line size may have been performed by one or more caches. If a write of zero cache line size has not been performed by any cache, then in block 4232, the first agent itself, interconnect 3920 (e.g., via write generator 3929), or the first agent responding to a message from interconnect 3920 causes a cache line in one or more caches (e.g., L1 cache 3905, L2 cache 3910, L3 cache 3915) to be configured to indicate all zeros (as described in the preceding section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or causes a write of zero cache line size to downstream memory at the address. As noted above and below in more detail, in some embodiments, the snoop controller 3925 includes a snoop responder 3927 (and optionally a write converter 3928 and a write generator 3929) that performs its role (if any) in the action. In some embodiments, a first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) performs its role (if any) in the action. In an alternative embodiment, the interconnect 3920 instructs the memory controller to write zeros to downstream memory.

[0349] As described above in the section titled "Triggering a cache to configure a cache line to indicate all zeros," different embodiments may implement different methods of issuing a proxy to cause a cache to be triggered to indicate all zeros (to ensure the atomicity of the cache line being wider than the data width inherently supported by the issuing proxy (e.g., 32 bytes, 64 bytes), implementing a zero-line field in other structures (e.g., intermediate buffers), implementing a write that can be made by a new command through an intermediate buffer (which does not carry a cache line of zeros but indicates a cache line size of zeros), or implementing sequential writes (e.g., one 16-byte at a time, one 32-byte at a time) of smaller blocks in an intermediate buffer (e.g., storage queue 8200, write combination buffer (WCB) 8600, separate stage buffer (not shown)) that are evicted when a block is not responded to (or is not responded to while a block is being written) and when a sufficient number of blocks are written to the size of the cache line (not earlier) so that blocks are written simultaneously). Different types of snooping

[0350] As previously stated, as part of snooping process 4190 or snooping process 4290, different embodiments may issue different types of snoops depending on the circumstances, or issue only one type of snoop. Several possible snoop types are available (e.g., write-up snoop (also known as write-zero snoop or write-and-zero snoop), write-invalid snoop, snoop indicating invalidity and write-back (also known as invalid even if modified snoop), snoop that writes any hit but does not send data back to the first agent and does not cause data to be read from downstream memory cache lines, prior art snoops (e.g., RFO)). As previously indicated, snoops of any of these different types can be used in conjunction with any of the above embodiments discussed with respect to Figures 41 and 42. Further details regarding the different types of snoops will now be described.

[0351] Write Update Snooping: Figure 43 is a flowchart illustrating an embodiment of the invention using write update snooping (also known as write zero snooping or write and zero snooping) to implement snooping processes 4190 or 4290. In the context of Figures 41 and 42, the process is passed from block 4124 or block 4212 to block 4326, which executes block 4126 or 4226 using write update snooping. Interconnect 3920 (e.g., snoop generator 3926 via snoop controller 3925) is implemented to issue write update snoops (block 4326) to those that may store homology caches of cache lines (in other words, if a hit exists, their homology caches must be determined). When a cache line hit occurs (block 4340) of a cache line that issues a write update snoop (e.g., the L1, L2, and / or L3 cache slices of the first agent and the L1, L2, and L3 cache slices of the second agent), the cache is used to: 1) if the cache synchronization protocol state of the hit cache line is "Modified" (and in some embodiments, one or more of "Forwarded", "Excluded", "Owned", and / or "Shared") (block 4342), configure the cache line to indicate all zeros (block 4344) (different embodiments may implement a cache to configure the cache line to indicate all zeros as described in the preceding section entitled "Techniques for Configuring a Cache Line to Indicate All Zeros") and send a response message indicating a zeroing to interconnect 3920. In some embodiments that support zeroing a hit cache line in a shared state, the response message also distinguishes the cache line's state—such as modified and zero or owned and zero against shared and zero (the latter indicating the original state was "shared," and the cache line was configured to indicate all zeros and its state was still "shared"); in an alternative embodiment that supports zeroing a cache line in a shared state, when the original state was "shared" and the cache line was configured to indicate all zeros and its state was still "shared," a response message indicating non-zeroing is sent (as in block 4350) (4346); and 2) otherwise, the cache line's cache synchro protocol state is configured as "invalid" (block 4328), and a response message indicating non-zeroing is sent to the interconnect (block 4350). When there is no hit of a cache line that issues a write update snoop (block 4340), the cache line sends a response message indicating non-zeroing to the interconnect (block 4350). Therefore, in some embodiments, a synchro cache can be implemented such that a write command or write and zero snoop that hits a cache line in any modified, owned, excluded, or forwarded state will cause the cache line to be zeroed (and its state to be changed to modified (modified and zeroed) or owned (owned and zeroed)).In alternative embodiments, such a cache may do this only for a subset of the modified, owned, excluded, and forwarded states; in this case, it results in any hit in the modified, owned, excluded, or forwarded states that has not been changed to modified cache lines and zeroed or owned and zeroed in response to a write and zero snooping, being changed to an invalid state. Thus, in some embodiments, all or a subset of the homogeneous cache is implemented such that (for all modified, excluded, owned, or forwarded states or subsets thereof) a write command or write and update (aka, write and zero) snooping in response to a hit in the cache results in the cache line being zeroed (and its state changing to modified (modified and zeroed)) or owned (owned and zeroed). Embodiments supporting zeroing of hit cache lines in a shared state and keeping them in a shared state do so only if any modified, excluded, owned, or forwarded line hit in another cache changes to owned and zeroed or invalid, rather than changing to modified and zeroed. In some embodiments, a cache implemented in response to a write update snoop includes a cache controller 4051 (e.g., via snoop controller 4053) that, in response to a write update snoop, determines whether a cache hit exists, configures a hit cache line to indicate all zeros (as described earlier in the section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement a cache to configure cache lines to indicate all zeros) and sends a response message to interconnect 3920.

[0352] After a write update snoop is issued, interconnect 3920 (e.g., snoop responder 3927 via snoop controller 3925) is implemented to track the reception of the corresponding response message (block 4352) (e.g., in one embodiment, snoop generator 3926 indicates information to snoop responder 3927 to track the reception of the corresponding response message). Depending on whether the embodiment of FIG. 41 or 42 is implemented, control is passed from block 4352 to block 4128 or block 4228. A write of zero cache line size may be performed by one of the caches in response to a write update snoop (however, in an embodiment where cache lines in a "shared" state are zeroed and no response message reflects that one of the cache lines is owned and zero or modified and zero, then a write of zero cache line size in response to one of the write update snoops is not considered to have been performed by one of the caches). If a write of zero cache line size is not executed by any cache (blocks 4128 and 4228) (all response messages indicate no zeroing; or in embodiments where zeroing of cache lines in a "shared" state is implemented, and no response message reflects that one of the cache lines is owned and zeroed or modified and zeroed), then block 4132 or 4232 is executed—that is, interconnect 3920 (e.g., via write generator 3929 of the spy controller QO25) or the first agent (e.g., through...). An execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure responds to a message from interconnect 3920, causing a cache line in one of the caches (e.g., L1 cache, L2 cache, L3 cache) to be configured to indicate all zeros (as described in the previous section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or causing a write of zeros to the cache line size of the downstream memory at the address.

[0353] As described above, using write-update snooping is advantageous compared to using RFO operations because it does not require reading the line and returning it to the publishing agent, and does require ownership of the data to be given to the publishing agent (write-update snooping causes the cache line to zero in the cache of another coherent agent when conditions 4340 and 4342 are met). Therefore, the advantage of embodiments using write-update snooping is that they can directly update the local cache of another agent (e.g., a second agent / non-issuing agent). For example, this allows for relatively fast communication—such as updating variables that another agent is spinning.

[0354] As previously indicated, write update snooping can be used in conjunction with the embodiments of Figures 41 and 42. For example, a specific embodiment of implementing write update snooping in one of the embodiments of Figure 41 will be described. In this specific embodiment, the issuing agent 3900 first attempts to write to the L1 cache 3905 of the issuing agent 3900; and if snooping is required, the interconnect 3920 issues write update snoops to those of the homogeneous caches of the storable cache line as described above. Therefore, an L1 cache is implemented in response to the write command as described above; L1, L2, and L3 caches (more specifically, if an L3 cache chip is implemented) are implemented in response to the write update snoop as described above; interconnect 3920 is implemented to issue a write update snoop in response to the write command as described above (e.g., via snoop generator 3926 of snoop controller 3925) and in response to a response message (e.g., via snoop responder 3927 of snoop controller 3925); and interconnect 3920 (e.g., via write generator 3929 of snoop controller QO25) or a first agent (e.g., by executing...) A unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure is implemented in response to a message from the interconnect to cause a cache line in one of the caches (e.g., L1 cache 3905, L2 cache 3910, or L3 cache 3915 of the first agent (more specifically, if L3 cache chip 3916 is implemented)) to be configured to indicate all zeros (as described in the previous section entitled "Techniques for configuring cache lines to indicate all zeros, different embodiments may implement caches to configure cache lines to indicate all zeros), or to cause a write of zeros to the cache line size of the downstream memory at a memory address.

[0355] Write Invalid Snoop: Figure 44 is a flowchart illustrating an embodiment of the invention using write invalid snoops (also known as "invalid even if modified snoops") to implement snooping processes 4190 or 4290. In the context of Figures 41 and 42, the process is passed from block 4124 or block 4212 to block 4426, which executes block 4126 or 4226 using write invalid snoops. Interconnect 3920 (e.g., snoop generator 3926 via snoop controller 3925) is implemented to issue write invalid snoops (block 4426) to those that may store homology caches of cache lines (in other words, if a hit exists, their homology caches must be determined). When a cache line that issued the write invalid snoop (e.g., L1, L2, and / or L3 cache slices of the first agent and L1, L2, and / or L3 cache slices of the second agent) is hit (block 4440), then the cache will set the cache synchronization protocol state to "invalid" (even if it is currently "modified") (block 4448); the cache does not need to be configured to indicate all zeros (as described in the previous section "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement a cache to configure cache lines to indicate all zeros) or if the invalidation completes within a fixed time, a response message is sent to the interconnect (if the invalidation does not complete within a fixed time, one embodiment has the snooping cache sending a response message indicating that the snooping has completed). When no cache line that issued the write invalid snoop (4440) is hit, then in one embodiment the cache does nothing (block 4430).

[0356] Furthermore, in the context of Figures 41 and 42, the flow is passed from block 4124 or block 4212 to block 4132 or 4232 respectively (blocks 4128 and 4228 are not implemented when write invalid snooping is used). In block 4132 or 4232, the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) in itself, interconnect 3920 (e.g., via write generator 3929 of snoop controller QO25) or the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) responds to a message from the interconnect, causing a cache line in one of the caches (e.g., L1 cache 3905, L2 cache 3910, L3 cache 3915 of the first agent (more specifically, if L3 cache chip 3916 is implemented)) to be configured to indicate all zeros (as described in the previous section entitled "Techniques for configuring cache lines to indicate all zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or causing a write of zeros to the cache line size of the downstream memory at the address.

[0357] As mentioned above, it is advantageous to use write invalid snooping instead of using RFO operation because it does not require the cache line to be read and returned to the issuing agent, since the issuing agent zeros the data.

[0358] As previously indicated, write invalid snooping can be used in conjunction with the embodiments of Figures 41 and 42. For example, a specific embodiment of implementing write invalid snooping in one of the embodiments of Figure 41 will be described. In this specific embodiment, the issuing agent 3900 first attempts to write to the L1 cache 3905 of the issuing agent 3900; and if snooping is required, the interconnect 3920 issues write invalid snoops to those of the homogeneous caches of the storable cache line as described above. Therefore, the L1 cache is implemented in response to the write command as described above; the L1 cache, L2 cache, and L3 cache (more specifically, if an L3 cache chip is implemented) are implemented in response to the write invalid snoop as described above; the interconnect 3920 is implemented to issue a write invalid snoop in response to a write command; and the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) itself, the interconnect 3920 (e.g., via the write generator 3929 of the snoop controller QO25) or the first agent (e.g., via the execution unit (e.g., via the write generator 3929 of the snoop controller QO25) or the first agent (e.g., via the execution unit (e.g., via the write generator 3929 of the snoop controller QO25) in itself, the interconnect 3920 (e.g., via the write generator 3929 of the snoop controller QO25) or the first agent (e.g., via the write generator 3929 of the execution unit (e.g., via the write generator 3929 of the write controller QO25) in itself, ...) in itself, the first agent ( The memory access unit 164, the load storage unit 340, or other hardware structures respond to a message from the interconnect by implementing actions that cause a cache line in one of the caches (e.g., the L1 cache 3905, L2 cache 3910, L3 cache 3915 of the first agent (more specifically, if the L3 cache chip 3916 is implemented)) to be configured to indicate all zeros (as described in the previous section entitled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or cause a write of zeros to the cache line size of the downstream memory at a memory address.

[0359] Snooping Invalidation and Write-back: Figure 45 is a flowchart illustrating an embodiment of the present invention using snooping invalidation and write-back (also referred to as "write-back and invalid snooping") to implement snooping flow 4190 or 4290. In the context of Figures 41 and 42, the flow is passed from block 4124 or block 4212 to block 4526, which executes block 4126 or 4226 using write-back and invalid snooping (invalid and write-back snooping). Interconnect 3920 (e.g., snooping generator 3926 via snooping controller 3925) is implemented to issue write-back and invalid snooping (block 4526) to those that may store the coherence cache of the cache line (in other words, if a hit exists, their coherence cache must be determined). When a cache line that is snipping this request is hit (e.g., the L1, L2, and / or L3 cache slices of the first agent and the L1, L2, and L3 cache slices of the second agent) (block 4540), the cache is used to: 1) write the cache line back to interconnect 3920 (block 4544) if the cache synchronization protocol status of the cache line is "Modified" (block 4542) (and in some embodiments, "Wipeout"); and regardless of 2) set the cache synchronization protocol status of the cache line to "Invalid" (block 4548) (the cache does not need to be configured to indicate all zeros). When no cache line that is snipping the request is hit (block 4540), in one embodiment the cache does nothing (control is passed to block 4552). In some embodiments, the cache implemented in response to such snooping includes a cache controller 4051 that, in response to such snooping, determines whether there is a cache hit, write-back modified cache line (e.g., hit and those with cache synchronization protocol state) to interconnect 3920 and modifies the cache synchronization protocol state of the cache line to "invalid".

[0360] After a snooping attempt is initiated, interconnect 3920 (e.g., via snooping responder 3927 of snooping controller 3925) is implemented to track the reception of any corresponding response message (block 4552) (e.g., in one embodiment, snooping generator 3926 instructs snooping responder 3927 to track the reception of any corresponding response message). If the response message is received along with data (block 4560) (i.e., data from the modified cache line), interconnect 3920 may optionally be implemented (e.g., via write converter 3928 of snooping controller 3925) to effectively zero out the data (block 4562). Otherwise, interconnect 3920 may optionally be implemented (e.g., via write generator 3929 of snooping controller 3925) to effectively establish a zero line (block 4564). Depending on whether the embodiment of Figure 41 or 42 is implemented, control is passed from blocks 4562 and 4564 to blocks 4132 or 4232 (blocks 4128 and 4228 are not implemented when invalid and write-back snooping is used). In block 4132 or 4232, the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) in response to a message from interconnect 3920 causes a cache line in one of the caches (e.g., L1 cache, L2 cache, L3 cache) to be configured to indicate all zeros (as described in the preceding section entitled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caches to configure cache lines to indicate all zeros), or causes a write of zeros to the cache line size of the downstream memory at the address. In one embodiment, blocks 4560 and 4562 are not implemented, and block 4564 is executed permanently. In another embodiment, block 4562 is not executed, the write-back data is sent to the first agent, and the first agent zeroes out the data. In another embodiment, blocks 4560, 4562, and 4564 are not executed, and the first agent zeroes out the data.

[0361] As mentioned above, in contrast to using RFO operation, it is advantageous to use invalid and write-back snooping because it does not require the cache line to be read and returned to the issuing agent, since the issuing agent zeros the data.

[0362] As previously stated, the above begins in response to a command issued by the first agent to initiate a write of zero cache line size (e.g., block 4112 or 4212) at an address aligned on the cache line boundary. As previously stated, this command may take the form of a write command (e.g., block 4112 or 4212). In other embodiments, this command may be a read command (e.g., block 4212); in this case, causing a cache line in one of the caches (e.g., L1 cache, L2 cache, L3 cache) to be configured to indicate all zeros by: 1) interconnect 3920 (e.g., snoop controller 3925) being implemented to respond to a read command from the first agent and to indicate a zero line to the first agent's response (this line will have a cache coherency agreement state set to modified or excluded); and 2) the first agent being implemented to put the result of its read command into a cache (causing a cache (e.g., L1 cache 3905) to configure a cache line to indicate all zeros (as described in the previous section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement a cache to configure a cache line to indicate all zeros), but not into the first agent's schema register file.

[0363] As previously indicated, the snooping with invalidation and write-back can be used in conjunction with the embodiments of Figures 41 and 42. For example, a specific embodiment of implementing such snooping in one of the embodiments of Figure 41 will be described. In this specific embodiment, the issuing agent 3900 first attempts to write to the L1 cache 3905 of the issuing agent 3900; and if snooping is required, the interconnect 3920 issues the snooping to those of the synchro caches of the storable cache line as described above. Therefore, an L1 cache is implemented in response to a write command as described above; L1, L2, and L3 caches (more specifically, if an L3 cache chip is implemented) respond to a snooping as described above; interconnect 3920 is implemented to issue a snooping response to a write command, optionally implemented to effectively convert any received data to zero in response to a snooping (e.g., via a write converter 3928 of the snooping controller 3925), and optionally to effectively establish a zero line (e.g., a write generator 3929 of the snooping controller 3925) if no data in response to a snooping is received; and a first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure). In itself, the interconnect 3920 (e.g., via the snoop controller QO25) or the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) responds to a message from the interconnect by being implemented to cause a cache line in one of the caches (e.g., L1 cache 3905, L2 cache 3910, L3 cache 3915 (more specifically, if L3 cache chip 3916 is implemented)) to be configured to indicate all zeros (as described in the previous section entitled "Techniques for configuring cache lines to indicate all zeros, different embodiments may implement caches to configure cache lines to indicate all zeros), or cause a write of zeros to the cache line size of the downstream memory at a memory address.

[0364] Writing any cache line without sending data back to the first agent and without causing data to be read from downstream memory, or prior art snooping (RFO) that typically writes the line out: Figure 46 is a flowchart illustrating an embodiment of the present invention using snooping to implement snooping processes 4190 or 4290, which writes any hits without sending data back to the first agent and without causing data to be read from downstream memory (or prior art snooping that typically writes the line out - such as RFO operation). In the context of Figures 41 and 42, the flow is passed from block 4124 or block 4212 to block 4526, respectively, and block 4526 uses this snooping to execute block 4126 or 4226. Interconnect 3920 (e.g., a snoop generator 3926 via snoop controller 3925) is implemented to issue such snoops to those that may store the homology cache of the cache line (block 4626) (in other words, if a hit occurs, their homology cache must be determined). When a cache line of a cache that issued such a snoop (e.g., the L1 cache, L2 cache, and / or L3 cache of the first agent and the L1 cache, L2 cache, and L3 cache of the second agent) is hit (block 4640), the cache will respond to the snoop (4644). In some embodiments, the cache is implemented to respond to such a snoop because prior art caches would typically respond according to the implemented cache homology protocol. While a new type of snooping is used in some embodiments, it is used in other prior art snooping techniques (e.g., RFO operations). In this case, incorporating the cache line zeroing instruction into the existing processor design does not require modification or minor modification to the cache depending (see the above heading "Triggering the cache to configure the cache line to indicate all zeros" section). When there is no cache line hit for the snooping cache (4640), in one embodiment the cache does nothing (control is passed to block 4652).

[0365] After a snooping request is sent, interconnect 3920 (e.g., snooping responder 3927 via snooping controller 3925) is configured to track the reception of any corresponding response message (e.g., in one embodiment, snooping generator 3926 instructs snooping responder 3927 to track the reception of any corresponding response message). If a response message (block 4660) is received along with data (e.g., data from a modified cache line), interconnect 3920 (e.g., snooping responder 3927 via snooping controller 3925) is configured not to send data to the sending agent or any cache of the sending agent (block 4662). If no response message (4660) is received along with data, interconnect 3920 (e.g., snooping responder 3927 via snooping controller 3925) is configured not to read data from downstream memory because it is not necessary (block 4664).

[0366] Depending on whether the embodiment of FIG41 or 42 is implemented, control is passed from blocks 4662 and 4664 to blocks 4132 or 4232 (blocks 4128 and 4228 are not implemented when this snooping is used). In block 4132 or 4232, the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) in itself (block 4232 only), the interconnect 3920 (e.g., via snooping controller QO25) or the first agent (e.g., via an execution unit (e.g., memory access unit 164, load storage unit 340) or other hardware structure) responds to a message from the interconnect 3920, causing a cache (e.g., L1 cache, L2 cache, L3 cache) to be cached. One of the cache lines is configured to indicate all zeros (as described in the preceding section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement cache to configure cache lines to indicate all zeros), or result in a write of zero to the cache line size to the downstream memory at the address. In embodiments where block 4662 is not implemented (data is sent back to the first agent) and / or block 4664 is not implemented (downstream memory is accessed and data is returned to the first agent), the first agent zeros out the data.

[0367] As described above, even when using RFO operation, the advantage of the illustrated embodiments is that they work with existing cache designs that support RFO operation with little or no modification.

[0368] As previously indicated, these types of snooping can be used in conjunction with the embodiments of Figures 41 and 42. For example, a specific embodiment of implementing such snooping in one of the embodiments of Figure 42 will be described. In this specific embodiment, the issuing agent 3900 will directly issue a command to the interconnect 3920 (skipping the cache of the publishing agent / first agent) to initiate a write of zero cache line size at the memory address, and the interconnect 3920 (e.g., via the snoop generator 3926 of the snoop controller 3925) is implemented to snoop on those that may be storing the coherent cache of the cache line as described above; if a response message is received along with data (i.e., data from the modified cache line), the interconnect 3920 may optionally implement (e.g., via the snoop responder 3927 of the snoop controller 3925) not to send data to the publishing agent or any cache of the publishing agent. If the response message is not received along with the data, the interconnect 3920 (e.g., via the snoop responder 3927 of the snoop controller 3925) may optionally implement not reading the data from the downstream memory because it is not necessary; and the publishing agent (first agent) itself or in response to the message from the interconnect causes a cache line in one of the caches (e.g., L1 cache, L2 cache, L3 cache) to be configured to indicate all zeros (different embodiments may implement caches to configure cache lines to indicate all zeros, as described in the section titled "Techniques for Configuring Cache Lines to Indicate All Zeros"), or causes a write of zeros to the cache line size of the downstream memory at the memory address. Therefore, in some embodiments, the L1 cache, L2 cache, and L3 cache (more specifically, if an L3 cache chip is implemented) are implemented in response to the snooping as described above; as described above, the interconnect 3920 is implemented to issue snooping in response to a command (e.g., via the snoop generator 3926 of the snoop controller 3925) and in response to response data from the cache (e.g., via the snoop responder 3927 of the snoop controller 3925); a publishing agent is implemented to directly send commands to the interconnect 3920 to initiate snooping. A write of zeros to a cache line size at a memory address; and an issuing agent (first agent) itself, or in response to a message from an interconnect, causes a cache line (e.g., L1 cache, L2 cache, L3 cache) in one of the caches to be configured to indicate all zeros (as described in the preceding section titled "Techniques for Configuring Cache Lines to Indicate All Zeros," different embodiments may implement caching to configure cache lines to indicate all zeros), or causes a write of zeros to a cache line size at a memory address to a downstream memory. In one specific embodiment, the issuing agent (first agent) causes a cache line (e.g., L1 cache, L2 cache, L3 cache) in one of the caches to be configured to indicate all zeros by itself. Multiple slots

[0369] As previously described, interconnect 3920 may, for example, represent: 1) interconnection only within a CCX; 2) interconnection within and between CCXs; 3) independent interconnection within different CCXs, and interconnection between CCXs. As discussed herein, the system can be implemented with one or more of the above-described processors (each comprising one or more CCXs) (see the section titled "Exemplary Computer Architecture" below). Such a system may include one or more sockets (referred to as CPU sockets or CPU slots), each containing one or more mechanical components providing mechanical and electrical connections. In a system with multiple sockets (e.g., a server), the sockets are connected by a set of one or more interconnects (also referred to as socket-to-slot interconnects). Different embodiments may implement the socket-to-slot interconnect set in different ways, including rings, multiple rings, point-to-point links (e.g., point-to-point links such as Fast Path Interconnect (QPI), Hyper Path Interconnect (UPI), HyperTransport (HP)), shared buses, etc. This set of socket-to-slot interconnects may be considered as part of or separate from interconnect 3920 depending on the embodiment. In some embodiments, this set of interconnects is implemented to support the same communications (write commands, snooping, response messages, etc.) discussed above with respect to interconnect 3920; wherein each of these communications may have the same or different formats when transmitted via slot-to-slot interconnects, etc. In other embodiments, one or more of these communications (e.g., one or more snooping types and / or response messages) are converted when transmitted from slot to slot. For example, some embodiments may use a write update snooping within the processor in a single slot, but when it is transmitted to another slot, this snooping is converted to a write invalid or write-back and invalid snooping. The advantage of this embodiment is that the decision of whether to generate a new zeroing cache line is made only within the slot (therefore, no "zeroing" or "non-zeroing" indication from other slots is required). Summary of some embodiments

[0370] One embodiment of the present invention may include a processor comprising a first coherence proxy, a second coherence proxy, and an interconnect. The first proxy is coupled to the interconnect via a cache of the first proxy. The second proxy is coupled to the interconnect via a cache of the second proxy. The first proxy is used to decode and execute instructions that result in a write of zero cache line size at a memory address. The first proxy is used to issue a write command to the cache of the first proxy to initiate a write of zero cache line size at a memory address. When there is a cache line hit in response to receiving a write command and the cache line's coherence protocol state is modified or excluded, the cache of the first proxy configures the cache line to indicate all zeros. When there is a cache miss in response to receiving a write command, the cache of the first proxy issues a write command to the interconnect. The interconnect snoops to the cache of the second proxy in response to receiving a write command. The interconnect or the first agent responds to a message from the interconnect, causing the cache line in the first agent's cache to be configured to indicate all zeros when a write command and snooping do not result in the cache line being written to zero.

[0371] Additionally, the following may apply: In some embodiments, when there is a cache hit in response to receiving a write command and the cache line's cache synchronization protocol state is not in a modified or excluded state, the first agent caches the cache line's cache synchronization protocol state to an invalid state and issues a write command to the interconnect.

[0372] Another embodiment of the present invention may include a processor comprising a decoder for decoding instructions to zero out cache lines. The processor also includes an execution unit coupled to the decoder and, in response to the decoding of the instructions, the execution unit issues a write command to initiate a write of zero cache line size at a memory address. The processor further includes a coherence cache coupled to the execution unit for receiving the write command, which, in response to the write command, determines whether a hit exists in the coherence cache, determines whether the cache coherence protocol state of the hit cache line is modified or excluded, configures the cache line to indicate all zeros when the cache coherence protocol state is modified or excluded, and issues a write command to an interconnect when there is a loss in response to the receipt of the write command. In response to the write command, the receiving interconnect probes each of a plurality of other coherence caches, for which a hit must be determined. The interconnect or execution unit responds to a message from the interconnect, causing the cache line in one of the coherent caches to be configured to indicate all zeros when a write command and snooping do not result in the cache line being written to zero.

[0373] Additionally, the following may apply: In some embodiments, the coherence cache also invalidates the cache coherence protocol state of the cache line, and issues a write command to the interconnect when the cache coherence protocol state of the hit cache line is not modified or excluded. In some embodiments, the decoder and execution unit are part of a first core, and the plurality of coherence caches include the coherence cache of a second core.

[0374] Another embodiment of the present invention may include a processor comprising a first core for issuing a write command in response to the execution of a cache line zeroing instruction. The first core further includes a Level 1 (L1) cache for receiving the write command, which, in response to the write command, determines whether there is a hit or a miss in the cache, and, in response to a hit, determines whether the cache synchronization protocol state of the hit cache line grants the cache permission to modify the cache line without broadcasting to other caches. When the cache synchronization protocol state of the hit cache line is one of granting the cache permission to modify the cache line without broadcasting to other caches, the L1 cache is configured to indicate all zeros in response to a hit. The L1 cache issues a write command to the interconnect in response to a miss. The interconnect coupled to the first core and in response to the write command probes to those plurality of other caches, for which it must determine whether there is a hit. The first core, the interconnect, or the first core responds to a message from the interconnect, causing a cache line in one of the caches or one of the other caches to be configured to indicate all zeros when a write command and a snoop do not result in a zero being written to the cache line.

[0375] Additionally, the following may apply: In some embodiments, when the cache synchronization protocol state of the hit cache line is not one that grants cache permission to modify the cache line without broadcasting to other caches, the L1 cache may also invalidate the cache synchronization protocol state and issue a write command to the interconnect in response to the hit. In some embodiments, in response to each of the plurality of other caches being spied on, it may also be implemented to determine whether there is a hit or a loss in other caches, and in response to a hit, to determine whether the cache synchronization protocol state of the hit cache line in other caches grants cache permission to modify the cache line without broadcasting to other caches. Each of the plurality of other caches is configured in that cache to indicate all zeros and issue a response message in response to the zeroing of the hit indication when the cache synchronization protocol state of the cache line hit in that cache is to grant cache permission to modify the cache line hit in that cache without broadcasting to other caches; and when the cache synchronization protocol state of the cache line hit in that cache is not to grant cache permission to modify the cache line hit in that cache, issue a response message in response to loss or in response to the non-zeroing of the hit indication. The interconnect is used to determine the trace reception of the response message to determine whether the snooping caused one of the plurality of other caches to be configured to indicate all zeros.

[0376] Another embodiment of the present invention may include a processor comprising a first coherent proxy, a second coherent proxy, and an interconnect. The first proxy is coupled to the interconnect via a cache of the first proxy. The second proxy is coupled to the interconnect via a cache of the second proxy. The first proxy is used to decode and execute instructions, the execution of which results in a write of zero cache line size at a memory address. The first proxy is used to issue commands to the interconnect. In response to receiving a command, the interconnect is used to send snoops to the caches of the first proxy and the second proxy. The first proxy, the interconnect, or the first proxy in response to a message from the interconnect causes a cache line in the cache of the first proxy to be configured to indicate all zeros when the snoop does not result in a write of zero to the cache line.

[0377] Another embodiment of the invention may include a processor comprising a decoder for decoding instructions to zero out cache lines. The processor further includes an execution unit coupled to the decoder for issuing a command in response to the decoding of the instruction. In response to the receipt of the command, an interconnect probes each of a plurality of coherent caches, for which a hit must be determined. The execution unit itself, the interconnect, or the execution unit in response to a message from the interconnect causes a cache line in one of the plurality of coherent caches coupled to the execution unit to be configured to indicate all zeros when the probe does not result in the execution of writing zeros to the cache line.

[0378] Another embodiment of the invention may include a processor comprising a first core that issues an execution command in response to a cache line zeroing instruction. The processor also includes interconnects coupled to a shared Level 3 (L3) cache, a Level 2 (L2) cache of the first core, and a Level 1 (L1) cache of the first core, for responding to an execution command to peer into a plurality of coherent caches, for which a hit must be determined. In some embodiments, the plurality of coherent caches include an L1 cache of the first core, an L2 cache of the first core, an L3 cache, an L1 cache of the second core, and an L2 cache of the second core. In response to a message from the interconnect, the first core itself, the interconnect, or the first core causes a cache line in one of the plurality of coherent caches coupled to the first core to be configured to indicate all zeros. PTE merging

[0379] The processor core may support a page table merging feature according to some exemplary embodiments, allowing multiple smaller memory pages to be merged into a single, efficient, larger memory page. In some embodiments, for example, eight 4KB memory pages may be merged into a single 32KB memory page. In other embodiments, 16 4KB memory pages may be merged into a single 64KB memory page.

[0380] Current computer architectures allow for virtual memory pages of various sizes. For example, the x86 architecture may allow pages of 4KB, 2MB, and 1GB. Processors implementing this architecture can provide a Translation Lookaside Buffer (TLB) for each of these page sizes, providing a mapping from virtual addresses to physical addresses. When attempting to translate a virtual address to a physical address, the processor can search each applicable TLB to determine if any of them contains an entry corresponding to the virtual address. If an entry is found (i.e., a "TLB hit"), the entry is retrieved from the found TLB, and the translation of virtual addresses to physical addresses continues.

[0381] If no entry corresponding to the virtual address exists in any TLB present on the processor (i.e., "TLB missing"), the processor may attempt to locate the entry in the paging table corresponding to the virtual address. If an entry is found (i.e., "paging table hit"), the entry is retrieved from the paging table and inserted into the appropriate TLB. The translation from the virtual address to the physical address can then be retried, resulting in a TLB hit.

[0382] If an entry corresponding to the virtual address is not found in the paging table (i.e., "paging table missing"), it can indicate that there is currently no physical address in memory corresponding to the provided virtual address. In this case, the processor can load the page corresponding to the virtual address from other storage (e.g., disk) into memory at the specific physical address, and can insert the mapping from the provided virtual address to the physical address into the paging table. Subsequent attempts to translate the provided virtual address will result in a paging table hit, which will cause the corresponding entry to be added to the appropriate TLB.

[0383] One challenge of current processor architectures is the lack of granularity in allowing page sizes. For example, as mentioned above, some processor architectures allow pages of 4KB, 2MB, and 1GB, providing a relatively "coarse" distribution across page sizes.

[0384] According to some embodiments, this difficulty can be addressed by merging multiple smaller pages to produce an intermediate page size, for example, greater than 4KB but less than 2MB. In some embodiments, this can be implemented by opportunistically merging, for example, eight 4KB pages to create a single valid 32KB page under specific conditions. In some embodiments, the eight 4KB pages must be aligned with the 32KB address boundary.

[0385] In some embodiments, the eight 4KB pages must be contiguous in one or both of the (a) virtual and (b) physical address spaces. For example, some embodiments may require that bits 12-14 of the virtual address VA and the physical address PA be equal to each other. That is, in some embodiments, smaller pages are merged into larger pages only for each smaller page VA[14:12] == PA[14:12].

[0386] In some embodiments, smaller pages are merged into a larger page only if each smaller page has the same permission bits. In some embodiments, when smaller pages are merged into a larger page, the operating system may combine the access / bad bits corresponding to each smaller page into a single value by, for example, performing a logical OR operation on the access / bad bits of all smaller pages. In some embodiments, when smaller pages are merged into a larger page, the operating system may set only the appropriate 4KB page bad / access bits to track which portions of the larger page have been accessed and / or corrupted.

[0387] Figure 47 is a diagram illustrating a page merging feature that may be included in a processor according to some embodiments. Block 4700 represents a portion of a paging table containing eight entries 4701-4708, each entry corresponding to a 4KB page. As shown in Figure 47, the eight entries 4701-4708 have consecutive addresses, with bits 12-14 of the eight addresses taking consecutive values ​​of 000, 001, 010, 011, 100, 101, 110, and 111. According to some embodiments, as shown in Figure 47, these eight 4KB pages can be combined into a valid 32KB page 4709.

[0388] In some embodiments, a valid 32KB page 4709 may be indicated by including additional bits in each page table entry (PTE) to indicate that eight 4KB pages should be considered valid 32KB pages. In some embodiments, a valid 32KB page 4709 may be indicated by additional bits in the page directory entry corresponding to page table entries 4701-08 to indicate that eight 4KB pages should be considered valid 32KB pages. In some embodiments, each time one of the eight 4KB pages is accessed, the consecutive, aligned addresses of the eight 4KB pages can be detected by the hardware and considered valid 32KB pages.

[0389] Various methods can be used to determine whether multiple smaller pages meet the criteria for merging into a single valid larger page. For example, Figure 48 is a flowchart illustrating a method for merging paging table entries into a single valid page. In the event of TLB loss across all TLBs (e.g., all 4KB, 32KB, 2MB, and 1GB TLBs) as shown in block 4801, the processor can traverse the paging table based on the hierarchical structure of the page directory (e.g., using an x86 paging table definition), as shown in block 4802. Once the location of the appropriate paging table entry is determined, the processor can retrieve a cache line containing multiple paging table entries (block 4803). For example, in some embodiments, the processor can retrieve eight paging table entries from the cache line.

[0390] When multiple page table entries are retrieved in the cache line, the processor may test whether the page table entries correspond to pages that meet the merging requirements, as shown in 4804. For example, the processor may test whether the page addresses are contiguous in virtual and / or physical memory. In some embodiments, the processor may further test whether the values ​​of the page's permission bits are the same. In some embodiments, the processor may determine whether the page addresses are aligned to a 32KB boundary.

[0391] If multiple paging table entries in the cache line meet the criteria for merging into a single composite page (e.g., a valid 32KB page), the entry corresponding to the composite page can be placed in the appropriate TLB (e.g., a 32KB TLB), and the entry in the cache line that forms the single entry is invalid, as shown in box 4805. If multiple paging table entries do not meet the criteria for merging into a single composite page, virtual-to-physical address translation can continue by using entries allocated in the TLB corresponding to the smaller (e.g., 4KB) TLB, as shown in box 4806.

[0392] In some embodiments, the processor may determine whether to merge multiple smaller pages based on the contents of the associated TLB. For example, after a 4KB TLB is lost, the processor may detect whether the corresponding 4KB page might be merged with additional entries present in the TLB (e.g., seven other TLB entries corresponding to the 4KB page). If the entry corresponding to the provided address can be combined with others used to create a valid larger page (e.g., a valid 32KB page), the existing TLB entry to be merged is invalidated, and an entry corresponding to the valid larger page in the appropriate TLB (e.g., in the TLB corresponding to the 32KB page) is created. In some embodiments, instead of using a separate TLB corresponding to the valid page size of the merge, information related to the virtual-to-physical address translation of the merged pages is stored in a TLB corresponding to the smaller page size (e.g., the 4KB page TLB). In some embodiments, additional bits reserved for this purpose may be used to encode this information in the TLB corresponding to the smaller page size.

[0393] In some embodiments, the above features can be used in conjunction with an operating system that uses an algorithm optimized for page merging as described above to allocate pages. Existing operating systems have algorithms for allocating, for example, 4KB, 2MB, and / or 1GB pages. Operating systems that can be used in conjunction with some embodiments may use additional algorithms designed for allocating combined pages (e.g., 32KB of valid pages).

[0394] The above-described page merging features are not limited to merging a specific number of pages of a particular size, but can be used to merge different numbers of pages of different sizes. For example, some embodiments can merge 16 4KB pages to form a 64KB effective combined page. Some embodiments can also support multiple sizes of effective combined pages (e.g., 32KB and 64KB combined pages). In some embodiments, multiple sizes of pages (e.g., 4KB and 32KB pages) can be combined into a single effective page (e.g., an effective 64KB page). Exemplary computer architecture

[0395] Figures 49-52 are block diagrams of exemplary computer architecture examples. Other system designs and configurations known in the art for laptop, desktop, and handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), general-purpose processors for server environments, server processors or processing elements, coprocessors (e.g., security coprocessors), high-throughput MIC processors, GPGPUs, accelerators (such as, for example, graphics accelerators, cryptographic accelerators, fixed-function accelerators, machine learning accelerators, network accelerators, or computer vision accelerators), field-programmable gate arrays, or any other processor or processing device, graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices capable of incorporating a processor and / or other execution logic disclosed herein are generally suitable.

[0396] Referring now to FIG49, a block diagram of a system 4900 according to one embodiment of the present invention is shown. The system 4900 may include one or more processors 4910, 4915 coupled to a controller hub 4920. In one embodiment, the controller hub 4920 includes a graphics memory controller hub (GMCH) 4990 and an input / output hub (IOH) 4950 (which may be located on separate chips); the GMCH 4990 includes memory and a graphics controller, which is coupled to memory 4940 and a processor 4945; the IOH 4950 is coupled to input / output (I / O) devices 4960 to the GMCH 4990. In addition, one or both of the memory and the graphics controller are integrated inside the processor (as described herein), and the memory 4940 and the coprocessor 4945 are directly coupled to the processor 4910 and to the controller hub 4920 having IOH 4950 in a single chip.

[0397] The selective nature of the additional processor 4915 is indicated by dashed lines in Figure 49. Each processor 4910, 4915 may include one or more of the processing cores described herein and may be a version of processor 3600.

[0398] The memory 4940 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of both. For at least one embodiment, the controller hub 4920 communicates with the processors 4910, 4915 via a multi-plug bus such as a front-side bus (FSB), a point-to-point interface such as a fast path interconnect (QPI), or a similar connection 4995.

[0399] In one embodiment, the coprocessor 4945 is a special-purpose processor (including, for example, a general-purpose processor for a server environment, a server processor or processing element, a coprocessor such as a security coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator such as, for example, a graphics accelerator or digital signal processing (DSP) unit, a cryptographic accelerator, a fixed-function accelerator, a machine learning accelerator, a network accelerator, or a computer vision accelerator), a field-programmable gate array, or any other processor or processing device). In one embodiment, the controller hub 4920 may include an integrated graphics accelerator.

[0400] In terms of a certain range of quality scales, including architecture, microarchitecture, thermal and power consumption characteristics, there may be multiple differences between entity resources 4910 and 4915.

[0401] In one embodiment, processor 4910 executes instructions that control a general category of data processing operations. These instructions internally embed coprocessor instructions. Processor 4910 recognizes that these coprocessor instructions belong to a category that must be executed by an attached coprocessor 4945. Therefore, processor 4910 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 4945 on the coprocessor bus or other interconnect. Coprocessor 4945 receives and executes the received coprocessor instructions.

[0402] Referring now to FIG. 50, a block diagram of a first more specific exemplary system 5000 according to one embodiment of the present invention is shown. As shown in FIG. 50, the multiprocessor system 5000 is a point-to-point interconnect system including a first processor 5070 and a second processor 5080 coupled via a point-to-point interconnect 5050. Processors 5070 and 5080 may each be a version of processor 3600. In one embodiment of the present invention, processors 5070 and 5080 are processors 4910 and 4915, respectively, and a coprocessor 5038 is a coprocessor 4945. In another embodiment, processors 5070 and 5080 are processor 4910 and coprocessor 4945, respectively.

[0403] Processors 5070 and 5080 are shown to include integrated memory controller (IMC) units 5072 and 5082, respectively. Processor 5070 also includes point-to-point (PP) interfaces 5076 and 5078 as part of its bus controller unit; similarly, the second processor 5080 may include PP interfaces 5086 and 5088. Processors 5070 and 5080 can exchange information through point-to-point (PP) interface 5050 using PP interface circuits 5078 and 5088. As shown in FIG50, IMCs 5072 and 5082 are coupled to individual memories, namely memories 5032 and 5034, which may be part of the main memory locally attached to the individual processors.

[0404] Processors 5070 and 5080 can exchange information with a chipset 5090 via point-to-point interface circuits 5076, 5094, 5086, and 5098 through PP interfaces 5052 and 5054. Chipset 5090 can also exchange information with coprocessor 5038 through a high-performance interface 5092. In one embodiment, coprocessor 5038 is a special-purpose processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, or embedded processor.

[0405] The shared cache (not shown in the figure) may be included in either processor or outside the two processors, but is still connected to the processors via the PP interconnect, so that if a processor is placed in a low power mode, the local cache information of either processor or the two processors can be stored in the shared cache.

[0406] Chipset 5090 may be coupled to a first bus 5016 via an interface 5096. In one embodiment, the first bus 5016 may be a peripheral component interconnect (PCI) bus, or one of the PCI fast buses or other third-generation I / O interconnect buses, but the scope of the invention is not limited thereto.

[0407] As shown in FIG. 50, multiple I / O devices 5014 may be coupled to a first bus 5016 via a bus bridge 5018, which is coupled from the first bus 5016 to a second bus 5020. In one embodiment, one or more additional processors 5015 (such as general-purpose processors, server processors or processing elements for server environments, coprocessors (e.g., security coprocessors), high-throughput MIC processors, GPGPUs, accelerators (such as graphics accelerators or digital signal processing (DSP) units, cryptographic accelerators, fixed-function accelerators, machine learning accelerators, network accelerators or computer vision accelerators), field-programmable gate arrays, or any other processor or processing device) are coupled to the first bus 5016. In one embodiment, the second bus 5020 may be a low pin count (LPC) bus. In one embodiment, multiple devices may be coupled to the second bus 5020, including, for example, a keyboard and / or mouse 5022, a communication device 5027, and a storage unit 5028, such as a disk drive or other mass storage device, which may include instruction / code and data 5030. Additionally, audio I / O 5024 may be coupled to the second bus 5020. Note that other architectural configurations are possible. For example, instead of the point-to-point architecture of Figure 50, a system may implement a multi-plug bus or other such architectures.

[0408] Referring now to FIG51, a block diagram of a second more specific exemplary system 5100 according to an embodiment of the present invention is shown. Similar elements in FIG50 and FIG51 have similar element symbols, and some features of FIG50 have been omitted from FIG51 to avoid unnecessarily obscuring other features of FIG51.

[0409] Figure 51 illustrates that processors 5070 and 5080 may respectively include integrated memory and I / O control logic ("CL") 5072 and 5082. Therefore, CL 5072 and 5082 include integrated memory controller units and I / O control logic. Figure 51 illustrates that not only are memories 5032 and 5034 coupled to CL 5072 and 5082, but I / O device 5114 is also coupled to control logic 5072 and 5082. The legacy I / O device 5115 is coupled to chipset 5090.

[0410] Referring now to FIG. 52, a block diagram of an SoC 5200 according to an embodiment of the present invention is shown. Similar elements in FIG. 36 have similar element symbols. Also, the dashed boxes represent optional features on more advanced SoCs. In Figure 52, interconnect unit 5202 is coupled to: an application processor 5210 comprising one or more cores 3602A-N including cache units 3604A-N and shared cache unit 3606; a system agent unit 3610; a bus controller unit 3616; an integrated memory controller unit 3614; a coprocessor 5220 comprising integrated graphics logic, image processor, audio processor and video processor, general-purpose processor for server environments, server processor or processing element, security coprocessor, high-throughput MIC processor, GPGPU, accelerator (such as, for example, a graphics accelerator or digital signal processing (DSP) unit, cryptographic accelerator, fixed-function accelerator, machine learning accelerator, network accelerator or computer vision accelerator), field-programmable gate array or any other processor or processing device; a static random access memory (SRAM) unit 5230; a direct memory access (DMA) unit 5232; and a display unit 5240 for coupling to one or more external displays. In one embodiment, the processor(s) 5220 includes a special-purpose processor, such as a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, etc.

[0411] As embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or combinations thereof. Embodiments of the present invention can be implemented as computer programs or code executable on a programmable system comprising at least one processor, wherein the processor includes, for example, a general-purpose processor for a server environment, a server processor or processing element, a coprocessor (e.g., a secure coprocessor), a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or digital signal processing (DSP) unit, a cryptographic accelerator, a fixed-function accelerator, a machine learning accelerator, a network accelerator, or a computer vision accelerator), a field-programmable gate array or any other processor or processing device, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0412] Code (such as code 5030 illustrated in Figure 50) can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor, such as a digital signal processor (DSP), microcontroller, application-specific integrated circuit (ASIC), or microprocessor.

[0413] The code may be implemented in a high-level programming or object-oriented programming language to communicate with a processing system. If necessary, the code may also be implemented in an assembly language or machine language. In fact, the scope of the mechanism described herein is not limited to any particular programming language. In any case, the language may be a compiled language or an interpreted language.

[0414] One or more forms of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing multiple logics within a processor, which, when read by a machine, cause the machine to combine the logic to perform the techniques described herein. This representation form is referred to as an "IP core" and may be stored on a tangible machine-readable medium and supplied to various customers or manufacturers for loading into assembly machines that actually produce the logic or processor.

[0415] Such machine-readable storage media may include, but are not limited to, non-transitory tangible objects manufactured or made by a machine or apparatus, including storage media such as hard disks, any other class of disks including floppy disks, optical disks, optical disc-ROMs, optical disc rewritable wrappers (CD-RWs), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic cards or optical cards; or any other class of media suitable for storing electronic instructions.

[0416] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description languages ​​(HDLs) that define the structures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products.

[0417] Instructions executed by the processor core according to embodiments of the present invention can be embodied in a "corresponding vector friendly instruction format," which will be described in detail below. In other embodiments, such a format is not used, and another instruction format is used; however, the following descriptions of writing to mask registers, various data conversions (mixing, broadcasting, etc.), addressing, etc., generally apply to the above descriptions of embodiments relating to instructions. Furthermore, exemplary systems, architectures, and pipelines are described in detail below. Instructions can be executed in such systems, architectures, and pipelines, but are not limited to those described in detail. Instruction Set

[0418] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit position) to specify the operation to be performed (e.g., opcode) and the operands and / or other data fields (e.g., mask) on which the operation will be performed, etc. Some instruction formats are further decomposed through the definition of instruction templates (or subformats). For example, an instruction template for a given instruction format may be defined as a different subset of the fields of the instruction format (the included fields are generally in the same order, but at least some have different bit positions because fewer fields are included) and / or defined as given fields with different interpretations. Thus, each instruction of the ISA is represented using a given instruction format (and, if defined, in a given instruction template within the instruction template of that instruction format), and includes fields for specifying operations and operands. For example, the exemplary ADD instruction has a specific opcode and instruction format, including an opcode field specifying the opcode and operand fields to select operands (source 1 / destination and source 2); and the occurrence of this ADD instruction in the instruction stream will have specific content in the operand field that selects the specific operand. A set of SIMD extensions, known as Advanced Vector Extensions (AVX, AVX2, and AVX-512), has been issued and / or published, and uses the Vector Extensions (VEX) encoding scheme (see, for example, the Intel® 64 and IA-32 Architecture Software Developer's Handbook, September 2014; the Intel® Advanced Vector Extensions Programming Reference, October 2014; and the Intel® Architecture Instruction Set Extensions Programming Reference, October 2016). Exemplary instruction format

[0419] Embodiments of the instructions described herein may be embodied in different formats. Furthermore, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the instructions can be executed on such systems, architectures, and pipelines, but are not limited to those described in detail. They belong to the same vector-friendly instruction format.

[0420] The vector-friendly instruction format is an instruction format applicable to vector instructions (e.g., certain fields are specific for vector operations). Although an embodiment supporting vector and scalar operations through the vector-friendly instruction format is described, alternative embodiments may use only the vector-friendly instruction format for vector operations.

[0421] Figures 53A-53B are block diagrams illustrating a shared vector friendly instruction format and its instruction template according to an embodiment of the present invention. Figure 53A is a block diagram illustrating a shared vector friendly instruction format and its category A instruction template according to an embodiment of the present invention; while Figure 53B is a block diagram illustrating a shared vector friendly instruction format and its category B instruction template according to an embodiment of the present invention. Specifically, category A and category B instruction templates are defined for shared vector friendly instruction format 5300, and both category A and category B instruction templates include a no-memory access 5305 instruction template and a memory access 5320 instruction template. In the context of the vector friendly instruction format, the term "shared" means that the instruction format is not bound to any specific instruction set.

[0422] Although embodiments of the invention will be described, the vector-friendly instruction format supports the following: 64-bit vector operand lengths (or sizes) having a 32-bit (4-byte) or 64-bit (8-byte) data element width (or size) (therefore, a 64-bit vector consists of 16 double-word elements or alternatively 8 quad-word elements); 64-bit vector operand lengths (or sizes) having a 16-bit (2-byte) or 8-bit (1-byte) data element width (or size); and 32-bit (4-byte), 64-bit (8-byte), and 16-bit vector operand lengths (or sizes). 32-byte vector operand lengths (or sizes) with a data element width (or size) of 2 bytes or 8 bytes (1 byte); and 16-byte vector operand lengths (or sizes) with a data element width (or size) of 32 bytes (4 bytes), 64 bytes (8 bytes), 16 bytes (2 bytes), or 8 bytes (1 byte); alternative embodiments support more, fewer, and / or different vector operand sizes (e.g., 256-byte vector operands) with more, fewer, or different data element widths (e.g., 128-byte (16-byte) data element widths).

[0423] The category A instruction template in Figure 53A includes: 1) within the no memory access 5305 instruction template, displaying the no memory access, full round control type operation 5310 instruction template and the no memory access, data conversion type operation 5315 instruction template; and 2) within the memory access 5320 instruction template, displaying the memory access, temporary 5325 instruction template and the memory access, non-temporary 5330 instruction template. The category B instruction template in Figure 53B includes: 1) within the no memory access 5305 instruction template, displaying the no memory access, write mask control, partial round control type operation 5312 instruction template and the no memory access, write mask co...

Claims

1. A processor comprising: a first coherence agent coupled to an interconnect via a first cache, the first coherence agent being configured to decode and execute instructions, the execution of which is configured to cause a zero cache line-sized write at a memory address, and to issue a write command to the first cache to initiate the zero cache line-sized write at the memory address; the first cache being configured to indicate all zeros when, in response to receiving the write command, there is a cache line hit and the cache coherence protocol state of the cache line is modified or excluded, and to issue the write command to the interconnect when, in response to receiving the write command, there is a cache loss; and a second coherence agent coupled to the interconnect via a second cache; the interconnect being configured to issue a snooping signal to the second cache in response to receiving the write command; The first coherent agent, which is the interconnect or responds to messages from the interconnect, is configured to indicate all zeros when other cache lines in the first cache are written to cache lines where the write command and the snooping do not cause the zero to be written.

2. The processor as claimed in claim 1, wherein when a hit for the cache line is received in response to the write command and the cache line's cache synchro protocol state is not the modified state or the excluded state, the first cache system is configured to invalidate the cache line's cache synchro protocol state and to issue the write command to the interconnect.

3. A processor comprising: a first core configured to issue a write command in response to executing a cache line zeroing instruction, the first core also including a Level 1 (L1) cache; the L1 cache coupled to receive the write command, configured to respond to the write command determining whether there is a hit or a miss in the L1 cache, configured to respond to whether the cache synchronization protocol state of the hit cache line is one, allowing the L1 cache to authorize modification of the cache line without broadcasting to at least one other cache line, configured to configure the cache line to indicate all zeros in response to the hit when the cache synchronization protocol state of the hit cache line is one, allowing the L1 cache to authorize modification of the first cache line without broadcasting to the at least one other cache line, and configured to issue the write command to an interconnect in response to the miss; and the interconnect coupled to the first core, configured to respond to the write command to snoop on those necessary for determining whether there are other hits in the at least one other cache line. The first core, the interconnect, or the first core that responds to messages from the interconnect is configured to indicate all zeros when other cache lines or at least one of the other caches are configured to indicate all zeros when the write command and the snooping do not cause a write to the cache line that is zero.

4. The processor as claimed in claim 3, wherein the first cache is configured to invalidate the cache synchronization protocol state, and when the cache synchronization protocol state of the hit cache line is one, allowing the cache authorization to modify the first cache line without broadcasting to at least one other cache line, the write command is issued in response to the hit to the interconnect.

5. The processor as described in claim 3, wherein in response to the snooping, each of the at least one other cache is configured to determine whether there are other hits or other misses in the other cache, and in response to the other hit, the cache synchronization protocol state of the cache line hit is set to one, thereby allowing the other cache to authorize modification of the cache line without broadcasting to the other cache.

6. The processor as claimed in claim 5, wherein each of the at least one other cache is configured to: configure the cache line in the other cache to indicate all zeros, and when the cache synchronization protocol state of the cache line hit in the other cache is one, allowing the other cache authorization to modify the cache line hit in the other cache without broadcasting to the other cache, issue a response message indicating zeroing in response to the other hit; and issue a response message indicating non-zeroing in response to the other hit or in response to the other hit when the cache synchronization protocol state of the cache line hit in the other cache is not one, allowing the cache authorization to modify the cache line hit in the other cache.

7. The processor as claimed in claim 6, wherein the interconnect is used to track the receipt of the response message to determine whether the snooping causes one of the other caches to be configured to indicate all zeros.

Images