Instructions for dual destination type conversion, accumulation, and atomic memory operations

Abstract

Disclosed embodiments relate to instructions for double destination type conversion, accumulation, and atomic memory operations. In one example, a system includes a memory; a processor including an extraction circuit to extract an instruction from a code storage, the instruction including an opcode, a first destination identifier, and a source identifier to specify a source vector register, the source vector register including a plurality of single precision floating point data elements; a decode circuit to decode the extracted instruction; and an execution circuit to execute the decoded instruction to convert elements of the source vector register to double precision floating point values, store a first half of the double precision floating point values to a first location identified by the first destination identifier, and store a second half of the double precision floating point values to a second location.

Description

Technical Field

[0001] The field of this invention generally relates to computer processor architecture, and more specifically to instructions for dual-destination type conversion, mixed-precision accumulation, and mixed-precision atomic memory operations. Background Technology

[0002] Modern processors often include instructions designed to provide computationally intensive operations, but which enable high levels of data parallelism through efficient implementation using various data storage devices, such as single-instruction multiple-data (SIMD) vector registers. Thus, the central processing unit (CPU) can provide parallel hardware to support vectorized processing. Vectorization, therefore, can improve the power-efficient performance of the processor.

[0003] The IEEE 754 standard for floating-point arithmetic is a technical standard for floating-point computation established by the Institute of Electrical and Electronics Engineers (IEEE) in 1985 (most recently updated and published in August 2008). IEEE 754 specifies at least the floating-point number format, required operations, and recommended operation statements. IEEE 754 defines formats for various precision levels, including half-precision (2 bytes), single-precision (4 bytes), double-precision (8 bytes), and quadruple-precision (16 bytes).

[0004] For efficiency reasons, processor instruction set architectures often limit register size and floating-point calculations to a fixed number of bits. Therefore, applications that desire increased precision and higher accuracy may seek to double the number of bits used for floating-point representation. However, doing so reduces the number of computations that can be performed per cycle, increases the instruction count, reduces the number of data elements that can be stored in the data cache, and requires more memory operations.

[0005] What is needed is a way to vectorize using high-precision data in accordance with IEEE 754 when necessary for accuracy, and otherwise using low-precision data. Attached Figure Description

[0006] The invention is illustrated by way of example and not by way of limitation in the accompanying drawings, in which similar references indicate similar elements and wherein:

[0007] Figure 1This is a block diagram illustrating, according to some embodiments, a processing unit for executing instructions for dual-destination type conversion, accumulation, and atomic memory operations;

[0008] Figure 2A This is a block diagram illustrating the format of instructions for dual-destination type conversion, accumulation, and atomic memory operations according to some embodiments;

[0009] Figure 2B This is a block diagram illustrating the format of instructions for dual-destination type conversion, accumulation, and atomic memory operations according to some embodiments;

[0010] Figure 3 This is a flowchart of a process, according to some embodiments, to be implemented by a processor to execute instructions for dual-destination type conversion, accumulation, and / or atomic memory operations;

[0011] Figure 4 The illustrations illustrate exemplary execution of instructions for dual-destination type conversion, accumulation, and / or atomic memory operations according to some embodiments;

[0012] Figure 5A-5G These are pseudocode and block flowcharts illustrating various embodiments of executing instructions for dual-destination type conversion, mixed-precision accumulation, or mixed-precision atomic memory operations, according to some embodiments.

[0013] Figure 5A This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment;

[0014] Figure 5B This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment;

[0015] Figure 5C This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment;

[0016] Figure 5D This is a pseudocode and block flowchart illustrating the execution of dual-destination type conversion and accumulation instructions according to one embodiment;

[0017] Figure 5E This is a pseudocode and block flowchart illustrating the execution of dual-destination mixed-precision type conversion and accumulation using two instructions according to one embodiment;

[0018] Figure 5FThis is a pseudocode and block flowchart illustrating the execution of mixed-precision type conversion and accumulation instructions according to one embodiment;

[0019] Figure 5G This is a pseudocode and block flowchart illustrating the execution of a mixed-precision atomic memory accumulation instruction according to one embodiment;

[0020] Figures 6A-6B This is a block diagram illustrating a general vector-friendly instruction format and its instruction template according to an embodiment of the present invention;

[0021] Figure 6A This is a block diagram illustrating the general vector-friendly instruction format and its category A instruction template according to an embodiment of the present invention;

[0022] Figure 6B This is a block diagram illustrating the general vector-friendly instruction format and its category B instruction template according to an embodiment of the present invention;

[0023] Figure 7A This is a block diagram illustrating an exemplary specific vector-friendly instruction format according to an embodiment of the present invention;

[0024] Figure 7B This is a block diagram illustrating the fields constituting the full opcode field 674 of a specific vector-friendly instruction format 700 according to an embodiment of the present invention;

[0025] Figure 7C This is a block diagram illustrating the fields of a specific vector-friendly instruction format 700 constituting the register index field 644 according to an embodiment of the present invention;

[0026] Figure 7D This is a block diagram illustrating the specific vector-friendly instruction format of the fields constituting the amplification operation field according to an embodiment of the present invention;

[0027] Figure 8 This is a block diagram of a register architecture according to an embodiment of the present invention;

[0028] Figure 9A This is a block diagram illustrating an exemplary in-order pipeline and an exemplary out-of-order issue / execution pipeline for register renaming, according to embodiments of the present invention.

[0029] Figure 9B This is a block diagram illustrating exemplary embodiments of renaming out-of-order release / execution architecture cores and ordered architecture cores to be included in a processor according to embodiments of the present invention;

[0030] Figure 10A-B diagram illustrates a more specific example of an ordered core architecture, where the core will be one of several logical blocks in the chip (including other cores of the same type and / or different types);

[0031] Figure 10A This is a block diagram of a single processor core according to an embodiment of the present invention, together with its connection to the on-die interconnect network 1002 and its local subset together with the Level 2 (L2) cache memory 1004;

[0032] Figure 10B This is an embodiment of the present invention. Figure 10A An expanded diagram of a portion of the processor core;

[0033] Figure 11 This is a block diagram of a processor 1100 according to an embodiment of the present invention, which may have more than one core, may have an integrated memory controller, and may have integrated graphics.

[0034] Figure 12-15 This is a block diagram of an exemplary computer architecture;

[0035] Figure 12 A block diagram of a system according to an embodiment of the present invention is shown;

[0036] Figure 13 This is a block diagram of a first more specific exemplary system according to an embodiment of the present invention;

[0037] Figure 14 This is a block diagram of a second, more specific, exemplary system according to an embodiment of the present invention;

[0038] Figure 15 This is a block diagram of a System-on-a-Chip (SoC) according to an embodiment of the present invention; and

[0039] Figure 16 This is a block diagram illustrating the use of a software instruction converter according to an embodiment of the present invention for converting binary instructions in a source instruction set into binary instructions in a target instruction set. Detailed Implementation

[0040] In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of the description.

[0041] References to "an embodiment," "an example embodiment," "exemplary embodiment," etc., in the specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Furthermore, such wording does not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is assumed that, whether explicitly described or not, the influence of such feature, structure, or characteristic on other embodiments is within the knowledge of those skilled in the art.

[0042] Using mixed-precision optimization can advantageously improve processor power efficiency performance to the extent that high-precision floating-point data can be used when higher precision is desired, and low-precision data can be used otherwise. In other words, some data and computations are performed with a lower-precision representation of the data, and the higher-precision representation is used only when necessary for accuracy.

[0043] Mixed precision is also used in many standardized benchmark codes used as benchmarks for measuring machine performance. These benchmark codes include machine learning codes as well as molecular dynamics codes (e.g., LAMMPS, NAMD, Amber).

[0044] While mixed-precision computation can improve performance, it suffers from inefficiencies due to type conversions and the increased number of registers required to store identical operands. For example, accumulating / reducing many values ​​into a single value is a potential source of error when the data is represented with low precision. The ability to implement mixed-precision operations mitigates these potential error sources by applying high precision to both the selected operation and the selected operands.

[0045] Unfortunately, in some current processors, adding a packed single-precision (SP) register to two packed double-precision (DP) registers requires at least five instructions:

[0046] 1. An instruction used to cast elements from the lower lane of the SP source register to the compact DP destination register.

[0047] 2. Add a pair of registers in double precision.

[0048] 3. Extract the high channel of the SP source register.

[0049] 4. Arrange the extracted channels in double precision, and

[0050] 5. Add another pair of registers in double precision.

[0051] The embodiments disclosed herein offer advantages to the processor's instruction set architecture by providing instructions for reducing the instruction count for certain mixed-precision operations. In some embodiments, the processor instruction set architecture is extended to support mixed-precision operations with increased symmetry and / or lower instruction counts for execution on multiple vector ports.

[0052] The disclosed mixed-precision operations include dual-type conversions (e.g., converting two halves of a single vector register containing single-precision data elements into double-precision data elements to be stored in two destination vector registers (compliant with IEEE 754)), accumulations (e.g., converting two halves of a single vector register containing single-precision data elements into double-precision values ​​to be added to the double-precision data values ​​previously stored in the two destination vector registers (compliant with IEEE 754)), and atomic memory operations (e.g., converting two halves of a single vector register containing single-precision data elements into double-precision values ​​(compliant with IEEE 754) and adding them atomically to a vector containing double-precision data elements in memory).

[0053] Figure 1 This is a block diagram illustrating processing components for executing instructions for dual-destination type conversion, accumulation, and atomic memory operations, according to some embodiments. As shown, the computing system 100 includes a code storage device 102, a fetch circuit 104, a decode circuit 106, an execution circuit 108, a register 110, a memory 112, and a retireor commit circuit 114. Instructions are fetched from the code storage device 102 by the fetch circuit 104, which may include, without limitation, cache memory, on-chip memory, on-die memory of the same processor, instruction register, general-purpose register, or system memory. In one embodiment, the instructions have... Figure 2A The format of instruction 200 is similar to that in another embodiment. The instructions have a format similar to... Figure 2B The format of instruction 250 is similar to that in the code storage device 102. After the extraction circuit 104 extracts the instruction from the code storage device 102, the decoding circuit 106 decodes the instruction, including by parsing the individual fields of the instruction. After the extracted instruction is decoded, the execution circuit 108 executes the decoded instruction. (Regarding...) Figure 3 to 5GSeveral exemplary embodiments of the execution circuit 108 are illustrated and described. In the step of executing instructions, the execution circuit 108 may read data from register 110 and memory 112 and write data to register 110 and memory 112. Register 110 may include, without limitation, a data register, instruction register, vector register, mask register, general-purpose register, on-chip memory, on-die memory of the processor, or memory in the same package as the processor. Memory 112 may include, without limitation, on-chip memory, on-die memory of the processor, memory in the same package as the processor, cache memory, or system memory. After the execution circuit 108 executes an instruction, the deprecation or commit circuit 114 is used to deprecate or commit the instruction, thereby ensuring that the execution result has been written to or has been written to its destination, and freeing up or releasing resources for later use.

[0054] Figure 2A This is a block diagram illustrating the format of instructions for dual-destination type conversion, accumulation, and atomic memory operations according to some embodiments. As shown, instruction 200 includes opcode 202, source identifier 204, first destination identifier 206, and optional second destination identifier 208 (optional instruction fields are shown in boxes with dashed borders).

[0055] In some embodiments, source identifier 204 is used to specify a source vector register, such as a vector register included in the processor's register file. Figure 8 The associated descriptions of embodiments of the processor's register file are further described below. In some embodiments, source identifier 204 is used to identify a memory location.

[0056] The first destination identifier 206 and the optional second destination identifier 208 identify two locations (the processor's register file vector register or memory location), as shown in the example below. Figure 3 to 5G Some of the described embodiments write the execution results to the two locations.

[0057] Figure 2B This is a block diagram illustrating the format of instructions for dual-destination type conversion, accumulation, and atomic memory operations according to some embodiments. As shown, instruction 250 includes opcode 252, source identifier 254, first destination identifier 256, and optional second destination identifier 258 (optional instruction fields are shown in boxes with dashed borders).

[0058] In some embodiments, source identifier 254 is used to specify a source vector register, such as a vector register included in the processor's register file. Figure 8An embodiment of the processor's register file is further described below, along with its associated description. In some embodiments, source identifier 254 is used to identify a memory location.

[0059] The first destination identifier 256 and the optional second destination identifier 258 identify two locations (the processor's register file vector register or memory location), as shown in the example below. Figure 3 to 5G Some of the described embodiments write the execution results to the two locations.

[0060] In some embodiments, opcode 252 includes CVT 260, which specifies that the operation to be performed by instruction 250 is an optional field that includes, for example, a conversion from single precision to double precision.

[0061] In some embodiments, opcode 252 includes ADD 262, an optional field that specifies the operation to be performed by instruction 250 as adding the result to data previously stored in a location identified by a first destination identifier 256 and / or a second destination identifier 258.

[0062] In some embodiments, opcode 252 includes LO / HI 264, an optional field specifying that the operation to be performed by instruction 250 is to process only the half of the source vector specified by source identifier 254. For example, when the LO / HI 264 field is "LO", the lower half of the source vector will be processed, and when the LO / HI 264 field is "HI", the upper half of the source vector will be processed. When the LO / HI 264 field is included in instruction 250, the instruction will need to be executed at least twice to process the entire source vector identified by source identifier 254.

[0063] In some embodiments, opcode 252 includes optional size identifiers 266, such as prefixes or suffixes “B,” “W,” “D,” and “Q” used to specify the size of each source vector element (1 byte, 2 bytes, 4 bytes, or 8 bytes, respectively). In some embodiments, the optional size identifiers 266 are included in the opcode as prefixes or suffixes “H,” “S,” “D,” “Q,” and “E,” which correspond to the precision level of each source vector element: half-precision (2 bytes), single-precision (4 bytes), double-precision (8 bytes), and quadruple-precision (16 bytes), respectively. In other embodiments, the optional size identifiers 266 are instruction parameters or operands specifying the size and / or precision level of the source vector element.

[0064] Figure 3This is a flowchart illustrating the process by which the processor executes instructions for dual-destination type conversions, accumulations, and / or atomic memory operations. After the start, at 302, the fetching circuitry fetches instructions from the code storage device. These instructions include an opcode, a first destination identifier, an optional second destination identifier, and a source identifier specifying a source vector register containing multiple single-precision floating-point data elements. At 304, the fetched instructions are decoded by the decoding circuitry. At 306, the execution circuitry executes the decoded instructions for each element of the source vector register. The process then ends.

[0065] Figure 4 This is a flowchart of the process by which the processor executes instructions for performing dual-destination type conversions, accumulations, and / or atomic memory operations. After the start, the fetch circuit at 402 fetches instructions from the code storage device, which include an opcode, an optional size identifier, a source identifier for identifying the source vector, a first destination identifier, and an optional second destination identifier.

[0066] Figure 2B The diagram may include optional fields in instructions for dual-destination type conversion, accumulation, and atomic memory operations. In some embodiments, the number and type of instruction operands are specified by indications in the opcode. For example, when the opcode includes "LO" or "HI", the instruction is used to operate on the low or high portion of the source vector. For example, when the opcode includes "ADD", the instruction is used to accumulate or add to data previously stored in the destination. For example, when the opcode includes "CVT", the instruction is used to transform data in the source vector. In other embodiments, the opcode can be modified without limitation to specify a particular behavior or specific source and destination operands.

[0067] At position 404, the extracted instruction is decoded by the decoding circuitry. In some embodiments, the source vector is stored in the vector register of the processor's register file, for example, regarding... Figure 8 As described. In other embodiments, the source vector is to be stored at a memory location and to be retrieved and stored in a vector register.

[0068] At 406, the execution circuitry begins executing the decoded instructions for each element of the source vector to at least execute steps 408 and 410. At 408, the execution circuitry converts each element of the source vector register into a double-precision floating-point value. In this case, the resulting vector will be twice the width of the source vector. At 410, the execution circuitry appends (or accumulates) each of the first halves of the converted double-precision values ​​to an existing vector element of the first destination vector, identified by the first destination identifier. At 412, the execution circuitry appends (or accumulates) each of the second halves of the converted double-precision values ​​to an existing vector element of the second destination vector, identified by the second destination identifier. The process then ends.

[0069] Consider, for example, an instruction to extract and decode a specified 64-byte (32-bit) single-precision vector element stored in vector register zmm1. An exemplary instruction further requires converting the source vector register to double precision (IEEE 754 compliant) and storing half of the upconverted double-precision vector elements into each of zmm2 and zmm3. For example, after execution, the 4-byte (32-bit) single-precision elements 0 through 7 (256 bits total) of the source vector will be converted to 8-byte (64-bit) double-precision values ​​(512 bits total) and stored as 64 bytes of elements 0 through 7 in the first destination, while the single-precision elements 8 through 15 of the source vector will be converted from 4-byte single-precision values ​​(256 bits total) to 8-byte double-precision values ​​(512 bits total) and stored as 64 bytes of elements 8 through 15 in the second destination.

[0070] Figure 5A-5G These are pseudocode and block flowcharts illustrating various embodiments of the process by which a processor implements instructions for executing dual-destination type conversion, mixed-precision accumulation, and mixed-precision atomic memory operations;

[0071] In some embodiments, Figure 5A-5G The pseudocode listed is used to operate on the elements of the source vector operand one element at a time. In some embodiments, the pseudocode 500 is used to operate on multiple elements of the source operand zmm1 in parallel.

[0072] Figure 5A-5G The pseudocode embodiments listed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Some embodiments of the pseudocode are intended to be implemented as computer programs or program code that execute on a programmable system 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.

[0073] It should be understood that Figure 5A-5G The pseudocode listed is insufficient on its own to implement all aspects of an application or other software. Figure 5A-5G The pseudocode listed herein is used to illustrate relevant aspects of the embodiments disclosed herein. Additional software routines for controlling inputs and outputs, as well as other functionalities, are known to and can be used by those skilled in the art.

[0074] Figure 5A This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment. Pseudocode 500 and block diagram 501 illustrate an embodiment for extracting, decoding, and executing the VCVTPS2PD2 dual-destination type conversion instruction (compliant with IEEE 754), which includes a source identifier for specifying the source vector register zmm1 503, a first destination identifier for specifying the first destination vector register zmm2 505, and a second destination identifier for specifying the second destination vector register zmm3 507. The instruction opcode VCVTPS2PD2 is chosen to illustrate a non-limiting example; other opcodes may be used without limitation. As shown, the eight lower half elements of zmm1 are converted to double precision (compliant with IEEE 754), thereby doubling their bit width, and are stored in the eight elements of zmm2, while the eight upper half elements of zmm1 are converted to double precision (compliant with IEEE 754), thereby doubling their bit width, and are stored in the eight elements of zmm3.

[0075] Figure 5B This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment. Pseudocode 510 and block diagram 511 illustrate the execution of a VCVTPS2PD2 dual-destination type conversion instruction, which includes a source identifier for specifying vector register zmm1 513 and a second destination identifier for specifying zmm2 517, excluding the first destination identifier because zmm1 is also used as a destination. In this embodiment, the source register is also used as the first destination register. Here, the source register is shown as 513 before execution and as 515 after execution. As shown, the eight lower half elements of zmm1 513 are upconverted to double precision (compliant with IEEE 754) and stored in the eight elements of zmm1 515 (after execution), while the eight upper half elements of zmm1 513 are upconverted to double precision (compliant with IEEE 754) and stored in the eight elements of zmm2 517.

[0076] Figure 5CThis is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion instruction according to one embodiment. Pseudocode 520 and block diagram 521 illustrate an embodiment for extracting, decoding, and executing the VCVTPS2PD2 dual-destination type conversion instruction (compliant with IEEE 754), which includes a source identifier for specifying the source vector register zmm1 523, a first destination identifier for specifying the first destination memory location mem2 525, and a second destination identifier for specifying the second destination memory location mem3 527. As shown, the eight lower half elements of zmm1 are converted to double precision (compliant with IEEE 754) and stored in the eight elements of the first destination memory location mem2 525, while the eight upper half elements of zmm1 are converted to double precision (compliant with IEEE 754) and stored in the eight elements of the second destination memory location mem3 527.

[0077] Figure 5D This is a pseudocode and block flowchart illustrating the execution of a dual-destination type conversion and accumulation instruction according to one embodiment. Pseudocode 530 and block diagram 531 illustrate an embodiment for extracting, decoding, and executing a VADDPS2PD mixed-precision type conversion (IEEE 754 compliant) and accumulation instruction, which includes a source identifier for specifying the source vector register zmm1 533, a first destination identifier for specifying the first destination register zmm2 535, and a second destination identifier for specifying the second destination register zmm3 537. As shown, the eight lower half elements of zmm1 are converted to double precision (IEEE 754 compliant) and accumulated or added to the data previously stored in the eight elements of zmm2 535, while the eight upper half elements of zmm1 are converted to double precision (IEEE 754 compliant) and accumulated or added to the data previously stored in the eight elements of zmm3 537.

[0078] Figure 5EThis is a pseudocode and block flowchart illustrating the execution of a dual-destination mixed-precision type conversion and accumulation using two instructions according to an embodiment. Pseudocode 540 and block diagram 541 illustrate an embodiment for extracting, decoding, and executing two instructions, namely VADDLOPS2PD and VADDHIPS2PD mixed-precision type conversion and accumulation instructions, each including a source identifier and a destination identifier for specifying the source vector register zmm1 543. The VADDLOPS2PD instruction is used to upconvert the "LO" half of the source vector register zmm1 543, i.e., elements [00:07], and accumulate or add the upconverted value to the corresponding value previously stored in the destination register zmm2 545. The VADDHIPS2PD instruction is used to upconvert the "HI" half of the source vector register zmm1 543, i.e., elements [08:15], and accumulate or add the upconverted value to the corresponding value previously stored in the destination register zmm3 547. As shown, after executing the two instructions, the eight lower half elements of zmm1 543 have been converted to double precision (compliant with IEEE 754) and added to the eight elements of zmm2 545, while the eight upper half elements of zmm1 543 have been converted to double precision (compliant with IEEE 754) and added to the eight elements of zmm3 547.

[0079] Figure 5F This is a pseudocode and block flowchart illustrating the execution of mixed-precision type conversion and accumulation instructions according to one embodiment. Pseudocode 550 and block diagram 551 illustrate an embodiment for extracting, decoding, and executing the VLADDPS2PD mixed-precision atomic memory accumulation instruction, which includes a source identifier for specifying a source vector register zmm1 553, a first destination identifier for specifying a first destination vector register zmm2 555, and a second destination identifier for specifying a second destination vector register zmm3 557. As shown, the eight lower half elements of zmm1 553 are converted to double precision (compliant with IEEE 754) and accumulated or added to the data previously stored in the eight elements stored in zmm2 555. As shown, the eight upper half elements of zmm1 553 are converted to double precision (compliant with IEEE 754) and accumulated or added to the data previously stored in the eight elements of zmm3 557.

[0080] Figure 5GThis is a pseudocode and block flowchart illustrating the execution of a mixed-precision atomic memory accumulation instruction according to one embodiment. Pseudocode 560 and block diagram 561 illustrate an embodiment for extracting, decoding, and executing the VLADDPS2PD mixed-precision atomic memory accumulation instruction, which includes a source identifier for specifying a source vector register zmm1 563, a first destination identifier for specifying a first destination memory location mem2 565, and an optional second destination identifier for specifying a second memory location mem3 567. Figure 5G The second destination identifier, illustrated with dashed lines, is used to indicate that it is optional: in some embodiments, only the first destination identifier is provided and used to identify the 16 adjacent memory locations. As shown, the 16 elements of zmm1 563 are converted to double precision (IEEE 754 compliant) and added to or accumulated with the data previously stored in the 16 elements starting at mem2 565. As shown, the eight upper-half elements of zmm1 563 are converted to double precision (IEEE 754 compliant) and added to or accumulated with the data previously stored in the eight elements of mem3 567 (memory location).

[0081] In other embodiments (not shown), the following two vector instructions are used for implementation. Figure 5G The operations illustrated in the diagram are: a first “LO” instruction used to upconvert and accumulate the 8 “LO” elements of zmm1 563 and add them to the elements of the first destination or accumulate them with the elements of the first destination; and a second “HI” instruction used to upconvert the 8 “HI” elements of zmm1 and accumulate them with the data previously stored in zmm3.

[0082] Instruction set

[0083] An instruction set may include one or more instruction formats. A given instruction format may define, among other things, various fields (e.g., number of bits, bit positions) and / or one or more other data fields (e.g., masks) to specify the operation (e.g., opcode) and operand(s)(s) to be performed, wherein the operation(s) are to be performed on said operand(s). Some instruction formats are further broken down by defining 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 generally in the same order, but because fewer fields are included, at least some have different bit positions) and / or be defined as given fields with different interpretations. Thus, each instruction of an ISA is expressed using a given instruction format (and, if defined, one of the given instruction templates of that instruction format) and includes fields for specifying the operation and operands. 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 operands (source 1 / destination and source 2); and the appearance of the ADD instruction in the instruction stream will have specific content in the operand field for selecting specific operands. A set of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) and using the Vector Extensions (VEX) encoding scheme has been released and / or published (see, for example, the Intel® 64 and IA-32 Architecture Software Developer's Handbook, September 2014; and the Intel® Advanced Vector Extensions Programming Reference, October 2014).

[0084] Exemplary instruction format

[0085] Implementations of the instructions(s) described herein may be embodied in various formats. Additionally, exemplary systems, architectures, and pipelines are detailed below. Implementations of the instructions(s) may be executed on such systems, architectures, and pipelines, but are not limited to those detailed herein.

[0086] General Vector-Friendly Instruction Format

[0087] A vector-friendly instruction format is an instruction format suitable for vector instructions (e.g., the existence of certain fields specifically for vector operations). Although an embodiment in which both vector and scalar operations are supported via a vector-friendly instruction format has been described, alternative embodiments use only vector operations within the vector-friendly instruction format.

[0088] Figures 6A-6BThis is a block diagram illustrating the general vector-friendly instruction format and its instruction template according to an embodiment of the present invention. Figure 6A This is a block diagram illustrating the general vector-friendly instruction format and its category A instruction template according to embodiments of the present invention; while Figure 6B This is a block diagram illustrating a general vector-friendly instruction format and its category B instruction template according to an embodiment of the present invention. Specifically, the general vector-friendly instruction format 600 defines category A and category B instruction templates, both of which include a no-memory-access 605 instruction template and a memory-access 620 instruction template. In the context of vector-friendly instruction formats, the term generally refers to an instruction format not bound to any specific instruction set.

[0089] Although the following embodiments of the invention will be described, the vector-friendly instruction format in these embodiments supports the following: a 64-byte vector operand length (or size) with a data element width (or size) of 32 bits (4 bytes) or 64 bits (8 bytes) (and therefore, a 64-byte vector consists of 16 double-word size elements or alternatively 8 quad-word size elements); a 64-byte vector operand length (or size) with a data element width (or size) of 16 bits (2 bytes) or 8 bits (1 byte); and 32-bit (4 bytes), 64-bit (8 bytes), 1 A 32-byte vector operand length (or size) with a 6-bit (2-byte) or 8-bit (1-byte) data element width (or size); and a 16-byte vector operand length (or size) with a 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element width (or size); alternative embodiments may support 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).

[0090] Figure 6A The Category A instruction module includes: 1) within the No Memory Access 605 instruction template, showing the No Memory Access, Full Round Control Type Operation 610 instruction template and the No Memory Access, Data Transformation Type Operation 615 instruction template; and 2) within the Memory Access 620 instruction template, showing the Memory Access, Temporary 625 instruction template and the Memory Access, Non-Temporary 630 instruction template. Figure 6BThe Category B instruction module includes: 1) within the No Memory Access 605 instruction template, showing the No Memory Access, Write Mask Control, Partial Rounding Control type operation 612 instruction template and the No Memory Access, Write Mask Control, vsize type operation 617 instruction template; and 2) within the Memory Access 620 instruction template, showing the Memory Access, Write Mask Control 627 instruction template.

[0091] The general vector-friendly instruction format 600 includes the following: Figures 6A-6B The following fields are listed in the order shown in the diagram.

[0092] Format field 640 - The specific value in this field (instruction format identifier value) uniquely identifies the vector-friendly instruction format, and therefore the occurrence of the instruction in the instruction stream in the vector-friendly instruction format. Thus, this field is optional in the sense that it is not needed for instruction sets that only have a general vector-friendly instruction format.

[0093] Base operation field 642 - its contents distinguish different base operations.

[0094] Register index field 644 – its contents directly or by address generate the locations of the specified source and destination operands (whether they are in registers or memory). These include a sufficient number of bits for selecting N registers from a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) register file. While in one embodiment N can be up to three source and one destination registers, alternative embodiments can support more or fewer source and destination registers (e.g., up to two sources, where one of these sources also acts as a destination; up to three sources, where one of these sources also acts as a destination; up to two sources and one destination).

[0095] Modifier field 646 – Its contents distinguish between the occurrence of instructions that specify a general vector instruction format for memory access and those that do not specify memory access; that is, between the no-memory-access instruction template 605 and the memory-access instruction template 620. Memory access operations read and / or write to the memory hierarchy (in some cases using values ​​in registers to specify source and / or destination addresses), while non-memory-access operations do not read and / or write to the memory hierarchy (e.g., the source and destination are registers). Although in one embodiment, this field also selects between three different methods for implementing memory address calculations, alternative embodiments may support more, fewer, or different methods for implementing memory address calculations.

[0096] The augmentation operation field 650 – its content distinguishes which of several different operations, besides the base address operation, should be performed. This field is context-specific. In one embodiment of the invention, this field is divided into a category field 668, an alpha (α) field 652, and a beta (β) field 654. The augmentation operation field 650 allows common groups of operations to be implemented in a single instruction, rather than in two, three, or four instructions.

[0097] Scale field 660 – Its contents allow for memory address generation (e.g., for using 2). 比例 * Scaling of the index field content (generated from the index and base address).

[0098] Displacement field 662A – its contents are used as part of memory address generation (e.g., for memory addresses using 2). 比例 * Address generation using index + base address + offset.

[0099] The displacement factor field 662B (note that the juxtaposition of displacement field 662A directly on displacement factor field 662B indicates that one or the other is used) – its contents are used as part of address generation; it specifies the displacement factor to be scaled by the size (N) of the memory access, where N is the number of bytes in the memory access (e.g., for a memory access using 2...). 比例 * Address generation from index + base address + scaled displacement). Redundant low-order bits are ignored and therefore the contents of the displacement factor field are multiplied by the total memory operand size (N) to generate the final displacement to be used in calculating the effective address. The value of N is determined by the processor hardware at runtime based on the total opcode field 674 (described later herein) and the data manipulation field 654C. The displacement field 662A and the displacement factor field 662B are optional in the sense that they are not used in the no-memory-access 605 instruction template, and / or different embodiments may implement only one of them or neither of them.

[0100] Data element width field 664 – Its content distinguishes which of the multiple data element widths to use (in some embodiments for all instructions; in other embodiments for only some instructions). This field is optional in the sense that it is not needed if only one data element width is supported and / or some aspect of the opcode is used to support the data element width.

[0101] Write mask field 670 – its content controls, based on the position of each data element, whether that data element position in the destination vector operand reflects the result of the base and augmentation operations. Category A instruction templates support merge write masking, while Category B instruction templates support both merging and zeroing write masking. When merging, the vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (specified by the base and augmentation operations); in another embodiment, the old value of each element in the destination is preserved, where the corresponding mask bit has 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 base and augmentation operations); in one embodiment, when the corresponding mask bit has a value of 0, the element in the destination is set to 0. This subset of functionality is the ability to control the vector length of the operations performed (i.e., the span of the modified elements, from first to last); however, it is not necessary for the modified elements to be consecutive. Therefore, write mask field 670 allows for some vector operations, including load, store, arithmetic, logic, etc. While an embodiment of the invention has been described in which the content of write mask field 670 selects one of a plurality of write mask registers containing the write mask to be used (and thus the content of write mask field 670 indirectly identifies the mask to be implemented), alternative embodiments may alternatively or additionally allow the content of mask write field 670 to directly specify the mask to be implemented.

[0102] The immediate field (672) – its contents allow for the specification of immediate values. This field is optional in the sense that it does not exist in implementations of general vector-friendly formats that do not support immediate values, and it does not exist in instructions that do not use immediate values.

[0103] Category field 668 – Its content distinguishes between instructions in different categories. (See reference) Figure 6A -B indicates that the content of this field selects between Category A and Category B instructions. Figure 6A In -B, rounded cornersquares are used to indicate that a specific value exists in the field (e.g., in...). Figure 6A -B represents category A668A and category B668B for category field 668 respectively.

[0104] Category A instruction template

[0105] In the case of the non-memory access instruction template 605 of category A, the alpha field 652 is interpreted as the rs field 652A, the content of which distinguishes which of the different amplification operation types should be executed (e.g., specifying rounding 652A.1 and data transformation 652A.2 for the no-memory access, rounding type operation 610 and the no-memory access, data transformation type operation 615 instruction templates, respectively), while the beta field 654 distinguishes which of the specified type of operation should be executed. In the no-memory access instruction template 605, the scaling field 660, the shift field 662A, and the shift-scale field 662B are not present.

[0106] No memory access instruction template - full rounding control type operation

[0107] In the no-memory-access, full-round-control type operation 610 instruction template, the beta field 654 is interpreted as a rounding control field 654A, the contents of which provide static rounding. While in the embodiments described in this invention, the rounding control field 654A includes a suppress all floating-point exception (SAE) field 656 and a rounding operation control field 658, alternative embodiments may support encoding both of these concepts into the same field or having only one or the other of these concepts / fields (e.g., only the rounding operation control field 658).

[0108] SAE field 656 – its content distinguishes whether exception event reporting is disabled; when the content of SAE field 656 indicates that suppression is enabled, a given instruction will not report any kind of floating-point exception flags and will not trigger any floating-point exception handlers.

[0109] Rounding operation control field 658 – its contents distinguish which of a set of rounding operations to be performed (e.g., round up, round down, round towards zero, and round-to-nearest). Therefore, rounding operation control field 658 allows the rounding mode to be changed based on each instruction. In one embodiment of the invention, where the processor includes a control register for specifying the rounding mode, the contents of rounding operation control field 658 overwrite that register value.

[0110] No Memory Access Instruction Template - Data Transformation Type Operations

[0111] In the instruction template 615 of the no-memory access data transformation type operation, the beta field 654 is interpreted as the data transformation field 654B, the contents of which distinguish which of the multiple data transformations to be performed (e.g., no data transformation, swizzle, broadcast).

[0112] In the case of memory access instruction template 620 of category A, alpha field 652 is interpreted as eviction hint field 652B, the content of which distinguishes which eviction hint is to be used (in... Figure 6A In this context, temporary 652B.1 and non-temporary 652B.2 are specified for memory access, temporary 625 instruction template, and memory access, non-temporary 630 instruction template, respectively. The beta field 654 is interpreted as the data manipulation field 654C, whose content distinguishes which of several data manipulation operations (also known as primitives) should be performed (e.g., no manipulation; broadcast; source upcast; and destination downcast). The memory access 620 instruction template includes a scaling field 660 and optionally a displacement field 662A or a displacement scaling field 662B.

[0113] Vector memory instructions, with translation support, perform vector loading from memory and vector storage to memory. For regular vector instructions, vector memory instructions transfer data from / to memory on an element-by-element basis, where the actual elements transferred are determined by the contents of the vector mask selected as the write mask.

[0114] Memory access instruction template – Temporary

[0115] Temporary data is data that may be quickly reused to benefit from caching. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely.

[0116] Memory access instruction template – non-temporary

[0117] Non-temporary data is data that is unlikely to be reused quickly to benefit from the L1 cache and should be given priority for eviction. However, this is a hint, and different processors may implement it differently, including ignoring the hint entirely.

[0118] Category B instruction template

[0119] In the case of instruction template of category B, alpha field 652 is interpreted as write mask control (Z) field 652C, the content of which distinguishes whether the write mask controlled by write mask field 670 should be merged or zeroed.

[0120] In the case of the non-memory access instruction template 605 (Category B), a portion of the beta field 654 is interpreted as the RL field 657A, the content of which distinguishes which of the different amplification operation types should be implemented (e.g., specifying rounding 657A.1 and vector length (VSIZE) 657A.2 for the no-memory access, write mask control, partial rounding control type operation 612 instruction template and the no-memory access, write mask control, VSIZE type operation 617 instruction template, respectively), while the remaining portion of the beta field 654 distinguishes which of the specified types of operations should be implemented. In the no-memory access instruction template 605, the scaling field 660, the displacement field 662A, and the displacement scaling field 662B are absent.

[0121] In the instruction template of operation 610 of type no memory access, write mask control, partial rounding control, the remainder of beta field 654 is interpreted as rounding operation field 659A and exception event reporting is disabled (the given instruction does not report any kind of floating-point exception flag and does not raise any floating-point exception handler).

[0122] Rounding operation control field 659A – Like rounding operation control field 658, its contents distinguish which of a set of rounding operations to perform (e.g., round up, round down, round toward zero, and round to nearest). Therefore, rounding operation control field 659A allows the rounding mode to be changed based on each instruction. In one embodiment of the invention, where the processor includes a control register for specifying the rounding mode, the contents of rounding operation control field 658 overwrite that register value.

[0123] In the instruction template 617 for no memory access, write mask control, and VSIZE type operation, the remainder of the beta field 654 is interpreted as the vector length field 659B, the contents of which distinguish which of the multiple data vector lengths to be implemented (e.g., 128, 256, or 512 bytes).

[0124] In the case of the memory access 620 instruction template of category B, a portion of the beta field 654 is interpreted as a broadcast field 657B, the content of which distinguishes whether a broadcast-type data manipulation operation is to be performed, while the remaining portion of the beta field 654 is interpreted as a vector length field 659B. The memory access 620 instruction template includes a scaling field 660, and optionally a displacement field 662A or a displacement scaling field 662B.

[0125] Regarding the general vector-friendly instruction format 600, a full opcode field 674 is shown, comprising a format field 640, a base address operation field 642, and a data element width field 664. While one embodiment is shown in which the full opcode field 674 includes all of these fields, in embodiments that do not support all of them, the full opcode field 674 includes fewer than all of these fields. The full opcode field 674 provides the operation code (opcode).

[0126] The augmentation operation field 650, the data element width field 664, and the write mask field 670 allow these features to be specified on a per-instruction basis in a generic vector-friendly instruction format.

[0127] Combining the write mask field and the data element width field creates typed instructions because they allow masks to be applied based on different data element widths.

[0128] The various instruction templates found within categories A and B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only category A, only category B, or both categories. For example, a high-performance general-purpose out-of-order core intended for general-purpose computing may support only category B, a core intended primarily for graphics and / or scientific (throughput) computing may support only category A, and a core intended for both may support both (of course, a hybrid core having templates and instructions from both categories, but not all templates and instructions from both categories, is within the scope of the invention). Moreover, a single processor may include multiple cores, all of which support the same category or where different cores support different categories. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores intended primarily for graphics and / or scientific computing may support only category A, while one or more of the general-purpose cores may be a high-performance general-purpose core with out-of-order execution and register renaming intended for general-purpose computing that supports only category B. Another processor without a separate graphics core may include one or more general-purpose ordered or out-of-order cores supporting both category A and category B. Of course, features from one category may also be implemented in another category in different embodiments of the invention. Programs written in high-level languages ​​will be put (e.g., just-in-time compilation or static compilation) into a variety of different executable forms, including: 1) forms that only have instructions of one or more classes supported by the target processor; or 2) forms that have alternative routines written using different combinations of instructions of all classes and control flow code for selection routines to execute based on instructions supported by the processor currently executing the code.

[0129] Exemplary Vector-Friendly Instruction Format

[0130] Figure 7A This is a block diagram illustrating an exemplary specific vector-friendly instruction format according to an embodiment of the present invention. Figure 7A A specific vector-friendly instruction format 700 is shown, which is specific in the sense of specifying positions, sizes, interpretations, and field ordering, as well as the values ​​used for some of those fields. This specific vector-friendly instruction format 700 can be used to extend the x86 instruction set, and therefore some of the fields are similar to or the same as those used in existing x86 instruction sets and their extensions (e.g., AVX). The format maintains consistency with prefix-coded fields, actual opcode byte fields, MOD R / M fields, SIB fields, shift fields, and immediate numeric fields of existing x86 instruction sets with extensions. The illustration is from the fields in Figure 6, where... Figure 7A The fields are mapped to the fields from Figure 6.

[0131] It should be understood that although embodiments of the invention have been described with reference to a specific vector-friendly instruction format 700 in the context of a general vector-friendly instruction format 600 for illustrative purposes, the invention is not limited to that specific vector-friendly instruction format 700, except as stated therein. For example, the general vector-friendly instruction format 600 is intended for a wide variety of possible sizes for various fields, while the specific vector-friendly instruction format 700 is shown as a field with a specific size. By way of specific example, although the data element width field 664 is illustrated as a single field in the specific vector-friendly instruction format 700, the invention is not limited thereto (that is, the general vector-friendly instruction format 600 is intended for other sizes of the data element width field 664).

[0132] The general vector-friendly instruction format 600 includes the following: Figure 7A The following fields are listed in the order shown in the diagram.

[0133] The EVEX prefix (bytes 0-3) 702 – is encoded in four-byte format.

[0134] Format field 640 (EVEX byte 0, bits [7:0]) - The first byte (EVEX byte 0) is format field 640 and it contains 0x62 (a unique value used in one embodiment of the invention to distinguish vector-friendly instruction formats).

[0135] The second to fourth bytes (EVEX bytes 1-3) include multiple bit fields that provide the specific capacity.

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

[0137] REX' field 710 - This is the first part of REX' field 710 and is the EVEX.R' bit field (EVEX byte 1, bit [4] - R') used to encode the upper 16 or lower 16 of the extended 32 register set. In one embodiment of the invention, this bit, along with the other bits indicated below, is stored in a bit-inverted format to distinguish it from the BOUND instruction, whose actual opcode byte is 62, but the value of 11 in the MOD field is not accepted in the MOD R / M field (described below); alternative embodiments of the invention do not store this bit and the other bits indicated below in an inverted format. A value of 1 is used to encode the lower 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and other RRRs from other fields.

[0138] Opcode mapping field 715 (EVEX byte 1, bit [3:0] – mmmm) - its contents are encoded for the implied leading opcode byte (0F, 0F 38 or 0F 3).

[0139] The data element width field is 664 (EVEX byte 2, bit [7] – W) – indicated by the label EVEX.W. EVEX.W is used to define the granularity (size) of the data type (32-bit data element or 64-bit data element).

[0140] EVEX.vvvv 720 (EVEX byte 2, bits [6:3] – vvvv) - The function of EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand specified in inverted (1s supplement) form and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand specified in 1s supplement form for some vectorshift; or 3) EVEX.vvvv does not encode any operands, the field is reserved and should contain 1111b. Therefore, the EVEX.vvvv field 720 encodes the four lower-order bits of the first source register specifier stored in inverted (1s supplement) form. Depending on the instruction, additional different EVEX bit fields are used to extend the specifier size to 32 registers.

[0141] EVEX.U 668 Category field (EVEX byte 2, bit [2]-U) – If EVEX.U=0, it indicates category A or EVEX.U0; if EVEX.U=1, it indicates category B or EVEX.U1.

[0142] Prefix encoding field 725 (EVEX byte 2, bits [1:0]-pp) - provides additional bits for the base address operation field. Besides supporting legacy SSE instructions in EVEX prefix format, this also has the benefit of compressing the SIMD prefix (not requiring bytes to express the SIMD prefix, the EVEX prefix only requires 2 bits). In one embodiment, to support legacy SSE instructions using SIMD prefixes (66H, F2H, F3H) in both legacy and EVEX prefix formats, these legacy SIMD prefixes are encoded into a SIMD prefix encoding field; and expanded at runtime to the legacy SIMD prefix before being provided to the PLA for the decoder (so the PLA can execute these legacy instructions in both legacy and EVEX formats without modification). Although newer instructions can use the contents of the EVEX prefix encoding field directly as opcode expansion, some embodiments expand in a similar manner for consistency, but allow different meanings to be specified through these legacy SIMD prefixes. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encoding and therefore do not require expansion.

[0143] Alpha field 652 (EVEX byte 3, bit [7] - EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl, and EVEX.N; also illustrated with α) - As previously described, this field is context-specific.

[0144] Beta field 654 (EVEX byte 3, bit [6:4] - SSS, also known as EVEX.s 2-0 EVEX.r 2-0 EVEX.rr1, EVEX.LL0, EVEX.LLB; also illustrated with βββ - As previously described, this field is context-specific.

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

[0146] Write mask field 670 (EVEX byte 3, bits [2:0]-kkk) - as previously described, its content specifies the index of the register in the write mask register. In one embodiment of the invention, the specific value EVEX.kkk=000 has a special behavior that implies no write mask is used for a particular instruction (this can be implemented in a variety of ways, including using a write mask that is hardwired to allones or makes the masking hardware bypass).

[0147] The actual opcode field 730 (byte 4) is also known as the opcode byte. This field specifies the portion of the opcode.

[0148] The MOD R / M field 740 (byte 5) includes the MOD field 742, the Reg field 744, and the R / M field 746. As previously described, the content of the MOD field 742 distinguishes between memory access and non-memory access operations. The function of the Reg field 744 can be summarized in two cases: encoding the destination register operand or the source register operand, or being treated as an opcode extension and not used for encoding any instruction operand. The function of the R / M field 746 can include encoding the instruction operand at the reference memory address, or encoding the destination register operand or the source register operand.

[0149] Scale, Index, Base (SIB) Byte (Byte 6) - As previously described, the contents of Scale field 660 are used for memory address generation. SIB.xxx 754 and SIB.bbb 756 - The contents of these fields have been previously discussed regarding register indices Xxxx and Bbbb.

[0150] Displacement field 662A (bytes 7-10) - When MOD field 742 contains 10, bytes 7-10 are displacement field 662A, and it works the same as a traditional 32-bit displacement (disp32) and operates at the byte granularity.

[0151] Displacement Factor Field 662B (Byte 7) - When MOD field 742 contains 0s and 1s, byte 7 is the displacement factor field 662B. This field is located in the same position as the traditional x86 instruction set 8-bit displacement (disp8) that operates at byte granularity. Because disp8 is sign-extended, it can be addressed only between -128 and 127 byte offsets; for a 64-byte cache line, disp8 uses 8 bits that can be set to only four truly useful values: -128, -64, 0, and 64; because a larger range is often required, disp32 is used; however, disp32 requires 4 bytes. The displacement factor field 662B is a reinterpretation of disp8 compared to disp8 and disp32; when using the displacement factor field 662B, the actual displacement is determined by multiplying the contents of the displacement factor field by the size (N) of the memory operand access. This type of displacement is called disp8*N. This reduces the average instruction length (a single byte used for displacement but with a much larger range). Such compressed displacements assume the effective displacement is a multiple of the granularity of memory access, and therefore eliminate the need for redundant low-order bit encoding of address offsets. In other words, the displacement factor field 662B replaces the traditional x86 instruction set 8-bit displacement. Therefore, the displacement factor field 662B is encoded in the same way as the x86 instruction set 8-bit displacement (so the ModRM / SIB encoding rules remain unchanged), with the only exception being that disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules or encoding length, but only in the interpretation of the displacement values ​​by the hardware (which requires scaling the size of the memory operand to obtain byte-level address offsets). Immediate digital segment 672 operates as previously described.

[0152] Full opcode field

[0153] Figure 7B This is a block diagram illustrating the fields constituting a specific vector-friendly instruction format 700 for the full opcode field 674 according to an embodiment of the present invention. Specifically, the full opcode field 674 includes a format field 640, a base address operation field 642, and a data element width (W) field 664. The base address operation field 642 includes a prefix encoding field 725, an opcode mapping field 715, and a real opcode field 730.

[0154] Register index field

[0155] Figure 7C This is a block diagram illustrating the fields of a specific vector-friendly instruction format 700 constituting register index field 644 according to an embodiment of the present invention. Specifically, register index field 644 includes REX field 705, REX' field 710, MODR / M.reg field 744, MODR / Mr / m field 746, VVVV field 720, xxx field 754, and bbb field 756.

[0156] Amplification operation field

[0157] Figure 7D This is a block diagram illustrating the fields of the specific vector-friendly instruction format 700 constituting the amplification operation field 650 according to an embodiment of the present invention. When the category (U) field 668 contains 0, it means EVEX.U0 (category A 668A); when it contains 1, it means EVEX.U1 (category B 668B). When U=0 and the MOD field 742 contains 11 (meaning no memory access operation), the alpha field 652 (EVEX byte 3, bits [7]-EH) is interpreted as the rs field 652A. When the rs field 652A contains a 1 (rounding 652A.1), the beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the rounding control field 654A. The rounding control field 654A includes a one-bit SAE field 656 and a two-bit rounding operation field 658. When the rs field 652A contains 0 (data transformation 652A.2), the beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data transformation field 654B. When U=0 and the MOD field 742 contains 00, 01, or 10 (meaning a memory access operation), the beta field 652 (EVEX byte 3, bits [7]-EH) is interpreted as an eviction hint (EH) field 652B, and the beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data manipulation field 654C.

[0158] When U=1, the alpha field 652 (EVEX byte 3, bit [7]-EH) is interpreted as the write mask control (Z) field 652C. When U=1 and the MOD field 742 contains 11 (meaning no memory access operation), a portion of the beta field 654 (EVEX byte 3, bit [4]-S0) is interpreted as the RL field 657A; when it contains 1 (rounded to 657A.1), the remainder of the beta field 654 (EVEX byte 3, bit [6-5]-S0) is interpreted as the RL field 657A. 2-1The remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, while when RL field 657A contains 0 (VSIZE 657.A2), the remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, and when RL field 657A contains 0 (VSIZ 2-1 ) is interpreted as vector length field 659B (EVEX byte 3, bits [6-5]-L) 1-0 When U=1 and MOD field 742 contains 00, 01, or 10 (meaning a memory access operation), beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as vector length field 659B (EVEX byte 3, bits [6:5]-L). 1-0 ) and broadcast field 657B (EVEX byte 3, bit [4]-B).

[0159] Exemplary Register Architecture

[0160] Figure 8 This is a block diagram of a register architecture 800 according to an embodiment of the present invention. In the illustrated embodiment, there are 32 vector registers 810, each 512 bits wide; these registers are referred to as zmm0 to zmm31. The lower 256 bits of the next 16 zmm registers overwrite registers ymm0-16. The lower 128 bits of the next 16 zmm registers (the lower 128 bits of the ymm registers) overwrite registers xmm0-15. As illustrated in the table below, the specific vector-friendly instruction format 700 operates on these overwritten register files:

[0161] .

[0162] In other words, the vector length field 659B is selected between a maximum length and one or more other shorter lengths, each of which is half the length of the preceding length; and instruction templates without the vector length field 659B operate on the maximum vector length. Further, in one embodiment, the category B instruction template of the specific vector-friendly instruction format 700 operates on compressed or scalar single / double-precision floating-point data and compressed or scalar integer data. Scalar operations are performed at the lowest-order data element positions in the zmm / ymm / xmm registers; according to an embodiment, higher-order data element positions are either on the left or zeroed out, as they are before the instruction.

[0163] Write mask register 815 – In the illustrated embodiment, there are eight write mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, write mask register 815 is 16 bits in size. As previously described, in one embodiment of the invention, the vector mask register k0 cannot be used as a write mask; when the encoding that would normally indicate k0 is used as the write mask, it selects a hardwired 0xFFFF write mask, effectively disabling write masking for that instruction.

[0164] General Purpose Registers 825 – In the illustrated embodiment, there are sixteen 64-bit general purpose registers used together with the existing x86 addressing modes for addressing memory operands. These registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0165] Scalar floating-point stack register file (x87 stack) 845 (aliased as MMX packed integer flat register file 850) - In the illustrated embodiment, this x87 stack is an octal stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions; while the MMX registers are used to perform operations on 64-bit packed integer data and to hold operands for some operations performed between the MMX and XMM registers.

[0166] Alternative embodiments of the present invention may use wider or narrower registers. Additionally, alternative embodiments of the present invention may use more, fewer, or different register files and registers.

[0167] Exemplary core architecture, processor, and computer architecture

[0168] Processor cores can be implemented in different ways and in different processors for different purposes. For example, such core implementations may include: 1) general-purpose ordered cores intended for general-purpose computing; 2) high-performance general-purpose unordered cores intended for general-purpose computing; and 3) dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) CPUs comprising one or more general-purpose ordered cores intended for general-purpose computing and / or one or more general-purpose unordered cores intended for general-purpose computing; and 2) coprocessors comprising one or more dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Such different processors result in different computer system architectures, which may include: 1) coprocessors on a separate chip from the CPU; 2) coprocessors 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 dedicated cores); and 4) systems-on-a-chip that may include the CPU (sometimes referred to as application cores or application processors), the aforementioned coprocessors, and additional functionality on the same die. The following describes an exemplary core architecture, followed by a description of exemplary processor and computer architectures.

[0169] Exemplary core architecture

[0170] Ordered and disordered core diagrams

[0171] Figure 9A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming and unordered release / execution pipeline according to embodiments of the present invention. Figure 9B This is a block diagram illustrating an exemplary embodiment of an ordered architecture core according to an embodiment of the present invention and an exemplary register renaming and out-of-order release / execution architecture core to be included in the processor. Figure 9A The solid boxes in -B illustrate ordered dies and ordered cores, while the optional dashed boxes illustrate register renaming, unordered release / execution dies, and cores. Since the ordered aspect is a subset of the unordered aspect, the unordered aspect will be described.

[0172] exist Figure 9A In the processor pipeline 900, there are fetch stage 902, length decoding stage 904, decoding stage 906, allocation stage 908, renaming stage 910, scheduling (also known as dispatch or issue) stage 912, register read / memory read stage 914, execution stage 916, write-back / memory write stage 918, exception handling stage 922, and commit stage 924.

[0173] Figure 9BThe diagram shows a processor core 990 including a front-end unit 930 coupled to an execution engine unit 950, and both the front-end unit 930 and the execution engine unit 950 are coupled to a memory unit 970. The core 990 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. Alternatively, the core 990 can be a dedicated core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.

[0174] Front-end unit 930 includes a branch prediction unit 932 coupled to instruction cache unit 934, which is coupled to instruction translation back buffer (TLB) 936, which is coupled to instruction fetch unit 938, which is coupled to decoding unit 940. Decoding unit 940 (or decoder) can decode instructions and, as output, generate one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals decoded from, or otherwise reflecting, or derived from, the original instructions. Decoding unit 940 can be implemented using various mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), etc. In one embodiment, core 990 includes a microcode ROM or other medium (e.g., in decoding unit 940 or otherwise within front-end unit 930) storing microcode for certain macro instructions. The decoding unit 940 is coupled to the rename / allocator unit 952 in the execution engine unit 950.

[0175] The execution engine unit 950 includes a rename / allocator unit 952 coupled to a retirement unit 954 and a set of one or more scheduler units 956. The scheduler units 956 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler units 956 are coupled to one or more physical register file units 958. Each of the physical register file units 958 represents one or more physical register files, which store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer to the address of the next instruction to be executed), etc. In one embodiment, the physical register file units 958 include vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. One or more physical register file units 958 are overlapped by retirement units 954 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using one or more reorder buffers and one or more retirement register files; using one or more future files, one or more history buffers, and one or more retirement register files; using register mappings and pools of registers; etc.). The retirement unit 954 and one or more physical register file units 958 are coupled to one or more execution clusters 960. The one or more execution clusters 960 include a set of one or more execution units 962 and a set of one or more memory access units 964. The execution unit 962 can perform various operations (e.g., shift, addition, subtraction, multiplication) and various operations on various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include multiple execution units dedicated to a specific function or function set, other embodiments may include only one execution unit or multiple execution units all performing all functions. One or more scheduler units 956, one or more physical register file units 958, and one or more execution clusters 960 are shown as possibly multiple, because some embodiments create separate pipelines for a certain type of data / operation (e.g., scalar integer pipeline, scalar floating-point / compacted integer / compacted floating-point / vector integer / vector floating-point pipeline, and / or memory access pipelines each having their own scheduler unit, one or more physical register file units, and / or execution clusters, and in the case of separate memory access pipelines, some embodiments are implemented in which only the execution cluster of that pipeline has one or more memory access units 964).It should also be understood that where separate pipelines are used, one or more of these pipelines may be published / executed out of order and the remainder may be published / executed in an ordered manner.

[0176] The memory access unit 964 is coupled to the memory unit 970, which includes a data TLB unit 972 coupled to the data cache unit 974, which is coupled to the level 2 (L2) cache unit 976. In one exemplary embodiment, the memory access unit 964 may include a load unit, a memory address unit, and a memory data unit, each of which is coupled to the data TLB unit 972 in the memory unit 970. The instruction cache unit 934 is further coupled to the level 2 (L2) cache unit 976 in the memory unit 970. The L2 cache unit 976 is coupled to one or more other levels of cache and ultimately to main memory.

[0177] For example, the exemplary register renaming, out-of-order release / execution core architecture can implement pipeline 900 as follows: 1) Instruction fetch unit 938 implements fetch level 902 and length decoding level 904; 2) Decoding unit 940 implements decoding level 906; 3) Rename / allocator unit 952 implements allocation level 908 and rename level 910; 4) (one or more) scheduler units 956 implement scheduling level 912; 5) (one or more) physical register file units 958 and memory units 970 implement register read / memory read level 914; execution cluster 960 implements execution level 916; 6) memory unit 970 and (one or more) physical register file units 958 implement write-back / memory write level 918; 7) various units can be associated with exception handling level 922; and 8) retirement unit 954 and (one or more) physical register file units 958 implement commit level 924.

[0178] The core 990 can support one or more instruction sets including the instructions described herein (e.g., the x86 instruction set (with some extensions already added with newer versions)); the MIPS instruction set of CA's Sunnyvale MIPS Technology; and the ARM instruction set of CA's Sunnyvale ARM Holdings (with optional additional extensions such as NEON). In one embodiment, the core 990 includes logic for supporting compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing the use of compressed data to perform operations used by many multimedia applications.

[0179] It should be understood that the core can support multithreading (two or more parallel sets of performing operations or threads) and can do so in a variety of ways, including time-slice multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads in which the physical core is simultaneously multithreaded), or combinations thereof (e.g., time-slice fetching and decoding followed by subsequent simultaneous multithreading, such as in Intel® Hyper-Threading Technology).

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

[0181] Specific examples of ordered core architecture

[0182] Figure 10A -B diagram illustrates a more specific and exemplary ordered core architecture, where the core will be one of several logic blocks in the chip (including other cores of the same type and / or different types). The logic block, depending on the application, communicates with a fixed-function logic, memory I / O interface, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network).

[0183] Figure 10A This is a block diagram of a single processor core according to an embodiment of the invention, along with its connection to the on-die interconnect network 1002 and a local subset thereof, along with the Level 2 (L2) cache 1004. In one embodiment, the instruction decoder 1000 supports the x86 instruction set with a compact data instruction set extension. The L1 cache 1006 allows low-latency accesses to cache memory into scalar and vector units. While in one embodiment (for simplicity), scalar unit 1008 and vector unit 1010 use separate register sets (scalar register 1012 and vector register 1014, respectively) and data passed between them is written to memory and then read back from the Level 1 (L1) cache 1006, alternative embodiments of the invention may use different methods (e.g., using a single register set or including a communication path that allows data to be passed between two register files without being written and read back).

[0184] The local subset of L2 cache 1004 is part of a global L2 cache that is divided into separate local subsets (one local subset per processor core). Each processor core has a direct access path to its own local subset of L2 cache 1004. Data read by a processor core is stored in its L2 cache subset 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 and flushed from other subsets if necessary. This ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents (such as processor cores, L2 cache, and other logical blocks) to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0185] Figure 10B This is an embodiment of the present invention. Figure 10A An expanded diagram of a portion of the processor core. Figure 10B This includes the L1 data cache 1006A portion of L1 cache 1004, and further details regarding vector unit 1010 and vector register 1014. Specifically, vector unit 1010 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1028) that executes one or more of integer, single-precision float, and double-precision float instructions. This VPU supports allocation of register inputs using allocation unit 1020, digital conversion using conversion units 1022A-B, and copying on memory inputs using copy unit 1024. Write mask register 1026 allows for the writing of vectors obtained from prediction results.

[0186] Figure 11 This is a block diagram of a processor 1100 that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to an embodiment of the present invention. Figure 11 The solid-line diagram in the figure has a processor 1100 with a single core 1102A, a system agent unit 1110, and a group of one or more bus controller units 1116, while the optional addition diagram with dashed lines has an alternative processor 1100 with multiple cores 1102A-N, a group of one or more integrated memory controller units 1114 from the system agent units 1110, and dedicated logic 1108.

[0187] Therefore, different implementations of processor 1100 may include: 1) a CPU having dedicated logic 1108 (which may include one or more cores) that is integrated graphics and / or scientific (throughput) logic and cores 1102A-N that are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose unordered cores, or a combination of both); 2) a coprocessor having a large number of dedicated cores 1102A-N that are intended primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor having a large number of general-purpose ordered cores 1102A-N. Thus, processor 1100 may be a general-purpose processor, coprocessor, or dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (General-Purpose Graphics Processing Unit), a high-throughput many-integrated-core (MIC) coprocessor (including 30 or more cores), an embedded processor, and so on. The processor may be implemented on one or more chips. The processor 1100 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of processing technologies (e.g., BiCMOS, CMOS, or NMOS).

[0188] The memory hierarchy includes one or more levels of cache within the core, a set or one or more shared cache units 1106, and external memory (not shown) coupled to a set of integrated memory controller units 1114. The set of shared cache units 1106 may include one or more intermediate-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other level caches, last-level caches (LLCs), and / or combinations thereof. While in one embodiment, integrated graphics logic (which is an example of dedicated logic and is also referred to as dedicated logic), the set of shared cache units 1106, and system proxy units 1110 / (one or more) of integrated memory controller units 1114 are interconnected based on a ring interconnect unit 1112, alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, consistency is maintained between one or more cache units 1106 and the core 1102-AN.

[0189] In some embodiments, one or more of the cores 1102A-N are multithreaded. System agent 1110 includes those components that coordinate and operate the cores 1102A-N. System agent unit 1110 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or include logic and components required for regulating the power state of the integrated graphics logic and the cores 1102A-N. The display unit is used to drive one or more externally connected displays.

[0190] In terms of the instruction set, the 1102A-N cores can be homogeneous or heterogeneous; that is, two or more cores in the 1102A-N cores may be able to execute the same instruction set, while other cores may be able to execute only a subset of that instruction set or a different instruction set.

[0191] Exemplary computer architecture

[0192] Figure 12-15 This is a block diagram of an exemplary computer architecture. Other system designs and configurations known in the art 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 various other electronic devices are also applicable. Generally, a large number of systems or electronic devices capable of incorporating processors and / or other execution logic as disclosed herein are typically applicable.

[0193] Now for reference Figure 12 This diagram illustrates a block diagram of a system 1200 according to an embodiment of the present invention. The system 1200 may include one or more processors 1210, 1215 coupled to a controller hub 1220. In one embodiment, the controller hub 1220 includes a graphics memory controller hub (GMCH) 1290 and an input / output hub (IOH) 1250 (which may be on a separate chip); the GMCH 1290 includes memory and a graphics controller, with memory 1240 and a coprocessor 1245 coupled to the memory and graphics controller; the IOH 1250 couples an input / output (I / O) device 1260 to the GMCH 1290. Alternatively, one or both of the memory and the graphics controller may be integrated into a processor (as described herein), with memory 1240 and coprocessor 1245 directly coupled to processor 1210 and controller hub 1220 on a single chip having IOH 1250.

[0194] exist Figure 12 The optional properties of the additional processor 1215 are indicated by a broken line. Each processor 1210, 1215 may include one or more of the processing cores described herein and may be some version of processor 1100.

[0195] The memory 1240 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of both. In at least one embodiment, the controller hub 1220 communicates with one or more processors 1210, 1215 via a multi-drop bus (such as a frontside bus, FSB)), a point-to-point interface (such as a QuickPath Interconnect, QPI) or similar connection 1295.

[0196] In one embodiment, the coprocessor 1245 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and so on. In one embodiment, the controller hub 1220 may include an integrated graphics accelerator.

[0197] In terms of the spectrum of metrics of merit, including indicators such as architecture, microarchitecture, thermal characteristics, and power consumption, there can be a wide variety of differences between physical resources such as processors 1210 and 1215.

[0198] In one embodiment, processor 1210 executes instructions that control general-type data processing operations. Coprocessor instructions may be embedded within these instructions. Processor 1210 identifies these coprocessor instructions as the type that should be executed by an attached coprocessor 1245. Therefore, processor 1210 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1245 on a coprocessor bus or other interconnect. One or more coprocessors 1245 receive and execute the received coprocessor instructions.

[0199] Now for reference Figure 13 This illustrates a block diagram of a first, more specific, exemplary system 1300 according to an embodiment of the present invention. (As shown in...) Figure 13 As shown, the multiprocessor system 1300 is a point-to-point interconnect system and includes a first processor 1370 and a second processor 1380 coupled via a point-to-point interconnect 1350. Each of the first processor 1370 and the second processor 1380 may be a version of processor 1100. In one embodiment of the invention, the first processor 1370 and the second processor 1380 are processors 1210 and 1215, respectively, and the coprocessor 1338 is a coprocessor 1245. In another embodiment, the first processor 1370 and the second processor 1380 are processor 1210 and coprocessor 1245, respectively.

[0200] A first processor 1370 and a second processor 1380 are shown, each including an integrated memory controller (IMC) unit 1372 and 1382, respectively. The first processor 1370, as part of its bus controller unit, also includes point-to-point (PP) interfaces 1376 and 1378; similarly, the second processor 1380 includes PP interfaces 1386 and 1388. The first processor 1370 and the second processor 1380 can exchange information via the point-to-point (PP) interface using the PP interface circuits 1378 and 1388. Figure 13 As shown, IMC 1372 and 1382 couple the processor to the corresponding memory (i.e., memory 1332 and memory 1334), which may be portions of the main memory locally attached to the corresponding processor.

[0201] The first processor 1370 and the second processor 1380 can each exchange information with the chipset 1390 via point-to-point interface circuits 1376, 1394, 1386, and 1398 through various PP interfaces 1352 and 1354. The chipset 1390 can optionally exchange information with the coprocessor 1338 via a high-performance interface 1392. In one embodiment, the coprocessor 1338 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc.

[0202] A shared cache (not shown) may be included in one or two processors and connected to the processors via the PP interconnect, such that if the processors are placed in a low-power mode, the local cache information of one or two processors can be stored in the shared cache.

[0203] Chipset 1390 can be coupled to first bus 1316 via interface 1396. In one embodiment, first bus 1316 may be a peripheral component interconnect (PCI) bus, or a bus such as a PCI Express bus or another third-generation I / O interconnect bus, although the scope of the invention is not limited thereto.

[0204] As in Figure 13As shown, various I / O devices 1314, along with a bus bridge 1318, can be coupled to a first bus 1316, which in turn couples the first bus 1316 to a second bus 1320. In one embodiment, one or more additional processors 1315 (such as coprocessors, high-throughput MIC processors, GPGPUs, accelerators such as graphics accelerators or digital signal processing (DSP) units, field-programmable gate arrays, or any other processors) are coupled to the first bus 1316. In one embodiment, the second bus 1320 may be a low pin count (LPC) bus. In one embodiment, various devices can be coupled to the second bus 1320, including, for example, a keyboard and / or mouse 1322, a communication device 1327, and a storage unit 1328 (such as a disk drive or other mass storage device that may include instructions / code and data 1330). Further, audio I / O 1324 can be coupled to the second bus 1320. Note that other architectures are possible. For example, instead of... Figure 13 The point-to-point architecture allows the system to implement multi-point branch bus or other similar architectures.

[0205] Now for reference Figure 14 The diagram shows a block diagram of a second, more specific, exemplary system 1400 according to an embodiment of the present invention. Figure 13 and 14 Similar elements in the model have similar reference numerals, and Figure 13 Some aspects have already been from Figure 14 Omitted to avoid Figure 14 Other aspects are unclear.

[0206] Figure 14 The first processor 1370 and the second processor 1380 can each include integrated memory and I / O control logic (“CL”). Therefore, CL includes an integrated memory controller unit and includes I / O control logic. Figure 14 The diagram not only illustrates the coupling of memories 1332 and 1334 to the CL, but also shows that I / O device 1414 is coupled to the control logic. Conventional I / O device 1415 is coupled to chipset 1390.

[0207] Now for reference Figure 15 The diagram shows a block diagram of a SoC 1500 according to an embodiment of the present invention. Figure 11 Similar components in the model have similar reference figures. Furthermore, the dashed box is an optional feature on more advanced SoCs. Figure 15In this embodiment, one or more interconnect units 1502 are coupled to: an application processor 1510, which includes a set of one or more cores 1102A-N and one or more shared cache units 1106, the cores 1102A-N including cache units 1104A-N; a system proxy unit 1110; one or more bus controller units 1116; one or more integrated memory controller units 1114; a set of one or more coprocessors 1520, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 1530; a direct memory access (DMA) unit 1532; and a display unit 1540 for coupling to one or more external displays. In one embodiment, one or more coprocessors 1520 include dedicated processors, such as, for example, network or communication processors, compression engines, GPGPUs, high-throughput MIC processors, embedded processors, etc.

[0208] 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 executable on a programmable system including at least one processor, a storage system (including volatile and non-volatile memories and / or storage elements), at least one input device, and at least one output device.

[0209] Program code (such as) Figure 13 The code 1330 in the diagram is applied to input instructions to implement the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0210] The program code can be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. If needed, it can also be implemented in assembly or machine language. In fact, the mechanisms described herein are not limited to any particular programming language. In any case, the language can be compiled or interpreted.

[0211] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium, which represents various logic within a processor that, when read by a machine, causes the machine to create logic to implement the techniques described herein. Such a representation (referred to as an "IP core") can be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into the machine that actually manufactures the logic or processor.

[0212] Such machine-readable storage media can include, without limitation, non-transient tangible devices that are articles made or formed by machines or equipment, including storage media such as hard disks, any other type of disk (including floppy disks, optical disks, CD-ROMs, CD-RWs, and magneto-optical disks), semiconductor devices such as read-only memory (ROMs), random access memory (RAMs) (such as dynamic random access memory (DRAMs), static random access memory (SRAMs), erasable programmable read-only memory (EPROMs), flash memory, electrically erasable programmable read-only memory (EEPROMs), phase-change memory (PCMs), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

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

[0214] Simulation (including binary translation, code morphing, etc.).

[0215] In some cases, an instruction translator can be used to translate instructions from a source instruction set into a target instruction set. For example, the instruction translator can translate, fuse, emulate, or otherwise translate instructions into one or more other instructions to be processed by the core (e.g., using static binary translation, including dynamic binary translation with dynamic compilation). Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. The instruction translator can be on the processor, off the processor, or partially on and partially off the processor.

[0216] Figure 16 This is a block diagram illustrating the use of a software instruction converter according to an embodiment of the present invention for converting binary instructions in a source instruction set into binary instructions in a target instruction set. While the instruction converter may alternatively be implemented in software, firmware, hardware, or various combinations thereof, in the illustrated embodiment, the instruction converter is a software instruction converter. Figure 16The diagram illustrates how an x86 compiler 1604 can be used to compile a program of a high-level language 1602 to generate x86 binary code 1606 that is natively executable by a processor having at least one x86 instruction set core 1616. A processor having at least one x86 instruction set core 1616 refers to any processor that can implement substantially the same functionality as an Intel processor having at least one x86 instruction set core by compatiblely executing or otherwise processing: (1) a substantial portion of the instruction set of the Intel x86 instruction set core or (2) an object code version of an application or other software aimed at running on an Intel processor having at least one x86 instruction set core, in order to substantially achieve the same results as an Intel processor having at least one x86 instruction set core. The x86 compiler 1604 represents a compiler operable to generate x86 binary code 1606 (e.g., object code) that can be executed on a processor having at least one x86 instruction set core 1616, with or without additional linkage processing. Similarly, Figure 16 A program of high-level language 1602 can be compiled using an alternative instruction set compiler 1608 to generate alternative instruction set binary code 1610 that can be natively executed by a processor that does not have at least one x86 instruction set core 1614 (e.g., a processor with a core that executes the MIPS instruction set of Sunnyvale's MIPS technology and / or the ARM instruction set of Sunnyvale's ARM Holdings). The instruction converter 1612 is used to translate the x86 binary code 1606 into code that can be natively executed by a processor that does not have an x86 instruction set core 1614. This translated code cannot be identical to the alternative instruction set binary code 1610 because an instruction converter capable of doing so would be difficult to manufacture; however, the translated code will perform general operations and consist of instructions from the alternative instruction set. Therefore, the instruction converter 1612 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code 1606 through emulation, simulation, or any other process.

[0217] Future examples

[0218] Example 1 provides a system for executing instructions, the system comprising: a memory; a processor including: fetch circuitry for fetching instructions from the memory, the instructions including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register including a plurality of single-precision floating-point data elements; decoding circuitry for decoding the fetched instructions; and execution circuitry for executing the decoded instructions to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point values ​​in a second location identified by the second destination identifier.

[0219] Example 2 includes the substance of the system in Example 1, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is used to store a first half of a double-precision floating-point value into a first location identified by the first destination identifier, and to store a second half of the double-precision floating-point value into a source vector register.

[0220] Example 3 includes the essence of the system in Example 1, wherein the first location includes a first destination vector register of the register file, and the second location includes a second destination vector register of the register file.

[0221] Example 4 includes the essence of the system in Example 3, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0222] Example 5 includes the essence of a system of any of Examples 1-4, wherein the execution circuitry is further configured to add each vector element of the first half of the double-precision floating-point value to the data previously stored in the first location and store the first sum in the first location, and add each vector element of the second half of the double-precision floating-point value to the data previously stored in the second location and store the second sum in the second location.

[0223] Example 6 includes the essence of a system of any of Examples 1-4, wherein the location identified by the first destination identifier and the second destination identifier is located in memory.

[0224] Example 7 includes the essence of the system of Example 6, wherein the execution circuitry is further configured to: perform a first atomic read-modify-write to read first data stored in a first location, add a first half of a double-precision floating-point value to the first data, and store a double-precision floating-point sum in the first location; and perform a second atomic read-modify-write to read second data stored in a second location, add a second half of a double-precision floating-point value to the second data, and store a double-precision floating-point sum in the second location.

[0225] Example 8 includes the essence of a system from any of Examples 1-4, where the execution circuitry is used to transform all elements of the source vector register in parallel.

[0226] Example 9 includes the essence of the system in Example 1, where the opcode is used to specify that only the lower half of the source vector register should be converted and stored in the first location.

[0227] Example 10 includes the essence of the system in Example 1, where the opcode is used to specify that only the upper half of the source vector register should be converted and stored in the first location.

[0228] Example 11 provides a method for executing an instruction, the method comprising: fetching an instruction from memory, the instruction including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register comprising a plurality of single-precision floating-point data elements; decoding the fetched instruction by a decoding circuit; and executing the decoded instruction by an execution circuit such that: the elements of the source vector register are converted into double-precision floating-point values, a first half of the double-precision floating-point values ​​are stored in a first location identified by the first destination identifier, and a second half of the double-precision values ​​are stored in a second location identified by the second destination identifier.

[0229] Example 12 includes the essence of the method of Example 11, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is used to store a first half of a double-precision floating-point value into a first location and to store a second half of a double-precision floating-point value into a source vector register.

[0230] Example 13 includes the essence of the method of Example 11, wherein the first position includes a first destination vector register of the register file, and the second position includes a second destination vector register of the register file.

[0231] Example 14 includes the essence of the method of Example 13, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0232] Example 15 includes the essence of the method of Example 11, further including: adding each of the first half of the double-precision floating-point value to the data previously stored in the first location by the execution circuit, and adding each of the second half of the double-precision floating-point value to the data previously stored in the second location.

[0233] Example 16 includes the essence of the method of Example 11, wherein the location identified by the first destination identifier and the second destination identifier is located in memory.

[0234] Example 17 includes the essence of the method of any of Examples 11-16, further including accumulating the results in the first and second positions by: performing a first atomic read-modify-write to read the first data stored in the first position, adding a first half of the double-precision floating-point value to the first data, and storing the double-precision floating-point result in the first position; and performing a second atomic read-modify-write to read the second data stored in the second position, adding a second half of the double-precision floating-point value to the second data, and storing the double-precision floating-point result in the second position.

[0235] Example 18 provides an apparatus for executing instructions, the apparatus comprising: means for fetching instructions, the means for fetching instructions from memory, the instructions including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register including a plurality of single-precision floating-point data elements; means for decoding the fetched instructions; and means for executing the decoded instructions to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point values ​​in a second location identified by the second destination identifier.

[0236] Example 19 includes the nature of the device in Example 18, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is configured to store a first half of a double-precision floating-point value into a first location and a second half of a double-precision floating-point value into a source vector register.

[0237] Example 20 includes the nature of the device in Example 18, wherein the first location includes a first destination vector register of the register file, and the second location includes a second destination vector register of the register file.

[0238] Example 21 provides a processor for executing instructions, the processor including: fetching circuitry for fetching instructions from memory, the instructions including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register including a plurality of single-precision floating-point data elements; decoding circuitry for decoding the fetched instructions; and execution circuitry for executing the decoded instructions to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point values ​​in a second location identified by the second destination identifier.

[0239] Example 22 includes the essence of the processor of Example 21, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is configured to store a first half of a double-precision floating-point value into a first location and a second half of a double-precision floating-point value into a source vector register.

[0240] Example 23 includes the essence of the processor of Example 21, wherein the first location includes a first destination vector register of the register file, and the second location includes a second destination vector register of the register file.

[0241] Example 24 includes the essence of the processor in Example 23, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0242] Example 25 includes the essence of a processor of any of Examples 21-24, wherein the execution circuitry is further configured to add each of the first half of a double-precision floating-point value to data previously stored in a first location, and to add each of the second half of a double-precision floating-point value to data previously stored in a second location.

[0243] Example 26 includes the essence of a processor of any of Examples 21-22, wherein the location identified by the first destination identifier and the second destination identifier is located in memory.

[0244] Example 27 includes the essence of the processor of Example 26, wherein the execution circuitry is further configured to: perform atomic read-modify-write to read first data stored in a first location, add a first half of a double-precision floating-point value to the first data, and store a double-precision floating-point sum in the first location; and perform atomic read-modify-write to read second data stored in a second location, add a second half of a double-precision floating-point value to the second data, and store a double-precision floating-point sum in the second location.

[0245] Example 28 includes the essence of a processor from any of Examples 21-24, wherein the execution circuitry is used to convert all elements of the source vector register in parallel.

[0246] Example 29 includes the essence of the processor in Example 21, where the opcode is used to specify that only the lower half of the source vector register should be converted and stored in the first location.

[0247] Example 30 includes the essence of the processor in Example 21, where the opcode is used to specify that only the upper half of the source vector register should be converted and stored in the first location.

[0248] Example 31 provides an apparatus for executing instructions, the apparatus comprising: means for fetching instructions, the means for fetching instructions from memory, the instructions including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register including a plurality of single-precision floating-point data elements; means for decoding the fetched instructions; and means for executing the decoded instructions to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point values ​​in a second location identified by the second destination identifier.

[0249] Example 32 includes the nature of the device in Example 31, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is configured to store a first half of a double-precision floating-point value into a first location and a second half of a double-precision floating-point value into a source vector register.

[0250] Example 33 includes the nature of the device in Example 32, wherein the first location includes a first destination vector register of the register file, and the second location includes a second destination vector register of the register file.

[0251] Example 34 includes the nature of the device in Example 33, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0252] Example 35 includes the essence of a device from any of Examples 31-34, wherein the execution circuitry is further configured to add each of the first half of a double-precision floating-point value to data previously stored in a first location, and to add each of the second half of a double-precision floating-point value to data previously stored in a second location.

[0253] Example 36 includes the essence of a device of any of Examples 31-32, wherein the location identified by the first destination identifier and the second destination identifier is located in memory.

[0254] Example 37 includes the essence of the device of any of Examples 31-32, wherein the execution circuitry is further configured to: perform an atomic read-modify-write to read first data stored in a first location, add a first half of a double-precision floating-point value to the first data, and store a double-precision floating-point sum in the first location; and perform an atomic read-modify-write to read second data stored in a second location, add a second half of a double-precision floating-point value to the second data, and store a double-precision floating-point sum in the second location.

[0255] Example 38 includes the essence of a device from any of Examples 31-32, wherein the execution circuitry is used to convert all elements of the source vector register in parallel.

[0256] Example 39 includes the nature of the device of any of Examples 31-32, where the opcode is used to specify that only the lower half of the source vector register is to be converted and stored in the first location.

[0257] Example 40 includes the nature of the device of any of Examples 31-32, where the opcode is used to specify that only the upper half of the source vector register is to be converted and stored in the first location.

[0258] Example 41 provides a non-transient computer-readable medium containing instructions that, when executed by a processor, cause the processor to perform an execution instruction, the method comprising: fetching instructions from memory, the instructions including an opcode, a first destination identifier, an optional second destination identifier, and a source identifier for specifying a source vector register comprising a plurality of single-precision floating-point data elements; decoding the fetched instructions by decoding circuitry; and executing the decoded instructions by execution circuitry to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision values ​​in a second location identified by the second destination identifier.

[0259] Example 42 includes the nature of the non-transient computer-readable medium of Example 41, wherein the instruction does not include an optional second destination identifier, and wherein the execution circuitry is configured to store a first half of a double-precision floating-point value into a first location and a second half of a double-precision floating-point value into a source vector register.

[0260] Example 43 includes the nature of the non-transient computer-readable medium of Example 41, wherein the first location includes a first destination vector register of the register file, and the second location includes a second destination vector register of the register file.

[0261] Example 44 includes the nature of the non-transient computer-readable medium of Example 43, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0262] Example 45 includes the nature of a non-transient computer-readable medium of any of Examples 41-44, further comprising: adding each of the first halves of a double-precision floating-point value to data previously stored in a first location by an execution circuit, and adding each of the second halves of a double-precision floating-point value to data previously stored in a second location.

[0263] Example 46 includes the nature of a non-transient computer-readable medium of any of Examples 41-42, wherein the location identified by the first destination identifier and the second destination identifier is located in memory.

[0264] Example 47 includes the nature of a non-transient computer-readable medium of any of Examples 41-44, further comprising accumulating a result in a location identified by a first destination identifier and a second destination identifier by: performing an atomic read-modify-write to read first data stored in a first location, adding a first plurality of double-precision floating-point values ​​to the first data, and storing the double-precision floating-point result in the first location; and performing an atomic read-modify-write to read second data stored in a second location, adding a second plurality of double-precision floating-point values ​​to the second data, and storing the double-precision floating-point result in the second location.

[0265] This application provides the following technical solution:

[0266] 1. A system for executing instructions, the system comprising:

[0267] Memory;

[0268] Processor, comprising:

[0269] A fetching circuit for retrieving instructions from a code storage device, the instructions including an opcode, a first destination identifier, and a source identifier for specifying a source vector register, the source vector register including multiple single-precision floating-point data elements;

[0270] Decoding circuitry used to decode the extracted instructions; and

[0271] An execution circuit is configured to execute decoded instructions to: convert an element of the source vector register into a double-precision floating-point value, store a first half of the double-precision floating-point value in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point value in a second location.

[0272] 2. The system as described in technical solution 1, wherein the instruction further includes a second destination identifier, and wherein the second location is identified by the second destination identifier.

[0273] 3. The system as described in technical solution 1, wherein the second location is the source vector register.

[0274] 4. The system as described in technical solution 3, wherein the source vector register, the first destination vector register, and the second destination vector register are 512-bit vector registers.

[0275] 5. The system of claim 1, wherein the execution circuitry is further configured to add each vector element of the first half of the double-precision floating-point value to the data previously stored in the first location and store a first sum in the first location, and add each vector element of the second half of the double-precision floating-point value to the data previously stored in the second location and store a second sum in the second location.

[0276] 6. The system as described in technical solution 1, wherein the location identified by the first destination identifier and the second destination identifier is located in the memory.

[0277] 7. The system as described in technical solution 6, wherein the execution circuit is further configured to:

[0278] Perform a first atomic read-modify-write to read the first data stored in the first location, add the first half of the double-precision floating-point value to the first data, and store the double-precision floating-point sum in the first location; and

[0279] Perform a second atomic read-modify-write to read the second data stored in the second location, add the second half of the double-precision floating-point value to the second data, and store the double-precision floating-point sum in the second location.

[0280] 8. The system as described in technical solution 1, wherein the execution circuitry is used to convert all elements of the source vector register in parallel.

[0281] 9. The system as described in technical solution 1, wherein the opcode is used to specify that only the lower half of the source vector register is to be converted and stored in the first location.

[0282] 10. The system of claim 1, wherein the opcode is used to specify that only the upper half of the source vector register is to be converted and stored in the first location.

[0283] 11. A method for executing instructions, the method comprising:

[0284] The instructions are retrieved from the code storage device, the instructions including an opcode, a first destination identifier, and a source identifier for specifying a source vector register comprising multiple single-precision floating-point data elements;

[0285] The extracted instructions are decoded by the decoding circuit; and

[0286] The decoded instructions are executed by the execution circuit to: convert the elements of the source vector register into double-precision floating-point values, store a first half of the double-precision floating-point values ​​in a first location identified by the first destination identifier, and store a second half of the double-precision values ​​in a second location.

[0287] 12. The method of claim 11, wherein the instruction further includes a second destination identifier, and wherein the second location is identified by the second destination identifier.

[0288] 13. The method as described in technical solution 11, wherein the second position is the source vector register.

[0289] 14. The method of claim 13, wherein the source vector register, the first destination vector register and the second destination vector register are 512-bit vector registers.

[0290] 15. The method of claim 11 further includes adding each of the first half of the double-precision floating-point value to data previously stored in the first location by the execution circuit, and adding each of the second half of the double-precision floating-point value to data previously stored in the second location.

[0291] 16. The method of claim 11, wherein the location identified by the first destination identifier and the second destination identifier is located in the memory.

[0292] 17. The method of claim 16 further includes accumulating the results at the first position and the second position by means of:

[0293] Perform a first atomic read-modify-write operation to read the first data stored in the first location, add the first half of the double-precision floating-point value to the first data, and store the double-precision floating-point result in the first location; and

[0294] Perform a second atomic read-modify-write to read the second data stored in the second location, add the second half of the double-precision floating-point value to the second data, and store the double-precision floating-point result in the second location.

[0295] 18. An apparatus for executing instructions, the apparatus comprising:

[0296] A means for retrieving instructions, the means for retrieving instructions from a code storage device, the instructions including an opcode, a first destination identifier, and a source identifier for specifying a source vector register, the source vector register including a plurality of single-precision floating-point data elements;

[0297] A device for decoding, used to decode the extracted instructions; and

[0298] A means for executing decoded instructions, configured to: convert an element of the source vector register into a double-precision floating-point value, store a first half of the double-precision floating-point value in a first location identified by the first destination identifier, and store a second half of the double-precision floating-point value in a second location.

[0299] 19. The device of claim 18, wherein the instructions further include a second destination identifier, and wherein the second location is identified by the second destination identifier.

[0300] 20. The device as described in technical solution 18, wherein the second location is the source vector register.

Claims

1. A system for executing an instruction, the system comprising: a memory; and a processor comprising: an extraction circuit to extract an instruction, the instruction having fields to specify an opcode and locations of a first destination vector, a second destination vector, and a source vector; a decode circuit to decode the instruction; and an execution circuit to execute the instruction according to the opcode; wherein the opcode instructs the execution circuit to convert elements of the source vector to double-precision floating point values, and for each converted element, to accumulate the element with a previous value of a corresponding destination element by reading, modifying, and writing the destination element at an atomic level; and wherein first and second halves of a converted element correspond to the first and second destination vectors, respectively.

2. The system of claim 1, wherein the source vector, the first destination vector, and the second destination vector each comprise 512 bits.

3. The system of claim 1, wherein the first and second destination vectors and the source vector each comprise 256 bits.

4. The system of claim 1, wherein the first and second destinations are located in the memory, and the execution circuit, in executing the instruction according to the opcode, is to: perform a first atomic read-modify-write by reading first data from the first destination, adding a first half of a double-precision floating point value to the first data, and storing a resulting double-precision floating sum to the first destination; and perform a second atomic read-modify-write by reading second data from the second destination, adding a second half of a double-precision floating point value to the second data, and storing a resulting double-precision floating sum to the second destination.

5. The system of claim 1, wherein the execution circuit is to convert all elements of the source vector in parallel.

6. The system of claim 1, wherein the opcode is to specify that only a lower half of the source vector is to be converted and stored to the first destination vector.

7. The system of claim 1, wherein the opcode is to specify that only an upper half of the source vector is to be converted and stored to the first destination vector.

8. The system of claim 1, wherein the instruction is further to specify one of a plurality of different data formats for the source vector elements, the plurality of different data formats comprising byte (1 byte), word (2 bytes), doubleword (4 bytes), quadword (8 bytes), half-precision floating point (2 bytes), single-precision floating point (4 bytes), double-precision floating point (8 bytes), and quad-precision floating point (16 bytes).

9. The system of claim 1, wherein the instruction is further to specify a write mask, the write mask having bits corresponding to each of the first destination vector and the second destination vector, the bits to indicate whether the elements are to be written or masked.

10. The system of claim 9, wherein the instruction is further to specify whether masked elements of the first and second destination vectors are to be zeroed or merged.

11. A method for executing an instruction, the method comprising: extracting the instruction using extraction circuitry, the instruction having fields to specify an opcode and locations of a first destination vector, a second destination vector, and a source vector; decoding the instruction using decoding circuitry; and executing the instruction according to the opcode using execution circuitry; wherein the opcode instructs the execution circuitry to convert elements of the source vector to double-precision floating point values, and for each converted element, to accumulate the element with a previous value of a corresponding destination element by reading, modifying, and writing the destination element in memory at an atomic level; and wherein first and second halves of the converted elements correspond to the first and second destination vectors, respectively.

12. The method of claim 11, wherein the source vector, the first destination vector, and the second destination vector each comprise 512 bits.

13. The method of claim 11, wherein the source vector, the first destination vector, and the second destination vector each comprise 256 bits.

14. The method of claim 13, further comprising accumulating results at the first location and the second location by performing a first atomic read-modify-write by reading first data from the first destination, adding a first half of a double-precision floating point value to the first data, and storing the resulting double-precision floating sum to the first destination; and performing a second atomic read-modify-write by reading second data from the second destination, adding a second half of a double-precision floating point value to the second data, and storing the resulting double-precision floating sum to the second destination.

15. A machine-readable medium comprising code, which, when executed, causes a machine to perform the method of any one of claims 11-14.

16. An apparatus for executing an instruction, the apparatus comprising: means for extracting an instruction, the instruction having fields to specify an opcode and locations of a first destination vector, a second destination vector, and a source vector; means for decoding the instruction; and means for executing the instruction according to the opcode; wherein the opcode instructs the means for executing the instruction to convert elements of the source vector to double-precision floating point values, and for each converted element, to accumulate the element with a previous value of a corresponding destination element by reading, modifying, and writing the destination element in memory at an atomic level; and wherein first and second halves of the converted elements correspond to the first and second destination vectors, respectively.

17. A processor for executing an instruction, the processor comprising: extraction circuitry for extracting an instruction, the instruction having fields to specify an opcode and locations of a first destination vector, a second destination vector, and a source vector; decoding circuitry for decoding the instruction; and execution circuitry for executing the instruction according to the opcode; wherein the opcode instructs the execution circuitry to convert elements of the source vector to double-precision floating point values, and for each converted element, to accumulate the element with a previous value of a corresponding destination element by reading, modifying, and writing the destination element in memory at an atomic level; wherein the opcode indicates to the execution circuitry to convert elements of the source vector to double-precision floating point values, and for each converted element, to accumulate the element with a previous value of a corresponding destination element in memory by reading, modifying, and writing the destination element atomically; and wherein the first and second halves of the converted elements correspond to first and second destination vectors, respectively.

Images