Apparatus and method for load instructions with read-sharing indication

Abstract

An apparatus and method are provided for a load instruction with a read-share indication. Techniques for loading data with hints related to other core shared data. For example, one embodiment of an apparatus comprises: a plurality of cores to process instructions; a first core of the plurality of cores includes decoder circuitry to decode a single instruction having a first field for an opcode to indicate a load operation to read data from the memory, a second field for the opcode to indicate a load operation to read the data from the memory, and a third field for the opcode to indicate the load operation to read the data from the memory. A second field to indicate a memory address for a location of the data in the memory, and a third field to store a value to indicate whether the data is expected to be shared between the first core and at least a second core of the plurality of cores; execution circuitry to execute a single instruction to read data from a location in the memory; and a cache controller circuit to store data in one or more caches in a state selected based on the value.

Description

Background Art

[0001] Today, many processors are optimized to run single-threaded applications. This includes policy and design decisions made in the cache hierarchy. When a thread performs a load or store, the hardware often assumes that the data touched will be private to that thread. For example, in some server processors, when a load is performed that misses in all caches, the data is loaded exclusively into the L2 cache of the requesting core instead of being loaded into the shared LLC cache.

[0002] Load and store instructions are the primary mechanism for accessing the processor's memory system. Each load / store instruction indicates an address in memory for reading / writing the corresponding data. Caches, prefetchers, and other hardware structures have been developed, in part, to convert the stream of read / write accesses from software into a set of predictions of what accesses the software will perform in the future, in order to maximize performance. These structures rely on a set of heuristics that are tuned for the most common cases, for example, sweeping through consecutive or strided locations in an array. When software deviates from the most common access patterns, performance can suffer. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0004] Figure 1 is a block diagram of an illustrative central processing unit (CPU) complex that may be included in a processor according to an example.

[0005] Figure 2 is a block diagram of an illustrative cache hierarchy that may be included in a processor according to an example.

[0006] Figure 3 Figure 1 shows an example of using a consistency agent.

[0007] Figure 4 is a block diagram illustrating a cache in a processor that implements, at least in part, a shared prefetch instruction according to an example.

[0008] Figure 5 An example of processing data starting in main memory without utilizing shared prefetch instructions is illustrated.

[0009] Figure 6 An example of the handling of data starting in main memory while utilizing shared prefetch instructions is illustrated.

[0010] Figure 7 An example of handling data in a core's private cache starting in a modified state (M) without utilizing a shared prefetch instruction is illustrated.

[0011] Figure 8 An example of handling data in a core's private cache starting in a modified state (M) is illustrated with the shared prefetch instruction being utilized.

[0012] Fig. 9 An example of hardware for processing instructions such as shared prefetch instructions is illustrated.

[0013] Fig.10 Some examples of methods performed to process shared prefetch instructions are illustrated.

[0014] Fig.11 An example of an exemplary system is illustrated.

[0015] Fig.12 A block diagram illustrating an example of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics.

[0016] 13(A) is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to an example.

[0017] 13(B) is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example.

[0018] Fig.14 Examples of execution unit circuit(s) are illustrated, such as the execution unit circuit(s) of FIG. 13(B) .

[0019] Fig.15 is a block diagram of a register architecture according to some examples.

[0020] Fig.16 An example of the instruction format is shown.

[0021] Fig.17 Figure 1 shows an example of an addressing field.

[0022] Fig.18 An example of the first prefix is ​​illustrated.

[0023] Figure 19(A)-Figure 19(D) An example of how the R, X, and B fields of the first prefix 1601 (A) are used is shown.

[0024] Figure 20(A)-Figure 20(B) An example of the second prefix is ​​shown in the figure.

[0025] Fig.21 An example of the third prefix is ​​shown in FIG.

[0026] Fig. 22A block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an example comparison;

[0027] Fig.23 illustrates an example architecture upon which embodiments of the present invention may be implemented;

[0028] Fig.24 illustrates methods and transaction sequences according to some embodiments;

[0028] Fig.25 illustrates another method and transaction sequence according to some embodiments;

[0030] Fig.26 illustrates the instruction processing pipeline of a core for executing a read shared load instruction;

[0031] Fig. 27 illustrates an embodiment in which a prefetcher is configured to process hints;

[0032] Fig.28 illustrates a hit confidence counter included in a prefetch table according to some embodiments;

[0033] Fig.29 illustrates a prefetch table with a hint predictor vector according to some embodiments;

[0034] Fig.30 illustrates a hash operation performed on the address of the request to identify a particular hint predictor vector; and

[0035] Fig.31 Illustrated is a prefetch table having fields containing page addresses and hints, according to some embodiments. DETAILED DESCRIPTION

[0036] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for instructions to perform a load of data that is intended to be read by a requesting core and one or more other cores.

[0037] A disadvantage of the caching strategy of the background art is that the hardware may process data in a suboptimal manner when running a multithreaded application. The focus of this article is on handling read-shared data because that is the common / critical case. For read-shared data, there may be a benefit to loading it into the shared cache as soon as possible so that later readers will hit in the shared cache; the alternative is to require snooping or redundant access to the next level of the memory hierarchy.

[0038] In some examples, the server CPU and / or chipset employs snooping when data is in the private cache of one core and another core requests the data. For clean data, once snooped, the data is loaded into the shared cache. If the read shared data is shared by a very large number of cores, these snoops are only a small portion of the access and are not critical. However, for data shared by a not too large number of cores (say, 2, 4, or 8), the cost of these snoops can be considerable. This cost appears in the form of higher latency, higher grid traffic, and increased pressure on the caching agent (sometimes referred to as a caching and home agent (CHA)).

[0039] Note that some systems include a cache line demote (CLDEMOTE) instruction that can be used by a thread to push data to a shared cache. Some instruction set architectures (ISAs) allow memory operations to specify (or hint) at the cache level where data should go. This includes hints such as: prefetching data into all levels of the cache hierarchy (e.g., T0), prefetching data into level 2 cache and higher (e.g., T1), prefetching data into level 3 cache and higher, or implementation-specific choices (e.g., T2), and / or prefetching data into non-temporal cache structures and prefetching data close to the processor to minimize cache pollution (e.g., NTA).

[0040] Knowing that a piece of data is shared allows the hardware to place it in a different cache than it might otherwise be in, and / or place the data in a different coherency state than it might otherwise be in. This reduces the amount of coherency traffic for shared data, and increases cache hit rates. This improves performance (through reduced latency, and reduced stress on the on-die grid and various caches) and power efficiency.

[0041] In architectures with a shared address space and hardware cache coherence, the hardware typically cannot easily distinguish between when a thread is attempting to load / store "private" data (i.e., data only touched by that thread) or "shared" data (i.e., data touched by multiple threads). Depending on the memory / cache hierarchy, there may be advantages to treating private and shared data differently. In such systems, software can know that it is about to touch shared data, and can communicate that information to the hardware, allowing for more efficient handling of the data. Shared prefetch instructions and support

[0042] Detailed herein are examples of instructions and support for performing prefetches with a hint that the data to be prefetched will be shared by other threads. The most critical case is for shared data that will be read by other threads. In some examples, bits in a model specific register (MSR) when set change the behavior of at least some software prefetch instructions to behave as if the instructions are touching shared data.

[0043] Specifically, in some examples, a "shared prefetch" instruction PREFETCHS m8 is described. Execution of this instruction causes a line of data containing the bytes specified by M8 to be prefetched from memory with a hint to the hardware that the data will be shared by multiple threads.

[0044] Figure 1 is a block diagram of an illustrative central processing unit (CPU) complex that may be included in a processor according to an example. In some examples, the L3 cache is an 8MB 16-way cache partitioned across a quad core module (referred to as a CPU complex or CCX), providing a 2MB L3 cache "slice" per core. However, the L3 cache slices in the CCX are implemented so that the L3 cache is a shared cache. Multiple CCXs may be included in a single processor (e.g., two CCXs form a 16MB L3 cache). The 8MB cache on each CCX is separate so that these caches act as the last level cache for each quad core module, with appropriate hooks into another L3 cache to determine if data is needed (the protocols involved in the L3 cache design allow each core to access the L3 cache of each other core). Therefore, these L1, L2, and L3 caches are coherent caches, where the L3 cache slices within a CCX and the L3 cache slices between CCXs are connected by a cache coherent interconnect (also referred to as a cache coherent fabric).

[0045] Figure 2 is a block diagram of an illustrative cache hierarchy that may be included in a processor according to an example. Figure 2 , the cache hierarchy 200 includes an L1 instruction cache 210A and an L1 data cache 210B (collectively referred to as L1 cache 210), an L2 instruction and data cache 220, and a level 3 (L3) instruction and data cache 230. In some examples, both the L1 cache 210 and the L2 cache 220 are private / local write-back caches, and the L3 cache 230 is a victim cache. In some examples, the L1 instruction cache 210A is a 64KB 4-way cache, the L1 data cache 210B is a 32KB 8-way cache, the L2 cache 220 is a 512KB 8-way cache, and the level 3 (L3) cache 230 is an 8MB 16-way cache. Memory organization characteristics

[0046] Processor cores, processors, and systems according to examples may include various features related to the organization and use of memory. Several such features are described individually using the non-limiting examples below, but the examples may include any combination of such features. Exemplary Memory Hierarchy

[0047] Figure 3 is a block diagram illustrating a memory hierarchy according to an example. The illustrated memory hierarchy may be implemented in conjunction with various processor cores, core clusters, CCXs, processors, computer architectures, and the like. Figure 3 Illustrated are consistency agent 300 and consistency agent 310, as well as the possibility of other consistency agents as indicated by "..." and consistency agent 302 represented using a dashed box. Figure 3 The memory hierarchy in includes a coherent cache 304A, an interconnect 320, and a downstream memory 330. Different examples may implement different numbers of caches and cache levels as part of the coherent cache 304A. The coherent agent and the coherent cache are parts of a cache coherence domain within which cache coherence is maintained using a cache coherence protocol (e.g., the MESI protocol, which uses cache coherence protocol states "modified", "exclusive", "shared", and "invalid"; the MESIF protocol, which adds a cache coherence protocol state "forwarded"; the MOESI protocol, which instead adds a cache coherence protocol state "owned"; and other such cache coherence protocols).

[0048] Coherence agent 300 is coupled to interconnect 320 through one or more caches at successively lower levels of a cache hierarchy. The cache hierarchy includes a cache at the highest level of the cache hierarchy and coupled to coherence agent 300, a cache at the lowest level of the cache hierarchy and coupled to interconnect 320 (e.g., L3 cache 315) (and thus, the cache is referred to as a lowest level cache or last level cache (LLC)), and zero or more caches at the intermediate level(s) of the cache hierarchy (e.g., L2 cache 310) coupled to one cache at a higher level and one cache at a lower level (e.g., L2 cache 310). Figure 3 The diagram shows a coherence agent 300 coupled to an L1 cache 305, which is coupled to an L2 cache 310, which is coupled to an L3 cache 315, which is coupled to an interconnect 320).

[0049] Coherence agent 301 is also coupled to the interconnect through one or more levels of cache. Figure 3The diagram shows a coherence agent 301 coupled to an optional L1 cache 306, which is coupled to an optional L2 cache 311, which is coupled to an L3 cache 315. In addition, Figure 3 Also illustrated is that optional coherence agent 302 may be coupled directly to interconnect 320 (eg, without any coherence cache).

[0050] In addition to or in lieu of connectivity that includes coupling the coherence agent to interconnect 320 through successive levels of cache, certain examples implement other connectivity to allow direct or more direct communication (e.g., coupling coherence agent 300 directly to interconnect 320, coupling coherence agent 300 directly to L2 cache 310, coupling L1 cache 305 directly to interconnect 320, and / or coupling L2 cache 310 directly to interconnect 320, as illustrated by dashed lines 335, 336, 337, and 338, respectively).

[0051] The interconnect 320 is coupled to downstream memory 330 (e.g., through a set of one or more memory controllers (not shown)). The downstream memory 330 is at a level of the memory hierarchy compared to the coherent cache 304 and may include one or more types of memory and / or memory hierarchies (e.g., volatile memory and / or non-volatile memory, main memory, memory mapped input / output (MMIO), (one or more) memory side caches, 2-level memory (2LM), DRAM, flash memory, phase change memory, 3D Xpoint, etc.). tm ).

[0052] The interconnect 320 (also referred to as a cache coherent interconnect, fabric, interconnect, uncore portion, interconnect network, interconnect unit(s)) includes a snoop controller 325 for issuing snoops to the coherent cache 304 and receiving any responses therefrom. The snoop controller 325 includes a snoop generator 326 for issuing snoops and, in some examples, a snoop responder 327 for receiving any responses. Additionally, while the interconnect 329 is illustrated in some examples as being between the L3 cache 315 and the downstream memory 330, alternative examples may implement the interconnect 320 in another location (e.g., between the L2 cache and the L3 cache, with either a set or one or more memory controllers for the downstream memory 330 external to the interconnect 320 (e.g., as a home agent) or a set or one or more memory controllers between the L3 cache 315 and the downstream memory 330). The interconnect 320 (e.g., as part of the snoop control 325) may include other items, such as snoop filters (not shown).

[0053] Different examples may be implemented using different numbers of consistency agents as general-purpose cores (also referred to as central processing units (CPUs)). For example, in some examples, consistency agent 300 is a core, consistency agent 301 is a core, there are zero or more additional consistency agents as cores, and there are zero or more additional consistency agents as other types of agents (e.g., general-purpose processors, server processors or processing elements for use in server environments, coprocessors (e.g., security coprocessors), high-throughput MIC processors, GPGPUs, accelerators (such as, for example, graphics accelerators or digital signal processing (DSP) units, cryptography accelerators, fixed-function accelerators, machine learning accelerators, networking accelerators, or computer vision accelerators), thread-programmable gate arrays, or any other processors or processing devices, to name a few).

[0054] In some embodiments of a CCX, there may be 4 coherence agents as cores, a private / local L1 cache for each core, a private / local L2 cache for each core, and a shared L3 cache; and there may be multiple CCXs coupled together in a single processor. The L1 and L2 caches are write-back caches, the L2 cache is an inclusive cache, and the L3 cache is a victim cache. Additionally, within a module (CCX), the L3 cache 315 may be sliced ​​between multiple coherence agents (e.g., 2MB per core on 4 cores, for a total of 8MB), and optionally between one or more such modules (e.g., two CCXs, each with 8MB, resulting in a 16MB L3 cache). Figure 3 This is illustrated with L3 cache slice 316 of coherence agent 300 and L3 cache slice 317 of coherence agent 301. Interconnect 320 may represent, for example: 1) interconnect only within a CCX; 2) interconnect within a CCX and between CCXs; 3) separate interconnects within different CCXs, and interconnect(s) between CCXs. Different examples may implement interconnect 320 in different ways including one or more of a ring, multiple rings, point-to-point links, shared bus(es), etc. In examples implementing a home agent and a cache agent, interconnect 320 is considered to include a cache agent.

[0055] Figure 3 One or more or all of the coherence agents in may be implemented to execute shared prefetch instructions. The coherence agent that is currently executing a shared prefetch instruction is an "issuing agent," "issuing coherence agent," or "first agent," and its cache is referred to as the Lx cache of the issuing agent (where x may be 1, 2, or 3; and where the L3 cache is implemented in slices, it is the L3 cache slice of the issuing agent). In the discussion below, this will be coherence agent 300. The coherence agent that is not currently executing a shared prefetch instruction is referred to as a "coherence but non-issuing agent," "non-issuing coherence agent," or "second agent" (as discussed above, there may be multiple second agents, but one second agent will be discussed below for brevity), and its cache is referred to as the Lx cache of the second agent (where x may be 1, 2, or 3; and where the L3 cache is implemented in slices, it is the L3 cache slice of the second agent). Exemplary Cache Architecture

[0056] Figure 4 is a block diagram illustrating a cache in a processor that implements, at least in part, a shared prefetch instruction according to an example. Figure 4An Lx cache 450 is included, where x indicates a level in the cache hierarchy (e.g., 1, 2, 3). The Lx cache 450 includes a cache controller 451 for controlling the operation of the cache, including detecting hits / misses, causing writes / reads to cache lines, receiving snoops (and thus, in some examples, the cache controller 451 includes a snoop interface, and in some examples includes a snoop controller 453), etc. The cache controller includes a tag array 455 having entries 460 (which include what is sometimes referred to as a "tag state"), and the Lx cache 450 includes a data array 456 having corresponding cache lines 470. Each of the entries 460 includes a tag field 461 for storing a tag used to determine whether a given address hits or misses the data in a corresponding one of the cache lines 470. In addition, each of the entries 460 includes a set of one or more attribute fields 462 (sometimes referred to as a "tag state") for storing attributes of the data stored in the corresponding one of the cache lines 470. The attribute field(s) 462 include a cache coherence protocol state field 465 for storing a value indicating the current cache coherence protocol state of data stored in a corresponding one of the cache lines 470. The attribute field(s) 462 may optionally include other fields, such as a zero line field 466, a pollution field 467, an error correction code field (not shown). Although Figure 4 The figure shows that the attribute field(s) 462 are in the tag array, but alternative examples may implement the field(s) in a separate state array (not shown). In some examples, a given cache line may have multiple taint indications in the taint field 467 (e.g., one taint indication for two 32-byte blocks of a 64-byte cache line). Although Figure 4 A separate pollution field 467 is shown, but alternative examples may encode the pollution indication into another field (eg, an error correction code (ECC) field or a cache coherence protocol status field).

[0057] In response to a hit in the cache (e.g., based on a tag in tag field 461), cache controller 451 includes circuitry (e.g., cache coherence protocol state circuitry or other circuitry) for responding to a cache coherence protocol state in cache coherence protocol state field 456 for the hit (e.g., a cache coherence protocol state field 456 corresponding to tag field 461 that matches its tag); the response varies between examples and is based on various factors (e.g., whether the cache lookup is initiated in response to a write command, a read command, a snoop (and possibly the type of snoop)). For example, in some examples, as discussed in more detail below, the response is to determine whether the cache coherence protocol state is a cache coherence protocol state that grants the cache permission to modify the cache line in response to a write command and / or certain types of snoops (e.g., a "modified" or "exclusive" state).

[0058] In some examples, the cache controller 451 includes: 1) a hit-miss circuit (not shown) for determining whether there is a hit or a miss in the cache in response to a command (e.g., a write command, a read command, a snoop command); 2) a snoop controller 453 coupled to a snoop interface (not shown) for receiving snoops and transmitting response messages to the snoops; and 3) a cache row read circuit (not shown) and a cache row write circuit (not shown).

[0059] To illustrate the conceptual benefit of such instructions, the following figures show behavior outside the core (also known as uncore) with and without the instruction for the following two cases: data starting in main memory and data starting dirty in a core's private cache.

[0060] Figure 5 An example of processing data starting in main memory without using a shared prefetch instruction is shown. Here, the first reader (core 0 501) misses in LLC 503, fetches data from DRAM, and places the data in its private cache in exclusive state (E). This works well if the line is private and core 0 501 eventually writes to the line. However, this is not optimal for the read sharing case. Here, the second reader (core 1 505) misses in LLC 503 and snoops a copy of the data from core 0 501 (which causes a state change to shared state (S)); this also triggers placing a copy of the line in LLC 503 and core 1 503 in shared state. Finally, the third reader (core 2 507) hits in LLC 503.

[0061] Figure 6The diagram shows an example of handling data starting in main memory when using shared prefetch instructions. For software using shared prefetch instructions, the first reader (core 0 601) will use shared prefetch instructions to touch data. This will trigger different types of requests to non-cores, which will inform non-cores that the data being touched should be considered shared data. As shown, the shared prefetch from core 0 601 triggers code to read shared. This instructs the cache agent / last level cache (LLC) to load the data into LLC 603 in a shared state and return a copy to core 0 601 to be stored in a shared state (S). Later readers (core 1 605 and core 2 607) hit the shared data in LLC 603. The diagram shows core 1 605 and core 2 607 performing normal reads, but in practice, they may also issue shared prefetches because they will not know who will touch the line first.

[0062] Figure 7 An example of handling data in the private cache of a core starting in the modified state (M) without utilizing shared prefetch instructions is illustrated. Here, the first reader (core 0 701) misses in LLC 703 and snoops data leaving the private cache of core 1 705. The coherence protocol uses an M2I (modified to invalid) flow, which migrates ownership of the line from core 1 705 to core 0 701. This works well when core 0 701 will continue to write to the line, but is not optimal for the read sharing case. Here, next, core 1 705 reads the data, and core 1 705 misses in its own private cache (even if it had a copy of the line earlier) and LLC 703, and snoops the line returned from core 0 701; this triggers placing a copy of the line in LLC 703. Finally, the third reader (core 2 707) hits in LLC 703.

[0063] Figure 8The diagram shows an example of handling data in the private cache of a core starting in a modified state (M) with a shared prefetch instruction. The first reader (core 0 801) will use a shared prefetch instruction to touch the data. Like the previous case (data in DRAM), the shared prefetch trigger code read shared from core 0 801. This instructs LLC 803 to load the data into LLC 803 in a shared state and return a copy to core 0 803. Since the data starts in the cache of core 1 805 in a modified state, the hardware uses an M2S (modified to shared) stream to listen to the data leaving the private cache of core 1 805, which leaves a copy of the line in the private cache of core 1 805. When core 1 805 reads the line later, it hits in its private cache (not shown in the diagram because it does not cause traffic). Finally, when core 2 807 reads, it hits in LLC 803.

[0064] As can be seen from the above description, for reads of shared data, loading lines into a shared cache rather than attempting to place them in a single private cache results in greatly reduced coherency transactions.

[0065] In some examples, a mechanism is used to override some or all existing prefetch instructions in an application and treat them as shared prefetches. The override is performed by software and can be performed via a configuration register, a machine-specific register, a range register, a new bit in a page table entry, or another mechanism for specifying a subset of prefetch instructions (a specific opcode and / or a specific IP) and / or a range / set of data or instruction addresses. The hardware responsible for the override in the core or non-core will detect that the prefetch instruction is the target of the override and will change its behavior.

[0066] Fig. 9 An example of hardware for processing instructions such as shared prefetch instructions is illustrated. As shown, a storage device 903 stores shared prefetch instructions 901 to be executed.

[0067] Instruction 901 is received by decode circuit 905. For example, decode circuit 905 receives the instruction from fetch logic / circuitry.

[0068] A more detailed example of at least one instruction format will be described later. Decoding circuitry 905 decodes the instruction into one or more operations. In some examples, the decoding includes generating a plurality of micro-operations to be executed by execution circuitry (such as execution circuitry 909). Decoding circuitry 905 also decodes instruction prefixes.

[0069] In some examples, the register renaming, register allocation and / or scheduling circuitry 907 provides functionality for one or more of: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some examples); 2) assigning status bits and flags to decoded instructions; and 3) scheduling decoded instructions from an instruction pool for execution on execution circuitry (e.g., using a reservation station in some examples).

[0070] Registers (register file) and / or memory 908 store data as operands for instructions to be operated on by execution circuitry 909. Exemplary register types include packed data registers, general purpose registers, and floating point registers.

[0071] Execution circuitry 909 at least partially executes the decoded instructions. Figure 1 , Figure 3 , as shown in FIG. 13(B), etc. Execution of the decoded instruction causes the execution circuit and cache coherence circuit (e.g., snoop controller, coherence agent, cache controller, etc.) to fetch a data line containing a byte specified by the source operand from memory and store the byte in at least a cache local to the requester. Note that the requester is a core with a shared prefetch instruction.

[0072] In some examples, retirement / writeback circuitry 911 architecturally commits and retires instructions.

[0073] Some examples of the format for a shared prefetch instruction are PREFETCHS M8. In some examples, PREFETCHS is the opcode mnemonic for the instruction. M8 is at least one field for the memory address where the data to be prefetched is located. Note that in some examples, the opcode indicates that the data line obtained from the memory containing the bytes specified by the source operand (M8) is to be stored in the local cache in a shared state. In some examples, the indication that the data to be prefetched is to be stored in a shared state is made in different ways, such as using bits of the Mod R / M byte 1702 (such as, REG field 1744), using bits in the MSR, etc. The source operand M8 is a byte memory location.

[0074] Fig.10 Some examples of methods executed to process shared prefetch instructions are shown. For example, a processor core as shown in FIG. 13(B), a pipeline as described in detail below, etc., executes the method.

[0075] At 1001, an instance of a single shared prefetch instruction is obtained. The single instruction has: at least one field for an opcode; at least one field for a source operand, the source operand being used to provide a memory address having at least a byte of data, wherein the opcode is used to indicate that the circuit is to: obtain from memory a row of data containing the byte specified by the source operand at the provided address, and store the byte in at least a cache local to the requester. Note that the requester is a core having the shared prefetch instruction. Depending on the implementation, the opcode itself or other indicators specify that the byte is to be stored in a shared state. Additionally, in some instances, the byte is stored in the LLC.

[0076] In some examples, at 1002 , a fetched instruction of a single instruction of a first instruction set is translated into one or more instructions of a second instruction set.

[0077] At 1003, an instance of a single instruction, or one or more translated instructions of a second instruction set, is decoded. In some examples, conversion and decoding are combined.

[0078] At 1005, data values ​​associated with source operands of the decoded instruction are retrieved.

[0079] At 1007, the decoded instruction(s) of the second instruction set are executed by execution circuitry (hardware) such as those described in detail herein. For a shared prefetch instruction, execution will cause the circuitry to fetch a row of data containing the byte specified by the source operand from memory at the provided address and store the byte in at least a cache local to the requestor. Note that the requestor is a core with a shared prefetch instruction. Depending on the implementation, the opcode itself or other indicators specify that the byte is to be stored in a shared state. Additionally, in some instances, the byte is stored in the LLC.

[0080] In some embodiments, at 1009 , the instruction is committed or retired. Exemplary Computer Architecture

[0081] Exemplary computer architectures are described in detail below. Other system designs and configurations for laptops, desktop computers, 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, cellular phones, portable media players, handheld devices, and a large number of various other electronic devices known in the art are also appropriate. In a word, various systems or electronic devices that can include processors disclosed herein and / or other execution logics are generally appropriate.

[0082] Fig.11 An example of an exemplary system is illustrated. Multiprocessor system 1100 is a point-to-point interconnect system and includes multiple processors, including a first processor 1170 and a second processor 1180 coupled via a point-to-point interconnect 1150. In some examples, first processor 1170 and second processor 1180 are homogeneous. In some examples, first processor 1170 and second processor 1180 are heterogeneous.

[0083] Processors 1170 and 1180 are shown as including integrated memory controller (IMC) unit circuits 1172 and 1182, respectively. Processor 1170 also includes point-to-point (PP) interfaces 1176 and 1178 as part of its interconnect controller unit; similarly, second processor 1180 includes PP interfaces 1186 and 1188. Processors 1170, 1180 can exchange information via PP interconnect 1150 using point-to-point (PP) interface circuits 1178, 1188. IMCs 1172 and 1182 couple processors 1170, 1180 to respective memories, namely memory 1132 and memory 1134, which can be part of the main memory locally attached to the respective processors.

[0084] Processors 1170, 1180 can each utilize point-to-point interface circuits 1176, 1194, 1186, 1198 to exchange information with chipset 1190 via respective PP interconnects 1152, 1154. Chipset 1190 can optionally exchange information with coprocessor 1138 via high-performance interface 1192. In some examples, coprocessor 1138 is a special-purpose processor, such as a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and the like.

[0085] A shared cache (not shown) may be included in either processor 1170, 1180, or external to both processors but connected to the processors via a PP interconnect, such that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0086] Chipset 1190 can be coupled to first interconnect 1116 via interface 1196. In some examples, first interconnect 1116 can be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some examples, one of these interconnects is coupled to a power control unit (PCU) 1117, which can include circuits, software, and / or firmware to perform power management operations with respect to processors 1170, 1180, and / or coprocessor 1138. PCU 1117 provides control information to the voltage regulator so that the voltage regulator generates an appropriate regulated voltage. PCU 1117 also provides control information to control the generated operating voltage. In various examples, PCU 1117 can include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0087] PCU 1117 is illustrated as existing as logic separate from processor 1170 and / or processor 1180. In other cases, PCU 1117 may execute on a given one or more cores of a core (not shown) of processor 1170 or 1180. In some cases, PCU 1117 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by PCU 1117 may be implemented outside the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by PCU 1117 may be implemented within a BIOS or other system software.

[0088] Various I / O devices 1114 and an interconnect (bus) bridge 1118 can be coupled to the first interconnect 1116, and the interconnect (bus) bridge 1118 couples the first interconnect 1116 to the second interconnect 1120. In some examples, one or more additional processors 1115 are coupled to the first interconnect 1116, such as a coprocessor, a high throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some examples, the second interconnect 1120 can be a low pin count (LPC) interconnect. Various devices can be coupled to the second interconnect 1120, including, for example, a keyboard and / or mouse 1122, a communication device 1127, and a storage unit circuit 1128. The storage unit circuit 1128 can be a disk drive or other mass storage device, which in some examples can include instructions / code and data 1130. In addition, audio I / O 1124 can be coupled to second interconnect 1120. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 1100 can implement a multi-drop interconnect or other such architecture instead of a point-to-point architecture. Exemplary Core Architectures, Processors, and Computer Architectures

[0089] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores, for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores, for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU, including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor, including one or more special-purpose cores mainly for graphics and / or scientific (throughput) purposes. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip, which may include the above-described coprocessors and additional functionality on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s). An exemplary core architecture is described next, followed by a description of exemplary processor and computer architectures.

[0090] Fig.12 A block diagram of an example of an example processor 1200 is illustrated, which may have more than one core, may have an integrated memory controller, and may have an integrated graphics device. The solid-lined box illustrates the processor 1200 as having a single core 1202(A), a system agent 1210, and a set of one or more interconnected controller unit circuits 1216, while the optionally added dashed-lined box illustrates an alternative processor 1200 as having multiple cores 1202(A)-(N), a set of one or more integrated memory control unit circuits 1214 in the system agent unit circuit 1210, dedicated logic 1208, and a set of one or more interconnected controller unit circuits 1216. Note that the processor 1200 may be Fig.11 One of processors 1170 or 1180 or coprocessors 1138 or 1115.

[0091] Thus, different implementations of processor 1200 may include: 1) a CPU, where dedicated logic 1208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1202(A)-(N) 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, where cores 1202(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 1202(A)-(N) are a large number of general purpose in-order cores. Thus, processor 1200 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit circuit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1200 may be part of and / or implemented on one or more substrates using any of a variety of process technologies, such as BiCMOS, CMOS, or NMOS.

[0092] The memory hierarchy includes one or more levels of cache unit circuits 1204(A)-(N) within the cores 1202(A)-(N), a set of one or more shared cache unit circuits 1206, and an external memory (not shown) coupled to the set of integrated memory controller unit circuits 1214. The set of one or more shared cache unit circuits 1206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other level caches, such as last level cache (LLC), and / or combinations thereof. While in some examples a ring-based interconnect network circuit 1212 interconnects the dedicated logic 1208 (e.g., integrated graphics logic), the set of shared cache unit circuits 1206, and the system agent unit circuit 1210, alternative examples use any number of well-known techniques to interconnect these units. In some examples, coherency is maintained between one or more circuits in the shared cache unit circuits 1206 and the cores 1202(A)-(N).

[0093] In some examples, one or more of the cores 1202(A)-(N) have multi-threading capabilities. System agent unit circuitry 1210 includes those components that coordinate and operate the cores 1202(A)-(N). System agent unit circuitry 1210 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be (or may include) logic and components required to regulate the power state of the cores 1202(A)-(N) and / or the dedicated logic 1208 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0094] The cores 1202(A)-(N) may be homogeneous or heterogeneous with respect to the architectural instruction set; that is, two or more of the cores 1202(A)-(N) may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of the instruction set or may be capable of executing a different ISA. Exemplary Core Architecture In-order and out-of-order core block diagram

[0095] The block diagram of FIG. 13(A) illustrates both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to an example. The block diagram of FIG. 13(B) illustrates both an exemplary embodiment of an in-order architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core according to an example. The solid-line boxes in FIG. 13(A)-(B) illustrate the in-order pipeline and the in-order core, while the optionally added dashed-line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0096] In FIG. 13(A), the processor pipeline 1300 includes a fetch stage 1302, an optional length decoding stage 1304, a decode stage 1306, an optional allocation stage 1308, an optional rename stage 1310, a dispatch (also called dispatch or issue) stage 1312, an optional register read / memory read stage 1314, an execute stage 1316, a write back / memory write stage 1318, an optional exception handling stage 1322, and an optional commit stage 1324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1302, one or more instructions are fetched from the instruction memory, during the decode stage 1306, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In some examples, the decode stage 1306 and the register read / memory read stage 1314 can be combined into one pipeline stage. In some examples, during the execute stage 1316, decoded instructions can be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface can be performed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, and the like.

[0097] As an example, the exemplary register renaming, out-of-order issue / execution core architecture can implement pipeline 1300 in the following manner: 1) instruction fetch 1338 executes fetch and length decoding stages 1302 and 1304; 2) decoding unit circuit 1340 executes decoding stage 1306; 3) rename / allocator unit circuit 1352 executes allocation stage 1308 and rename stage 1310; 4) (one or more) scheduler unit circuit 1356 executes scheduling stage 1312; 5) (one or more) physical register file unit Circuit 1358 and memory unit circuit 1370 perform register read / memory read phase 1314; execution cluster 1360 performs execution phase 1316; 6) memory unit circuit 1370 and (one or more) physical register file unit circuit 1358 perform write back / memory write phase 1318; 7) various units (unit circuits) may be involved in the exception handling phase 1322; and 8) retirement unit circuit 1354 and (one or more) physical register file unit circuit 1358 perform commit phase 1324.

[0098] 13(B) shows that the processor core 1390 includes a front end unit circuit 1330 coupled to an execution engine unit circuit 1350, and both are coupled to a memory unit circuit 1370. The core 1390 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1390 can be a special-purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0099] The front end unit circuit 1330 may include a branch prediction unit circuit 1332, which is coupled to an instruction cache unit circuit 1334, which is coupled to an instruction translation lookaside buffer (TLB) 1336, which is coupled to an instruction fetch unit circuit 1338, which is coupled to a decode unit circuit 1340. In some examples, the instruction cache unit circuit 1334 is included in the memory unit circuit 1370 instead of the front end unit circuit 1330. The decode unit circuit 1340 (or decoder) can decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode unit circuit 1340 may also include an address generation unit (AGU, not shown). In some examples, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode unit circuit 1340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In some examples, the core 1390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode unit circuit 1340 or otherwise within the front end unit circuit 1330). In some examples, the decode unit circuit 1340 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1300. The decode unit circuit 1340 may be coupled to the rename / allocator unit circuit 1352 in the execution engine unit circuit 1350.

[0100] The execution engine circuit 1350 includes a rename / allocator unit circuit 1352, which is coupled to a retirement unit circuit 1354 and a set of one or more scheduler circuits 1356. The scheduler circuit 1356 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit(s) 1356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit(s) 1356 is coupled to the physical register file(s) circuit(s) 1358. Each of the physical register file(s) circuit(s) 1358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In some examples, the (one or more) physical register file unit circuits 1358 include vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The (one or more) physical register file circuits 1358 are overlapped by retirement unit circuits 1354 (also called retirement queues) to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROBs) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and pools of registers; etc.). The retirement unit circuits 1354 and (one or more) physical register file circuits 1358 are coupled to (one or more) execution clusters 1360. The (one or more) execution clusters 1360 include a set of one or more execution unit circuits 1362 and a set of one or more memory access circuits 1364. Execution unit circuitry 1362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 1356, physical register file unit circuit(s) 1358, and execution cluster(s) 1360 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuit(s), physical register file unit circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has memory access unit circuit(s) 1364 in some examples of the implementation). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0101] In some examples, the execution engine unit circuit 1350 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0102] A set of memory access circuits 1364 are coupled to the memory cell circuit 1370, which includes a data TLB unit circuit 1372, which is coupled to a data cache circuit 1374, which is coupled to a level 2 (L2) cache circuit 1376. In an exemplary embodiment, the memory access unit circuit 1364 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 1372 in the memory cell circuit 1370. The instruction cache circuit 1334 is further coupled to the level 2 (L2) cache unit circuit 1376 in the memory cell circuit 1370. In some examples, the instruction cache 1334 and the data cache 1374 are combined into a single instruction and data cache in the L2 cache unit circuit 1376, a level 3 (L3) cache unit circuit (not shown), and / or a main memory (not shown). The L2 cache unit circuit 1376 is coupled to one or more other levels of cache and ultimately coupled to the main memory.

[0103] Core 1390 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set; the ARM instruction set (with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In some examples, core 1390 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data. Exemplary Execution Unit Circuit(s)

[0104] Fig.14 An example of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 1362 of FIG. 13 (B). As shown, (one or more) execution unit circuits 1362 may include one or more ALU circuits 1401, vector / SIMD unit circuits 1403, load / store unit circuits 1405, and / or branch / jump unit circuits 1407. ALU circuits 1401 perform integer arithmetic and / or Boolean operations. Vector / SIMD unit circuits 1403 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store unit circuits 1405 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store unit circuits 1405 may also generate addresses. Branch / jump unit circuits 1407 cause branches or jumps to a certain memory address depending on the instruction. Floating-point unit (FPU) circuits 1409 perform floating-point arithmetic. The width of execution unit circuit(s) 1362 varies depending on the embodiment and may range from 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit). Exemplary Register Architecture

[0105] Fig.15 It is a block diagram of a register architecture 1500 according to some examples. As shown, there is a vector / SIMD register 1510, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1510 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some examples, the vector / SIMD register 1510 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the embodiment.

[0106] In some examples, the register architecture 1500 includes a write mask / predicate register 1515. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 1515 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1515 corresponds to a data element position at the destination. In other examples, the write mask / predicate register 1515 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0107] The register architecture 1500 includes a plurality of general purpose registers 1525. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some examples, these registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0108] In some examples, register architecture 1500 includes scalar floating point registers 1545, which are used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using x87 instruction set extensions, or as MMX registers to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between MMX and XMM registers.

[0109] One or more flag registers 1540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1540 can store condition code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1540 are referred to as program status and control registers.

[0110] Segment registers 1520 contain segment points for accessing memory. In some examples, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0111] Machine-specific registers (MSRs) 1535 control and report processor performance. Most MSRs 1535 handle system-related functions and are not accessible to applications. Machine check registers 1560 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0112] One or more instruction pointer registers 1530 store instruction pointer values. Control register(s) 1555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1170, 1180, 1138, 1118, and / or 1200) and the characteristics of the currently executing task. Debug registers 1550 control and allow monitoring of debug operations of a processor or core.

[0113] Memory management registers 1565 specify the location of data structures used in protected mode memory management. These registers may include the GDTR, IDTR, task register, and LDTR registers.

[0114] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer or different register files and registers. Instruction Set

[0115] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets 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 there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, an exemplary ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field to select the specific operand. Example instruction format

[0116] The examples of the (one or more) instructions described herein may be implemented in different formats. In addition, exemplary systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0117] Fig.16 An example of an instruction format is illustrated. As shown, an instruction may include multiple components, including, but not limited to, one or more fields for the following items: one or more prefixes 1601, an opcode 1603, addressing information 1605 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1607, and / or an immediate value 1609. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1603 field. In some examples, the illustrated order is the order in which these fields are to be encoded, however, it should be understood that in other examples, these fields may be encoded in another order, combined, etc.

[0118] (One or more) prefix fields 1601 modify the instruction when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0119] The opcode field 1603 is used to at least partially define the operation to be performed when the instruction is decoded. In some examples, the length of the primary opcode encoded in the opcode field 1603 is 1, 2, or 3 bytes. In other examples, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0120] The addressing field 1605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig.17An example of an addressing field 1605 is illustrated. In this illustration, an optional MOD R / M byte 1702 and an optional Scale, Index, Base (SIB) byte 1704 are shown. The MOD R / M byte 1702 and SIB byte 1704 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that each of these fields is optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 1702 includes a MOD field 1742, a Register field 1744, and an R / M field 1746.

[0121] The content of MOD field 1742 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 1742 has a value of b11, register direct addressing mode is utilized, otherwise register indirect addressing is used.

[0122] Register field 1744 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register index field 1744 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 1744 is supplemented with additional bits from a prefix (e.g., prefix 1601) to allow for greater addressing.

[0123] R / M field 1746 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 1746 may be combined with MOD field 1742 to specify an addressing mode.

[0124] SIB byte 1704 includes a scale field 1752, an index field 1754, and a base address field 1756 for address generation. Scaling field 1752 indicates a scaling factor. Index field 1754 specifies the index register to be used. In some examples, index field 1754 is complemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. Base address field 1756 specifies the base address register to be used. In some examples, base address field 1756 is complemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. In practice, the contents of scale field 1752 allow the contents of index field 1754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0125] Some addressing forms use displacement values ​​to generate memory addresses. For example, 缩放 * index + base + displacement, index * scaling + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. to generate a memory address. The displacement can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 1607 provides this value. In addition, in some examples, the use of a displacement factor is encoded in the MOD field of the addressing field 1605, which indicates a compressed displacement scheme, for which the displacement value is calculated by multiplying disp8 with a scaling factor N determined based on the vector length, the value of the b bit, and the input element size of the instruction. The displacement value is stored in the displacement field 1607.

[0126] In some examples, the immediate value field 1609 specifies an immediate value for the instruction. The immediate value can be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0127] Fig.18 An example of a first prefix 1601(A) is illustrated. In some examples, the first prefix 1601(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0128] Instructions using the first prefix 1601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702; 2) using the MOD R / M byte 1702 with the SIB byte 1704, including using the reg field 1744 as well as the base field 1756 and the index field 1754; or 3) using the register field of the opcode.

[0129] In the first prefix 1601 (A), bit positions 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0130] Note that adding another bit allows for 16 (2 4 ) registers, while the separate MOD R / M reg field 1744 and the R / M field 1746 of MOD R / M can only address 8 registers each.

[0131] In the first prefix 1601(A), bit position 2 (R) may be an extension of the MOD R / M reg field 1744 and may be used to modify the MOD R / M reg field 1744 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 1702 specifies another register or defines an extended opcode, R is ignored.

[0132] Bit position 1 (X) X bits may modify the SIB byte index field 1754 .

[0133] Bit position B (B) B may modify the base address in the R / M field 1746 or SIB byte base address field 1756 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 1525).

[0134] 19(A)-(D) illustrate examples of how the R, X, and B fields of the first prefix 1601(A) are used. FIG. 19(A) illustrates that when the SIB byte 1704 is not used for memory addressing, the R and B from the first prefix 1601(A) are used to extend the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702. FIG. 19(B) illustrates that when the SIB byte 1704 is not used, the R and B from the first prefix 1601(A) are used to extend the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702 (register-register addressing). FIG. 19(C) illustrates that when the SIB byte 1704 is used for memory addressing, the R, X, and B from the first prefix 1601(A) are used to extend the reg field 1744 and the index field 1754 and the base address field 1756 of the MOD R / M byte 1702. 19(D) illustrates that when a register is encoded in the opcode 1603 , the B from the first prefix 1601 (A) is used to extend the reg field 1744 of the MOD R / M byte 1702 .

[0135] Figure 20 (A)-(B) illustrates an example of a second prefix 1601 (B). In some examples, the second prefix 1601 (B) is some examples of a VEX prefix. The second prefix 1601 (B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD registers 1510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1601 (B) provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 1601 (B) enables the operands to perform non-destructive operations, such as A=B+C.

[0136] In some examples, the second prefix 1601(B) has two forms: a two-byte form and a three-byte form. The two-byte second prefix 1601(B) is mainly used for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 1601(B) provides a compact replacement for 3-byte opcode instructions and the first prefix 1601(A).

[0137] Figure 20 (A) illustrates an example of a two-byte form of the second prefix 1601 (B). In one example, the format field 2001 (byte 0 2003) contains a value of C5H. In one example, byte 1 2005 includes an "R" value in bit [7]. This value is the complement of the same value of the first prefix 1601 (A). Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0138] Instructions using this prefix may use the R / M field 1746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0139] Instructions using this prefix may use the reg field 1744 of MOD R / M to encode either a destination register operand or a source register operand, treated as an opcode extension and not used to encode any instruction operand.

[0140] For instruction syntax supporting four operands, vvvv, the R / M field 1746 of MOD R / M, and the reg field 1744 of MOD R / M encode three of the four operands. Bits [7:4] of immediate 1609 are then used to encode the third source register operand.

[0141] Figure 20 (B) illustrates an example of a three-byte form of the second prefix 1601 (B). In one example, the format field 2011 (byte 0 2013) contains the value C4H. Byte 1 2015 includes "R", "X" and "B" in bit [7:5], which are the complements of these values ​​of the first prefix 1601 (A). Bit [4:0] (shown as mmmmm) of byte 1 2015 includes the content of encoding one or more implicit leading operation code bytes as needed. For example, 00001 means 0FH leading operation code, 00010 means 0F38H leading operation code, 00011 means 0F3AH leading operation code, etc.

[0142] The use of bit [7] of byte 2 2017 is similar to W of the first prefix 1601 (A), including helping to determine the size of the operand that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0143] Instructions using this prefix may use the R / M field 1746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0144] Instructions using this prefix may use the reg field 1744 of MOD R / M to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0145] For instruction syntax supporting four operands, vvvv, the R / M field 1746 of MOD R / M, and the reg field 1744 of MOD R / M encode three of the four operands. Bits [7:4] of immediate 1609 are then used to encode the third source register operand.

[0146] Fig.21 An example of a third prefix 1601(C) is illustrated. In some examples, the third prefix 1601(C) is some examples of an EVEX prefix. The third prefix 1601(C) is a four-byte prefix.

[0147] The third prefix 1601(C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see the discussion of registers in previous figures, e.g., Fig.15 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 1601 (B).

[0148] The third prefix 1601(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0149] The first byte of the third prefix 1601 (C) is the format field 2111, which in one example has a value of 62 H. The subsequent bytes are called payload bytes 2115-2119, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0150] In some examples, P[1:0] of payload byte 2119 is the same as the two mm bits in the lower order. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and the reg field 1744 of MOD R / M. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 1744 and the R / M field 1746 of MOD R / M, access to the next set of 8 registers beyond the lower 8 registers is allowed. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

[10] is a fixed value of 1 in some examples. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0151] P

[15] is similar to W of the first prefix 1601 (A) and the second prefix 1611 (B), and can be used as an opcode extension bit or an operand size increase.

[0152] P[18:16] specifies the index of a register in the operation mask (write mask) register (e.g., write mask / predicate register 1515). In some examples, the particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be achieved in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in other examples, the old value of each element of the destination is retained (if the corresponding mask bit has a value of 0). In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in some examples, elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span of elements modified, from first to last); however, the elements modified do not have to be consecutive. Thus, the operation mask field enables a subset of vector operations, including loads, stores, arithmetic, logical, etc. Although in the described examples, the contents of the operation mask field select which of several operation mask registers contains the operation mask to be used (so that the contents of the operation mask field indirectly identify the masking to be performed), alternative examples alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0153] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes various features that vary in different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0154] The following table details illustrative examples of encoding of registers in instructions using the third prefix 1601 (C). Table 1: 32-register support in 64-bit mode Table 2: Encoding register specifiers in 32-bit mode Table 3: Operation Mask Register Specifier Encoding

[0155] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the present application, a processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0156] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0157] Examples of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of these implementation approaches. Examples can be implemented as computer programs or program codes, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0158] One or more aspects of at least some examples may be implemented by representative instructions stored on a machine-readable medium, which represent various logic within a processor, which, when read by a machine, causes the machine to fabricate logic for performing the techniques described herein. These representations, known as "IP cores," may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a fabrication machine that actually fabricates the logic or processor.

[0159] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by a machine or device, including storage media such as: hard disks, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic cards or optical cards, or any other type of medium suitable for storing electronic instructions.

[0160] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description languages ​​(HDL), that define the structures, circuits, devices, processors and / or system features described herein. Such examples may also be referred to as program products. Emulation (including binary translation, code deformation, etc.)

[0161] In some cases, the instruction converter can be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0162] Fig. 22The block diagram of using a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an example comparison is illustrated. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig. 22 It is shown that a program in a high-level language 2202 can be compiled using a first ISA compiler 2204 to generate first ISA binary code 2206 that can be natively executed by a processor 2216 having at least one first ISA instruction set core. The processor 2216 having at least one first ISA instruction set core represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the instruction set of the first ISA instruction set core or (2) executing a program in a first ISA instruction set core in a manner compatible with or otherwise processing the instruction set of the processor. The first ISA compiler 2204 represents a compiler operable to generate first ISA binary code 2206 (e.g., object code) that can be executed on a processor 2216 having at least one first ISA instruction set core with or without additional linking processing. Similarly, Fig. 22 It is shown that the program of high-level language 2202 can be compiled with alternative instruction set compiler 2208 to generate alternative instruction set binary code 2210, which can be executed natively by processor 2214 without first ISA core. Instruction converter 2212 is used to convert first ISA binary code 2206 into code that can be executed natively by processor 2214 without first ISA instruction set core. This converted code may not be the same as alternative instruction set binary code 2210, because the instruction converter that can do this is difficult to make; however, the converted code will implement the total operation and be composed of instructions from the alternative instruction set. Thus, instruction converter 2212 represents software, firmware, hardware or a combination thereof, which allows a processor or other electronic device without a first ISA instruction set processor or core to execute first ISA binary code 2206 through simulation, emulation or any other process. Apparatus and method for load instruction with read share indication

[0163] Embodiments of the present invention address the problem of suboptimal management of cached data, which typically arises from caches that are optimized for private read and write access flows. For example, in data processing hardware tuned for situations where a cache line is touched by a single core, a cache line is provided to a core with write permission even when the first access to the cache line is a read operation. For certain types of data, such as "read-shared" data (e.g., data that is expected to be accessed by more than a single core), this implementation has negative consequences, resulting in additional snoops, increased latency for read operations, and increased cache controller occupancy (i.e., interfering with loads / stores).

[0164] To reduce overhead, one embodiment of the present invention includes instructions with an indication that the requested data is expected to be read shared across multiple cores. For example, one embodiment includes a set of load instructions that include a "read shared" indication (e.g., a hint to the hardware) that the data is expected to be read by the requesting core and one or more other cores. In other words, the software expects that at least one other thread will be used to read the data in the future before any thread writes the data (assuming that the software has written the data). As described below, the "read shared" hint is used by the cache / memory subsystem to determine the state to be used for caching the corresponding data. Since this is just a hint, future writes will still be processed according to the cache consistency protocol.

[0165] The group of read-shared load instructions is sometimes referred to by the mnemonic MOVRS. These read-shared load instructions include instructions for loading different types of data, including scalar data, vector data, and matrix data. The examples of the four MOVRS instructions listed in Table D are functionally equivalent to the corresponding silent load instructions with respect to the specific data identified. instruction type movrs r8 / 16 / 32 / 64,m8 / 16 / 32 / 64 GPR vmovrsb / w / d / qx / y / zmm{k}{z},m128 / 256 / 512 vector tileloaddrs[t1]tmm,sibmem matrix t2rpntrlvwz[0 / 1]rs[t1]tmm+1,sibmem matrix Form D

[0166] For example, the standard MOV instruction moves data of various sizes (e.g., 8-bit, 16-bit, 32-bit, or 64-bit) between immediate values, general registers, segment registers, and memory. In one embodiment, when executed, the MOVRS instruction moves the same data, and the instruction also includes a read-share hint indicating that the data is expected to be read by the requesting core and one or more other cores.

[0167] Similarly, the VMOV instruction (a) copies a 1-byte / word / doubleword / quadword element from an XMM register to a general register or memory location, or (b) copies a 1-byte / word / doubleword / quadword element from a general register or memory location to an XMM register. An embodiment of the MOVRS instruction performs the corresponding operations and also includes a read-share hint indicating that the corresponding data is read-shared.

[0168] In some embodiments, various matrix load instructions are also configured with a read share hint. For example, the tile load instruction TILELOADD loads matrix data into tile registers (tmm0-tmm7). The TILELOADDRS instruction does the same and also includes a read share field for providing an indication of whether the matrix data may be read by other cores.

[0169] Although the same data may be identified as a silent load instruction, the data corresponding to the read-share load instruction is managed differently within the cache / memory subsystem. Specifically, in one embodiment, the read-share instruction triggers different choices in the cache hierarchy regarding where the corresponding data should be stored and in what state the data should be stored.

[0170] Fig.23 An example cache / memory subsystem 2320 is illustrated that includes multiple L1 caches 2305A-B, L2 caches 2310A-B, and an L3 cache / LLC 2315. L1 cache controllers (L1 CC) 2351A-B are associated with respective L1 caches 2305A-B, L2 cache controllers (L2 CC) 2352A-B are associated with respective L2 caches 2310A-B, and an L3 cache controller (L3 CC) 2350 of the L3 cache may operate as a subcomponent of an integrated cache controller unit 2360 that implements the techniques described herein within the cache / memory subsystem 2320 to manage cache lines associated with reading shared data.

[0171] As previously described, each core 2390-2391 is coupled to the cache / memory subsystem 2320 via a corresponding coherence agent 2300-2301. For example, when one of the read-share load instructions described herein is executed on a core 2390-2391, the corresponding coherence agent 2300-2301 transmits a read-share request to the cache / memory subsystem 2320 when data is loaded from the memory 2317. The cache controller 2360 manages the corresponding cache lines according to the read-share provision.

[0172] In existing implementations, if the data associated with a load instruction is in memory 2317 and not in any on-die cache (i.e., on an L2 and L3 read miss), the data is stored exclusively in the L2 cache of the requesting core only to optimize for private data that will eventually be written. This means that when another core reads the cache line, it must be snooped from the original requester's cache. An example of this mode of operation is described above with reference to Figure 5 Described.

[0173] In one embodiment of the present invention, a different sequence of operations is triggered in response to a read sharing instruction, wherein the cache controller 2360 causes the cache line to be preemptively placed in both the L2 cache and the L3 cache of the requesting party, so that the subsequent sharing party hits in the L3 without any snooping. For example, in response to the core 2390 executing the read sharing instruction, the cache controller 2360 loads the requested data into both the L2 cache 2310A of the core 2390 and the L3 cache 2315. When the core 2391 attempts to access the data (e.g., by executing the read sharing instruction), the cache controller 2360 provides the data from the L3 cache 2315 without performing a snooping operation.

[0174] The example sequence is Fig.24 2390 executes an instruction that generates a read shared request. The cache / memory subsystem reads the data from memory and provides the data to the requesting core 2390, which is stored in the L2 cache 2310A of core 2390 and in the LLC 2315 in a shared (S) state. When another core 2391 subsequently generates a read shared request for the data, the data is provided directly from the LLC 2315 and stored in the L2 cache 2310A of core 2391 in a shared state. Any other request for the data (such as by Fig.24 A read shared request generated by core 2492 in ) causes the data to be retrieved from LLC 2315 and cached in the requester's L2 cache in a shared state.

[0175] For a read of shared data that starts in a dirty state in one core's private cache, the current implementation migrates the cache line to the reader. If the core that wrote the cache line subsequently reads the cache line (or if any other core reads the cache line), this triggers a snoop on the previous reader. Then, and only then, the subsequent reader will be able to get a copy of the cache line from the shared L3 cache. An example of this mode of operation is described above with reference to Figure 7 Described.

[0176] refer to Fig.25In one embodiment, in response to data being loaded via a read shared instruction, a different sequence of operations is performed in the cache controller 2360. Specifically, when a core 2390 reads a cache line in a dirty state in the private cache of another core 2391, the cache line state is changed from modified (M) to shared (S), and a snoop response (as processed by the cache controller 2360) causes the cache line to be stored in the LLC 2315 and the L2 cache of the requesting core 2390 in the shared (S) state. Subsequently, the writer (core 2391) retains a valid copy of the cache line in its private cache (e.g., its L2 cache) for future reads. In addition, other cores (such as core 2492) that make requests for the cache line will hit in the LLC 2315, thereby minimizing the number of snoops.

[0177] Although in the above embodiments the read sharing hint is indicated based on the instruction opcode, some embodiments include a separate field to encode the read sharing hint. For example, any of the load instructions (such as tileload or vmov) may be configured to have a separate instruction field (e.g., an immediate value or a register identifier) ​​to indicate whether the corresponding load operation is a read sharing load or a non-read sharing load.

[0178] Fig.26 The diagram illustrates additional details associated with the core 2390 for processing the read shared load instruction 2601 as described above. As illustrated, the storage device 2603 stores the read shared load instruction 2601, which is decoded by the decoding circuit 2605. In one embodiment, the storage device 2603 includes an instruction cache, and the read shared load instruction 2601 is fetched into the instruction cache by fetch logic / circuitry (not shown). For example, referring to Fig.16 , Fig.18 and Fig.19A - Fig.19D A more detailed example of at least one instruction format is described in detail. Decode circuitry 2605 decodes instructions into one or more operations, such as one or more micro-operations, which are executed by execution circuitry 2609. Decode circuitry 2605 also decodes instruction prefixes (e.g., prefix 1601 (A)).

[0179] In some examples, the register renaming, register allocation and / or scheduling circuitry 2607 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 examples); 2) assigning status bits and flags to decoded instructions; and 3) scheduling decoded instructions from an instruction pool for execution on execution circuitry (e.g., using a reservation station in some examples).

[0180] Registers (register file) and / or memory 2608 store data as the object of operations for instructions to be operated on by execution circuitry 2609. Exemplary register types include packed data registers, general purpose registers, and floating point registers.

[0181] Execution circuit 2609 at least partially executes the decoded instructions. Figure 1 , Figure 3 , FIG. 13(B), etc. Execution of the decoded instruction causes execution circuit 2709 and cache coherence circuit (e.g., cache controller 2360, coherence agent 2300-2301, etc.) to fetch a data cache line containing a data block (e.g., bytes) specified with a source operand from memory, and store the data block in a cache local to the requester (e.g., core 2390) and store it in LLC 2315. In some examples, retirement / writeback circuit 2611 architecturally commits and retires read-shared instruction 2601.

[0182] Some examples of the format of a read shared instruction are provided in Table D above, including an opcode mnemonic for the instruction (e.g., movrs, vmovrs, tileloaddrs, t2rpntrlvwz[0 / 1]rs) and at least one field for a memory address at which the data to be stored is located. Note that in some examples, the opcode indicates that the data line loaded from memory containing the specified data block is to be stored in a shared state in the local cache and the LLC. In some examples, the indication that the data is to be stored in a shared state is made via a bit or bit group in an instruction field. For example, the indication may utilize a bit in the ModR / M byte 1702 (such as, REG field 1744), utilize a bit in an MSR, and so on. Enhanced hardware prefetcher using hints for memory access

[0183] As described above, loads with read sharing hints can trigger caches within the cache / memory architecture to behave differently than caches for loads without such hints. For example, software can use loads with read sharing hints to indicate that the data being loaded will also be loaded by other cores, and that cache and coherency states should be optimized accordingly. With these hints, software can see improved cache hit rates and reduced coherency activity.

[0184] However, these advantages may be mitigated if the hardware prefetcher is not configured to use hints. The hardware prefetcher attempts to identify memory access patterns and submit requests to the memory system in advance of a load or store sequence. If the prefetcher correctly predicts such patterns but does not utilize hints to submit requests, this may reduce the advantages of certain embodiments.

[0185] To address these issues, a hardware prefetcher is configured to include hints about memory accesses as part of its access pattern prediction mechanism. Specifically, the hardware prefetcher is configured to (a) identify hints associated with load and store instructions, (b) record these hints, and (c) issue requests to the memory architecture using appropriate hints. There are several options for implementing these techniques. For the following discussion, for simplicity, the access type (i.e., read versus read-for-ownership (RFO)) will be ignored and all accesses are assumed to be reads. However, it should be noted that the basic principles of the present invention are applicable to other memory operations (e.g., RFO).

[0186] Fig. 27 An embodiment of a prefetcher 2701 is illustrated having a table 2702 for tracking address streams. For this type of prefetcher 2701, each entry of the table 2702 stores information for a single address stream within a single physical page of memory. In addition to the address of the corresponding page 2703, each table entry also stores the most recent page offset 2704 seen by the prefetcher 2701, the span 2706 detected between consecutive accesses to the page, a saturation counter 2707 that maintains a confidence level (e.g., the number of times the same span has been seen), and the state 2708 of the particular address stream (i.e., indicating whether training is still being performed on the stream or whether the prefetcher 2701 is actively prefetching for the stream). In the illustrated embodiment, each row in the prefetcher table 2702 also includes a hint value 2705 indicating a read sharing hint as described herein.

[0187] When the prefetcher 2701 is notified about a new memory access, it checks to see if a prefetch entry has been allocated for the page. For example, if the prefetcher 2701 is configured to be at the level of the L2 cache, it has visibility to all L1 misses that are redirected to the L2 cache, and updates the table 2702 accordingly. If the prefetch entry has not yet been allocated, the prefetcher 2701 allocates a new entry in response to the L1 miss. If the entry has been allocated, the prefetcher 2701 calculates the difference between the most recent offset value from the table 2702 and the page offset from the new access, and then compares the difference with the recorded span 2706. If they match, the confidence counter value 2702 is incremented (but it will saturate at a certain value, for example, for a 2-bit counter, saturation occurs when the value is 3). If they are different, the confidence counter is decremented, and if the counter is already 0, the span in the table is replaced by the newly calculated span. Once the prefetcher 2701 has sufficient confidence that it has detected a stream with a constant span (i.e., the confidence counter value 2707 exceeds some threshold), then for each incoming request for a given stream, the prefetcher 2701 generates one or more requests for that stream using a specific prefetch distance (i.e., some multiple of the span beyond the most recent offset).

[0188] Prefetcher 2702 may maintain a single entry for each stream / page. In one particular implementation, the hint value 2705 in each entry records the first hint value seen by prefetcher 2701 for any access to the corresponding page. Alternatively, prefetcher 2701 may record the most recent hint value seen. Subsequently, confidence counter 2707 is incremented only when the span and hint value match the corresponding values ​​2706 and 2705 in the entry, respectively. If the span is different or the hint is different, confidence counter 2707 is decremented. Further, when prefetcher 2701 sends requests for a given stream to the cache / memory subsystem, these requests carry hints from the entry for that stream in table 2702.

[0189] In one embodiment, if any subsequent request for the page is a request without a hint, then the hint field 2705 is set to "None" and will not be changed during the life of the stream. The confidence counter 2707 is trained in the same manner and is not affected by the hint field 2705. When the prefetcher 2701 sends requests for a given stream to the cache / memory subsystem, these requests carry hints for entries from that stream.

[0190] In an implementation where the most recent hint value seen by the prefetcher 2701 is recorded for the corresponding stream, the confidence counter 2707 is trained in the same manner and is not affected by the hint field. Requests to the cache / memory subsystem for a given stream continue to include hints for entries from that stream.

[0191] refer to Fig.28 , one implementation includes a hint confidence counter field 2801 that stores a value from a multi-bit (e.g., 2-bit) saturating counter. The hint confidence counter 2801 is trained by the hint value seen by the prefetcher 2701 for any access to the corresponding page. The counter value 2801 is incremented on hinted requests and decremented on unhinted requests. When a given stream triggers a request to the cache / memory subsystem, if the hint confidence counter value 2801 is greater than a threshold, a hinted request is generated. Otherwise, the prefetcher 2701 generates a regular request to the cache / memory subsystem. The original confidence counter 2707 is trained as previously described and is not affected by the hint confidence counter 2801.

[0192] refer to Fig.29 , one embodiment of the prefetcher table also includes a hint predictor vector 2901 in each entry to allow multiple interleaved streams to the same page to have different hint values ​​with the same span. Each element of the hint predictor vector 2901 includes a multi-bit saturation counter. In one implementation, there is one such counter for each hint that is tracked (but one type of hint is assumed in the discussion below).

[0193] like Fig.30 As illustrated in , when a request 3001 accesses a given stream, the address of the request is used to index into vector 2901 using a hash function (e.g., in this example, (Address>>log2(stride))&(#entry-1)((Address>>log2(span))&(entry number-1))). If the access is a hinted access, the corresponding counter value is incremented, otherwise the counter value is decremented. When a given stream sends a prefetch request to the cache / memory subsystem, the address of the prefetch request is used to index into the hint prefetcher using the same hash function. If the counter value is greater than a threshold, a hinted request is generated, otherwise a regular request is generated.

[0194] like Fig.31As shown, in another embodiment, the table is indexed not only with the physical page address but also with a hint value (as indicated in field 3101). This means that a given physical page may have multiple entries in the table. If software touches a given page with memory accesses with different hints, this may consume more table entries than the above embodiment, which may be useful if the software intentionally uses different hints to interleave accesses to different cache lines within a page (e.g., even cache lines use regular loads and odd cache lines use hinted loads). This also makes the confidence logic simpler than the embodiment described above.

[0195] Although several embodiments are described above in conjunction with specific instructions (such as the MOVRS instruction), the basic principles of the invention are applicable to any hint type. These embodiments include microarchitectural changes to the hardware prefetchers so that they will use the hint along with the address and operation type (read versus RFO) to train themselves and use the hint along with the address and operation type (read versus RFO) when issuing their own requests for predicted access streams.

[0196] References to "some examples," "certain examples," "example embodiments," etc. indicate that the described embodiments may include a particular feature, structure, or characteristic, but not every embodiment may necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in conjunction with some examples, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0197] Example

[0198] The following are example implementations of different embodiments of the invention.

[0199] Example 1. A processor, comprising: a plurality of cores for processing instructions; a first core of the plurality of cores comprising: a decoder circuit for decoding a single instruction, the single instruction having a first field and a second field, the first field for an opcode for indicating a read-shared load operation for reading data from a memory, and the second field for indicating at least one memory address for a location of the data in the memory; an execution circuit for executing the single instruction to read the data from the location in the memory; and a cache controller circuit for: initially storing the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

[0200] Example 2. The processor of Example 1, wherein the cache comprises a level 2 (L2) and / or a level 1 (L1) cache associated with the first core.

[0201] Example 3. The processor of example 1 or 2, wherein, in response to the opcode indicating a read shared load operation, the cache controller circuit is to additionally store the data in a shared state in at least a second cache line of a level 3 (L3) cache.

[0202] Example 4. A processor as described in any of Examples 1-3, wherein, in response to a request from a second core of the plurality of cores, the cache controller circuit is to store the data in a shared state in at least a third cache line of an L2 and / or L1 cache of the second core.

[0203] Example 5. The processor of any of Examples 1-4, wherein in response to the data being changed by the first core to produce modified data, the shared state of the first cache line is to be changed to a modified state.

[0204] Example 6. A processor as described in any of Examples 1-5, wherein, in response to a request for data by a second core of the plurality of cores, the cache controller circuit is to snoop a first cache line in a cache associated with the first core and store a copy of the modified data in a shared state in a cache associated with the second core.

[0205] Example 7. The processor of any of Examples 1-6, wherein the cache controller circuit is to further store a copy of the modified data in a shared state in a level 3 (L3) cache.

[0206] Example 8. The processor of any of Examples 1-7, wherein the opcode of the single instruction is to indicate that the load operation comprises a slice load operation, and wherein the data comprises a plurality of matrix data elements to be stored in a slice register.

[0207] Example 9. The processor of any of Examples 1-7, wherein the opcode of the single instruction is to indicate that the load operation comprises a vector load operation, and wherein the data comprises a plurality of vector data elements to be stored in a vector or packed data register.

[0208] Example 10. A non-transitory machine-readable medium having instructions stored thereon that, when processed by a machine, cause the machine to perform operations, the operations comprising: processing instructions on a plurality of cores; decoding, by a first core of the plurality of cores, a single instruction having a first field for an opcode indicating a read-shared load operation to read data from a memory and a second field indicating at least one memory address for a location of the data in the memory; executing circuitry executing the single instruction to read the data from the location in the memory; and cache controller circuitry initially storing the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

[0209] Example 11. The non-transitory machine-readable medium of Example 10, wherein the cache comprises a level 2 (L2) and / or a level 1 (L1) cache associated with the first core.

[0210] Example 12. The non-transitory machine-readable medium of Example 10 or 11, wherein, in response to the opcode indicating a read shared load operation, the cache controller circuit is to additionally store the data in at least a second cache line of a level 3 (L3) cache in a shared state.

[0211] Example 13. The non-transitory machine-readable medium of any of Examples 10-12, wherein, in response to a request from a second core of the plurality of cores, the cache controller circuit is to store the data in a shared state in at least a third cache line of an L2 and / or L1 cache of the second core.

[0212] Example 14. The non-transitory machine readable medium of any of Examples 10-13, wherein in response to the data being changed by the first core to produce modified data, the shared state of the first cache line is to be changed to a modified state.

[0213] Example 15. The non-transitory machine-readable medium of any of Examples 10-14, wherein, in response to a request for data by a second core of the plurality of cores, the cache controller circuit is to snoop a first cache line in a cache associated with the first core and store a copy of the modified data in a shared state in a cache associated with the second core.

[0214] Example 16. The non-transitory machine-readable medium of any of Examples 10-15, wherein the cache controller circuit is to further store a copy of the modified data in a level 3 (L3) cache in a shared state.

[0215] Example 17. A method, comprising: processing instructions on a plurality of cores; decoding, by a first core of the plurality of cores, a single instruction having a first field and a second field, the first field being for an opcode indicating a read-shared load operation to read data from a memory, and the second field being for indicating at least one memory address for a location of the data in the memory; executing circuitry executing the single instruction to read the data from the location in the memory; and cache controller circuitry initially storing the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

[0216] Example 18. The method of Example 17, wherein the cache comprises a level 2 (L2) and / or a level 1 (L1) cache associated with the first core.

[0217] Example 19. The method of Example 17 or 18, wherein, in response to the opcode indicating a read shared load operation, the cache controller circuit is to additionally store the data in at least a second cache line of a level 3 (L3) cache in a shared state.

[0218] Example 20. The method of any of Examples 17-19, wherein, in response to a request from a second core of the plurality of cores, the cache controller circuit is to store the data in a shared state in at least a third cache line of an L2 and / or L1 cache of the second core.

[0219] Furthermore, in the examples described above, unless specifically stated otherwise, separation language such as the phrase "at least one of A, B, or C" is intended to be understood to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Thus, separation language is not intended to and should not be understood to imply that a given embodiment requires that at least one of A, at least one of B, or at least one of C each be present.

[0220] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the claims.

Claims

1. A processor, comprising: Multiple cores for processing instructions; A first core of the plurality of cores comprises: a decoder circuit for decoding a single instruction having a first field for an opcode indicating a read-shared load operation to read data from a memory and a second field indicating at least one memory address for a location of the data in the memory; execution circuitry for executing the single instruction to read the data from the location in the memory; and A cache controller circuit is configured to initially store the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

2. The processor of claim 1, wherein: The cache includes a second level L2 and / or a first level L1 cache associated with the first core.

3. The processor according to claim 1 or 2, wherein: In response to the operation code indicating the read-shared load operation, the cache controller circuit is used to additionally store the data in at least a second cache line of a third level L3 cache in a shared state.

4. The processor according to any one of claims 1 to 3, wherein: In response to a request from a second core among the plurality of cores, the cache controller circuit is configured to store the data in a shared state in at least a third cache line of an L2 and / or L1 cache of the second core.

5. The processor according to any one of claims 1 to 4, wherein: In response to the data being changed by the first core to produce modified data, a shared state of the first cache line is to be changed to a modified state.

6. The processor of claim 5, wherein: In response to a request for the data by a second core of the plurality of cores, the cache controller circuit is to snoop the first cache line in a cache associated with the first core and store a copy of the modified data in a shared state in a cache associated with the second core.

7. The processor of claim 6, wherein: The cache controller circuit is further configured to store a copy of the modified data in a third level L3 cache in a shared state.

8. The processor according to any one of claims 1 to 7, wherein: The opcode of the single instruction is to indicate that the load operation comprises a slice load operation, and wherein the data comprises a plurality of matrix data elements to be stored in a slice register.

9. The processor according to any one of claims 1 to 8, wherein: The opcode of the single instruction is used to indicate that the load operation comprises a vector load operation, and wherein the data comprises a plurality of vector data elements to be stored in a vector or packed data register.

10. A non-transitory machine-readable medium having instructions stored thereon, the instructions, when processed by a machine, causing the machine to perform operations comprising: Process instructions on multiple cores; decoding, by a first core of the plurality of cores, a single instruction having a first field for an opcode indicating a read-shared load operation to read data from a memory and a second field indicating at least one memory address for a location of the data in the memory; execution circuitry executing the single instruction to read the data from the location in the memory; as well as Cache controller circuitry initially stores the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

11. The non-transitory machine-readable medium of claim 10, wherein: The cache includes a second level L2 and / or a first level L1 cache associated with the first core.

12. The non-transitory machine-readable medium of claim 10 or 11, wherein: In response to the operation code indicating the read-shared load operation, the cache controller circuit is to additionally store the data in at least a second cache line of a third level L3 cache in a shared state.

13. The non-transitory machine-readable medium of any one of claims 10 to 12, wherein: In response to a request from a second core of the plurality of cores, the cache controller circuit is to store the data in at least a third cache line of an L2 and / or L1 cache of the second core in a shared state.

14. The non-transitory machine-readable medium of any one of claims 10 to 13, wherein: In response to the data being changed by the first core to produce modified data, a shared state of the first cache line is to be changed to a modified state.

15. The non-transitory machine-readable medium of claim 14, wherein: In response to a request for the data by a second core of the plurality of cores, the cache controller circuit is to snoop the first cache line in a cache associated with the first core and store a copy of the modified data in a shared state in a cache associated with the second core.

16. The non-transitory machine-readable medium of claim 15, wherein: The cache controller circuit is further to store a copy of the modified data in a third level L3 cache in a shared state.

17. A method comprising: Process instructions on multiple cores; decoding, by a first core of the plurality of cores, a single instruction having a first field for an opcode indicating a read-shared load operation to read data from a memory and a second field indicating at least one memory address for a location of the data in the memory; execution circuitry executing the single instruction to read the data from the location in the memory; as well as Cache controller circuitry initially stores the data in a shared state in at least a first cache line of a cache associated with the first core based on the opcode indicating the read-shared load operation.

18. The method of claim 17, wherein: The cache includes a second level L2 and / or a first level L1 cache associated with the first core.

19. The method according to claim 17 or 18, wherein: In response to the operation code indicating the read-shared load operation, the cache controller circuit is to additionally store the data in at least a second cache line of a third level L3 cache in a shared state.

20. The method of any one of claims 17 to 19, wherein: In response to a request from a second core of the plurality of cores, the cache controller circuit is to store the data in at least a third cache line of an L2 and / or L1 cache of the second core in a shared state.

Images