Prefetcher for delayed irregular loads
阅读说明：本技术 用于延迟的不规则载荷的预取器 (Prefetcher for delayed irregular loads ) 是由 K.桑卡拉纳拉雅南 S.J.塔萨 G.N.钦亚 H.奈伊米 于 2019-05-28 设计创作，主要内容包括：所公开的实施例涉及一种用于延迟的不规则载荷的预取器。在一个示例中,处理器包含：高速缓冲存储器；提取和解码电路,用于从存储器提取和解码指令；以及执行电路,包含二进制翻译器(BT),用于通过如下方式响应解码的指令：将多个解码的指令存储在BT高速缓存中,标识多个解码的指令之中的延迟的不规则载荷(DIRRL),确定DIRRL是否是可预取的,并且如果是,则生成定制预取器以使处理器预取引导到可预取DIRRL的指令区域。(The disclosed embodiments relate to a prefetcher for delayed irregular loads. In one example, a processor comprises: a cache memory; fetch and decode circuitry to fetch and decode instructions from memory; and execution circuitry comprising a Binary Translator (BT) responsive to the decoded instruction by: storing a plurality of decoded instructions in a BT cache, identifying a delayed irregular load (DIRRL) among the plurality of decoded instructions, determining whether the DIRRL is prefetcheable, and if so, generating a custom prefetcher to cause a processor to prefetch an instruction region directed to the prefetcheable DIRRL.)
1. A processor, comprising:
a cache memory;
fetch and decode circuitry to fetch and decode instructions from memory; and
a Binary Translator (BT) to respond to the decoded instruction by:
storing a plurality of the decoded instructions in a BT cache;
identifying a delayed irregular load (DIRRL) among the stored instructions;
determining whether the DIRRL is prefetcheable; and is
If so, a custom prefetcher is generated to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
2. The processor of claim 1, wherein the DIRRL is a latency load that experiences more than a first threshold number of cache misses on consecutive dynamic instances.
3. The processor of claim 2, wherein the DIRRL is an irregular payload having at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
4. The processor of claim 3, wherein the execution circuitry computes a post-slice between two consecutive dynamic instances of the DIRRL, and determines that the DIRRL is pre-prefetchable when the post-slice comprises a loop consisting entirely of non-memory operations or regular memory operations.
5. The processor of claim 4, wherein the custom prefetcher, when executing the prefetch, causes the processor to execute one or more critical loads among the post-slices before executing non-critical loads.
6. The processor of any of claims 4-5, wherein the custom prefetcher is to cause the processor to prefetch a plurality of irregular payloads containing fewer instructions than are contained in the post-slice.
7. The processor of any one of claims 1, 4, and 5, wherein the customized prefetcher comprises one or more prefetch hints among the plurality of instructions stored in the memory.
8. The processor of any one of claims 1, 4, and 5, wherein the custom prefetcher comprises a hardware prefetcher using the execution circuitry.
9. The processor of any one of claims 1, 4, and 5, wherein the processor further comprises execution circuitry, and wherein the BT is separate from the execution circuitry.
10. The processor of any one of claims 1, 4 and 5, wherein the processor further comprises execution circuitry, and wherein the BT is incorporated into the execution circuitry.
11. A method performed by a processor, the processor comprising:
a cache memory;
fetch and decode circuitry to fetch and decode instructions from memory; and
execution circuitry comprising a Binary Translator (BT) to respond to the decoded instruction by:
storing a plurality of the decoded instructions in a BT cache;
identifying a delayed irregular load (DIRRL) among the stored instructions;
determining whether the DIRRL is prefetcheable; and is
If so, a custom prefetcher is generated to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
12. The method of claim 11 wherein the DIRRL is a latency load that experiences more than a first threshold number of cache misses on consecutive dynamic instances.
13. The method of claim 12 wherein the DIRRL is an irregular payload having at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
14. The method of claim 13, wherein the execution circuitry computes a post-slice between two consecutive dynamic instances of the DIRRL and determines that the DIRRL is prefetcheable when the post-slice comprises a loop consisting entirely of non-memory operations or regular memory operations.
15. The method of claim 14, wherein the custom prefetcher focuses the processor on one or more critical loads in the post-slice by enqueuing only the one or more critical loads and not others.
16. The method of any of claims 14-15, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than contained in the post-slice.
17. The method of any of claims 14-15, wherein the customized prefetcher includes one or more prefetch hints among the plurality of instructions stored in the memory.
18. The method of any of claims 11, 14, and 15, wherein the custom prefetcher comprises a hardware prefetcher using the execution circuitry.
19. The method of any of claims 11, 14, and 15, wherein the custom prefetcher includes one or more prefetch hint instructions to be executed using an existing instruction execution pipeline of the processor.
20. The method of any of claims 11, 14, and 15, wherein the customized prefetcher comprises a hardware prefetcher that uses an existing execution cluster of the processor.
21. A machine-readable medium comprising code, which when executed, causes a machine to perform the method of any of claims 11-20.
Technical Field
Background
As out-of-order cores become wider and deeper, micro-architectural performance tends to become more limited by two bottlenecks: cache misses and branch mispredictions. Data prefetching can improve the performance of many applications. By a combination of hardware and software, prefetching data before it is actually needed can result in reduced latency for memory accesses.
The impact of cache misses can be mitigated in a number of ways, including: 1) hiding latency of misses by using out-of-order execution; 2) customizing the cache replacement policy to better match the needs of the application; and 3) by prefetching memory locations before the actual demand occurs.
The load instructions can be classified into several categories, including: a) its virtual address remains a constant load that is constant across multiple dynamic instances; b) stride loads with consecutive virtual addresses, primarily in arithmetic progression; and c) irregular loads that are neither constant loads nor step loads.
Also, as described herein, a load that misses frequently (i.e., more than a threshold number of times, e.g., 100, 1000, 10,000, etc.) in a cache is referred to as a latency load.
The irregular loading of prefetch delays remains an open challenge.
Drawings
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1A is a block diagram illustrating processing components for executing instructions, in accordance with some embodiments;
FIG. 1B is a block diagram illustrating processing components for executing instructions, in accordance with some embodiments;
FIG. 2 is a block diagram of a system for generating application-specific customized prefetchers according to some embodiments;
FIG. 3A is a block flow diagram of operations performed by a processor to generate an application specific custom prefetcher according to some embodiments;
FIG. 3B is a block flow diagram of operations performed by a processor to generate an application specific custom prefetcher according to some embodiments;
FIG. 4A is a code listing illustrating a back slice (backslice), in accordance with some embodiments;
FIG. 4B is a custom hardware prefetcher generated for the code listing of FIG. 4A in accordance with some embodiments;
FIG. 4C is a custom software prefetcher generated for the code listing of FIG. 4A in accordance with some embodiments;
FIG. 5A is a code listing of instruction regions directed to delayed irregular loads according to some embodiments;
FIG. 5B is a block flow diagram of an instruction flow of the code listing of FIG. 5A, according to some embodiments;
FIG. 6A is a code listing of instruction regions directed to delayed irregular loading according to some embodiments;
FIG. 6B is a block flow diagram of an instruction flow of the code listing of FIG. 6A, according to some embodiments;
FIG. 6C is another more detailed block flow diagram of the instruction flow of the code listing of FIG. 6A, according to some embodiments;
FIG. 7A illustrates an exemplary application specific custom software prefetcher according to some embodiments;
FIG. 7B illustrates an exemplary application specific custom hardware prefetcher corresponding to the custom software prefetcher of FIG. 7A in accordance with some embodiments;
8A-8B are block diagrams illustrating a generic vector friendly instruction format and instruction templates thereof according to some embodiments of the invention;
FIG. 8A is a block diagram illustrating a generic vector friendly instruction format and class A instruction templates thereof according to some embodiments of the invention;
FIG. 8B is a block diagram illustrating the generic vector friendly instruction format and class B instruction templates thereof according to some embodiments of the invention;
FIG. 9A is a block diagram illustrating an exemplary specific vector friendly instruction format according to some embodiments of the invention;
FIG. 9B is a block diagram illustrating fields of a particular vector friendly instruction format that make up a full opcode field, according to one embodiment;
FIG. 9C is a block diagram illustrating fields of a particular vector friendly instruction format that make up a register index field according to one embodiment;
FIG. 9D is a block diagram illustrating fields of a particular vector friendly instruction format that make up an augmentation operation field, according to one embodiment;
FIG. 10 is a block diagram of a register architecture according to one embodiment;
FIG. 11A is a block diagram illustrating an example in-order pipeline and an example register renaming, out-of-order issue/execution pipeline, in accordance with some embodiments;
FIG. 11B is a block diagram illustrating an exemplary embodiment of an exemplary register renaming out-of-order issue/execution architecture core and an in-order architecture core to be included in a processor in accordance with some embodiments;
12A-B illustrate block diagrams of more specific example in-order core architectures that would be one of several logic blocks (containing other cores of the same type and/or different types) in a chip;
FIG. 12A is a block diagram of a single processor core along with its connection to an on-die interconnect network and its local subset of a level 2 (L2) cache, according to some embodiments;
FIG. 12B is an expanded view of a portion of the processor core in FIG. 12A, in accordance with some embodiments;
FIG. 13 is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics in accordance with some embodiments;
FIGS. 14-17 are block diagrams of exemplary computer architectures;
FIG. 14 illustrates a block diagram of a system according to some embodiments;
fig. 15 is a block diagram of a first more particular exemplary system, in accordance with some embodiments;
fig. 16 is a block diagram of a second more particular exemplary system, in accordance with some embodiments;
FIG. 17 is a block diagram of a system on a chip (SoC) in accordance with some embodiments; and
FIG. 18 is a block diagram that compares the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set, according to some embodiments.
Detailed Description
In the following description, numerous specific details are set forth. However, it is understood that some embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a feature, structure, or characteristic, but every embodiment may not necessarily include the feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments if explicitly described.
The disclosed embodiments describe an improved system and method for generating an application-specific custom prefetcher specifically designed for each Delay (DIRRL), sometimes referred to as a difficult-to-prefetch (HTP) or (HTP) payload, using profiling and analysis, for example, performed by a runtime Binary Translator (BT). According to some embodiments, BT analyzes loops in backward slices (also referred to as "post slices") of the instructions of the DIRRL to determine whether the DIRRL is prefetcheable. If so, BT either generates specific code containing prefetch hint instructions or configures a custom hardware prefetcher to prefetch one or more payloads in a region of code containing DIRRL.
Unlike some failed approaches, the disclosed embodiments avoid relying on large amounts of on-chip storage to record address patterns and attempt to predict future addresses. In addition to requiring an excessively high amount of on-chip memory, the difficulty of implementing this approach in real hardware can be seen in its absence in commercial transport processors.
The disclosed embodiments also avoid a resource intensive, compute-based prefetching approach that uses a separate helper thread to execute instructions from a program ahead of time to prefetch a delayed payload. Moreover, it is difficult to ensure that the helper thread does not far exceed the main thread, which in fact eventually pollutes the cache.
The disclosed embodiments improve the processor architecture and its prefetch performance in several ways. One advantage of the disclosed embodiments is the possibility of highly accurate prefetching with low overhead, because the prefetcher generated is part of the main thread itself, and there is no need for spare thread context or large memory. Moreover, since the prefetcher code (or custom hardware) is generated to keep a constant number of iterations before the main computation, no additional effort needs to be expended to match the rate of the main thread and prefetcher. Still further, with prefetching inserted only in delayed irregular payload Instruction Pointers (IPs), cache and memory bandwidth interference is kept to a minimum.
In describing the disclosed embodiments below, a number of terms are defined herein and are used as part of the description of the disclosed embodiments. As used herein, "delayed" loads are those load instructions that have a number of first level cache misses greater than a threshold (e.g., 1K, 10K, etc.). As further used herein, an "address increment" of a payload instruction is defined as the difference in value between the virtual addresses of its successive dynamic instances. Still further, in some embodiments, the "irregular" payload is those payload instructions having at least ten unique address increments, and the ten most popular unique increments still cover less than 90% of all increments. This definition distinguishes regular patterns, such as multidimensional arrays and other occasionally irregular (but primarily strided) loads, from irregular loads in the context of the disclosed embodiments.
As described herein, and as illustrated with respect to fig. 2, some disclosed embodiments are comprised of three parts: 1) parser, 2) optimizer, and 3) prefetcher.
Dissector
According to some embodiments, the profiler identifies delayed irregular loading. In some embodiments, the profiler is a combination of both hardware and Binary Translator (BT) software. In such embodiments, the hardware tracks data cache misses for each load instruction in flight to identify the delayed load. In some embodiments, the BT software runs detailed address increment profiling on the identified delayed payloads to classify them as regular or irregular payloads.
When the disclosed embodiments are incorporated into a processor that already has a stride detection prefetcher, the address increment information that would otherwise be available to the processor can also be passed to the BT software for analysis. Incorporating the disclosed embodiments into a processor may thus improve the prefetch performance of the processor without adding too much, if any, cost.
In some embodiments, the disclosed profiler operates online (concurrently with profiling the thread), and in other embodiments, operates offline (at a different time than the actual runtime of the thread, e.g., by analyzing the source code in advance).
Optimizer
Some disclosed embodiments further include an optimizer that analyzes the executing code to calculate a for delayed irregular loads. As used herein, a post-slice (also referred to as a post-slice) of a delayed irregular payload is a set of instructions in a program that execute before and directly or indirectly contribute to operands of the delayed irregular payload instruction. Based on the address increment of the instruction in the post-slice (received from the profiler), the optimizer then identifies the "prefetcheable" payload as one whose post-slice consists entirely of non-memory operations or regular memory operations. The optimizer will then generate a custom prefetcher for the region of code containing the prefetcheable payload.
Customized prefetcher
The custom prefetcher generated by the optimizer can be either software (code generated with prefetch hint instructions; see, e.g., FIG. 7A) or hardware (custom hardware that captures the data stream of address computations; see, e.g., FIG. 7B).
It should be understood that for simplicity, 1) the parser, 2) the optimizer, and 3) the prefetcher are described herein as separate components. Indeed, in some embodiments, all three of 1) the parser, 2) the optimizer, and 3) the prefetcher are incorporated in what is broadly referred to as "execution circuitry" and portions thereof. The same is true with respect to the binary translator described herein. In some embodiments, the binary translator is incorporated in the "execution circuitry", while in other embodiments BT is separate from and external to the execution circuitry.
FIG. 1A is a block diagram illustrating processing components for executing instructions, in accordance with some embodiments. As illustrated, storage 101 stores instruction(s) 103 to be executed. As described further below, in some embodiments,
In operation, instruction(s) 103 are fetched from storage 101 by fetch
In some embodiments, register renaming, register allocating and/or
Registers (register files) and/or memory 115 store data as operands to decoded instructions 111 that are operated on by
In some embodiments, the register file and/or memory 115 includes a cache hierarchy, including L1, L2, and L3 (or LLC) caches. In some embodiments, the caches are unified, and other embodiments have separate data and instruction caches. Exemplary register types include writemask registers, packed data registers, general purpose registers, and floating point registers, as further described and illustrated below at least with respect to FIG. 10.
In some embodiments, the writeback circuitry 120 commits the results of executing the decoded instruction 111. The
FIG. 1B is a block diagram illustrating processing components for executing instructions, in accordance with some embodiments. As illustrated, storage 151 stores instruction(s) 153 to be executed. As described further below, in some embodiments, the
In operation, instruction(s) 153 are fetched from storage 151 by fetch
In some embodiments, register renaming, register allocating and/or
Registers (register files) and/or
In some embodiments, the register file and/or
In some embodiments, the writeback circuitry 170 commits the results of executing the decoded
FIG. 2 is a block diagram of a system for generating application-specific customized prefetchers according to some embodiments. As shown,
FIG. 3A is a block flow diagram of operations performed by a processor to generate an application specific custom prefetcher according to some embodiments. The processor executes
FIG. 3B is a block flow diagram of operations performed by a processor to generate an application specific custom prefetcher according to some embodiments. The processor will perform
Fig. 4A is a code listing illustrating a post-slice according to some embodiments. As shown, the code listing 400 defines an exemplary function foo (). For ease of discussion, the code listing is shown in a relatively easy to understand C programming language syntax. Some embodiments (e.g., embodiments that analyze code segments offline and in advance) are able to generate application-specific custom prefetchers by analyzing code segments in a high-level programming language, such as C. However, some embodiments analyze instructions in assembly code format using a hardware binary translator to dynamically and online generate application specific custom prefetchers. For example, a code segment having an assembly instruction format is illustrated and described with respect to FIGS. 5A, 6A, and 7A. In some embodiments, the code to be analyzed includes macro-operations generated by decoding circuitry, such as decoding circuitry 109 (fig. 1).
As shown, the instruction at line 0160 is the target instruction 402, and a "post-slice" leading to the target instruction is to be computed. As used herein, a "post-slice" is a set of all instructions that directly or indirectly contribute to a computation performed in a target instruction. In some embodiments, instructions to be included in the post-slice can be identified by working backwards from the target instructions 402 to identify all contributing instructions that make up the post-slice 404. For example, the instruction at line 0140 contributes directly to the target instruction 402 because it sets the operands of the instruction. Working backwards from the instruction at 0140, the instructions at 0110, 0090, and 0070 will be contained in the post-slice 404, as they indirectly contribute to the computation of the target instruction 402. In some embodiments, as here, the target instruction 402 is part of a loop, and the post-slice extends backward, but stops at the beginning of the current iteration.
Notably, some instructions in the code listing 400 do not directly or indirectly contribute to the computation of the target instruction 402, and are therefore not included in the post-slice 404. For example, instructions at rows 0080, 0100, 0120, and 0150 are not included in the post-slice. The instructions at lines 0130 and 0170, even though they affect the operand 'c' used in the target instruction 402, are not included in the post-slice because the value of 'c' set by those instructions is overwritten before reaching the target instruction 402.
FIG. 4B is a custom hardware prefetcher generated for the code listing of FIG. 4A according to some embodiments. As shown, the custom hardware prefetcher 420 contains a first-in-first-out (FIFO) buffer 421, the buffer 421 having pointers for a head 422 and a tail 424, and where instructions at lines [0090], [0110] and [0140] from the code manifest 400 (FIG. 4A) have been enqueued. Custom hardware prefetch control circuitry 426, arithmetic/logic unit (ALU) 428, and Memory Load Unit (MLU) 430 are also shown.
For simplicity, and to illustrate operation of the disclosed embodiments, instructions enqueued in FIFO 421 are shown in a format according to a high-level programming language (such as Basic, C, Fortran, or C + +). However, in some embodiments, those instructions will instead be stored as decoded micro-or macro-operations generated by decoding circuitry, such as decoding circuitry 109 (fig. 1A) or 159 (fig. 1B).
In operation, the custom hardware prefetch control circuitry 426 will cause one or more instructions within the instruction region directed to the target instruction 402 (FIG. 4A) to be enqueued in the FIFO 421, and then cause the processor to perform the resulting arithmetic operations (if any, using ALU 428) and memory load (if any, using MLU 430).
In other embodiments, a different instruction from the code listing 400 is selected for inclusion in the FIFO 421. For example, if one of the instructions is identified as a "critical load," as described below, control circuitry 426 may cause the processor to focus on that instruction by enqueuing that instruction only, while the other instructions are not enqueued. In some embodiments, the entire rear slice 404 (fig. 4A) is added to the FIFO 421 and executed by the processor.
The FIFO 421, custom hardware prefetch control circuit 426, ALU 428, and MLU 430 are all optional, as indicated by their dashed borders, in which case they may use hardware resources already contained in the processor, they may use firmware or software, or they may not be included at all. For example, the FIFO 421 may be implemented in memory already available to the processor. Some embodiments implement FIFO 421 using registers in a processor's register file. Some embodiments implement FIFO 421 using several special purpose registers. Some embodiments use a different memory organization than the FIFO 421, such as random access memory. For example, ALU 428 may include one or more dedicated ALUs to perform arithmetic operations. In some embodiments, ALU 428 uses existing processor execution unit(s) 1162 within execution cluster(s) 1160, as illustrated and described with respect to FIGS. 11A-B.
FIG. 4C is a customized software prefetcher generated for the code listing of FIG. 4A according to some embodiments. As shown,
For simplicity, and to illustrate operation of the disclosed embodiments, instructions enqueued in FIFO 441 are shown in a format according to a high-level programming language (such as Basic, C, Fortran, or C + +). However, in some embodiments, those instructions will instead be stored as decoded micro-or macro-operations generated by decoding circuitry, such as decoding circuitry 109 (fig. 1A) or 159 (fig. 1B).
In operation, custom software
In other embodiments, a different instruction from code listing 400 is selected for inclusion in FIFO 441. For example, if one of the instructions is identified as a "critical load," as described below,
The FIFO 441 and the customization software prefetch control circuit 426 are optional in the case where they may use resources already contained in the processor, or they may not be contained at all, as indicated by their dashed borders. For example, FIFO 441 may be implemented within memory already available to the processor. For example, one or more hints enqueued in FIFO 441 might instead be stored in instructions in memory. Some embodiments implement FIFO 441 using registers in a processor's register file. Some embodiments implement FIFO 441 using several dedicated registers. Some embodiments use a different memory organization than FIFO 441, such as random access memory. In some embodiments,
Identifying post-slices for exemplary assembly
FIG. 5A is a code listing of instructions to be parsed by a profiler and then optimized by an optimizer, according to some embodiments. As shown, each instruction in the assembly
Also illustrated is an arc defining a post-slice of the
FIG. 5B illustrates a post-slicing of the instruction flow of FIG. 5A as a flow diagram. As shown, the seven arcs labeled a through G identify the same seven arcs between the same eight post-slicing instructions (which are represented here by eight flow diagram nodes) that trace back to 1500. In particular, the eight flow diagram nodes labeled 522, 524, 526, 528, 530, 532, 534, and 536 correspond to the eight instructions at
In operation, according to some embodiments, a processor having a Binary Translator (BT) including a BT cache stores the instruction stream of trace back 1500 to the BT cache, as described further below with respect to FIGS. 5A-B and 6A-B. Using a profiler, the binary translator identifies a delayed irregular load (DIRRL). Then, using an optimizer, as described below, BT determines whether DIRRL is prefetcheable and, if so, generates a custom prefetcher to cause the processor to prefetch an instruction region directed to prefetcheable DIRRL. The generated customized prefetcher can be implemented in software and/or hardware.
Post-slice analysis and prefetcher generation for
FIG. 6A is a code listing of assembly instructions to be parsed by a profiler and then optimized by an optimizer, according to some embodiments. As shown, each instruction in the assembly code manifest trace 2600 includes an address, an opcode, and an operand, and some have comments indicating their instruction type. Trace back 2600 is sometimes referred to as a "hot region" and is also a loop here (having 48 instructions) but with a more complex control flow (shown in FIGS. 6B and 6C). It has two striding loads (0 x765 and 0x 770) and four irregular loads (0 x7cb, 0x7dc, 0x7ea, 0x7 fb), but no storage. It also has three branches with high misprediction rates on the common branch prediction circuit.
Also illustrated is an arc defining a post-slice of traceback 2600. Beginning with the last irregular load in the loop, the delayed irregular load at 0x7fb, arcs A, B, D, E, F, R, and S identify the dependency chain that comes all the way back through the instructions at 0x7f4, 0x7f1, 0x7ee, 0x7bf, 0x765,
For ease of illustration and discussion, the code listing trace 2600 has been divided into eight (8) regions, labeled a 602, B604, C606, D608, E610, F612, G614, and H616,each of which ends in a branch instruction. The 8 regions illustrated are further described and illustrated in fig. 6B, which fig. 6B contains nodes in the flow diagram for each region.
Fig. 6B is a control flow diagram illustrating a post-slice of the region traced back 2600 as defined in fig. 6A as a flow block. As shown, the
Fig. 6C illustrates a post-slicing of the instruction flow of trace back 2 of fig. 6A as a flow block diagram. As shown, the
As illustrated and described with respect to fig. 5B, 6B, and 6C, the post-slicing of
In fig. 5B and 6C, nodes representing regular and constant loads are marked with a "# symbol, and irregular loads are marked with a" # symbol. It can be seen that the number of instructions in the post-slice of the irregular load is significantly smaller than the size of the loop (8 <17 in
Another advantage of the disclosed embodiments is that the loop in this post-slice captures the critical relationship between successive iterations of irregular loading. The cycle describes the following: the computation performed by the later instruction depends on the output of the earlier instruction and produces a new value that itself is relied upon by the previous instruction when the instruction is subsequently executed. For example, fig. 5B shows two cycles, which are: (0 xee7,00 eea) and (0 xee2,0 xefb). Of these, the latter is a simple loop, consisting of register moves only, and can be ignored. Similarly, there are three cycles in the region from trace back 2: (0 x7e 6), (0 x765,0x7 bf), and (0 x770,0x7c 5). These loops capture the substantial recursive relationship between virtual addresses of successive dynamic instances of the irregular payload. Note that these loops have a significantly smaller number of instructions than the post-slice itself (4 to 8 in
The optimizer determines whether "Preprefetchable"
The optimizer determines whether the delayed irregular payload is prefetcheable by analyzing the post-slice of the instruction. "prefetcheable" payloads are those whose slices have a loop that consists entirely of non-memory operations or regular memory operations. If the irregular latency payload is determined to be prefetcheable, the optimizer generates a customized prefetcher for a region of code containing the prefetcheable payload.
In some embodiments, all cycles in the region from
Thus, as long as the loops are executed long enough, they can be "run" (by prefetching stride loads) for multiple iterations before the main computation. On the other hand, a non-simple cycle in trace back 1 (0 xee7,0 xeea) has one constant address load (0 xee 7), but the other load (0 xeea) is irregular. Therefore, it is not possible to "run" this loop simply by prefetching
As described above, the optimizer performs a data flow analysis on regions with irregular loading. It generates a dataflow graph for the integer dataflow of address computations and enumerates all the primary cycles in the graph. If no primary loop has any irregular memory operations, the optimizer determines the region as prefetcheable and generates a custom prefetcher for it.
Another advantageous aspect of the disclosed embodiments stems from the fact that: the prevailing pattern in the irregular payload is indirect with the stride payload, i.e., the value of the stride payload is used as the address of the irregular payload with optional linear transformations (K1 × address + K2, where K1 and K2 are constants). This occurs in an indirect program access mode, such as A [ B [ i ] ], where B is a contiguous array of indexes. The techniques applied in the disclosed embodiments will not only determine such scenarios as prefetcheable and generate custom prefetchers for them, but will also be applicable to the more general case where the transform energy is any arbitrary function (not necessarily linear, i.e. A [ f (B [ i ] ]), where f is an arbitrary function).
Optimizer generation of customized prefetchers
According to the disclosed embodiments, the next step after identifying prefetcheable payloads is to generate custom prefetchers for them. In some embodiments, a software profiler applies heuristics to define a custom prefetcher, either as software or as hardware, to prefetch a calculated number of instruction iteration values from a loop, where the calculation involves estimating how long it will take to execute instructions in the loop, and then prefetch enough loop iterations to establish a "look ahead" and remain sufficiently ahead of code instructions to hide the latency encountered by cache misses.
Still further, in some embodiments, the software profiler identifies one or more "critical loads" of loops that are expected to require a relatively high number of loops to execute, and then generates a customized prefetcher for those critical load(s). The critical load may include loads that experience frequent cache misses. The critical loads may include loads coupled with complex arithmetic operations. In some embodiments, the custom prefetcher focuses the processor on the critical load (if any). To focus on critical loads, the custom prefetcher may cause the processor to execute those critical loads before non-critical operations.
In some embodiments, the operations performed in the post-slice and selected for inclusion in the custom prefetcher, in addition to register movement, are load and arithmetic and/or logical operations, all of which are implemented using several dedicated address generation units and ALUs in the case of a hardware prefetcher. The selected arithmetic and/or logical operations (if any) include one or more of addition, subtraction, increment, decrement, multiplication, division, and, or, xor, negate, and shift. In some embodiments, the selected arithmetic operation, in some embodiments, comprises a complex number operation, such as a square root. In some embodiments, the selected arithmetic operation comprises a trigonometric operation.
FIG. 7A illustrates an exemplary application specific custom software prefetcher according to some embodiments. Illustrated is a custom software prefetcher generated for trace back 2 using the prefetch hint instruction '
In some embodiments, all of the payload in the custom
FIG. 7B illustrates an exemplary application specific custom hardware prefetcher corresponding to the custom software prefetcher of FIG. 7A in accordance with some embodiments. The hardware prefetcher 720 is a hardware alternative to the prefetcher for trace back 2 and is implemented in custom hardware that is tightly coupled to the strided payload prefetcher of the CPU (strider 1722 and strider 2724 in fig. 7B). The input to the stride block is a stride payload instruction (at addresses 0x765 and 0x 770) for which the user wants to track the address. The "value" blocks 726 and 728 access the cache and data translation look-aside buffer (DTLB), while the "+" operations 730 and 732 and the "& operations 734 and 736 are addition operations and bitwise AND operations, respectively. The "address" block 738 is an address generation unit that calculates a virtual address 742 based on the value 740 and the base-index-scale input. For clarity, FIG. 7B shows a scenario in which the prefetcher remains one iteration before the main computation. However, this look-ahead can be incremented by configuring the striders to correspondingly remain further advanced and by reusing the ALUs for multiple iterations of the look-ahead. It is noted that in some embodiments, this hardware is enabled when entering a loop and disabled when exiting therefrom.
Further examples
Example 1 provides an exemplary processor, comprising: a cache memory; fetch and decode circuitry to fetch and decode instructions from memory; and execution circuitry comprising a Binary Translator (BT) responsive to the decoded instruction by: the decoded instruction stream is stored in the BT cache, a delayed irregular load (DIRRL) among the streams is identified, it is determined whether the DIRRL is prefetcheable, and if so, a custom prefetcher is generated to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Example 2 includes the substance of the example processor of example 1, wherein the DIRRL is a latency load that experiences more than a first threshold number of cache misses on consecutive dynamic instances.
Example 3 includes the substance of the example processor of example 2, wherein the DIRRL is an irregular load having at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Example 4 includes the substance of the example processor of example 3, wherein the execution circuitry is to calculate a post-slice between two consecutive dynamic instances of the DIRRL and determine that the DIRRL is pre-prefetchable when the post-slice includes a loop consisting entirely of non-memory operations or regular memory operations.
Example 5 includes the substance of the example processor of example 4, wherein customizing the prefetcher causes the processor to prefetch a single critical load among the slices after the processor prefetches.
Example 6 includes the substance of the example processor of example 4, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than are contained in the post-slice.
Example 7 includes the substance of the example processor of example 1, wherein the customized prefetcher includes one or more prefetch hints stored within an instruction stream in the memory.
Example 8 includes the substance of the example processor of example 1, wherein the custom prefetcher includes a hardware prefetcher using the execution circuitry.
Example 9 encompasses the essence of the example processor of example 1, wherein BT is separate from the execution circuitry.
Example 10 includes the substance of the example processor of example 1, wherein BT is incorporated into execution circuitry.
Example 11 provides an exemplary method performed by a processor, the method comprising: fetching and decoding instructions from memory using fetch and decode circuitry; responding, using a binary translator, to the decoded instruction with an execution circuit to: storing the decoded instruction stream in a BT cache; tracking cache misses for load instructions to identify a latency load; parsing address increments of successive instances of the delayed payload to identify a delayed irregular payload (DIRRL); determining whether the DIRRL is prefetcheable by analyzing post-slicing between successive dynamic instances of the DIRRL, and if so, generating a custom prefetcher to cause a processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Example 12 includes the substance of the example method of example 11, wherein the DIRRL is a lazy load whose consecutive instances experience more than a first threshold number of cache misses.
Example 13 includes the substance of the example method of example 12, wherein the DIRRL is further an irregular loading of at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Example 14 includes the substance of the example method of example 11, wherein it is determined that the DIRRL is prefetcheable when the post-slice includes an instruction that fully includes a non-memory operation or a regular memory operation.
Example 15 includes the substance of the example method of example 11, wherein the customized prefetcher includes one or more prefetch hints stored in memory among an instruction stream in the memory.
Example 16 includes the substance of the example method of example 11, wherein the custom prefetcher comprises a custom hardware prefetcher using the execution circuitry.
Example 17 includes the substance of the example processor of example 11, wherein customizing the prefetcher causes the processor to prefetch a single critical load among the slices after the processor prefetches.
Example 18 includes the substance of the example processor of example 11, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than contained in the post-slice.
Example 19 includes the essence of the example method of example 11, wherein BT is separate from the execution circuitry.
Example 20 includes the substance of the example method of example 11, wherein BT is incorporated into the execution circuitry.
Example 21 provides an example processor, comprising: a cache memory; fetch and decode circuitry to fetch and decode instructions from memory; and a Binary Translator (BT) responsive to the decoded instruction by: storing a plurality of decoded instruction streams in a BT cache, identifying a delayed irregular load (DIRRL) among the stored instructions, determining whether the DIRRL is prefetcheable, and if so, generating a custom prefetcher to cause a processor prefetch an instruction region directed to the prefetcheable DIRRL.
Example 22 includes the substance of the example processor of example 21, wherein the DIRRL is a latency load that experiences more than a first threshold number of cache misses on consecutive dynamic instances.
Example 23 includes the substance of the example processor of example 22, wherein the DIRRL is an irregular load having at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Example 24 includes the substance of the example processor of example 23, wherein the execution circuitry is to calculate a post-slice between two consecutive dynamic instances of the DIRRL, and determine that the DIRRL is pre-prefetchable when the post-slice comprises a loop consisting entirely of non-memory operations or regular memory operations.
Example 25 includes the substance of the example processor of example 24, wherein the customized prefetcher causes the processor to prefetch one or more critical loads among the slices after the processor prefetches.
Example 26 includes the substance of the example processor of example 24, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than contained in the post-slice.
Example 27 includes the substance of the example processor of example 21, wherein the customized prefetcher includes one or more prefetch hints from among the plurality of instructions stored in the memory.
Example 28 includes the substance of the example processor of example 21, wherein the custom prefetcher comprises a hardware prefetcher using the execution circuitry.
Example 29 includes the substance of the example processor of example 21, wherein the processor further includes execution circuitry, and wherein the BT is separate from the execution circuitry.
Example 30 includes the substance of the example processor of example 21, wherein the processor further includes execution circuitry, and wherein the BT is incorporated into the execution circuitry.
Example 31 provides an exemplary non-transitory computer-readable medium containing instructions that, when executed by a computing device, cause the computing device to respond by: fetching and decoding instructions from memory using fetch and decode circuitry; responding to the decoded instruction using a Binary Translator (BT) to: storing a plurality of decoded instructions in a BT cache; tracking cache misses for load instructions to identify a latency load; parsing address increments of successive instances of the delayed payload to identify a delayed irregular payload (DIRRL); and determining whether the DIRRL is prefetcheable by analyzing post-slicing between successive dynamic instances of the DIRRL, and if so, generating a custom prefetcher to cause a processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Example 32 includes the substance of the example computer-readable medium of example 31, wherein the DIRRL is a lazy load whose consecutive instances experience more than a first threshold number of cache misses.
Example 33 includes the substance of the example computer-readable medium of example 32, wherein the DIRRL has at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Example 34 includes the substance of the example computer-readable medium of example 31, wherein the DIRRL is determined to be prefetcheable when the post-slice includes instructions that entirely include non-memory operations or regular memory operations.
Example 35 includes the substance of the example computer-readable medium of example 31, wherein the customized prefetcher includes one or more prefetch hints stored in memory among the plurality of instructions in the memory.
The invention also provides the following technical scheme:
a cache memory;
fetch and decode circuitry to fetch and decode instructions from memory; and
execution circuitry comprising a Binary Translator (BT) to respond to the decoded instruction by:
storing a plurality of the decoded instructions in a BT cache;
identifying a delayed irregular load (DIRRL) among the stored instructions;
determining whether the DIRRL is prefetcheable; and is
If so, a custom prefetcher is generated to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Solution 3. the processor of
Scheme 4. the processor of scheme 3, wherein the execution circuitry calculates a post-slice between two consecutive dynamic instances of the DIRRL and determines that the DIRRL is prefetcheable when the post-slice comprises a loop consisting entirely of non-memory operations or regular memory operations.
Solution 5. the processor of solution 4, wherein the customized prefetcher focuses the processor on one or more critical loads in the post-slice by enqueuing only the one or more critical loads and not others.
The processor of claim 6, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than are contained in the post-slice.
Claim 8 the processor of
Claim 9 the processor of
Claim 10 the processor of
a cache memory;
fetch and decode circuitry to fetch and decode instructions from memory; and
a Binary Translator (BT) to respond to the decoded instruction by:
storing a plurality of the decoded instructions in a BT cache;
identifying a delayed irregular load (DIRRL) among the stored instructions;
determining whether the DIRRL is prefetcheable; and is
If so, a custom prefetcher is generated to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Solution 12. the processor of
Solution 13 the processor of solution 12, wherein the DIRRL is an irregular load having at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Technical scheme 14 the processor of technical scheme 13, wherein the execution circuitry calculates a back-slice between two consecutive dynamic instances of the DIRRL and determines that the DIRRL is prefetcheable when the back-slice comprises a loop consisting entirely of non-memory operations or regular memory operations.
Claim 15 the processor of claim 14, wherein the custom prefetcher, when executing the prefetch, causes the processor to execute one or more critical loads within the post-slice before executing non-critical loads.
The processor of claim 16, wherein the custom prefetcher causes the processor to prefetch a plurality of irregular payloads containing fewer instructions than are contained in the post-slice.
Claim 17 the processor of
Claim 18 the processor of
Claim 19 the processor of
Claim 20 the processor of
A non-transitory computer-readable medium containing instructions that, when executed by a computing device, cause the computing device to respond by:
fetching and decoding instructions from memory using fetch and decode circuitry; and
responding to the decoded instruction using a Binary Translator (BT) to:
storing a plurality of decoded instructions in a BT cache;
tracking cache misses for load instructions to identify a latency load;
parsing address increments for successive instances of the delayed payload to identify a delayed irregular payload (DIRRL); and
determining whether the DIRRL is prefetcheable by analyzing post-slicing between successive dynamic instances of the DIRRL, and if so, generating a custom prefetcher to cause the processor to prefetch an instruction region directed to the prefetcheable DIRRL.
Solution 22 the computer readable medium of solution 21, wherein the DIRRL is a lazy load whose consecutive instances experience more than a first threshold number of cache misses.
Solution 23 the computer readable medium of solution 22, wherein the DIRRL has at least a second threshold number of address increments among its consecutive dynamic instances, and wherein the second threshold number of address increments covers less than a third threshold number of consecutive dynamic instances.
Solution 24 the computer readable medium of solution 21, wherein the DIRRL is determined to be prefetcheable when the post-slice includes instructions that entirely include non-memory operations or regular memory operations.
Claim 25 the computer readable medium of claim 21, wherein the customized prefetcher includes one or more prefetch hints stored in memory among the plurality of instructions in memory.
Instruction set
The instruction set may include one or more instruction formats. A given instruction format may define various fields (number of bits, location of bits, etc.) and/or other data field(s) (e.g., mask) that specify, among other things, the operation to be performed (opcode) and the operand(s) on which the operation is to be performed. Some instruction formats are further decomposed by the definition of an instruction template (or subformat). For example, an instruction template for a given instruction format may be defined to have different subsets of the fields of the instruction format (the fields included are typically in the same order, but at least some have different bit positions because fewer fields are included) and/or to interpret a given field in a different manner. Thus, each instruction of the ISA is represented using a given instruction format (and, if defined, a given one of the instruction templates of that instruction format) and contains fields for specifying operations and operands. For example, an exemplary ADD instruction has a particular opcode and instruction format that includes an opcode field specifying the opcode and an operand field selecting operands (
Exemplary instruction Format
Embodiments of the instructions described herein may be implemented in different formats. Further, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instructions may be executed on such systems, architectures, and pipelines, but are not limited to those detailed.
Generic vector friendly instruction format
The vector friendly instruction format is an instruction format that is appropriate for vector instructions (e.g., there are certain fields that are specific to vector operations). Although embodiments are described that support vector and scalar operations via the vector friendly instruction format, alternative embodiments use only vector operations of the vector friendly instruction format.
Figures 8A and 8B are block diagrams illustrating a generic vector friendly instruction format and instruction templates thereof according to some embodiments of the invention. FIG. 8A is a block diagram illustrating a generic vector friendly instruction format and class A instruction templates thereof according to some embodiments of the invention; and FIG. 8B is a block diagram illustrating the generic vector friendly instruction format and class B instruction templates thereof according to some embodiments of the invention. In particular, the generic vector friendly instruction format 800 is defined as class A and class B instruction templates, both of which include no
Although embodiments of the present invention will be described in which the vector friendly instruction format supports the following sizes: a 64 byte vector operand length (or size) having a 32 bit (4 byte) or 64 bit (8 byte) data element width (or size) (and thus, a 64 byte vector consists of 16 elements of a doubleword size, or alternatively 8 elements of a quadword size); a 64 byte vector operand length (or size) with a 16 bit (2 bytes) or 8 bit (1 byte) data element width (or size); a 32-byte vector operand length (or size) having a 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element width (or size); a 16 byte vector operand length (or size) having a 32 bit (4 bytes), 64 bit (8 bytes), 16 bit (2 bytes), or 8 bit (1 byte) data element width (or size); alternative embodiments may support more, fewer, and/or different vector operand sizes (e.g., 256 byte vector operands) with more, fewer, or different data element widths (e.g., 128 bit (16 byte) data element widths).
The class A instruction templates in FIG. 8A include: 1) within the no
The generic vector friendly instruction format 800 includes the following fields listed below in the order illustrated in FIGS. 8A-8B.
Format field 840-a specific value in this field (an instruction format identifier value) uniquely identifies the vector friendly instruction format and, thus, instructions in the vector friendly instruction format appear in the instruction stream. As such, this field is optional in the sense that it is not required for an instruction set that has only a generic vector friendly instruction format.
Modifier field 846-its content distinguishes the occurrence of an instruction in the generic vector instruction format that specifies a memory access from the occurrence of an instruction that does not specify a memory access; that is, between the no
Augmentation operation field 850 — its content distinguishes which of a variety of different operations to perform in addition to the basic operation. This field is context specific. In some embodiments, this field is divided into a
Scaling field 860-whose contents allow the contents of the scaling index field to be used for memory address generation (e.g., for using 2)ZoomIndex + address generation of base address).
Data element width field 864-its content distinguishes which of several data element widths to use (for all instructions in some embodiments; for only some of the instructions in other embodiments). This field is optional in the sense that it is not needed if only one data element width is supported and/or multiple data element widths are supported using some aspect of the opcode.
A writemask field 870-whose contents control whether the data element position in the destination vector operand reflects the results of the base operation and the augmentation operation on a per data element position basis. Class a instruction templates support merge-writemask, while class B instruction templates support both merge-and zero-writemask. When merging, the vector mask allows any set of elements in the destination to be protected from updating during the execution of any operations (specified by the base operation and the augmentation operation); in another embodiment, the old value of each element of the destination for which the corresponding mask bit has a 0 is preserved. In contrast, the Angelica zero vector mask allows any set of elements in the destination to be zeroed during the performance of any operations (specified by the base operation and the augmentation operation); in one embodiment, when the corresponding mask bit has a value of 0, the element of the destination is set to 0. A subset of this functionality is the ability to control the vector length (i.e., the span from the first to the last modified element) of the operation being performed; however, the elements being modified need not be consecutive. Thus, the
Immediate field 872-its contents allow for the specification of an immediate. This field is optional in the sense that it is not present in implementations of the generic vector friendly format that do not support immediate, and it is not present in instructions that do not use immediate.
Category field 868-its contents distinguish between different classes of instructions. Referring to FIGS. 8A-B, the contents of this field select between class A and class B instructions. In FIGS. 8A-B, rounded squares are used to indicate the particular values present in the fields (e.g., class A868A and class B868B, respectively, in FIGS. 8A-B, class fields 868).
Class A instruction template
In the case of a class a
Instruction templates with no memory access-full round control type operation
In the no memory access full round
The round operation control field 858-its contents distinguish which of a set of rounding operations is to be performed (e.g., round up, round down, round towards zero, and round towards nearest). Thus, the round operation control field 858 allows the rounding mode to be changed on a per instruction basis. In some embodiments where the processor includes a control register for specifying the rounding mode, the contents of the rounding operation control field 850 overwrite the register value.
Instruction template-data transformation type operation without memory access
In the no memory access data
In the case of a class a
Vector memory instructions support execution of loads and stores vectors from and to memory by translation. As with regular vector instructions, vector memory instructions transfer data from/to memory on a data element-by-data element basis, with the actual elements transferred being determined by the contents of the vector mask selected as the write mask.
Memory access instruction template-temporary
Temporary data is data that may be reused fast enough to benefit from caching. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint altogether.
Memory access instruction templates-non-transient
Non-transient data is data that is unlikely to be reused fast enough to benefit from caching in the first level cache, and should give priority to evictions. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint altogether.
Class B instruction templates
In the case of class B instruction templates, the
In the case of a class B
In the no memory access, write mask control, partial round
Rounding
In the no memory access, write mask control,
In the case of a class
With respect to the generic vector friendly instruction format 800, a full opcode field 874 is shown that contains the
The augmentation operation field 850, the data
The combination of the writemask field and the data element width field creates typed instructions because they allow masks to be applied based on different data element widths.
The various instruction templates found within class a and class B are beneficial in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only class A, only class B, or both. For example, a high performance general out-of-order core intended for general purpose computing may support only class B, a core intended primarily for graphics and/or scientific (throughput) computing may support only class a, and a core intended for both may support both (of course, cores having some mix of instructions and templates from both classes but not all templates and instructions from both classes are within the purview of the invention). Also, a single processor may contain multiple cores, all of which support the same class, or in which different cores support different classes. For example, in a processor having separate graphics and general-purpose cores, one of the graphics cores intended primarily for graphics and/or scientific computing may support only class A, while one or more of the general-purpose cores may be high performance general-purpose cores having out-of-order execution and register renaming intended for general-purpose computing that supports only class B. Another processor without a separate graphics core may contain one or more generic in-order or out-of-order cores supported by both class A and class B. Of course, features from one class may also be implemented in another class in different embodiments of the invention. Programs written in high-level languages will be translated (e.g., just compiled or statically compiled) into a variety of different executable forms, including: 1) instructions of only the class(s) supported by the target processor for execution; or 2) have alternative routines written using different combinations of instructions of all classes and have the form of control flow code that selects a routine to execute based on instructions supported by the processor currently executing the code.
Exemplary specific vector friendly instruction Format
FIG. 9A is a block diagram illustrating an exemplary specific vector friendly instruction format according to some embodiments of the invention. Fig. 9A illustrates a specific vector friendly instruction format 900 that is specific in the sense that it specifies the location, size, interpretation, and order of the fields, as well as the values of some of those fields. The specific vector friendly instruction format 900 may be used to extend the x86 instruction set and thus some of the fields are similar or identical to those used in the existing x86 instruction set and its extensions (e.g., AVX). This format is consistent with the prefix encoding field, the true opcode byte field, the MOD R/M field, the SIB field, the displacement field, and the immediate field of the existing x86 instruction set with extensions. Illustrating the fields from fig. 8 to which the fields from fig. 9A map.
It should be understood that although embodiments of the present invention are described with reference to the specific vector friendly instruction format 900 in the context of the generic vector friendly instruction format 800 for illustrative purposes, the present invention is not limited to the specific vector friendly instruction format 900 except where stated. For example, the generic vector friendly instruction format 800 considers various possible sizes for various fields, while the specific vector friendly instruction format 900 is shown as having fields of a specific size. As a particular example, while the data
The generic vector friendly instruction format 800 includes the following fields listed below in the order illustrated in FIG. 9A.
The EVEX prefix (bytes 0-3) 902 is encoded in four bytes.
Format field 840 (
The second-four bytes (EVEX bytes 1-3) contain several bit fields that provide specific capabilities.
REX field 905 (
REX '910A-this is the first part of REX'
Opcode map field 915 (
Data element width field 864 (
The role of evex.vvv 920 (
Prefix encoding field 925 (
Alpha field 852 (EVEX byte 3, bits [7] -EH; also known as EVEX. EH, EVEX.rs, EVEX.RL, EVEX. write mask control, and EVEX.N; also illustrated with alpha) -this field is context specific as previously described.
Beta field 854 (EVEX byte 3, bits [ 6: 4]]SSS, also known as EVEX.s2-0、EVEX.r2-0Evex. rr1, evex.ll0, evex.llb; also illustrated with β β β) -as previously described, this field is context specific.
REX '910B-which is the remainder of REX'
Writemask field 870 (EVEX byte 3, bits [ 2: 0] -kkk) -whose contents specify the index of the register in the writemask register as previously described. In some embodiments, the particular value evex.kkk =000 has special behavior, implying that no writemask is used for a particular instruction (this may be implemented in various ways, including using hardware that is hardwired to all writemasks or that bypasses masking hardware).
The true opcode field 930 (byte 4) is also referred to as the opcode byte. A portion of the opcode is specified in this field.
MOD R/M field 940 (byte 5) includes a
Scale, index, base address (SIB) byte (byte 6) — as previously described, the contents of the scale field 850 are used for memory address generation.
Complete operation code field
Figure 9B is a block diagram illustrating fields of the specific vector friendly instruction format 900 that make up the full opcode field 874, in accordance with some embodiments. In particular, the full opcode field 874 includes the
Register index field
Fig. 9C is a block diagram illustrating fields of the specific vector friendly instruction format 900 that make up the
Augmentation operation field
Figure 9D is a block diagram illustrating fields of a particular vector friendly instruction format 900 that make up an augmentation operation field 850, according to some embodiments. When class (U)
Alpha field 852 (EVEX byte 3, bit [7 ]) when U =1]EH) is interpreted as a writemask control (Z)
Exemplary register architecture
Fig. 10 is a block diagram of a register architecture 1000 according to some embodiments. In the illustrated embodiment, there are 32 vector registers 1010 of width 512 bits; these registers are referenced zmm0 through zmm 31. The lower order 256 bits of the lower 16 zmm registers are superimposed on the register ymm 0-16. The lower order 128 bits of the lower 16 zmm registers (the lower order 128 bits of the ymm registers) are superimposed on the register xmm 0-15. The specific vector friendly instruction format 900 operates on these overlaid register files as illustrated in the following table:
in other words, the
General purpose registers 1025-in the illustrated embodiment, there are 16 64-bit general purpose registers that are used to address memory operands along with the existing x86 addressing scheme. These registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.
A scalar floating point stack register file (x 87 stack) 1045 on which the MMX packed integer
Alternative embodiments may use wider or narrower registers. Moreover, alternative embodiments may use more, fewer, or different register files and registers.
Exemplary core architecture, processor, and computer architecture
Processor cores may be implemented in different ways, for different purposes, and in different processors. For example, an implementation of such a core may include: 1) a generic ordered core intended for generic computation; 2) a high performance general out-of-order core intended for general purpose computing; 3) dedicated cores are expected to be used mainly for graphics and/or scientific (throughput) computations. Implementations of different processors may include: 1) a CPU comprising one or more general-purpose in-order cores intended for general-purpose computing and/or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) coprocessors containing one or more special purpose cores intended primarily for graphics and/or science (throughput). Such different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 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) a system on a chip that may contain the described CPUs (sometimes referred to as application core(s) or application processor(s), co-processors described above, and additional functionality on the same die. An exemplary core architecture is described next, followed by a description of an exemplary processor and computer architecture.
Exemplary core architecture
In-order and out-of-order core block diagrams
FIG. 11A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to some embodiments of the invention. FIG. 11B is a block diagram illustrating an exemplary embodiment of both 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 some embodiments of the invention. The solid boxes in FIGS. 11A-B illustrate an in-order pipeline and an in-order core, while the optional addition of the dashed boxes illustrates a register renaming, out-of-order issue/execution pipeline and a core. Given that the ordered aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.
In FIG. 11A, processor pipeline 1100 includes fetch
Fig. 11B shows processor core 1190 including a
The
The
The set of memory access units 1164 is coupled to
By way of example, the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline 1100 as follows: 1) instruction fetch 1138 performs fetch and length decode
Core 1190 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 of MIPS technology by Sunnyvale of CA, the ARM instruction set by ARM holdings corporation of Sunnyvale of CA (with optional additional extensions such as NEON)), including the instruction(s) described herein. In one embodiment, the core 1190 contains logic that supports packed data instruction set extensions (e.g., AVX1, AVX 2), thereby allowing packed data to be used to perform operations used by many multimedia applications.
It should be appreciated that the cores may support multi-threading (performing two or more sets of parallel operations or threads) and may do so in a variety of ways, including time-sliced multi-threading, simultaneous multi-threading (where a single physical core provides a logical core for each thread where the physical core is simultaneously multi-threading), or a combination thereof (e.g., time-sliced fetch and decode and thereafter simultaneous multi-threading, such as with Intel @hyper-threading technology).
Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. While the illustrated processor embodiment also includes separate instruction and data cache units 1134, 1174 and a shared
Specific exemplary ordered core architecture
12A-B illustrate block diagrams of more specific example in-order core architectures that would be one of several logic blocks (including other cores of the same type and/or different types) in a chip. The logic blocks communicate with some fixed function logic, memory I/O interfaces, and other necessary I/O logic, depending on the application, over a high bandwidth interconnection network (e.g., a ring network).
Figure 12A is a block diagram of a single processor core along with its connection to the on-die interconnect network 1202 and its local subset of the level 2 (L2) cache 1204, according to some embodiments of the invention. In one embodiment, the instruction decoder 1200 supports the x86 instruction set with a packed data instruction set extension. The
The local subset of the L2 cache 1204 is part of a global L2 cache, and the global L2 cache is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of the L2 cache 1204. Data read by a processor core is stored in its L2 cache subset 1204 and can be accessed quickly, in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1204 and is flushed from other subsets, if necessary. The ring network ensures consistency with respect to shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches and other logic blocks to communicate with each other on-chip. Each ring data path is 1012 bits wide in each direction.
Figure 12B is an expanded view of a portion of the processor core in figure 12A according to some embodiments of the invention. FIG. 12B includes the
Fig. 13 is a block diagram of a processor 1300, which may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to some embodiments of the invention. The solid line block diagram in FIG. 13 illustrates a processor 1300 with a single core 1302A, a
Thus, different implementations of processor 1300 may include: 1) a CPU having special purpose logic 1008 and cores 1002A-N, special purpose logic 1008 being integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and cores 1302A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of both); 2) coprocessors with cores 1002A-N that are a large number of specialized cores intended primarily for graphics and/or science (throughput); and 3) coprocessors having cores 1302A-N that are a number of general purpose ordered cores. Thus, the processor 1300 may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), a high-throughput Many Integrated Core (MIC) coprocessor (including 30 or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. The processor 1300 may be part of and/or implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.
The memory hierarchy includes one or more levels of cache within the cores, a set or one or more shared
In some embodiments, one or more of the cores 1302A-N are capable of multi-threading operation.
The cores 1302A-N may be homogeneous or heterogeneous in terms of architectural instruction set; that is, two or more of the cores 1302A-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 a different instruction set.
Exemplary computer architecture
FIGS. 14-17 are block diagrams of exemplary computer architectures. Other system designs and configurations known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, hubs, switches, embedded processors, Digital Signal Processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular telephones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, countless systems or electronic devices capable of incorporating a processor and/or other execution logic disclosed herein are generally suitable.
Referring now to FIG. 14, shown is a block diagram of a
The optional nature of the
The
In one embodiment, the
There can be various differences between the
In one embodiment,
Referring now to FIG. 15, shown is a block diagram of a first more specific
A shared cache (not shown) may be included in either processor or external to both processors, yet connected with the processors via the P-P interconnect, such that if a processor is placed in a low power mode, local cache information for either or both processors may be stored in the shared cache.
As shown in fig. 15, various I/
Referring now to fig. 16, shown is a block diagram of a second more specific
FIG. 16 illustrates that the
Referring now to fig. 17, shown is a block diagram of a
Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the invention may be implemented as computer programs or program code executing on programmable systems comprising 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.
Program code, such as
The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.
One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores" may be stored on a tangible, machine-readable medium and provided to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.
Such machine-readable storage media may include, but are not limited to, non-volatile tangible arrangements of articles of manufacture made or formed by machines or devices, including storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), Random Access Memories (RAMs) such as Dynamic Random Access Memories (DRAMs), Static Random Access Memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), Phase Change Memories (PCMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
Thus, embodiments of the invention also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL) that defines the structures, circuits, devices, processors, and/or system features described herein. Such embodiments may also be referred to as program products.
Simulation (including binary translation, code deformation, etc.)
In some cases, an instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), morph, emulate, or otherwise convert an instruction into one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on the processor, off-processor, or partially on and partially off-processor.
FIG. 18 is a block diagram comparing the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set, according to some embodiments of the invention. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Fig. 18 illustrates that a program of a high-level language 1802 can be compiled using an x86 compiler 1804 to generate x86 binary code 1806 that can be natively executed by a processor having at least one x86
- 上一篇：一种医用注射器针头装配设备
- 下一篇：存储器装置和系统、集成电路的制造方法