Flexible cache allocation technology priority-based cache line eviction algorithm

Abstract

To provide a cache line eviction algorithm.SOLUTION: A computing system 200 includes a last level cache (LLC) 204 and a cache control circuit (CCC) 201. The LLC has multiple ways, each allocated to one of multiple priorities, each specifying minimum and maximum numbers of ways to occupy. The CCC stores an incoming cache line (CL) having a requestor priority to an invalid CL if the invalid CL exists. Otherwise, when the requestor priority is a lowest priority and has an occupancy of one or more, or when the occupancy is at the maximum, the CCC evicts a least recently used (LRU) CL of the requestor priority. Otherwise, when the occupancy is between the minimum and the maximum, the CCC evicts an LRU CL of the requestor priority or a lower priority.SELECTED DRAWING: Figure 2

Description

[Technology Field]

[0001] The technical field of the present invention generally relates to computer processor architectures, and more particularly to priority-based eviction algorithms for improved flexible cache allocation techniques (Flex-CAT) for cache partitioning. [Background technology]

[0002] Multi-tenancy has been proven to be a solution that achieves high system utilization and cost savings through spatial sharing. Multi-tenancy is possible in cloud environments through virtualization, where each core hosts virtual machines (VMs) running user applications. New computing paradigms such as Function as a Service (FaaS) utilize container-based virtualization to run numerous individual lightweight functions within containers. In a typical multi-tenant environment, high-priority (HP) jobs and low-priority (LP) jobs coexist on the same computing resource, such as a multi-core processor or core. HP jobs are latency-sensitive, while LP jobs often have more flexible deadlines. Some HP jobs require low latency as well as performance determinism. Users submitting jobs enter into Quality of Service (QoS) Service Level Agreements (SLAs) with their Cloud Service Providers (CSPs), and comply with these agreements regarding latency or performance determinism. The CSP must meet the SLA by mitigating performance fluctuations or QoS degradation of HP jobs caused by other LP jobs in the same location. [Brief explanation of the drawing]

[0003] The present invention is shown in the accompanying drawings as examples, not as limitations, where similar reference numerals indicate similar elements.

[0004] [Figure 1] This is a block diagram showing a processing component that executes instructions, according to several embodiments.

[0005] [Figure 2] This block diagram shows a system including a multicore system that runs virtual machines, according to several embodiments.

[0006] [Figure 3] An exemplary cache partitioning scheme, according to several embodiments, is shown.

[0007] [Figure 4] Block diagram showing a cashline eviction according to several embodiments.

[0008] [Figure 5] This is a block flow diagram illustrating the processing performed by the cache control circuit in response to a cache fill request, according to several embodiments.

[0009] [Figure 6] A flowchart illustrating a cache control circuit that processes a cache fill request according to several embodiments.

[0010] Figures 7A and 7B are block diagrams showing a general-purpose vector instruction format and its instruction templates according to several embodiments of the present invention.

[0011] [Figure 7A] This block diagram shows a general-purpose vector instruction format and its Class A instruction template according to several embodiments of the present invention.

[0012] [Figure 7B] This block diagram shows a general-purpose vector instruction format and its Class B instruction template according to several embodiments of the present invention.

[0013] [Figure 8A] A block diagram showing an exemplary instruction format for a specific vector, according to several embodiments of the present invention.

[0014] [Figure 8B] FIG. 8C is a block diagram showing fields that constitute a full opcode field of an instruction format for a specific vector according to one embodiment.

[0015]

FIG. 8C

[0016]

FIG. 8D

[0017]

FIG. 9

[0018]

FIG. 10A

[0019]

FIG. 10B

[0020] FIGS. 11A and 11B are block diagrams of a more specific and exemplary in-order core architecture, the core being one of several logical blocks (including other cores of the same type and / or different types) within a chip.

[0021]

FIG. 11A

[0022] [Figure 11B] This is an enlarged view of a portion of the processor core in Figure 11A, according to several embodiments.

[0023] [Figure 12] This is a block diagram of a processor according to some embodiments, which may have two or more cores, an integrated memory controller, and integrated graphics.

[0024] Figures 13 to 16 are block diagrams of exemplary computer architectures.

[0025] [Figure 13] This is a block diagram of a system according to several embodiments.

[0026] [Figure 14] This is a block diagram of a first more specific exemplary system according to several embodiments.

[0027] [Figure 15] This is a block diagram of a second, more specific exemplary system according to several embodiments.

[0028] [Figure 16] This is a block diagram of a system-on-a-chip (SoC) according to several embodiments.

[0029] [Figure 17] This block diagram illustrates, in some embodiments, the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set. [Modes for carrying out the invention]

[0030] The following description provides numerous specific details. However, it will be understood that some embodiments can be implemented without these specific details. In other examples, known circuits, structures, and techniques are not described in detail so as not to impair the understanding of this description.

[0031] In this specification, expressions such as “one embodiment,” “a particular embodiment,” and “an exemplary embodiment” indicate that the described embodiment may include features, structures, or characteristics, but not all embodiments necessarily include these features, structures, or characteristics. Furthermore, such language does not necessarily refer to the same embodiment. In addition, if a feature, structure, or characteristic is described in relation to one embodiment, it is assumed that, if explicitly stated, it will be obvious to those skilled in the art that it will affect other embodiments as well.

[0032] As described above, cloud service providers (CSPs) must meet service level agreements (SLAs) by suppressing performance fluctuations or degradation of quality of service (QoS) of high-performance (HP) jobs caused by other low-performance LP jobs in the same location. Specifically, the embodiments of the disclosure describe Flexible Cache Allocation Technology (Flex-CAT), a structural solution that suppresses HP last-level cache (LLC) eviction by LP jobs. The Flex-CAT method dynamically determines the optimal number of ways for each cache set based on the utilization of cache lines (CLs) within each cache set, according to various priorities. The boundaries (minimum and maximum number of ways) are specified in a model-specific register (MSR) that provides hints for selecting targets for eviction when the LLC cache is filled.

[0033] Flex-CAT offers the advantage of providing an easily configurable yet flexible interface for specifying cache partitions. Because Flex-CAT manages partitions at a fine granularity, it supports a dynamic cache partitioning scheme that makes priority-based LLC eviction decisions based on real-time data. Flex-CAT contributes to meeting cloud service providers' requirements for structural features that ensure QoS guarantees, such as performance determinism and the separation of high-performance and low-performance jobs. In this specification, low-performance jobs may also be referred to as "noisy neighbors."

[0034] A less effective alternative approach has attempted to resolve the imbalance between HP and LP jobs sharing resources by assigning separate sets of ways to cores and restricting HP and LP jobs to specific cores. However, such approaches have several problems. For example, the concept of priority is absent in these mechanisms. Some of these approaches separate HP jobs from LP jobs by assigning all cache sets and way sets unique to HP cores, but these unique resources cannot be used for LP workloads when they are not being used for HP workloads. Furthermore, some of these approaches cause certain limited cache sets (e.g., x sets) to become more saturated than others (e.g., Nx sets, where N is the total number of cache sets). This saturation of x sets can lead to equal way allocation to HP jobs, potentially resulting in over-allocation of the entire Nx set, as well as under-utilization of these Nx sets. Additionally, allocating fewer ways than the maximum number to cores leads to reduced coupling, more race-based misses, and decreased performance. Methods using static allocation, which assigns fixed cache ways to cores, leave no room for flexibility during cache eviction and fill.

[0035] On the other hand, the disclosed embodiment provides a flexible interface for dynamically specifying priorities and cache partitions. Priorities are listed in descending order of priority. Flexible cache partitions can be specified for the maximum and minimum number of ways for each priority. Unlike some other methods, Flex-CAT does not require software to precisely specify the cache ways to be allocated to each partition.

[0036] Such dynamic priority and cache partitioning specifications are supported by the Class of Service (CLOS) register. This register holds the following values ​​for each CLOS: • CLOS Priority P: Pn bits • Maximum number of ways occupied by priority P: mxwn bits • Minimum number of ways occupied by priority P: mnwn bits

[0037] For example, if the maximum number of priorities is 4, then Pn = log(4) = 2. If the maximum number of ways is 16, then mxwn = mnwn = log(16) = 4. [Table 1]

[0038] According to embodiments disclosed herein, the requester is the owner of a CL to be embedded in the LLC. The requester's priority is PF. In the system, PL is the lowest priority and PH is the highest priority. loc is the final storage location for the requester's CL as determined by Flex-CAT. The requester's occupancy O[PF] is the number of CLs occupied by the requester within the indexed cache set.

[0039] Flex-CAT is a novel eviction algorithm that performs priority-based cache partitioning at the cache set granularity. LP CLs are preferentially evictioned as long as the number of requests does not exceed the maximum way allocation (mxw). When the number of requests reaches the maximum allocation, Flex-CAT prioritizes self-eviction over other priority evictions, ensuring the request remains within the partition boundary. In limited situations where the target cannot be found in these first two stages, Flex-CAT selects HP CLs for eviction to make space for subsequent cache fills. Figure 4 illustrates this basic concept of Flex-CAT.

[0040] The detailed algorithm is shown in the flowcharts from Figures 4 to 6 and is explained below. During LLC fill, the disclosed embodiment determines the cache set index for the requester's subsequent cache line using a conventional hashing algorithm.

[0041] After indexing into the appropriate cache set, Flex-CAT first searches for invalid LLC entries within the indexed cache set. If the cache set is full and no invalid storage locations are found, Flex-CAT determines which target CLs need to be evicted from the LLC. This ensures that Flex-CAT is only enabled on saturated cache sets and does not incur unnecessary workloads if there is no content. Flex-CAT scans the entire cache set and determines the index of LRU CLs, their elapsed time, and their occupancy for each priority in the system.

[0042] If the original occupancy of the requester is less than the minimum allocation (O[PF] < PF[mnw]), Flex-CAT preferentially evicts the LP LRU CL to increase its occupancy. If the original occupancy of the requester reaches the minimum allocation and is less than the maximum allocation (PF[mnw] ≤ O[PF] < PF[mxw]), Flex-CAT searches for the LRU target from the priorities and further adds its LRU CL to the candidate list. When the original occupancy of the requester reaches the maximum allocation, Flex-CAT ignores the LP LRU candidates and selects the requester's LRU (LRUF) as the target CL to ensure that the original occupancy of the requester never exceeds the upper limit (PF[mxw]). If no target is found in the previous stage (if all lines belong to owners with higher priorities), Flex-CAT performs a HP eviction.

[0043] As shown in FIGS. 5 and 6 and described below in the flowchart, the stages that Flex-CAT goes through after indexing to the appropriate cache set are shown.

[0044] FIG. 1 is a block diagram showing a processing component for executing instructions according to some embodiments. As shown, the storage 101 stores the instruction(s) 103 to be executed. As will be described further below, in some embodiments, the system 100 (also referred to herein as a "computing system") is a SIMD processor that simultaneously processes multiple elements of a packed data vector, including matrices.

[0045] During operation, the instruction(s) 103 are fetched from the storage 101 by the fetch circuit 105. The instruction is decoded by the decode circuit 109. The decode circuit 109 decodes the fetched instruction 107 into one or more operations. In some embodiments, this decoding includes generating a plurality of micro-operations to be executed by an execution circuit (such as execution circuit 117, etc.). The decode circuit 109 further decodes the instruction suffix and prefix (if used).

[0046] In some embodiments, the register renaming, register assignment, and / or scheduling circuit 113 provides functionality for one or more of the following: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some embodiments); 2) assigning status bits and flags to decoded instructions; and 3) scheduling the decoded instructions 111 from the instruction pool for execution on the execution circuit 117 (e.g., utilizing a reservation station in some embodiments).

[0047] Registers (register files) and / or memory 115 store data as operands to instructions 111 executed by the execution circuit 117. Exemplary register types include, but are not limited to, write mask registers, packed data registers, general-purpose registers, and floating-point registers, as further described and shown below with reference to at least Figure 9.

[0048] In some embodiments, the write-back circuit 119 commits the instruction execution result. The execution circuit 117 and system 100 are further illustrated in Figures 2–4, 10A, 10B, 11A, and 11B, and will be described with reference to them.

[0049] Figure 2 is a block diagram showing a system including a multicore processor running virtual machines according to several embodiments. As shown, the computing system 200 includes a multicore processor 202, which includes cores 0 206A, 1 206B, ... up to core N 206N, sharing a last-level cache LLC 204. Together, the resources of the processor 202 can function as part of a cloud service provider's (CSP) computing platform to provide network services to one or more clients. For example, as shown, cores 0, 1, through N support VM0 210A, VM1 210B, ... up to VMN 210N. VM0 210A supports VNF application 0 212A (Virtual Network Functions application) and guest OS 0 214A. Similarly, VM1 210B supports VNF application 1 212B and guest OS 1 214B. Similarly, VMN 210N supports VNF application 212N and guest OS N 214N. During operation, virtual machines are started and managed using the hypervisor / VMM208. Furthermore, operating system 214 can be invoked to manage the system.

[0050] In some embodiments, the cache control circuit 201 works in cooperation with the hypervisor / VMM208 to implement the cache partitioning scheme described herein.

[0051] In some embodiments, the cache monitoring circuit 203 maintains statistics and heuristics related to cache access requests, such as the percentage of low-priority cache fill requests that result in eviction of high-priority cache lines. The cache monitoring circuit 203 is optional, as indicated by the dashed lines, and can be alternatively incorporated into the processor 202. In some examples, the computing system 200 is a standalone computing platform, while in other examples, it is coupled to another computing platform via a network (not shown).

[0052] In some embodiments, the computing system 200 is a node in a data center that supports VMs running one or more VNF applications individually. These applications include, for example, cloud service providers, database network services, website hosting services, routing network services, email services, firewall services, domain name services (DNS), caching services, network address translation (NAT) services, or virus scanning network services. VMs 210A to 210N in the computing system 200 may be managed or controlled by a hypervisor or virtual machine manager (VMM), such as a hypervisor / VMM208. In other embodiments, the computing system 200 may be configured as a more conventional server having the various computing resources described above, housed in the same physical enclosure, chassis, or container.

[0053] According to some embodiments, a virtual machine is a software computer that runs an operating system and applications, just like a physical computer. Some virtual machines are configured by a set of configuration files and are supported by the host's physical resources. A hypervisor or VMM is computer software, firmware, or hardware that creates and manages virtual machines. The computer on which a hypervisor runs one or more virtual machines is referred to as the host machine, and each virtual machine is referred to as a guest machine. The hypervisor or VMM presents the guest operating system through a virtual operating platform and manages the execution of the guest operating system. Numerous instances of various operating systems can share virtualized hardware resources. For example, Linux®, Windows®, and macOS® instances can all run on a single physical processor with multiple cores.

[0054] In some examples, as shown in Figure 2, at least a portion of the computing resources for the computing system 200 may include processing elements such as CPUs / cores 206A, 206B, ..., 206N, which have a shared last-level cache (LLC) 204.

[0055] In some examples, LLC204 is located outside of processor 202. According to some examples, shared LLC204 can be a relatively fast access memory type because it functions as a shared LLC from CPU / core 206A to 206N to minimize access latency. The relatively fast access memory types included in shared LLC204 may include, but are not limited to, volatile or non-volatile memory. Volatile memory types may include, but are not limited to, static random access memory (SRAM) or dynamic random access memory (DRAM), thyristor RAM (TRAM), or zero-capacitor RAM (ZRAM). Non-volatile memory types may include, but are not limited to, byte- or block-addressable non-volatile memory types having a three-dimensional (3D) crosspoint memory structure containing chalcogenide phase-change material (e.g., chalcogenide glass) (hereinafter referred to as "3D crosspoint memory"). Non-volatile memory types may further include other types of byte- or block-addressable non-volatile memory. Examples of such technologies include, but are not limited to, multi-threshold NAND flash memory, NOR flash memory, single or multi-phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), magnetoresistive random access memory (MRAM) incorporating memristor technology, spin-transfer torque MRAM (STT-MRAM), or any combination of the above.

[0056] Figure 3 shows exemplary LLC cache partitioning schemes according to several embodiments. As shown, scheme 300 is an example of a scheme that can be used as a shared LLC 204 in a computing system 200 as shown in Figure 2. Here, LLC 304 is shown as an 8-way set-combined cache, where each cache way 302 contains 8 cache lines. Some of the cache lines of LLC 304 are allocated to low-priority applications 306, some to high-priority applications 310, and some are disabled 308. For brevity of explanation, shared LLC 354 is shown as an 8-way set-combined cache, where each way contains 1 cache line. Some of the cache lines of LLC 354 are allocated to low-priority applications 356, some to high-priority applications 360, and some are disabled 358. The embodiments shown in Figure 3 are not limited to any particular configuration. Other schemes may include more or fewer sets, more or fewer ways within a set, more or fewer cache lines within each way, and so on. For example, LLC204 could be an N-way set joined cache where each set contains M cache lines, and N and M are positive integers greater than or equal to 1.

[0057] During operation, as will be further described later, LLC204 is dynamically repartitioned as needed by the applications sharing the LLC. An advantage of the disclosed embodiment is that low-priority applications minimize the eviction of cache lines allocated to high-priority applications.

[0058] Figure 4 is a block diagram showing cache line evictions according to several embodiments of the Flex-CAT algorithm. According to the embodiments of the disclosure, Flex-CAT is an eviction algorithm that performs priority-based cache partitioning at the cache set granularity. As shown in the figure, scheme 400 indicates an application of priority that falls within the range of priority 402. Arcs 404, 406, and 408 are subsequent cache lines from the requesting core, showing cache line evictions to make space for requests filling the cache lines. Some evictions, such as eviction 408, make space for higher priority assignments by evictions of lower priority assignments. Some evictions are self-evictions, shown by arc 406 (for example, a priority that has already been assigned the maximum number of ways self-evictions to make space for subsequent CLs). When the number of requests reaches the maximum assignment, Flex-CAT prioritizes self-evictions over other priority evictions to keep them within the partition boundary. In the limited situations where the target cannot be found in the previous two stages, Flex-CAT selects an HP CL for eviction to make space for subsequent cache fills. Flex-CAT aims to maximize evictions for LP CLs such as eviction 408 and minimize evictions for HP CLs such as eviction 404.

[0059] Figure 5 is a block flow diagram showing the processing performed by the cache control circuit in response to a cache fill request according to several embodiments. For example, flow 500 can be executed by the cache control circuit (CCC) 201 in Figure 2. As shown in the figure, flow 500 starts at 501, and the CCC receives a subsequent cache fill request from the requester with requester priority. For example, the requester may be one of the cores 206A, 206B, ... 206N in Figure 2, and the subsequent cache line can be obtained from memory such as memory 115 in Figure 1. The requester priority can reflect the priority assigned to the application running in the requester core. In operation 502, the CCC determines whether there is at least one invalid cache line (CL) in the LLC. If there is, in operation 504, the CCC writes the subsequent CL to the storage location of the invalid cache line, and the flow ends at 505 when the storage location is found. However, if operation 502 indicates that no invalid CLs exist, then in operation 506, the CCC shall determine for each priority in the system the priority (P), the index of the LRU CL with priority P(LRUp), the elapsed time of LRUp, and the number of ways occupied by the priority. In operation 508, the CCC shall determine the requesting priority (P R The system shall determine if the requester priority (O[P R The task is to determine if the number of occupants of ]) is equal to 0. If they are equal, the flow proceeds to operation 524. Here, the subsequent CL(P R To make space for ), a higher priority CL(P H ) will be evicted.

[0060] Operation 524 describes a situation in which a high-priority cache line is evictioned to make room for a lower-priority cache line. This is a situation that the disclosed embodiments strive to avoid as much as possible, except as described above. In some embodiments, a cache monitoring circuit, such as the cache monitoring circuit 203 in Figure 2, maintains a heuristic tracking response to cache fill requests, including instances of operation 524. In some embodiments, the CCC monitors the heuristics and, if necessary, dynamically adjusts the minimum and maximum number of ways assigned to each priority. This adjusts the aggressiveness of higher-priority applications to the eviction of lower-priority applications, which ultimately leads to operation 524. In some embodiments, the cache monitoring circuit 203 causes the LLC to be repartitioned. Or, in some embodiments, if the maintained heuristics, such as the occurrence of operation 524, exceed a predetermined threshold, the cache monitoring circuit causes the boundaries of ways associated with the different priorities to be adjusted. For example, the number of ways assigned to high-priority applications can be reduced to mitigate repeated, aggressive, and complete evictions of lower-priority applications, which would lead to repeated execution of operation 524. If the CCC determines in operation 510 that the number of requesters occupied is not zero, the CCC shall evict the longest unused CL of the requester priority in operation 514.

[0061] Returning to operation 508, if the CCC determines that the requesting priority is not the lowest priority, the CCC will determine in operation 512 whether the number of requests for the requesting priority is at its maximum. If it is, the CCC will evict the requesting priority's longest unused CL in operation 514. The flow ends in operation 515 when the storage location is found.

[0062] Returning to operation 512, if the CCC determines that the number of requestser priority occupants is not the maximum, the CCC determines in operation 516 whether the number of requestser priority occupants is less than the maximum and greater than or equal to the minimum for the requestser priority. If so, the flow proceeds to operation 518; otherwise, the flow proceeds to operation 520. In operation 518, the CCC determines the requestser priority (P R ) or lower priority (P L The CCC attempts to evict any LRU CLs with priority equal to the requester priority, and the flow terminates when a storage location is found at 519. In operation 520, the CCC attempts to evict any LRU CLs with priority lower than the requester priority. If such a line exists, the storage location at 522 is determined to be non-NULL, and the flow moves to 523, where the flow terminates when a storage location is found. If no such CLs exist, the storage location at 522 becomes equal to NULL, and the flow moves to operation 524, where it evicts any LRU CLs with priority higher than the requester priority. The flow terminates when a storage location is found at 525.

[0063] Figure 6 is a flowchart illustrating how a cache fill request is executed by a cache control circuit (CCC) according to several embodiments. For example, flow 600 can be executed by the cache control circuit (CCC) 201 in Figure 2. As shown, in operation 605, the CCC receives a request to store a subsequent cache line (CL) having a requesting priority among several priorities in the last-level cache (LLC). In operation 610, if an invalid cache line (CL) exists in the LLC, the subsequent cache line (CL) is stored in the invalid CL. In operation 615, if the requesting priority has the lowest occupation count of several priorities and one or more occupation counts, or the highest occupation count relative to the requesting priority, the subsequent CL is stored instead of the requesting priority's Least Recently Used (LRU) CL. In operation 620, if the occupation count is between the maximum and minimum for the requesting priority, the subsequent CL is stored instead of the requesting priority's or a lower priority's LRU CL. In operation 625, if there is a CL with a lower priority and an occupancy count less than the minimum, the subsequent CL is stored instead of the LRU CL with the lower priority. In operation 630, if there are no invalid CLs or CLs with the requesting priority or lower, the subsequent CL is stored instead of the LRU CL with a higher priority. [Instruction Set]

[0064] An instruction set may contain one or more instruction formats. A given instruction format may, among other things, determine various fields (e.g., number of bits, bit positions) and / or other data fields (e.g., masks) for specifying the operation to be performed (e.g., opcode) and the operand(s) on which that operation should be performed. Some instruction formats are further classified by the definition of instruction templates (or subformats). For example, an instruction template for a particular instruction format may be defined to have a different subset of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because they include fewer fields), and / or may be defined to have certain fields that are interpreted differently. Thus, each instruction in the ISA is expressed using a particular instruction format (and, if defined, in one of the instruction templates for that instruction format), and includes fields for specifying the operation and operands. For example, an exemplary ADD instruction has an instruction format that includes a specific opcode, an opcode field for specifying that opcode, and an operand field for selecting operands (source 1 / destination / source 2). When this ADD instruction appears in an instruction stream, it will have specific content in the operand field for selecting a specific operand. A set of SIMD extensions that use the Vector Extensions (VEX) coding scheme, referred to as Advanced Vector Extensions (AVX) (AVX1 and AVX2), have been released and / or made public (see, for example, the Intel® 64 and IA-32 Architecture Software Developer's Manual, September 2014 and the Intel® Advanced Vector Extensions Programming Reference, October 2014). [Example command format]

[0065] The embodiments of the instructions described herein may be embodied in different formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Multiple embodiments of the instructions may be executed on multiple such systems, architectures, and pipelines, but are not limited to these details. [General-purpose vector instruction format]

[0066] A vector-oriented instruction format is an instruction format suitable for vector instructions (for example, it has specific fields unique to vector operations). While embodiments that support both vector and scalar operations via a vector-oriented instruction format are described, alternative embodiments that use only vector operations via the vector-oriented instruction format are also described.

[0067] Figures 7A and 7B are block diagrams showing a general-purpose vector instruction format and its instruction templates according to some embodiments of the present invention. Figure 7A is a block diagram showing a general-purpose vector instruction format and its Class A instruction template according to some embodiments of the present invention, while Figure 7B is a block diagram showing a general-purpose vector instruction format and its Class B instruction template according to some embodiments of the present invention. Specifically, the general-purpose vector instruction format 700 defined for Class A and Class B instruction templates includes instruction templates for non-memory access 705 and instruction templates for memory access 720 in both classes. In the context of vector instruction formats, the term general-purpose refers to an instruction format that is not tied to any particular set of instructions.

[0068] Embodiments of the present invention are described, hereof supporting the following instruction formats for vectors: a 64-byte vector operand length (or size) having a 32-bit (4-byte) or 64-bit (8-byte) data element width (or size) (thus a 64-byte vector consists of 16 elements of double-word size, or 8 elements of quad-word size instead); a 64-byte vector operand length (or size) having a 16-bit (2-byte) or 8-bit (1-byte) data element width (or size); a 32-byte vector operand length (or size) having a 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element width (or size); and a 16-byte vector operand length (or size) having a 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element width (or size). Alternative embodiments may support larger vector operand sizes, smaller vector operand sizes, and / or different vector operand sizes (e.g., 256-byte vector operands) having larger data element widths, smaller data element widths, or different data element widths (e.g., 128-bit (16-byte) data element widths).

[0069] The Class A instruction template in Figure 7A includes 1) the non-memory access full-round control type arithmetic 710 instruction template and the non-memory access data conversion type arithmetic 715 instruction template, shown within the non-memory access 705 instruction template, and 2) the memory access temporary 725 instruction template and the memory access non-temporary 730 instruction template, shown within the memory access 720 instruction template. The Class B instruction template in Figure 7B includes 1) the non-memory access write mask control partial-round control type arithmetic 712 instruction template and the non-memory access write mask control VSIZE type arithmetic 717 instruction template, shown within the non-memory access 705 instruction template, and 2) the memory access write mask control 727 instruction template, shown within the memory access 720 instruction template.

[0070] The general-purpose vector instruction format 700 includes the fields shown below in the order shown in Figures 7A and 7B.

[0071] Format field 740 - A specific value in this field (instruction format identifier value) uniquely identifies the occurrence of an instruction in a vector-oriented instruction format, and therefore an instruction in a vector-oriented instruction format within an instruction stream. Therefore, this field is optional in the sense that it is not required for instruction sets that only have a generic vector-oriented instruction format.

[0072] Base calculation field 742: Its content identifies different base calculations.

[0073] Register index field 744: Its contents specify the location of the source and destination operands, whether they reside in registers or memory, either directly or through address generation. These contain a sufficient number of bits to select N registers from P × Q (e.g., 32 × 5¹², 16 × 12⁸, 32 × 10²⁴, 64 × 10²⁴) register files. In one embodiment, N may be up to three source and one destination registers, but alternative embodiments may support more or fewer source and destination registers (e.g., up to two sources may be supported, in which case one of these sources also functions as the destination; up to three sources may be supported, in which case one of these sources also functions as the destination; and up to two sources and one destination may be supported).

[0074] Modifier field 746: Its content distinguishes the occurrence of instructions that specify memory access in the general-purpose vector instruction format from instructions that do not specify memory access. That is, it distinguishes between the non-memory access 705 instruction template and the memory access 720 instruction template. Memory access operations perform reads and / or writes to the memory hierarchy (and in some cases specify source and / or destination addresses using values ​​in registers), while non-memory access operations do not (for example, the source and destination are registers). In one embodiment, this field selects from three separate methods for performing memory address calculations, but alternative embodiments may support more, fewer, or different methods for performing memory address calculations.

[0075] Expansion operation field 750: Depending on its content, in addition to the base operation, it distinguishes which of various different operations is to be executed. This field is specific to the context. In some embodiments, this field is divided into a class field 768, an alpha field 752, and a beta field 754. The expansion operation field 750 enables a common operation group to be performed with a single instruction rather than with two, three, or four instructions.

[0076] Scale field 760: Depending on its content, it enables scaling of the content of the index field for memory address generation (e.g., for address generation using 2 scale* index + base).

[0077] Displacement field 762A: Its content is used as part of memory address generation (e.g., for address generation using 2 scale* index + base + displacement).

[0078] Displacement coefficient field 762B (note that the displacement field 762A is juxtaposed directly above the displacement coefficient field 762B, indicating that one or the other is to be used): Its content is used as part of address generation, which specifies a displacement coefficient to be scaled by the size of the memory access (N). Here, N is the number of bytes in the memory access (e.g., 2 scale*(For address generation using index + base + scaled displacement). The redundant lower bits are ignored, and therefore the contents of the displacement coefficient field are multiplied by the total size (N) of the memory operands to produce the final displacement used in calculating the valid address. The value of N is determined at runtime by the processor hardware based on the full opcode field 774 (described later herein) and the data manipulation field 754C. The displacement field 762A and the displacement coefficient field 762B are not used in the instruction template for non-memory access 705, and / or different embodiments may implement only one of these two, or neither at all, in that sense.

[0079] Data element width field 764: Its content distinguishes which of several data element widths is used (for all instructions in some embodiments, and for only some instructions in other embodiments). This field is optional in the sense that it is not required if only one data element width is supported and / or if the data element width is supported using some aspect of the opcode.

[0080] Write mask field 770: Its content controls whether, for each data element position base, the data element position in the destination vector operand reflects the result of the base and extension operations. Class A instruction templates support merge write masks, while Class B instruction templates support both merge write masks and zeroing write masks. In the case of merge, the vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (specified by the base and extension operations). In another embodiment, if the corresponding mask bit has a value of 0, the old value of each element in the destination is retained. In contrast, in the case of zeroing, the vector mask allows any set of elements in the destination to be zeroed out during the execution of any operation (specified by the base and extension operations). In one embodiment, if the corresponding mask bit has a value of 0, the elements of the destination are set to 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span over which elements are modified, from the first to the last), although the elements being modified do not need to be continuous. Therefore, the write mask field 770 enables partial vector operations, including load, store, arithmetic, and logical operations. While embodiments of the present invention describe the contents of the write mask field 770 as selecting from a plurality of write mask registers that contain the write mask to be used (thus, the contents of the write mask field 770 indirectly identify the masking to be performed), alternative embodiments may alternatively or additionally allow the contents of the write mask field 770 to directly specify the masking to be performed.

[0081] Immediate value field 772: Its content allows for the specification of an immediate value. This field is optional in the sense that it does not exist in implementations of general-purpose vector formats that do not support immediate values, and does not exist in several instructions that do not use immediate values.

[0082] Class field 768: Its content distinguishes between instructions of different classes. Referring to Figures 7A and 7B, the content of this field selects between Class A instructions and Class B instructions. In Figures 7A and 7B, a square with rounded corners is used to indicate the presence of a specific value in the field (for example, in Figures 7A and 7B, for class field 768, Class A 768A and Class B 768B, respectively). [Class A instruction template]

[0083] In the case of a Class A non-memory access 705 instruction template, the alpha field 752 is interpreted as the RS field 752A, which distinguishes which of the different extended arithmetic types is performed (for example, round 752A.1 and data conversion 752A.2 are specified for the non-memory access round type arithmetic 710 and the non-memory access data conversion type arithmetic 715 instruction templates, respectively), while the beta field 754 distinguishes which of the specified types of arithmetic is performed. The non-memory access 705 instruction template does not have a scale field 760, a displacement field 762A, and a displacement coefficient field 762B. [Non-memory access instruction template - Full round control type arithmetic]

[0084] In the non-memory-access full-round-control type arithmetic 710 instruction template, the beta field 754 is interpreted as the round control field 754A, whose contents provide static rounding. In the embodiments described in the present invention, the round control field 754A includes the Suppress All floating-point Exceptions (SAE) field 756 and the round arithmetic control field 758, while alternative embodiments may encode both of these concepts in the same field, or alternative embodiments may have only one or the other of these concepts / fields (for example, only the round arithmetic control field 758).

[0085] SAE field 756: Its contents determine whether or not exception event reporting is disabled. If the contents of SAE field 756 indicate that suppression is enabled, a particular instruction will not report any floating-point exception flags and will not raise a floating-point exception handler.

[0086] The round arithmetic control field 758: Its contents distinguish which of a set of round arithms (e.g., rounding up, rounding down, rounding to zero, and rounding to an approximate value) is performed. Therefore, the round arithmetic control field 758 allows for a change in the round mode on an instruction-by-instruction basis. In some embodiments where the processor includes a control register for specifying the round mode, the contents of the round arithmetic control field 750 override the value of that register. [Non-memory access instruction template - Data conversion type arithmetic]

[0087] In the 715 instruction template for non-memory access data conversion type arithmetic, the beta field 754 is interpreted as the data conversion field 754B, and the content of the data conversion field 754B determines which of several data conversions (e.g., no data conversion, swizzle, broadcast) will be performed.

[0088] In the case of a Class A memory access 720 instruction template, the alpha field 752 is interpreted as an eviction hint field 752B, which distinguishes which of the eviction hints should be used (in Figure 7A, transient 752B.1 and non-transient 752B.2 specify the memory access transient 725 instruction template and the memory access non-transient 730 instruction template, respectively), while the beta field 754 is interpreted as a data operation field 754C, which distinguishes which of several data operation behaviors (also known as primitives) will be performed (e.g., no operation, broadcast, source upconversion, and destination downconversion). The memory access 720 instruction template includes a scale field 760, which optionally includes a displacement field 762A or a displacement coefficient field 762B.

[0089] Vector memory instructions perform vector loading from and vector storing to memory with translation support. As with regular vector instructions, vector memory instructions transfer data from / to memory in whole data elements, and the elements actually transferred are described by the contents of a vector mask selected as the write mask. [Memory access instruction template: temporary]

[0090] Temporary data is data that is likely to be reused quickly enough to benefit from caching. However, this is a hint, and different processors may implement it in different ways, including completely ignoring the hint. [Memory access instruction template: non-temporary]

[0091] Non-transient data is data that is unlikely to be reused quickly enough to benefit from being cached in the first-level cache, and therefore should be given eviction priority. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely. [Class B instruction template]

[0092] In the case of a Class B instruction template, the alpha field 752 is interpreted as the write mask control (Z) field 752C, and the contents of the write mask control (Z) field 752C distinguish whether the write masking controlled by the write mask field 770 should be merging or zeroing.

[0093] In the case of a Class B non-memory access 705 instruction template, a portion of the beta field 754 is interpreted as the RL field 757A, which distinguishes which of the different extended arithmetic types is performed (for example, round 757A.1 and vector length (VSIZE) 757A.2 are specified for the non-memory access write mask control partial round control type arithmetic 712 instruction template and the non-memory access write mask control VSIZE type arithmetic 717 instruction template, respectively), while the remainder of the beta field 754 distinguishes which of the specified types of arithmetic is performed. The non-memory access 705 instruction template does not have a scale field 760, a displacement field 762A, and a displacement coefficient field 762B.

[0094] In the non-memory access write mask control partial round control type arithmetic 712 instruction template, the remainder of the beta field 754 is interpreted as the round arithmetic field 759A, and exception event reporting is disabled (certain instructions do not report any floating-point exception flags and do not raise floating-point exception handlers).

[0095] Round operation control field 759A: Similar to round operation control field 758, its contents distinguish which of a set of round operations will be performed (e.g., round up, round down, round to zero, and round to an approximate value). Thus, round operation control field 759A allows for changing the round mode on an instruction-by-instruction basis. In some embodiments, if the processor includes a control register for specifying the round mode, the contents of round operation control field 750 override the value of that register.

[0096] In the non-memory access write mask control VSIZE type arithmetic instruction template 717, the remainder of the beta field 754 is interpreted as the vector length field 759B, and the contents of the vector length field 759B determine which of several data vector lengths (e.g., 128, 256, or 512 bytes) the operation will be performed with.

[0097] In the case of a Class B memory access 720 instruction template, a portion of the beta field 754 is interpreted as a broadcast field 757B, whose content determines whether or not a broadcast-type data operation is performed, while the remainder of the beta field 754 is interpreted as a vector length field 759B. The memory access 720 instruction template includes a scale field 760 and optionally includes a displacement field 762A or a displacement coefficient field 762B.

[0098] For the general-purpose vector instruction format 700, the full opcode field 774 is shown to include the format field 740, the base arithmetic field 742, and the data element width field 764. One embodiment is shown in which the full opcode field 774 includes all of these fields, but in embodiments that do not support all of these fields, the full opcode field 774 includes fewer fields than all of these fields. The full opcode field 774 provides the arithmetic code (opcode).

[0099] The extended arithmetic field 750, the data element width field 764, and the write mask field 770 enable these features to be specified on a per-instruction basis in the instruction format for general-purpose vectors.

[0100] The combination of the write mask field and the data element width field forms a typed instruction in that they allow the mask to be applied based on different data element widths.

[0101] The various instruction templates found within Class A and Class B are beneficial in different situations. In some embodiments of the present invention, multiple different processors or different cores within a given processor may support only Class A, only Class B, or both. For example, a high-performance general-purpose out-of-order core for general-purpose computing may support only Class B, a core primarily for graphics and / or scientific (throughput) computing may support only Class A, and a core for both may support both (of course, a core that has some combination of templates and instructions from both classes but does not have all templates and instructions from both classes is within the scope of the present invention). Also, a single processor may include multiple cores, all of which may support the same class, or different cores among them may support different classes. For example, in a processor having separate graphics cores and general-purpose cores, one of the graphics cores, primarily for graphics and / or scientific computing, may support only Class A, while one or more of the general-purpose cores may be high-performance general-purpose cores using out-of-order execution and register renaming for general-purpose computing that support only Class B. Another processor without a separate graphics core may include one or more general-purpose in-order or out-of-order cores that support both Class A and Class B. Of course, in different embodiments of the present invention, functions belonging to one class may be implemented in the other class. Multiple programs written in a high-level language may be made into various different executable formats, including 1) a form having only instructions of a class supported by the target processor for execution, or 2) a form having multiple alternative routines written using different combinations of instructions of all classes, and having control flow code that selects one of the routines to execute based on the instructions supported by the processor currently executing the code (e.g., compiled just-in-time or statically). [Example instruction format for specific vectors]

[0102] Figure 8A is a block diagram illustrating an exemplary instruction format for a specific vector according to several embodiments of the present invention. Figure 8A shows an instruction format for a specific vector 800, which is specific in that it specifies the position, size, interpretation, and order of the fields, as well as the values ​​for some of these fields. The instruction format for a specific vector 800 may be used to extend an x86 instruction set, and some of its fields are similar to or identical to fields used in existing x86 instruction sets and their extensions (e.g., AVX). This format maintains consistency with the prefix coding fields, real opcode byte fields, MOD R / M fields, SIB fields, displacement fields, and immediate value fields of existing x86 instruction sets with some extensions. Fields from Figure 7A or Figure 7B to which fields from Figure 8A are mapped are illustrated.

[0103] Although embodiments of the present invention are described for illustrative purposes with respect to the specific vector instruction format 800 in light of the general vector instruction format 700, it should be understood that the present invention is not limited to the specific vector instruction format 800 unless otherwise claimed. For example, while the specific vector instruction format 800 is shown to have fields of a specific size, the general vector instruction format 700 assumes various possible sizes for various fields. In a particular embodiment, the data element width field 764 is shown as a 1-bit field in the specific vector instruction format 800, but this does not limit the present invention (i.e., the general vector instruction format 700 assumes data element width fields 764 of other sizes).

[0104] The instruction format 800 for a specific vector includes the following fields listed below in the order shown in Figure 8A:

[0105] EVEX prefix (bytes 0-3) 802. This is encoded in 4-byte format.

[0106] Format field 740 (EVEX byte 0, bits [7:0]). The first byte (EVEX byte 0) is the format field 740, which contains 0 × 62 (a unique value used in some embodiments to distinguish the instruction format for vectors).

[0107] The second to fourth bytes (EVEX bytes 1-3) contain multiple bit fields that provide specific functions.

[0108] REX field 805 (EVEX byte 1, bits [7-5]): consists of the EVEX.R bit field (EVEX byte 1, bits [7]-R), the EVEX.X bit field (EVEX byte 1, bits [6]-X), and the EVEX.B bit field (EVEX byte 1, bits [5]-B). The EVEX.R bit field, EVEX.X bit field, and EVEX.B bit field provide the same functionality as the corresponding VEX bit field, and they are encoded using one's complement form, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of the instruction encode the lower three bits of the register index (rrr, xxx, and bbb), as is known in the art, so Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.

[0109] REX'810A: This is the first part of the REX' field 810, the EVEX.R' bit field (EVEX byte 1, bit [4]-R') used to encode either the upper or lower 16 of the extended 32 register set. In some embodiments, this bit, along with others shown below, is stored in a bit-inverted format to distinguish it from the BOUND instruction (in the well-known x86 32-bit mode). The real opcode byte for the BOUND instruction is 62, but within the MOD R / M field (described later), it does not accept the value 11 for the MOD field. Alternative embodiments of the invention do not store this bit and the other bits described later in an inverted format. The value 1 is used to encode the lower 16 registers. In other words, EVEX.R', EVEX.R and the other RRRs of the other fields are combined to form R'Rrrr.

[0110] Opcode map field 815 (EVEX byte 1, bits [3:0]-mmmm): Its contents encode the suggested leading opcode byte (0F, 0F38, or 0F3).

[0111] The data element width field 764 (EVEX bytes 2, bits[7]-W) is represented by the notation EVEX.W. EVEX.W is used to specify the granularity (size) of the data type (32-bit data element or 64-bit data element).

[0112] EVEX.vvvv field 820 (EVEX byte 2, bits [6:3]-vvvv). The role of EVEX.vvvv may include: 1) EVEX.vvvv encodes the first source register operand in a specified inverted (one's complement) form, and EVEX.vvvv is valid for instructions with two or more source operands. 2) EVEX.vvvv encodes the destination register operand in a specified one's complement form for a particular vector shift. Or 3) EVEX.vvvv does not encode any operands, and the field is reserved and should contain 1111b. Thus, EVEX.vvvv field 820 encodes the four lower bits of the first source register specifier stored in inverted (one's complement) form. Depending on the instruction, additional different EVEX bit fields are used to extend the specifier size to 32 registers.

[0113] EVEX.U 768 class field (EVEX byte 2, bit[2]-U): If EVEX.U=0, it indicates class A or EVEX.U0. If EVEX.U=1, it indicates class B or EVEX.U1.

[0114] Prefix encoding field 825 (EVEX byte 2, bit [1:0]-pp): Provides additional bits for the base arithmetic field. In addition to providing support for legacy SSE instructions in the EVEX prefix format, this also has the advantage of compacting SIMD prefixes (instead of requiring one byte to represent a SIMD prefix, an EVEX prefix requires only two bits). In one embodiment, to support legacy SSE instructions using SIMD prefixes (66H, F2H, F3H) in both the legacy and EVEX prefix formats, these legacy SIMD prefixes are encoded in the SIMD prefix encoding field. These legacy SIMD prefixes are extended to legacy SIMD prefixes at runtime before being provided to the decoder's PLA (thus the PLA can execute both the legacy and EVEX formats of these legacy instructions without modification). While newer instructions can directly use the contents of the EVEX prefix coding field as an opcode extension, certain embodiments allow for different means specified by these legacy SIMD prefixes, extending them in a similar manner for consistency. Alternative embodiments could redesign the PLA to support 2-bit SIMD prefix coding and therefore require no extension.

[0115] Alpha field 752 (EVEX byte 3, bit [7]-EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.writemaskcontrol, and EVEX.N; also denoted as α): As previously mentioned, this field is context-specific.

[0116] Beta field 754 (EVEX byte 3, bits [6:4] - SSS. EVEX.S 2-0 EVEX.r 2-0 Also known as EVEX.rr1, EVEX.LL0, and EVEX.LLB. (Also denoted as βββ): As mentioned earlier, this field is context-specific.

[0117] REX'810B. This is the remainder of REX' field 810, which is the EVEX.V' bit field (EVEX byte 3, bit[3]V') that can be used to encode either the upper 16 or lower 16 of the extended set of 32 registers. This bit is stored in a bit-inverted format. The value 1 is used to encode the lower 16 registers. In other words, by combining EVEX.V' and EVEX.vvvv, V'VVVV' is formed.

[0118] The write mask field 770 (EVEX byte 3, bits [2:0]-kkk): its contents specify the register index in the write mask register, as described above. In some embodiments, a specific value EVEX.kkk=000 has special behavior that implies that no write mask is used for a particular instruction (this may be implemented in various ways, including the use of a write mask hardwired to all 1s or the use of hardware that bypasses masking hardware).

[0119] The real opcode field 830 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0120] The MOD R / M field 840 (byte 5) contains the MOD field 842, the Reg field 844, and the R / M field 846. As described above, the contents of the MOD field 842 distinguish between memory access operations and non-memory access operations. The role of the Reg field 844 can be summarized into two situations: encoding either a destination register operand or a source register operand, or being treated as an opcode extension and not used to encode instruction operands. The role of the R / M field 846 may include encoding an instruction operand that references a memory address, or encoding either a destination register operand or a source register operand.

[0121] The scale, index, base (SIB) byte 850 (byte 6) contains SS852 related to the scale. As previously mentioned, the scale field 760 is used for memory address generation. SIB.xxx854 and SIB.bbb856. The contents of these fields have already been described with respect to register indices Xxxx and Bbbb.

[0122] Displacement field 762A (bytes 7-10): If MOD field 842 contains 10, then bytes 7-10 are displacement field 762A, which functions the same as legacy 32-bit displacement (disp32) but works at byte granularity.

[0123] Displacement coefficient field 762B (byte 7): If the MOD field 842 contains 01, then byte 7 is the displacement coefficient field 762B. The location of this field is the same as that of the 8-bit displacement (disp8) of the legacy x86 instruction set, which operates at byte granularity. Since disp8 is sign-extended, disp8 can only address between -128 and 127 byte offsets. For 64-byte cache lines, disp8 uses 8 bits that can only be set to four actually useful values: -128, -64, 0, and 64. Usually, a wider range is needed, so disp32 is used, but disp32 requires 4 bytes. In contrast to disp8 and disp32, the displacement coefficient field 762B is a reinterpretation of disp8. When using the displacement coefficient field 762B, the actual displacement is determined by the contents of the displacement coefficient field multiplied by the size of the memory operand access (N). This type of displacement is referred to as disp8*N. This reduces the average instruction length (although a single byte is used for displacement, it involves an extremely large range). Such compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and therefore the redundant lower bits of the address offset do not need to be encoded. In other words, the displacement coefficient field 762B replaces the 8-bit displacement of the legacy x86 instruction set. Thus, the displacement coefficient field 762B is encoded in the same way as the 8-bit displacement of the x86 instruction set (and therefore there are no changes to the ModRM / SIB encoding rules), with the sole exception that disp8 is overloaded to disp8*N. In short, there are no changes to the encoding rules or encoded length, only to how the hardware interprets the displacement value (the hardware needs to scale the displacement by the size of the memory operand to obtain the byte-by-byte address offset). The immediate value field 772 performs the operations as described above. [Full operation code field]

[0124] Figure 8B is a block diagram showing the fields that constitute the full opcode field 774 of a specific vector instruction format 800 according to several embodiments. Specifically, the full opcode field 774 includes a format field 740, a base calculation field 742, and a data element width (W) field 764. The base calculation field 742 includes a prefix coding field 825, an opcode map field 815, and a real opcode field 830. [Register Index Field]

[0125] Figure 8C is a block diagram showing the fields that make up the register index field 744 of a specific vector instruction format 800 according to several embodiments. Specifically, the register index field 744 includes the REX field 805, the REX' field 810, the MODR / M.reg field 844, the MODR / Mr / m field 846, the VVVV field 820, the xxx field 854, and the bbb field 856. [Extended calculation field]

[0126] Figure 8D is a block diagram showing the fields constituting the extended arithmetic field 750 of the instruction format 800 for a specific vector according to one embodiment of the present invention. If the class(U) field 768 contains 0, it represents EVEX.U0 (class A 768A). If the class(U) field 768 contains 1, it represents EVEX.U1 (class B 768B). If U=0 and the MOD field 842 contains 11 (meaning non-memory access operation), the alpha field 752 (EVEX byte 3, bit [7]-EH) is interpreted as the rs field 752A. If the rs field 752A contains 1 (round 752A.1), the beta field 754 (EVEX byte 3, bit [6:4]SSS) is interpreted as the round control field 754A. The round control field 754A includes a 1-bit SAE field 756 and a 2-bit round arithmetic field 758. If the rs field 752A contains 0 (data conversion 752A.2), the beta field 754 (EVEX byte 3, bit [6:4]SSS) is interpreted as a 3-bit data conversion field 754B. If U=0 and the MOD field 842 contains 00, 01, or 10 (meaning a memory access operation), the alpha field 752 (EVEX byte 3, bit [7]-EH) is interpreted as an eviction hint (EH) field 752B, and the beta field 754 (EVEX byte 3, bit [6:4]SSS) is interpreted as a 3-bit data manipulation field 754C.

[0127] If U=1, the alpha field 752 (EVEX byte 3, bit [7]-EH) is interpreted as the write mask control (Z) field 752C. If U=1 and the MOD field 842 contains 11 (meaning non-memory access operation), a portion of the beta field 754 (EVEX byte 3, bit [4]S0) is interpreted as the RL field 757A. If the RL field 757A contains 1 (round 757A.1), the remainder of the beta field 754 (EVEX byte 3, bit [6-5]S 2-1) is interpreted as round arithmetic field 759A, while if RL field 757A contains 0 (VSIZE 757.A2), the remainder of beta field 754 (EVEX byte 3, bit [6-5]S) 2-1 ) is a vector-length field 759B (EVEX bytes 3, bits [6-5]L 1-0 ) is interpreted as follows: If U=1 and MOD field 842 contains 00, 01 or 10 (meaning a memory access operation), then beta field 754 (EVEX byte 3, bit [6:4]SSS) is the vector length field 759B (EVEX byte 3, bit [6-5]L 1-0 ) and is interpreted as broadcast field 757B (EVEX byte 3, bit [4]B). [Exemplary Register Architecture]

[0128] Figure 9 is a block diagram of the register architecture 900 according to several embodiments. The illustrated embodiments have 32 vector registers 910, each 512 bits wide. These registers are referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers overlap with registers ymm0 to ymm15. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) overlap with registers xmm0 to xmm15. The instruction format 800 for a specific vector operates on these overlapping register files as shown in the table below. [Table 2]

[0129] In other words, the vector length field 759B is selected between a maximum length and one or more other shorter lengths, each of which is half the length of the preceding length, and instruction templates without the vector length field 759B perform operations on the maximum vector length. Furthermore, in one embodiment, a Class B instruction template of instruction format 800 for a particular vector performs operations on packed single-precision / double-precision floating-point data or scalar single-precision / double-precision floating-point data and packed integer data or scalar integer data. Scalar operations are performed at the least significant data element positions in the zmm / ymm / xmm registers, while the higher data element positions are left as they were before the instruction or zeroed out, depending on the embodiment.

[0130] In the illustrated embodiment, the write mask register 915 has eight write mask registers (k0 to k7), each with a size of 64 bits. In an alternative embodiment, the write mask register 915 has a size of 16 bits. As described above, in some embodiments, the vector mask register k0 cannot be used as a write mask. When the encoding that normally represents k0 is used as the write mask, it selects a hardwired write mask of 0xffff and effectively disables write masking for that instruction.

[0131] In the illustrated embodiment, the general-purpose register 925 contains 16 64-bit general-purpose registers used in conjunction with the existing x86 addressing mode to address memory operands. These registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0132] In the illustrated embodiment, the scalar floating-point stack register file (x87 stack) 945 is shown with the alias MMX packed integer flat register file 950. The x87 stack is an 8-element stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions. MMX registers are used to perform operations on 64-bit packed integer data, but are also used to hold operands for some operations performed between MMX and XMM registers.

[0133] Alternative embodiments may use wider or narrower registers. In addition, alternative embodiments may use more, fewer, or different register files and registers. [Embodimental core architectures, processors, and computer architectures]

[0134] Processor cores may be implemented in different ways and for different purposes in different processors. For example, such core implementations may include: 1) a general-purpose in-order core for general-purpose computing; 2) a high-performance general-purpose out-of-order core for general-purpose computing; and 3) a dedicated core primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) a CPU containing one or more general-purpose in-order cores and / or one or more general-purpose out-of-order cores for general-purpose computing, and 2) a coprocessor containing one or more dedicated cores primarily for graphics and / or scientific (throughput) computing. Such different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; and 3) a coprocessor on the same die as the CPU (in this case, such a coprocessor may also be called a dedicated logic, or dedicated core, such as integrated graphics and / or scientific (throughput) logic). 4) A system-on-a-chip that may include the CPU (sometimes called application cores or application processors) listed on the same die, the coprocessors mentioned above, and additional functions. An exemplary core architecture is described below, followed by a description of exemplary processor and computer architectures. [Example Core Architecture] [Block diagrams of in-order core and out-of-order core]

[0135] Figure 10A is a block diagram illustrating exemplary in-order pipelines and exemplary register renaming, as well as both out-of-order issue / execution pipelines, according to some embodiments of the present invention. Figure 10B is a block diagram illustrating exemplary embodiments of in-order architecture cores and exemplary register renaming, as well as both out-of-order issue / execution architecture cores, included in a processor, according to some embodiments of the present invention. The boxes shown with solid lines in Figures 10A and 10B illustrate in-order pipelines and in-order cores. On the other hand, any additional boxes shown with dashed lines illustrate register renaming, out-of-order issue / execution pipelines and cores. Out-of-order embodiments will be described because in-order embodiments are a subset of out-of-order embodiments.

[0136] In Figure 10A, the processor pipeline 1000 includes a fetch stage 1002, a length decoding stage 1004, a decoding stage 1006, an allocation stage 1008, a renaming stage 1010, a scheduling (also known as distribution or issue) stage 1012, a register read / memory read stage 1014, an execution stage 1016, a write-back / memory write stage 1018, an exception handling stage 1022, and a commit stage 1024.

[0137] Figure 10B shows a processor core 1090 including a front-end unit 1030 coupled to an execution engine unit 1050, both coupled to a memory unit 1070. Core 1090 may be a reduced instruction set computing (RISC) core, a composite instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Further options include dedicated cores such as a network or communications core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, or a graphics core.

[0138] The front-end unit 1030 includes a branch prediction unit 1032 coupled to an instruction cache unit 1034, the instruction cache unit 1034 coupled to an instruction translation lookaside buffer (TLB) 1036, the instruction translation lookaside buffer (TLB) 1036 coupled to an instruction fetch unit 1038, and the instruction fetch unit 1038 coupled to a decoding unit 1040. The decoding unit 1040 (i.e., decoder) may decode an instruction and may produce one or more microoperations, microcode entry points, microinstructions, other instructions or other control signals as outputs, which are decoded from the original instruction, reflect the original instruction, or are derived from the original instruction. The decoding unit 1040 may be implemented using a variety of different mechanisms. Examples of preferred mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), and microcode read-on rememory (ROMs). In one embodiment, the core 1090 includes a microcode ROM or other medium for storing microcode for specific macro instructions (for example, in the decoding unit 1040, or otherwise in the front-end unit 1030). The decoding unit 1040 is coupled to a rename / allocator unit 1052 in the execution engine unit 1050.

[0139] The execution engine unit 1050 includes a rename / allocator unit 1052 coupled with a retirement unit 1054 and a set of one or more scheduler units 1056. The scheduler units 1056 represent any number of different schedulers, including multiple reservation stations, a central instruction window, etc. The scheduler units 1056 are coupled with physical register file units 1058. Each of the physical register file units 1058 represents one or more physical register files, each of which stores one or more different data types. Such types include scalar integers, scalar floating-point numbers, packed integers, packed floating-point numbers, vector integers, vector floating-point numbers, and states (e.g., instruction pointers, which are the addresses of the next instruction to be executed). In one embodiment, the physical register file unit 1058 comprises multiple vector register units, a write mask register unit, and a scalar register unit. These register units may provide the architecture's vector registers, vector mask registers, and general-purpose registers. The physical register file unit 1058 overlaps with the retirement unit 1054 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using reorder buffers and retirement register files, using future files, history buffers, and retirement register files (or more)), using multiple register maps and register pools, etc. The retirement unit 1054 and the physical register file unit(s) 1058 are joined to an execution cluster(s) 1060. The execution cluster 1060 contains one or more sets of execution units 1062 and one or more sets of memory access units 1064. The execution units 1062 may perform various operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar floating-point, packed integers, packed floating-point, vector integers, vector floating-point).Some embodiments may include multiple execution units dedicated to a particular function or set of functions, while other embodiments may include only one execution unit or multiple execution units, all of which perform all functions. The scheduler unit 1056, physical register file unit 1058, and execution cluster 1060 are shown as multiple because certain embodiments form separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / packed integer / packed floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines. Each of these has its own scheduler unit, physical register file unit, and / or execution cluster. In the case of a separate memory access pipeline, a particular embodiment implements only the execution cluster of this pipeline having memory access unit(s) 1064). It should also be understood that when separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0140] A set of multiple memory access units 1064 is coupled to a memory unit 1070, which includes a data TLB unit 1072 coupled to a data cache unit 1074, which in turn is coupled to a level 2 (L2) cache unit 1076. In one exemplary embodiment, the memory access units 1064 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 1072 of the memory unit 1070. An instruction cache unit 1034 is further coupled to the level 2 (L2) cache unit 1076 of the memory unit 1070. The L2 cache unit 1076 is coupled to one or more other levels of caches and ultimately to main memory.

[0141] As an example, the exemplary register renaming, out-of-order issue / execution core architecture may implement pipeline 1000 as follows: 1) The instruction fetch unit 1038 executes the fetch stage 1002 and the length decoding stage 1004; 2) The decoding unit 1040 executes the decoding stage 1006; 3) The rename / allocator unit 1052 executes the allocation stage 1008 and the renaming stage 1010; 4) The scheduler unit 1056 executes the scheduling stage 1012; 5) The physical register file unit 1058 and the memory unit 1070 execute the register read / memory read stage 1014, and the execution cluster 1060 executes the execution stage 1016; 6) The memory unit 1070 and the physical register file unit 1058 execute the write-back / memory write stage 1018; 7) Various units may be involved in the exception handling stage 1022; and 8) The retirement unit 1054 and the physical register file unit 1058 execute the commit stage 1024.

[0142] The core 1090 may support one or more instruction sets, including the instructions described herein (for example, the x86 instruction set (with several extensions, including newer versions), the MIPS instruction set from MIPS Technologies in Sunnyvale, California, and the ARM instruction set from ARM Holdings in Sunnyvale, California (with any additional extensions such as NEON)). In one embodiment, the core 1090 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby enabling multiple operations used by many multimedia applications to be performed using packed data.

[0143] The core supports multithreading (execution of two or more parallel sets of operations or threads) and can support it in various ways, including time-slice multithreading, concurrent multithreading (where a single physical core provides a logical core for each thread that a physical core is simultaneously multithreading), or a combination thereof (e.g., time-slice fetch and decryption and subsequent concurrent multithreading in Intel® Hyper-Threading Technology).

[0144] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may also be used in in-order architectures. The illustrated embodiment of the processor may also include separate instruction cache unit 1034 and data cache unit 1074, as well as a shared L2 cache unit 1076, but several alternative embodiments may have a single internal cache for both instructions and data, such as a level 1 (L1) internal cache or a multi-level internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache located outside the core and / or processor. Alternatively, all of the cache may be located outside the core and / or processor. [Specific Exemplary In-Order Core Architectures]

[0145] Figures 11A and 11B show block diagrams of a more specific example of an in-order core architecture, where a core would be one of several logic blocks within the chip (including other cores of the same and / or different types). Depending on the application, the logic blocks communicate with several fixed-function logics, memory I / O interfaces, and other necessary I / O logics through a high-bandwidth interconnect network (e.g., a ring network).

[0146] Figure 11A is a block diagram of a single processor core, according to some embodiment of the present invention, which includes a connection to an on-die interconnect network 1102 and a local subset 1104 of a Level 2 (L2) cache. In one embodiment, the instruction decoder 1100 supports the x86 instruction set using a packed data instruction set extension. The L1 cache 1106 enables low-latency access to the cache memory within the scalar and vector units. In one embodiment, (for the sake of design simplification) the scalar unit 1108 and the vector unit 1110 use separate register sets (a number of scalar registers 1112 and a number of vector registers 1114, respectively), and the data transferred between them is written to and read from the memory of the Level 1 (L1) cache 1106; however, several alternative embodiments of the present invention may use different approaches (e.g., using a single register set, or including a communication path that allows data transfer between two register files without writing and reading).

[0147] The local subset 1104 of the L2 cache is part of the global L2 cache, which is divided into separate local subsets, one per processor core. Each processor core has a direct path to its own local subset 1104 of the L2 cache. Data read by a processor core is stored in its L2 cache subset 1104, and this data is readily accessible in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1104 and is flushed from other subsets when necessary. The ring network ensures coherence for shared data. The ring network is bidirectional, allowing agents such as processor cores, L2 caches, and other logical blocks to communicate with each other within the chip. Each ring data path is 10¹² bits wide in each direction.

[0148] Figure 11B is a magnified view of a portion of the processor core in Figure 11A according to some embodiments of the present invention. Figure 11B includes the L1 data cache 1106A, which is part of the L1 cache 1106, as well as more detailed aspects of the vector unit 1110 and the vector register 1114. Specifically, the vector unit 1110 is a 16-width vector processing unit (VPU) (see 16-width ALU 1128) that executes one or more of integer instructions, single-precision floating instructions, and double-precision floating instructions. The VPU supports swizzling of register inputs using the swizzle unit 1120, numerical conversion using numerical conversion units 1122A and 1122B, and replication using the replication unit 1124 on memory inputs. The write mask register 1126 allows prediction of the resulting vector writes.

[0149] Figure 12 is a block diagram of a processor 1200 according to some embodiments of the present invention, which may have two or more cores, an integrated memory controller, and integrated graphics. The solid box in Figure 12 illustrates a processor 1200 comprising a single core 1202A, a system agent unit 1210, and a set of one or more bus controller units 1216. The dashed box illustrates an optional additional processor 1200 comprising multiple cores 1202A to 1202N, a set of one or more integrated memory controller units 1214 within the system agent unit 1210, and dedicated logic 1208.

[0150] Therefore, different implementations of processor 1200 may include: 1) a CPU in which dedicated logic 1208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and cores 1202A to 1202N are one or more general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, or a combination of the two); 2) a coprocessor in which cores 1202A to 1202N are numerous dedicated cores primarily used for graphics and / or scientific (throughput); and 3) a coprocessor in which cores 1202A to 1202N are numerous general-purpose in-order cores. Thus, processor 1200 may be a general-purpose processor, coprocessor, or dedicated processor, such as a network processor or communications processor, a compression engine, a graphics processor, a GPGPU (general-purpose graphics processing unit), a high-throughput multi-integrated core (MIC) coprocessor (including 30 or more cores), or an embedded processor. The processor may be implemented on one or more chips. The processor 1200 may be part of and / or mounted on one or more substrates, using, for example, one of several process technologies such as BiCMOS, CMOS, or NMOS.

[0151] The memory hierarchy includes one or more levels of cache within the core, a set of one or more shared cache units 1206, and external memory (not shown) coupled to a set of integrated memory controller units 1214. The set of shared cache units 1206 may include one or more intermediate level caches, last level caches (LLCs), and / or combinations thereof, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of cache. In one embodiment, a ring-based interconnection unit 1212 interconnects the integrated graphics logic 1208 (which is an example of dedicated logic and is also referred to herein as dedicated logic), the set of shared cache units 1206, and the system agent unit 1210 / integrated memory controller unit 1214, while alternative embodiments may use any number of known techniques for interconnecting such units. In one embodiment, coherency is maintained between one or more cache units 1206 and cores 1202A-1202N.

[0152] In some embodiments, one or more of the cores 1202A to 1202N are capable of multithreading. The system agent unit 1210 includes these components for coordinating and operating the cores 1202A to 1202N. The system agent unit 1210 may also include, for example, a power control unit (PCU) and a display unit. The PCU may be, or include, the logic and several components required to coordinate the power states of the cores 1202A to 1202N and the integrated graphics logic 1208. The display unit is for driving one or more externally connected displays.

[0153] Cores 1202A through 1202N may be homogeneous or heterogeneous in terms of their architectural instruction sets. That is, two or more of the cores 1202A through 1202N may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set. [Embodimentary computer architecture]

[0154] Figures 13–16 are block diagrams of exemplary computer architectures. Other system designs and configurations known in the art are also suitable for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices. Generally, a wide variety of systems or electronic devices that can incorporate the processors and / or other execution logic disclosed herein are generally suitable.

[0155] Referring now to Figure 13, a block diagram of a system 1300 according to one embodiment of the present invention is shown. The system 1300 may include one or more processors 1310, 1315 coupled to a controller hub 1320. In one embodiment, the controller hub 1320 includes a graphics memory controller hub (GMCH) 1390 and an input / output hub (IOH) 1350 (which may be on a separate chip), the GMCH 1390 includes a memory controller and a graphics controller to which memory 1340 and a coprocessor 1345 are coupled, and the IOH 1350 couples input / output (I / O) devices 1360 to the GMCH 1390. Alternatively, one or both of the memory controller and the graphics controller may be integrated within a processor (as described herein), and the memory 1340 and coprocessor 1345 may be directly coupled to the controller hub 1320 in a single chip having processor 1310 and IOH 1350.

[0156] The optional nature of the additional processor 1315 is shown by a dashed line in Figure 13. Each processor 1310, 1315 may include one or more of the processing cores described herein and may be any version of processor 1200.

[0157] The memory 1340 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of the two. In at least one embodiment, the controller hub 1320 communicates with the processors 1310, 1315 via a multidrop bus such as a front-side bus (FSB), a point-to-point interface such as a QuickPath interconnect (QPI), or a similar connection 1395.

[0158] In one embodiment, the coprocessor 1345 is a dedicated processor such as a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, or an embedded processor. In one embodiment, the controller hub 1320 may include an integrated graphics accelerator.

[0159] There can be a variety of differences between physical resources 1310 and 1315 in terms of various criteria for advantages, including architectural, microarchitectural, thermal, and power consumption characteristics.

[0160] In one embodiment, the processor 1310 executes a number of instructions that control a general type of data processing operation. Coprocessor instructions may be incorporated within these instructions. The processor 1310 recognizes these coprocessor instructions as the type that should be executed by the attached coprocessor 1345. Therefore, the processor 1310 issues these coprocessor instructions (or a number of control signals representing a number of coprocessor instructions) to the coprocessor 1345 over the coprocessor bus or other interconnect. The coprocessor 1345 accepts and executes the received coprocessor instructions.

[0161] Referring here to Figure 14, a block diagram of a first more specific exemplary system 1400 is shown according to one embodiment of the present invention. As shown in Figure 14, the multiprocessor system 1400 is a point-to-point interconnection system and includes a first processor 1470 and a second processor 1480 coupled via a point-to-point interconnection 1450. Each of the processors 1470 and 1480 may be several versions of processor 1200. In some embodiments of the present invention, processors 1470 and 1480 are processors 1310 and 1315, respectively, while coprocessor 1438 is coprocessor 1345. In other embodiments, processors 1470 and 1480 are processor 1310 and coprocessor 1345, respectively.

[0162] Processors 1470 and 1480 are shown to include integrated memory controller (IMC) units 1472 and 1482, respectively. Processor 1470 also includes point-to-point (PP) interfaces 1476 and 1478 as part of its bus controller unit, and similarly, the second processor 1480 includes PP interfaces 1486 and 1488. Processors 1470 and 1480 may exchange information via point-to-point (PP) interface 1450 using PP interface circuits 1478 and 1488. As shown in Figure 14, IMCs 1472 and 1482 connect the processors to their respective memories, namely memory 1432 and memory 1434. Memory 1432 and memory 1434 may be part of the main memory locally attached to each processor.

[0163] Processors 1470 and 1480 may exchange information with chipset 1490 via their respective PP interfaces 1452 and 1454, using point-to-point interface circuits 1476, 1494, 1486, and 1498, respectively. Chipset 1490 may optionally exchange information with coprocessor 1438 via high-performance interface 1492. In one embodiment, coprocessor 1438 is a dedicated processor such as a high-throughput MIC processor, network processor or communication processor, compression engine, graphics processor, GPGPU or embedded processor.

[0164] A shared cache (not shown) is located either outside the processor or outside both processors already connected to the processor via a PP interconnect, and as a result, when the processor is put into low-power mode, the local cache information of either or both processors may be stored in the shared cache.

[0165] The chipset 1490 may be coupled to the first bus 1416 via interface 1496. In one embodiment, the first bus 1416 may be a Peripheral Component Interconnection (PCI) bus, a PCI Express bus, or another third-generation I / O interconnection bus, but the scope of the present invention is not limited thereto.

[0166] As shown in Figure 14, various I / O devices 1414 may be coupled to the first bus 1416 along with a bus bridge 1418 that connects the first bus 1416 to the second bus 1420. In one embodiment, one or more additional processors 1415, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or a digital signal processing (DSP) unit), a field-programmable gate array, or any other processor, are coupled to the first bus 1416. In one embodiment, the second bus 1420 may be a low-pin-count (LPC) bus. In one embodiment, various devices, such as a keyboard and / or mouse 1422, a communication device 1427, and a storage unit 1428, such as a disk drive or other mass storage device that may contain multiple instructions / codes and data 1430, may be coupled to the second bus 1420. Furthermore, audio I / O 1424 may be coupled to the second bus 1420. It should be noted that other architectures are also possible. For example, instead of the point-to-point architecture in Figure 14, the system could implement a multidrop bus or other such architectures.

[0167] Referring now to Figure 15, a block diagram of a second, more specific exemplary system 1500 is shown according to one embodiment of the present invention. Identical elements in Figures 14 and 15 have multiple identical reference numerals, and certain aspects of Figure 14 are omitted from Figure 15 to avoid obscuring other aspects of Figure 15.

[0168] Figure 15 shows that processors 1470 and 1480 may include integrated memory and I / O control logic ("CL") 1572 and 1582, respectively. Thus, CLs 1572 and 1582 include an integrated memory controller unit and I / O control logic. Figure 15 shows that not only memories 1432 and 1434 are coupled to CLs 1572 and 1582, but multiple I / O devices 1514 are also coupled to CLs 1572 and 1582. Legacy I / O device 1515 is coupled to chipset 1490.

[0169] Referring now to Figure 16, a block diagram of SoC 1600 is shown according to one embodiment of the present invention. Several similar elements in Figure 12 have the same reference numerals. Also, dashed boxes are optional functions on a more advanced SoC. In Figure 16, the interconnection unit 1602 is connected to the application processor 1610, the system agent unit 1210, the bus controller unit 1216, the integrated memory controller unit 1214, a set of one or more coprocessors 1620, the static random access memory (SRAM) unit 1630, the direct memory access (DMA) unit 1632, and the display unit 1640 for connecting to one or more external displays. The application processor 1610 includes a set of one or more cores 1202A to 1202N and a shared cache unit 1206, including cache units 1204A to 1204N. The set of coprocessors 1620 may include integrated graphics logic, an image processor, an audio processor, and a video processor. In one embodiment, the coprocessor 1620 includes, for example, a dedicated processor such as a network or communications processor, a compression engine, a GPGPU, a high-throughput MIC processor, or an embedded processor.

[0170] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as computer programs or program code to run on a programmable system, which comprises at least one processor, a storage system (e.g., volatile and non-volatile memory and / or memory elements), at least one input device, and at least one output device.

[0171] Program code such as code 1430 shown in Figure 14 may be applied to input a plurality of instructions for performing a plurality of functions described herein and generating output information. The output information may be applied to one or more output devices in known manner. For this application, the processing system includes any system comprising a processor such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0172] The program code may be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. Alternatively, if necessary, the program code may be implemented in assembly language or machine language. In fact, the mechanisms described herein are not limited to any particular programming language within their scope. In any case, the language may be a compiled language or an interpreted language.

[0173] One or more aspects of at least one embodiment may be implemented by typical instructions stored in a machine-readable medium, which represent various logic within a processor and, when read by a machine, cause the machine to create logic for performing the techniques described herein. Multiple such descriptive representations, known as multiple "IP cores," may be stored in a tangible machine-readable medium and supplied to various customers or manufacturing facilities, and may be loaded into multiple manufacturing machines that actually create the logic or processor.

[0174] Such machine-readable storage media may include non-transient tangible configurations of articles manufactured or formed by machines or apparatus, including, but not limited to, storage media such as hard disks, floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and any other type of disk such as magneto-optical disks, 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 or optical cards, or any other type of media suitable for storing electronic instructions.

[0175] Accordingly, embodiments of the present invention also include non-temporary tangible machine-readable media such as a hardware description language (HDL) that includes instructions defining the structures, circuits, devices, processors and / or system features described herein, or design data. Such embodiments may be referred to as program products. [Emulation (including binary conversion, code morphing, etc.)]

[0176] In some cases, instruction converters may be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction converter may interpret, morph, emulate, or otherwise translate an instruction into one or more other instructions to be processed by the core (e.g., using static binary translation, dynamic binary translation including dynamic compilation). Instruction converters may be implemented in software, hardware, firmware, or a combination thereof. Instruction converters may reside within the processor, outside the processor, or partially within or partially outside the processor.

[0177] Figure 17 is a block diagram illustrating the use of a software instruction converter to translate binary instructions in a source instruction set to binary instructions in a target instruction set, according to some embodiments of the present invention. In the illustrated embodiments, the instruction converter is a software instruction converter, but alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Figure 17 shows a program in a high-level language 1702 that can be compiled using an x86 compiler 1704 to produce x86 binary code 1706 that can be natively executed by a processor 1716 with at least one x86 instruction set core. The processor 1716 with at least one x86 instruction set core represents any processor capable of performing substantially the same functions as an Intel® processor with at least one x86 instruction set core, which is done as follows: In other words, to obtain substantially the same results as an Intel® processor using at least one x86 instruction set core, this is achieved by (1) executing or otherwise processing in a compatible manner either a large portion of the instruction set of an Intel® x86 instruction set core, or (2) an object code version of an application or other software intended to run on an Intel® processor using at least one x86 instruction set core. The x86 compiler 1704 represents a compiler capable of generating x86 binary code 1706 (e.g., object code) executable on a processor 1716 using at least one x86 instruction set core, with or without further linking.Similarly, Figure 17 shows a high-level language 1702 program that can be compiled using an alternative instruction set compiler 1708 to generate alternative instruction set binary code 1710 that can be natively executed by a processor 1714 that does not use at least one x86 instruction set core (for example, a processor with multiple cores that execute the MIPS instruction set from MIPS Technology, Sunnyvale, California, and / or the ARM instruction set from ARM Holdings, Sunnyvale, California). An instruction converter 1712 is used to translate the x86 binary code 1706 into code that can be natively executed by the processor 1714 that does not use an x86 instruction set core. This translated code may not be the same as the alternative instruction set binary code 1710 because it is difficult to create an instruction converter that can do so. However, the translated code performs common operations and is composed of instructions from the alternative instruction set. Therefore, the instruction converter 1712 represents software, firmware, hardware, or a combination thereof, which enables a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code 1706, through emulation, simulation, or any other processing. [Further examples]

[0178] Example 1 includes an exemplary system comprising a processor having one or more cores, a last-level cache (LLC), and a cache control circuit (CCC). The LLC has multiple ways, each assigned to one of multiple priorities, and each priority is associated with a class of service (CLOS) register that specifies the minimum and maximum number of ways to occupy. If an invalid cache line (CL) exists in the LLC, the CCC stores a subsequent cache line with the requesting priority among multiple priorities in that invalid CL; or if the requesting priority is the lowest among multiple priorities and has one or more occupancy counts, or if the occupancy count is the highest for the requesting priority, it stores a subsequent CL in place of the Least Recently Used (LRU) CL for the requesting priority; or if the occupancy count is between the minimum and maximum for the requesting priority, it stores a subsequent CL in place of an LRU CL with the requesting priority or a lower priority; or if there is an LRC CL with a occupancy count lower than the minimum and a lower priority, it stores a subsequent CL in place of that LRU CL; or if there are no eviction candidates with the requesting priority or a lower priority, it stores a subsequent CL in place of an LRU CL with a higher priority than the requesting priority.

[0179] Example 2 includes the contents of the exemplary system of Example 1, wherein the LLC includes multiple sets of ways, the multiple ways are part of multiple sets, and the CCC determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before deciding where to store the subsequent CL.

[0180] Example 3 includes the contents of the exemplary system of Example 1, further comprising a cache monitoring circuit that maintains heuristics regarding LLC cache eviction, and when a percentage of high-priority cache lines are evictioned that are higher than a threshold, the CLOS register for high priority is updated to increase the minimum and maximum ways it occupies in order to make room for subsequent CLs with lower priority.

[0181] Example 4 includes the contents of the exemplary system of Example 1, where multiple ways each contain N CLs, and N is a positive integer greater than or equal to 1.

[0182] Example 5 includes the contents of the exemplary system of Example 1, and when an LRU CL with a lower priority exists and a subsequent CL is stored in its place, the CCC flushes any other CLs that exist in the way containing the LRU CL.

[0183] Example 6 includes the contents of the exemplary system in Example 1, where one or more cores each implement a virtual machine, and the CCC includes a hypervisor.

[0184] Example 7 includes the contents of the exemplary system in Example 1, where the processor is one of several processors in the data center of a cloud service provider.

[0185] Example 8 includes an exemplary method performed by a cache control circuit (CCC) in a system comprising a processor having one or more cores and a last-level cache (LLC) having multiple ways, each assigned to one of multiple priorities, wherein each priority is associated with a class of service (CLOS) register specifying the minimum and maximum number of ways to occupy. The process includes receiving a request to store a subsequent cache line (CL) with a certain requester priority among multiple priorities in the LLC; if an invalid CL exists in the LLC, storing the subsequent CL in this invalid CL; or if the requester priority is the lowest of multiple priorities and has one or more occupancy counts, or if the occupancy count is the highest for the requester priority, storing the subsequent CL in place of the Least Recently Used (LRU) CL for the requester priority; or if the occupancy count is between the minimum and maximum for the requester priority, storing the subsequent CL in place of an LRU CL with the requester priority or a lower priority; or if an LRC CL exists with a occupancy count lower than the minimum and a lower priority, storing the subsequent CL in place of this LRU CL; or if there are no eviction candidates with the requester priority or a lower priority, storing the subsequent CL in place of an LRU CL with a higher priority than the requester priority.

[0186] Example 9 includes the contents of the exemplary method of Example 8, wherein the LLC includes multiple sets of ways, the multiple ways are part of multiple sets, and the CCC determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before deciding where to store the subsequent CL.

[0187] Example 10 includes the contents of the exemplary method of Example 8, and uses an LLC cache monitoring circuit to maintain heuristics regarding LLC cache evictions and to make space to fill subsequent CLs with lower priority. If a percentage of high-priority cache lines are evictioned that are higher than a threshold, the CLOS register for high priority is updated to increase the minimum and maximum ways it occupies.

[0188] Example 11 includes the content of the exemplary method of Example 8, where multiple ways each contain N CLs, and N is a positive integer greater than or equal to 1.

[0189] Example 12 includes the contents of the exemplary method of Example 8, wherein when an LRU CL with lower priority exists and a subsequent CL is stored in its place, the CCC flushes any other CLs that exist in the way containing the LRU CL.

[0190] Example 13 includes the contents of the exemplary method of Example 8, where one or more cores each implement a virtual machine, and the CCC includes a hypervisor.

[0191] Example 14 includes the exemplary method of Example 8, where the processor is one of several processors in the data center of a cloud service provider.

[0192] Example 15 includes an exemplary non-transient computer-readable medium containing instructions to which a cache control circuit (CCC) responds in a system comprising a processor having one or more cores and a last-level cache (LLC) having multiple ways, each assigned to one of multiple priorities, wherein each priority is associated with a class of service (CLOS) register specifying the minimum and maximum number of ways to occupy. The response is performed by, if an invalid cache line (CL) exists in the LLC, storing a subsequent CL with a requesting priority among several priorities in this invalid CL; or, if the requesting priority is the lowest of several priorities and has one or more occupancy counts, or if the occupancy count is the highest for the requesting priority, storing a subsequent CL in place of the requesting priority's Least Recently Used (LRU) CL; or, if the occupancy count is between the minimum and maximum for the requesting priority, storing a subsequent CL in place of an LRU CL with the requesting priority or a lower priority; or, if an LRC CL exists with a occupancy count lower than the minimum and a lower priority, storing a subsequent CL in place of this LRU CL; or, if there are no eviction candidates with the requesting priority or a lower priority, storing a subsequent CL in place of an LRU CL with a higher priority than the requesting priority.

[0193] Example 16 includes the contents of an exemplary non-temporary computer-readable medium of the exemplary method of Example 15, wherein the LLC includes multiple sets of ways, the multiple ways being part of multiple sets, and the CCC determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before deciding where to store the subsequent CL in response to the instruction.

[0194] Example 17 includes the contents of an exemplary non-temporary computer-readable medium of the exemplary method of Example 15, where the processor is one of several processors in a data center of a cloud service provider.

[0195] Example 18 includes the contents of an exemplary non-temporary computer-readable medium of the exemplary method of Example 15, where multiple ways each contain N CLs, and N is a positive integer greater than or equal to 1.

[0196] Example 19 contains the contents of an exemplary non-temporary computer-readable medium of the exemplary method of Example 15, and when an LRU CL with a lower priority exists and a subsequent CL is stored in its place, the CCC flushes any other CLs that exist in the way containing the LRU CL.

[0197] Example 20 includes the contents of an exemplary non-temporary computer-readable medium of the exemplary method of Example 15, where one or more cores each implement a virtual machine, and the CCC includes a hypervisor.

[0198] [Other adjacent items] (Item 1) A last-level cache (LLC) having multiple ways, each assigned to one of multiple priorities, wherein each priority is associated with a class of service (CLOS) register specifying the minimum and maximum number of ways to occupy, and a cache control circuit (CCC) which, if an invalid cache line (CL) exists in the LLC, stores a subsequent cache line (CL) having the requesting priority which is one of the multiple priorities in the invalid CL, and if the requesting priority is the lowest of the multiple priorities and has one or more ways to occupy, or if the number of ways to occupy is the maximum for the requesting priority, stores the subsequent CL in place of the Least Recently Used (LRU) CL for the requesting priority, and if the number of ways to occupy is between the minimum and the maximum for the requesting priority, stores the subsequent CL in place of an LRU CL of the requesting priority or a lower priority, and if the number of ways to occupy is lower than the minimum and there is a CL with a lower priority, the LRU with a lower priority A system comprising a CCC that stores the above subsequent CL in place of the CL, and if there are no invalid CLs or CLs with the above requester priority or a lower priority, stores the above subsequent CL in place of a higher priority LRU CL. (Item 2) The system as described in Item 1, wherein the LLC includes multiple sets of ways, the multiple ways are part of the multiple sets, and the CCC determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before determining where to store the subsequent CL. (Item 3) The system as described in Item 1, further comprising a cache monitoring circuit that maintains heuristics regarding LLC cache eviction, wherein if a high-priority cache line is evictioned at a rate higher than a threshold to make room for subsequent CLs with lower priority, the CLOS register for the high priority is updated to increase the minimum and maximum ways occupied. (Item 4) The system described in Item 1, where each of the above ways contains N CLs, and N is a positive integer greater than or equal to 1. (Item 5) The system as described in Item 1, wherein when there is an LRU CL with a lower priority than the above, and the subsequent CL is stored in its place, the CCC flushes any other CLs that exist in the way containing the LRU CL. (Item 6) The system described in Item 1, further comprising a processor having one or more cores that implement virtual machines, each having an LLC and a CCC, wherein the CCC includes a hypervisor. (Item 7) The above processor is one of several processors in the data center of the cloud service provider, as described in Item 6. (Item 8) A method performed by a cache control circuit (CCC) in a system having a last-level cache (LLC) having multiple ways, each assigned to one of multiple priorities, wherein each priority is associated with a class of service (CLOS) register specifying the minimum and maximum number of ways to occupy, the method comprising: receiving a request to store a subsequent cache line (CL) having a requesting priority among the multiple priorities in the LLC; if an invalid CL exists in the LLC, storing the subsequent CL in the invalid CL; if the requesting priority is the lowest of the multiple priorities and has one or more ways to occupy, or if the number of ways to occupy is the maximum for the requesting priority, storing the subsequent CL in place of the Least Recently Used (LRU) CL of the requesting priority; if the number of ways to occupy is between the minimum and the maximum for the requesting priority, storing the subsequent CL in place of an LRU CL of the requesting priority or a lower priority; and if the number of ways to occupy is lower than the minimum and there is a CL with a lower priority, LRU A method comprising the steps of: storing the subsequent CL in place of the CL; and, if there are no invalid CLs or CLs with the above requester priority or a lower priority, storing the subsequent CL in place of a higher priority LRU CL. (Item 9) The method of Item 8, wherein the LLC includes multiple sets of ways, the multiple ways are part of the multiple sets, and the CCC determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before determining where to store the subsequent CL. (Item 10) The method of Item 8, wherein an LLC cache monitoring circuit is used to maintain heuristics regarding LLC cache evictions and, if a high-priority cache line is evictioned at a rate higher than a threshold, updates the CLOS register for the high-priority to increase the minimum and maximum ways occupied, in order to make room for subsequent CLs with lower priority. (Item 11) The method described in Item 8, wherein each of the above ways contains N CLs, where N is a positive integer greater than or equal to 1. (Item 12) The method of Item 8, wherein when there is an LRU CL with a lower priority than the above, and the subsequent CL is stored in its place, the CCC flushes any other CLs in the way containing the LRU CL. (Item 13) The method of Item 8, wherein the system further comprises a processor having one or more cores that incorporate the LLC and the CCC and each implement a virtual machine, and the CCC includes a hypervisor. (Item 14) The method described in Item 13, wherein the above processor is one of several processors in the data center of a cloud service provider. (Item 15) A non-temporary computer-readable medium containing instructions to which a cache control circuit (CCC) in a system having a last-level cache (LLC) having multiple ways each assigned to one of multiple priorities, each priority associated with a class of service (CLOS) register specifying the minimum and maximum number of ways to occupy, wherein the response includes receiving a request to store a subsequent cache line (CL) having a requesting priority among the multiple priorities in the LLC; storing the subsequent CL in an invalid CL if an invalid CL exists in the LLC; storing the subsequent CL in place of the Least Recently Used (LRU) CL of the requesting priority if the requesting priority is the lowest of the multiple priorities and has one or more ways to occupy, or if the number of ways to occupy is the maximum for the requesting priority; and if the number of ways to occupy is between the minimum and the maximum for the requesting priority, the LRU of the requesting priority or a lower priority. A non-temporary computer-readable medium, which is implemented by storing the subsequent CL in place of the CL; storing the subsequent CL in place of an LRU CL with a lower priority if there is a CL whose occupancy count is lower than the minimum and which has a lower priority; and storing the subsequent CL in place of a higher priority LRU CL if there is no invalid CL or a CL with the requesting priority or a lower priority. (Item 16) A non-temporary computer-readable medium as described in Item 15, wherein the LLC includes multiple sets of ways, the multiple ways being part of the multiple sets, and the CCC, in response to the instruction, determines which of the multiple sets the subsequent CL belongs to based on a hashing algorithm performed on the logical address of the subsequent CL before deciding where to store the subsequent CL. (Item 17) The system further comprises a processor containing the LLC and the CCC, the processor being one of several processors in the data center of a cloud service provider, and is a non-transient computer-readable medium as described in Item 15. (Item 18) The above multiple ways each contain N CLs, where N is a positive integer greater than or equal to 1, and are non-temporary computer-readable media as described in Item 15. (Item 19) A non-temporary computer-readable medium as described in Item 15, wherein when there is an LRU CL with a lower priority than the above, and the subsequent CL is stored in its place, the CCC flushes any other CLs that exist in the way containing the LRU CL. (Item 20) The system described above further comprises a processor having one or more cores that incorporate the LLC and the CCC, each implementing a virtual machine, wherein the CCC includes a hypervisor, and is a non-temporary computer-readable medium as described in Item 15.

Claims

1. a last level cache (LLC) having a number of ways each assigned to one of a number of priorities, each priority associated with a class of service register (CLOS register) that specifies a minimum and maximum number of ways that it may occupy; A cache control circuit (CCC) if an invalid cache line (invalid CL) exists in the LLC, storing a succeeding cache line (successor CL) having a requestor priority that is one of the plurality of priorities in the invalid CL; if the requester priority is the lowest of the plurality of priorities and the number of ways occupied by the requester priority is one or more, or the number of ways occupied by the requester priority is the largest for the requester priority, storing the successor CL in place of a Least Recently Used (LRU) CL for the requester priority; storing the successor CL in place of an LRU CL of the requestor priority or lower if the number of occupied ways for the requestor priority is between a minimum and the maximum; if the number of ways occupied for the requester priority is less than the minimum and a CL having the lower priority exists, storing the successor CL instead of the LRU CL having the lower priority; a CCC that stores the successor CL in place of a higher priority LRU CL if there is no invalid CL or a CL having the requestor priority or a priority lower than the requestor priority; A system comprising:

2. 2. The system of claim 1, wherein the LLC includes multiple sets of ways, the multiple ways being part of the multiple sets, and the CCC determines which of the multiple sets the successor CL is in based on a hashing algorithm performed on the logical address of the successor CL before determining where to store the successor CL.

3. a cache monitoring circuit for maintaining heuristics regarding LLC cache eviction; 2. The system of claim 1, wherein if a higher than threshold percentage of cache lines with high priority are evicted to make room for subsequent CLs with lower priority, the CLOS register for the high priority is updated to increase the minimum and maximum ways occupied.

4. The system of claim 1 , wherein each of the plurality of ways includes N CLs, where N is a positive integer greater than or equal to 1.

5. 2. The system of claim 1, wherein when the LRU CL having the lower priority exists and the successor CL is stored in its place, the CCC flushes other CLs if they exist in a way that contains the LRU CL.

6. The system of claim 1 , further comprising a processor incorporating the LLC and the CCC, each having one or more cores implementing a virtual machine, the CCC including a hypervisor.

7. The system of claim 6 , wherein the processor is one of a plurality of processors in a data center of a cloud service provider.

8. 1. A method performed by a cache control circuit (CCC) in a system having a last level cache (LLC) having a number of ways each assigned to one of a number of priorities, each priority associated with a class of service register (CLOS register) that specifies a minimum and maximum number of ways to occupy, comprising: receiving a request to store a successor cache line (successor CL) in the LLC having a requestor priority among the plurality of priorities; storing the successor CL in the invalid CL if an invalid CL exists in the LLC; storing the subsequent CL in place of a least recently used (LRU) CL of the requester priority when the requester priority is the lowest of the plurality of priorities and the number of ways occupied by the requester priority is one or more, or the number of ways occupied by the requester priority is the largest for the requester priority; storing the successor CL instead of an LRU CL of the requestor priority or a lower priority if the number of occupied ways for the requestor priority is between a minimum and the maximum; storing the succeeding CL instead of the LRU CL having the lower priority when the number of occupied ways for the requester priority is lower than the minimum and a CL having the lower priority exists; storing the successor CL in place of a LRU CL of a higher priority if there is no invalid CL or a CL having the requestor priority or a priority lower than the requestor priority; A method comprising:

9. 9. The method of claim 8, wherein the LLC includes multiple sets of ways, the multiple ways being part of the multiple sets, and the CCC determines in which of the multiple sets the successor CL is included based on a hashing algorithm performed on the logical address of the successor CL before determining where to store the successor CL.

10. Using an LLC cache monitoring circuit to maintain heuristics regarding LLC cache eviction; 9. The method of claim 8, further comprising: updating the CLOS register for a high priority cache line to increase the minimum and maximum ways occupied if a higher than a threshold percentage of the high priority cache lines are evicted to make room for subsequent CLs having lower priority.

11. The method of claim 8 , wherein each of the plurality of ways includes N CLs, where N is a positive integer greater than or equal to 1.

12. 9. The method of claim 8, wherein when the LRU CL having the lower priority exists and the successor CL is stored in its place, the CCC flushes other CLs if they exist in the way containing the LRU CL.

13. 13. The method of claim 8, wherein the system further comprises a processor incorporating the LLC and the CCC, each processor having one or more cores implementing a virtual machine, the CCC including a hypervisor.

14. The method of claim 13 , wherein the processor is one of a plurality of processors in a data center of a cloud service provider.

15. 1. A computer program comprising instructions for execution by a cache control circuit (CCC) in a system having a last level cache (LLC) having a plurality of ways each assigned to one of a plurality of priorities, each priority associated with a class of service (CLOS) register that specifies a minimum and maximum number of ways to occupy, said execution comprising: receiving a request to store a successor cache line (successor CL) having a requestor priority among the plurality of priorities in the LLC; If an invalid CL exists in the LLC, storing the succeeding CL in the invalid CL; storing the successor CL in place of a least recently used (LRU) CL of the requester priority when the requester priority is the lowest of the plurality of priorities and the number of ways occupied by the requester priority is one or more, or the number of ways occupied by the requester priority is the largest for the requester priority; storing the successor CL in place of an LRU CL of the requestor priority or lower if the number of occupied ways for the requestor priority is between a minimum and the maximum; storing the successor CL instead of the LRU CL having the lower priority if the number of occupied ways for the requester priority is lower than the minimum and a CL having the lower priority exists; if there is no invalid CL or a CL having the requestor priority or a priority lower than the requestor priority, storing the successor CL in place of a higher priority LRU CL; A computer program implemented by

16. 16. The computer program product of claim 15, wherein the LLC includes a plurality of sets of ways, the plurality of ways being part of the plurality of sets, and the CCC is further responsive to the instruction to determine in which of the plurality of sets the successor CL is included based on a hashing algorithm performed on a logical address of the successor CL before determining where to store the successor CL.

17. 16. The computer program product of claim 15, wherein the system further comprises a processor housing the LLC and the CCC, the processor being one of a plurality of processors in a data center of a cloud service provider.

18. The computer program product of claim 15 , wherein each of the plurality of ways includes N CLs, where N is a positive integer equal to or greater than 1.

19. 16. The computer program product of claim 15, wherein when the LRU CL having the lower priority exists and the successor CL is stored in its place, the CCC flushes other CLs if they exist in a way that contains the LRU CL.

20. 20. The computer program product of claim 15, wherein the system further comprises a processor incorporating the LLC and the CCC, each processor having one or more cores implementing a virtual machine, the CCC including a hypervisor.

21. A non-transitory computer readable medium storing a computer program according to any one of claims 15 to 20.

Images