Systems and methods for executing a fused multiply-add instruction for complex numbers

Abstract

Disclosed embodiments relate to executing a vector-complex fused multiply-add Instruction. In one example, a method includes fetching an instruction, a format of the instruction including an opcode, a first source operand identifier, a second source operand identifier, and a destination operand identifier, wherein each of the identifiers is to identify a location storing a packed data comprising at least one complex number, decoding the instruction, retrieving data associated with the first and second source operand identifiers, and executing the decoded instruction to, for each packed data element position of the identified first and second source operands, cross-multiply the real and imaginary components to generate four products: a product of real components, a product of imaginary components, and two mixed products, to generate a complex result by summing the four products according to the instruction, and to store a result to the corresponding position of the identified destination operand.

Description

[Technical Field]

[0001] The embodiments described herein generally relate to instruction set architecture. More specifically, the embodiments generally relate to systems and methods for performing fused multiplication-addition instructions on complex numbers. [Previous Technology]

[0002] In computation, especially in high-performance computation, instructions for performing complex multiplication and accumulation are common. Processor instruction set architectures often include instructions for performing complex arithmetic. Because these instructions are common, improvements in performance and power consumption, including reducing scratchpad file pressure, reducing memory pressure, and reducing the number of required instructions, can be beneficial to overall performance. [Summary of the Invention]

[0003] and

Implementation Method

[0037] In the following description, various specific details are described. However, it should be understood that embodiments of this invention can also be implemented without these specific details. In other instances, known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0038] In the specification, terms such as "an embodiment," "an embodiment," and "an exemplary embodiment" indicate that the described embodiment may include a specific characteristic, structure, or feature, but not every embodiment needs to include that specific characteristic, structure, or feature. Furthermore, these terms do not necessarily represent the same embodiment. Moreover, when a specific characteristic, structure, or feature is described in conjunction with an embodiment, it is considered to be within the understanding of those skilled in the art, and may influence the combination of this characteristic, structure, or feature with other embodiments, whether detailed or not.

[0039] Processor instruction set architectures often include instructions for performing complex arithmetic. Instructions for performing complex multiplication and accumulation are common, especially in high-performance computing (HPC). Some processor instruction set architectures (ISAs), such as AVX512 or earlier x86 SIMD ISAs, support instruction sequences for complex multiplication, but often require a large number of instructions. Using many instructions to perform common multiplication-product operations results in low efficiency and relatively high power consumption because the instruction sequence imposes register file pressure and memory pressure.

[0040] The embodiments disclosed herein disclose instructions that perform fused complex multiplication and addition using fewer machine resources and less temporary file and memory pressure. In one embodiment, the instructions perform the multiplication of two complex vectors and add the result to the destination vector. In another embodiment, an instruction takes the digital conjugate of one of the input vectors (the conjugate of a complex number is its imaginary part with a different sign).

[0041] In some embodiments of the disclosed fusion multiply-accumulate instruction, the instruction arguments can be temporary registers or memory. Complex numbers are stored as natural numbers in pairs (real part, imaginary part). The instruction allows for double, single, or half-precision implementations.

[0042] The advantages of the disclosed instructions over other instruction set architectures, such as AVX512 or earlier x86 SIMD ISAs, include higher performance and lower power consumption due to reduced register file pressure, reduced memory pressure and reduced number of instructions required for common arithmetic operations.

[0043] Figure 1 is a block diagram illustrating a processing element for executing an instruction to multiply two compressed or scalar complex numbers and sum the results according to one embodiment. Specifically, block diagram 100 includes an instruction memory 102, a fetch circuit 103, a decode circuit 104, an execution circuit 106, a register 108, a memory 110, and a deselect or confirm circuit 112. The instruction is fetched by the instruction memory 102 by the fetch circuit 103. The instruction memory 102 includes cache memory, on-chip memory, memory on the same die as the processor, an instruction register, a general-purpose register, or system memory, without limitation. The decode circuit 104 decodes the instruction. In one embodiment, the instruction includes the following columns, which are further discussed with reference to Figures 2A-2B. The decoded instruction is executed by the execution circuit 106. Execution circuitry 106 is configured to read data from register 108 and memory 110 or write data to register 108 and memory 110. Register 108 includes one or more of a data register, an instruction register, a general-purpose register, and on-chip memory. Memory 110 includes one or more of on-chip memory, memory on the same die as the processor, memory in the same package as the processor, cache memory, and system memory. Several exemplary embodiments of execution circuitry 106 are described and illustrated with reference to Figures 3 through 8. Defer or confirm circuitry 112 ensures that the execution result has been written to or has been written to its destination and releases or frees up resources for subsequent use.

[0044] Figure 2A illustrates a field included in an instruction for multiplying and summing two compressed or scalar complex numbers according to an embodiment. Specifically, instruction 200 includes an operand code 202, a first source operand identifier 204, a second source operand identifier 206, and a destination operand identifier 208. The operand code 202 identifies the instruction and / or the operation performed, and the operand type (e.g., as shown in Figure 10D, the instruction is used to multiply and sum first source operands stored in a register file). The first source operand identifier 204 contains the first source operand (compressed complex number or compressed vector data) or identifies the register or memory location where the first source operand is retrieved. In some embodiments, the first source operand comprises a plurality of vector data elements, each containing a pair of numbers: the real part and the imaginary part of the complex number. Each element in the first source operand has a corresponding element in the second source operand, specified by the second source operand identifier 206, and a corresponding element in the destination operand, specified by the destination operand identifier 208. Because the second and destination operands correspond to the first source operands, their minimum size depends on the size of the first source operand. For example, if the first source operand contains 8 elements, the destination operand will contain at least 8 elements, and the second source operand will contain at least 8 elements, each containing a pair of numbers representing the real and imaginary parts of a complex number. In another example, if the first source operand contains 64 elements, the destination operand will contain at least 64 elements, and the second source operand will contain at least 64 elements, each containing a pair of numbers representing the real and imaginary parts of a complex number.

[0045] The first and second source and destination operands identified by 204, 206, and 208 are stored in the registers or memory of the register group. The register group is part of a register file and may have other registers, such as status registers, flag registers, dedicated mask registers, vector registers, etc. An embodiment of a register file is shown in FIG10D. These registers can be viewed from outside the processor or by the programmer. In one embodiment, an instruction specifies the operands to be stored in the register. Various types of registers are applicable, as long as they can store and provide the data described herein. Alternatively, one or more source and destination operands are stored in a storage location outside the register, for example, a location in system memory.

[0046] Figure 2B illustrates a field included in an instruction used to multiply two compressed or scalar complex numbers using a write mask and sum the results according to an embodiment. Specifically, instruction 250 includes an operand code 252, a first source operand identifier 254, a second source operand identifier 256, a destination operand identifier 258, and a write mask 260. The operand code 252 identifies the instruction and / or operation to be executed, and the operand type (e.g., the instruction is used to multiply and sum first source operands stored in a register file, as shown in Figure 10D). The first source operand identifier 254 includes the first source operand (compressed complex number, or compressed vector data) or identifies a register or retrieves the memory location of the first source operand from there. In some embodiments, the first source operand includes a plurality of vector data elements, each containing a pair of numbers: the real part and the imaginary part of the complex number. Each element in the first source operand has a corresponding element specified by the second source operand identifier 256 in the second source operand, and a corresponding element specified by the destination operand identifier 258 in the destination operand. Because the second and destination operands correspond to the first source operands, their minimum size depends on the size of the first source operand. For example, if the first source operand contains 8 elements, the destination operand will contain at least 8 elements, and the second source operand will contain at least 8 elements, each containing a pair of numbers representing the real and imaginary parts of the complex number. In another example, if the first source operand contains 64 elements, the destination operand will contain at least 64 elements, and the second source operand will contain at least 64 elements, each containing a pair of numbers representing the real and imaginary parts of the complex number.

[0047] The first and second source and destination operands identified for fields 254, 256, and 258 are stored in registers or memory within a register set. This embodiment includes a write mask 260, which is used to control the vector element of the destination operand to be written. In some embodiments, a 0 bit in the write mask causes the corresponding destination element to retain its value prior to the instruction. In other embodiments, a 0 bit causes the corresponding vector element of the destination to be set to 0. As used herein, the destination element at the Nth position in the destination vector corresponds to a bit at the Nth position in the write mask. The register set is part of a register file and may include other registers, such as status registers, flag registers, dedicated mask registers, vector registers, etc. An embodiment of a register file is shown in FIG10D. Registers can be seen from outside the processor or from the programmer's perspective. In one embodiment, an instruction specifies an operand stored in a register. Various types of temporary registers are applicable, as long as they can store and provide the data described herein. Alternatively, one or more source and destination operands may be stored in a storage location other than a temporary register, such as a location in system memory.

[0048] Figure 3 illustrates an execution circuit 300 for implementing a Vector-Complex Fusion Multiply-Add (VCFMADD) instruction to multiply two compressed complex numbers and accumulate the results, according to one embodiment. The execution circuit 300 is an embodiment of the execution circuit 106 (Figure 1). As shown, the first source operand 302 and the second source operand 304 are 512-bit vector registers, each compressed into eight 64-bit complex numbers, each containing a 32-bit real portion and a 32-bit imaginary portion. In other embodiments, the first and second source operands have different sizes, such as 32 bits, 128 bits, or 256 bits. In other embodiments, the first and second source operands are compressed into different numbers of elements, such as four, sixteen, or 32 elements. In some embodiments, the VCFMADD instruction includes a source operand identifier indicating a memory location. In some embodiments, when the source operand identifier identifies a memory location, the full vector is retrieved from memory and stored in a vector register for use by the execution circuit 300. In other embodiments, when the source operand identifier identifies a memory location, a single element is retrieved from memory and broadcast to the vector register as the full vector length for use by the execution circuit 300. In some embodiments, the source operand identifier identifies a register whose contents are broadcast to the vector register as the full vector length for use by the execution circuit 300.

[0049] The execution circuit 300 is an exemplary embodiment of the execution circuit 106 (FIG. 1). As shown, the execution circuit 300 includes multipliers 310, 312, 314, and 316, which, together with adders 318 and 320 and sign inverter 322, operate to generate the first element of the first source operand 302 (the first compressed vector element position of the complex element position) recognized by i0, and the first element of the second source operand 304 also recognized by i0, to produce the first element of the destination operand 306 also recognized by i0. More specifically, the corresponding element of the destination operand 306 is composed of two numbers set according to Equations 1 and 2 based on the VCFMADD calculation method.

[0050] Although Figure 3 only shows the execution circuit 300 for generating the elements i0 of the target operand 306, it should be understood that multipliers, adders, and subtractors are replicated in some embodiments to compute at least two elements of the target operand 306 in parallel. One embodiment replicates the multipliers, adders, and subtractors to the extent required to compute each element of the target operand in parallel. The number of target operand elements computed and generated in parallel can be varied, for example, two at a time, four at a time, or any number of elements at a time.

[0051] On the other hand, embodiments of the serial implementation of VCFMADD include circuitry for calculating one element of the target operand at a time. In the serial implementation, the elements of the target operand 306 are calculated and set in series, and one element of the target operand 306 is calculated and set at a time, which has the advantage of requiring less execution circuitry.

[0052] Some embodiments include parallel hardware circuitry to allow execution circuitry 300 to calculate and set elements in target operand 306 within one clock cycle. Other embodiments include parallel hardware circuitry to allow execution circuitry 300 to calculate and set elements in target operand 306 within several clock cycles. These embodiments illustrated in FIG3 are executed faster than the functionality of executing the VCFMADD instruction using scalar arithmetic.

[0053] Figure 4 illustrates an execution circuit 400 for implementing the Vector-Complex Fusion Conjugate Multiply-Add (VCFCMADD) instruction according to an embodiment, to multiply two compressed complex numbers and accumulate the results. The execution circuit 400 is an embodiment of the execution circuit 106 (Figure 1). As shown, the first source operand 402 and the second source operand 404 are 512-bit vector registers, each compressed into eight 64-bit complex numbers, each composed of a 32-bit real portion and a 32-bit imaginary portion. In other embodiments, the first and second source operands have different sizes, for example, 32 bits, 128 bits, or 256 bits. In other embodiments, the first and second source operands are compressed into different numbers of elements, for example, 4, 16, or 32 elements. In some embodiments, the VCFCMADD instruction includes a source operand identifier that identifies a memory location, wherein the vector operand is first retrieved from memory. In some embodiments, when the source operand identifier identifies a memory location, the full vector system is retrieved from memory and stored in a vector register for use by the execution circuit 400. In other embodiments, when the source operand identifier identifies a memory location, a single element is retrieved from memory and broadcast to the full vector length of the vector register for use by the execution circuit 400. In some embodiments, the source operand identifier identifies a register, the contents of which are broadcast to the full vector length of the vector register for use by the execution circuit 400.

[0054] The execution circuit 400 is an exemplary embodiment of the execution circuit 106 (FIG. 1). As shown, the execution circuit 400 includes multipliers 410, 412, 414, and 416, which, together with adders 418 and 420 and sign inverter 422, operate on the first element (the first position of compressed data containing real and imaginary components) identified by i0 for the first source operand 402 and the first element identified by l for the second source operand 404, to generate the corresponding first element identified by i0 for the destination operand 406. More specifically, the first element of the destination operand 406 consists of two numbers, which are set using Equations 3 and 4 according to VCFCMADD calculation.

[0055] Equations 3 and 4 for implementing the VCFCMADD instruction are similar to Equations 1 and 2 for implementing the VCFMADD instruction, but differ in the symbols used to calculate DST[l+0] and DST[l+1].

[0056] Although Figure 4 only shows the execution circuitry for generating the elements i0 of the target operand 406, it should be understood that multipliers, adders, and subtractors are replicated in some embodiments to compute at least two elements of the target operand 406 in parallel. One embodiment replicates the multipliers, adders, and subtractors to the extent required for parallel computation of each element of the target operand. The number of target operand elements computed and generated in parallel can be varied, for example, two at a time, four at a time, or any number of elements at a time.

[0057] On the other hand, one embodiment of the serial implementation of VCFCMADD includes circuitry for calculating one element of the target operand at a time. In the serial embodiment, the element of the target operand 406 is calculated and set serially by calculating and setting one element of the target operand 406 at a time, which has the advantage of requiring less execution circuitry.

[0058] Some embodiments include parallel hardware circuitry to allow execution circuitry 400 to calculate and set elements of the target operand 406 within one clock cycle. Other embodiments include parallel hardware circuitry to allow execution circuitry to calculate and set elements of the target operand 406 within several clock cycles. The embodiment shown in FIG4 can execute faster than the functionality of using scalar arithmetic to execute the VCFMADD instruction.

[0059] Figure 5A illustrates a method embodiment of a processor (e.g., core, CPU, GPU, APU, etc.) to execute instructions to multiply two complex source operands and accumulate the result. In some embodiments, the source operands are scalar values. Instructions are fetched at 502, decoded at 504, data related to the identifiers of the first and second source operands are retrieved at 506, and the decoded instructions are executed at 508.

[0060] Figure 5A illustrates execution 508 according to the embodiment. At 510, for each compressed data element location of the identified first and second source operands, the real and imaginary components are cross-multiplied to produce four products: a product of the real components, a product of the imaginary components, and two mixed products. At 512, according to the instruction, the complex result is generated by summing the four products. At 514, the complex result is stored in the corresponding location of the identified target operand.

[0061] As used herein, generating a product of imaginary parts means multiplying the imaginary parts of at least two complex numbers, for example, compressed in the first and second source operands. As used herein, generating a product of real parts means multiplying the real parts of at least two complex numbers, for example, compressed in the first and second source operands. As used herein, generating a mixed product means multiplying the imaginary part of one complex number by the real part of another complex number.

[0062] In some embodiments, the first and second source operands can be scalar values ​​instead of vectors, and execution ends after 514. In some embodiments, the first and second source operands are compressed data vectors to be executed in parallel, wherein at 508, execution will occur in parallel at at least two element positions of the compressed vector. In some embodiments, the first and second source operands are compressed data vectors to be executed in sequence, wherein executions 508 to 514 will occur in sequence at at least two element positions of the compressed vector.

[0063] When executing the Vector Complex Multiply-Add (VCFMADD) instruction, 508 will generate the real part of the complex result by subtracting the product of the imaginary parts from the product of the real parts (see Equation 1 above), generate the imaginary part of the complex result by adding the two mixed products (see Equation 2 above), and write the complex result to the corresponding compressed data element location of the destination operand.

[0064] When executing the Vector-Complex Fusion Conjugate Multiply-Add (VCFCMADD) instruction, 508 is executed to generate the real part of the complex result by adding the product of the imaginary part and the product of the real part (see Equation 3 above), to generate the imaginary part of the complex result by subtracting the other of the two mixed products from one of the two mixed products (see Equation 4 above), and to store the complex result in the corresponding compressed data element location of the destination operand.

[0065] FIG. 5B illustrates a method embodiment of a processor (e.g., core, CPU, GPU, APU, etc.) for executing instructions to multiply two complex source operands and accumulate the result. In some embodiments, the source operands are scalar values. In other embodiments, the source operands include compressed data vectors and the method of FIG. 5B performs serial or parallel operations on the positions of the respective compressed data elements. FIG. 5B illustrates the vector and scalar implementation, and the parallel and serial implementation. Instructions are fetched at 5102, decoded at 5104, data regarding the first and second source operand identifiers of the decoded instructions are retrieved at 5106, and the decoded instructions are executed at 5108.

[0066] The instruction fetched at 5102 has a format having a first source operand identifier, a second source operand identifier, and a destination operand identifier. At 5104, an instruction is fetched and executed from an instruction memory, such as instruction memory 102 (FIG. 1), which includes cache memory, instruction registers, general-purpose registers, or system memory. Embodiments of the instruction fetching unit included within the processor core are discussed below with reference to FIG. 12A and 12B.

[0067] Decoding the instruction at 5104 includes decoding various fields of the instruction as shown in Figure 2, including the operand code 202, the first source operand identifier 204, the second source operand identifier 206, and the destination operand identifier 208. Decoding the instruction at 5104 also includes determining where to retrieve the operands and where to write the result.

[0068] Retrieving data regarding the first and second source operand identifiers at 5106 includes loading operands stored in registers within a register set or in memory. A register set is part of a register file and may include other registers, such as status registers, flag registers, dedicated mask registers, vector registers, etc. An embodiment of a register file is described below with reference to FIG11. In one embodiment, the registers may be visible external to the processor or from the programmer's perspective. For example, an instruction specifies an operand stored in a register. Various types of registers are applicable, as long as they can store and provide the data described herein. Alternatively, one or more source and destination operands may be stored in a storage location outside the register, for example, in a location in system memory.

[0069] The instruction executed at 5108 includes 5110 determining whether the first and second source operands are scalar values, or, if they are vectors containing complex data elements. When the first and second source operands are scalars and not vector data, the first and second source operands are identified as scalar values ​​and each contains a single complex number. If the source operands are scalar values, then at 5114, for example, according to Equations 1 and 2 of the VCFMADD instruction or Equations 3 and 4 of the VCFCMADD instruction, two parts of the complex result are produced. Before completion, the result is then written to the corresponding element identified by the destination operand identifier.

[0070] On the other hand, if it is determined at 5110 that the first and second source operands identify a vector containing data elements, then at 5112 it is determined whether the instruction should be executed serially or in parallel. In one embodiment, an additional character is included in the operation code 202, which specifies whether the execution should be serial or in parallel. In another embodiment, registers in the register group are configured to store control values ​​controlling whether VCFMADD and VCFMADD should be executed serially or in parallel on the vector elements.

[0071] If at 5112 it is determined that the execution circuit will use the elements for serial calculation and setting the target operand, then at 5116, the two parts of the complex number are calculated for each element of the vector, for example according to Equations 1 and 2 of the VCFMADD instruction, or according to Equations 3 and 4 of the VCFMADD instruction. At 5116, the result is written back to the identified position for the target operand.

[0072] At 5112, if it is determined that the execution circuitry is used to calculate and set the target operand elements in parallel, then at least two elements of the vector at 5118 are calculated, for example, according to Equations 1 and 2 of the VCFMADD instruction, or according to Equations 3 and 4 of the VCFMADD instruction. In some embodiments, the individual elements of the target operand are executed in parallel. The result is then written to the target. In some embodiments, all elements of the target operand are calculated and written in parallel.

[0073] Execution 5108 is further described with reference to the virtual code illustrated in Figures 6, 7 and 8.

[0074] In some embodiments, the execution circuitry performs execution method 5108 within a single clock cycle. In other embodiments, the execution circuitry performs execution method 5108 over several clock cycles. In both cases, the execution of the VCFMADD and MCFCMADD instructions according to the embodiments disclosed herein is faster than using a sequential scalar instruction to perform these functions.

[0075] Figure 5C illustrates a method embodiment of a processor (e.g., a core, CPU, GPU, APU, etc.) to execute an instruction to multiply two complex source operands and accumulate the result. The method illustrated in Figure 5B performs a function similar to that of execution circuit 508 (Figure 5A). At 550, the real and imaginary portions of the first and second source operands are stored in a register. The embodiment illustrated in Figure 5B is an example of a method executed by a processor that begins at a point after the first and second source operands have been retrieved from the register or memory and stored in the register, for example, after 506 (Figure 5A).

[0076] In 552, four products are generated by cross-multiplying the real and imaginary components of the first and second source operands, resulting in S1R*S2R, S1I*S2I, S1R*R2I, and S2R*S1I. In the compressed data embodiment, the multiplication in 552 is performed on one of the complex elements of the first and second source operands. In the compressed data embodiment where parallel processing is to be used, in 552-P1, 552-P2, ..., 552-PN, N additional complex elements of the first and second source operands are processed in parallel to generate four products, and the remainder of the method is performed on these additional elements. For simplicity, the remainder of the method beyond 551-P1 to 551-PN does not show these additional elements. In some embodiments, N is 1. In other embodiments, N is large enough that all remaining elements of the first and second source operands are processed in parallel.

[0077] At 554, it is determined whether the instruction is VCFMADD or VCFCMADD.

[0078] Figure 6 illustrates the virtual code for the operation of an execution circuit to implement a VCFMADD instruction according to an embodiment. As shown, the virtual code illustrates that the execution circuit 106 (Figure 1) is provided with a VLEN (vector length) variable, which is used to set the number of elements looping on it. If it is VCFMADD, then at 556, four products are accumulated to the real and imaginary parts of the complex number of the corresponding element of the target operand:

[0079] On the other hand, if the instruction is VCFCMADD, then at 558, the four products are accumulated to the real and imaginary parts of the complex number of the corresponding element of the destination operand; at 560, it is determined whether the instruction is a vector or scalar instruction. If it is a scalar, the method ends. If the instruction is a vector instruction that operates on a compressed data element, then at 562, it is determined whether the execution performed on the remaining elements of the first and second source operands is parallel or serial. If the execution is parallel, then at 564, the parallel calculations following 552-P1, 552-P2, and 552-PN are allowed to be completed, and then the method ends. If the execution is serial, then at 566, the method performs 552 to 558 serially on each of the remaining elements of the destination vector. Then, the method ends.

[0080] The operand code 202 of the VCFMADD instruction is used to establish this function. Regarding VLEN, in some embodiments, operand code 202 (FIG. 2) contains a number used to set VLEN, such as 8, 16, 32, or 64. In some embodiments, operand code 202 (FIG. 2) contains numbers or letters representing the size of a data element, such as Q, D, or W.

[0081] As shown in Figure 6, the VCFMADD function receives 512-bit first source operands SRC1 and SRC2 as inputs and uses them to store the result in the destination operand DST. The locations where the first and second source operands are retrieved and the locations where the destination operand is written can be in a register or in memory, such as the register 108 and memory 110 (Figure 1) indicated by the first source operand identifier 204, the second source operand identifier 206, and the destination operand identifier 208 (Figure 2). The execution circuit 106 (Figure 1) illustrated by the virtual code in Figure 6 loops through the 16 32-bit elements of SRC1 and SRC2 to calculate and store the 16 32-bit elements of DST. During each loop recursion, the operand determines whether DST is calculated using Equations 1 and 2 if VCFMADD is selected, or whether DST is calculated using Equations 3 and 4 if VCFMADD is selected.

[0082] The execution circuit 106 (Fig. 1) can process one element at a time in series, or can process multiple elements or all elements simultaneously in parallel.

[0083] Figure 7 is a virtual code used to illustrate the operation of the execution circuit to implement the VCFMADD instruction according to an embodiment. As shown, the virtual code illustrates that the execution circuit 106 (Figure 1) is provided with VLEN variables, which are used to set the number of elements looping on it, and mask bit variables indicating which elements in the target operand should be set.

[0084] The operand code 202 of the VCFMADD instruction is used to set this function. Regarding VLEN, in some embodiments, the operand code 202 of the VCFMADD instruction (FIG. 2) includes a number for setting VLEN, for example, 8, 16, or 32. In some embodiments, the operand code 202 of the VCFMADD instruction (FIG. 2) includes numbers or letters indicating the size of the data element, for example, "Q" for an 8-byte quad word, "D" for a 4-byte double word, "W" for a 2-byte word, and "B" for an 8-byte byte. Regarding the mask bit, in some embodiments, when the VCFMADD instruction is called, a value can be configured in the general register or mask register of the register file for use in the mask bit. In some embodiments, the operand code 202 of VCFMADD is a full operand code field 974, which, as discussed below with reference to FIG. 9A, includes a data element width field 964 and a write mask field 970.

[0085] As shown in FIG7, the VCFMADD function receives 512-bit first source operands SRC1 and second source operands SRC2 as inputs and uses them to store the results in the destination operand DST. The location retrieved by the first source operand and the second source operand and the location to be written to the destination operand can be in a temporary register or in memory, for example, in the temporary register 108 and memory 110 (FIG. 1) as indicated by the first source operand identifier 204, the second source operand identifier 206 and the destination operand identifier 208 (FIG. 2). The execution circuit 106 (FIG. 1) illustrated by the virtual code in FIG7 loops through the 16 32-bit elements of SRC1 and SRC2 to calculate and store the 16 32-bit elements of DST. During each loop recursion, the values ​​of the two components of DST are calculated using Equations 1 and 2 as described above. On the other hand, if there is a write mask, for each data element with the corresponding mask bit equal to zero (0), the process determines whether "merge mask" is true, and if it is true, the DST remains unchanged, and if it is not true, the DST element is reset to zero (0).

[0086] The execution circuit 106 (FIG. 1) can process one of the elements at a time in series, or it can process multiple elements or all elements simultaneously in parallel.

[0087] Figure 8 is a virtual code used to illustrate the operation of the execution circuit to implement the VCFCMADD instruction according to an embodiment. As shown, the virtual code illustrates that the execution circuit 106 (Figure 1) is set with a VLEN variable and a mask bit variable. The VLEN variable is used to set the number of loops on which the element is given, and the mask bit variable indicates which bits in the target operand should be set.

[0088] The operand code 202 of the VCFCMADD instruction is used to establish this function. Regarding VLEN, in some embodiments, the operand code 202 of the VCFCMADD instruction (FIG. 2) includes a number for setting VLEN, such as 8, 16, or 32. In some embodiments, the operand code 202 of the VCFCMADD instruction (FIG. 2) includes a number or letter representing the size of the data element, such as Q, D, or W. Regarding the mask bit, in some embodiments, the general register or mask register of the register file can be configured to be used for the mask bit value when the VCFCMADD instruction is called. In some embodiments, the operand code 202 of VCFCMADD is a full operand code field 974, including a data element width field 964 and a write mask field 970, and will be discussed below with reference to FIG. 9A.

[0089] As shown in Figure 8, the VCFCMADD function receives 512-bit first source operands SRC1 and SRC2 as inputs and uses them to store the results in the destination operand DST. The locations retrieved by the first and second source operands and the locations to be written to the destination operand can be in a register or memory, such as the register 108 and memory 11 (Figure 1) indicated by the first source operand identifier 204, the second source operand identifier 206, and the destination operand identifier 208 (Figure 2). The execution circuit 106 (Figure 1) illustrated by the virtual code in Figure 8 loops through the 16 32-bit elements of SRC1 and SRC2 to calculate and store the 16 32-bit elements of DST. During each loop iteration, the values ​​of the two components of DST are calculated using Equations 3 and 4 above. On the other hand, if there is a write mask for each data element with a corresponding mask bit equal to zero (0), the process determines whether "merge mask" is true, and if true, DST remains unchanged, and if not, DST is reset to zero (0). Instruction set

[0090] An instruction set may contain one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) to indicate the operation to be performed (e.g., operand code) and the operands and / or other data fields (e.g., masking), etc. Some instruction formats are further decomposed through the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined with instruction format fields that have different subsets (including fields that are typically in the same order but at least partially have different bit positions because they contain fewer fields) and / or defined as given fields that are interpreted differently. Thus, each instruction of the ISA is represented using a given instruction format (and, if defined, one of the instruction templates of that instruction format) and includes fields to indicate the operation and the operands. For example, the exemplified ADD instruction has a specific operand and instruction format, including an operand field to specify the operand and an operand field to select operands (source 1 / destination and source 2). The occurrence of this ADD instruction in the instruction stream will have specific content in the operand field where the specific operand is selected. A set of SIMD extensions called Advanced Vector Extensions (AVX) (AVX1 and AVX2) and designed using Vector Extensions (VEX) encoding have been released and / or made public (e.g., see the Intel® 64 and IA-32 Architecture Software Developer's Manual, September 2014, and the Intel® Advanced Vector Extensions Planning Reference Manual, October 1, 2014). Example instruction format.

[0091] Embodiments of the instructions described herein can be implemented in different formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instructions can be executed on such systems, architectures, and pipelines, but are not limited to those detailed herein. This pertains to a vector-friendly instruction format.

[0092] The vector-friendly instruction format is an instruction format applicable to vector instructions (e.g., certain fields are specific to vector operations). Although both vector and scalar operations are supported through the vector-friendly instruction format in the described embodiment, other embodiments only use the vector-friendly instruction format to support vector operations.

[0093] Figures 9A-9B are block diagrams illustrating the same-type vector friendly instruction format and its instruction template according to an embodiment of the present invention. Figure 9A is a block diagram illustrating the same-type vector friendly instruction format and its type A instruction template according to an embodiment of the present invention; while Figure 9B is a block diagram illustrating the same-type vector friendly instruction format and its type B instruction template according to an embodiment of the present invention. Specifically, the same-type vector friendly instruction format 900 defines type A and type B instruction templates, both of which include the no-memory access 905 instruction template and the memory access 920 instruction template. The term "same-type" in the vector friendly instruction format text indicates that the instruction format is not bound to any specific instruction set.

[0094] Although embodiments of the present invention will be described as supporting vector-friendly instruction formats as follows: 64-bit vector operand length (or size) has a 32-bit (4-bit) or 64-bit (8-bit) data element width (or size) (and, therefore, a 64-bit vector consists of 16 double-word-size elements or 8 quad-word-size elements); 64-bit vector operand length (or size) has a 16-bit (2-bit) or 8-bit (1-bit) data element width (or size); 32-bit vector operand length (or size) has a 32-bit (4-bit) data element width (or size). 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element widths (or sizes); and 16-bit vector operand lengths (or sizes) having 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element widths (or sizes), but other embodiments may also support more or fewer and / or different vector operand sizes (e.g., 256-bit vector operands) having more, fewer, or different data element widths (e.g., 128-bit (16-byte) data element widths).

[0095] The Type A instruction template in Figure 9A includes: 1) In the No Memory Access 905 instruction template, the following are displayed: No Memory Access Full Rounding Control Type Operation 910 instruction template; and No Memory Access Data Conversion Type Operation 915 instruction template; and 2) In the Memory Access 920 instruction template, the following are displayed: Memory Access, Timing 925 instruction template; and Memory Access, Non-Timing 930 instruction template. The Type B instruction template in Figure 9B includes: 1) In the No Memory Access 905 instruction template, the following are displayed: No Memory Access, Write Mask Control, Partial Rounding Control Type Operation 912 instruction template; and No Memory Access, Write Mask Control, vsize Type Operation 917 instruction template; and 2) In the Memory Access 920 instruction template, the following are displayed: Memory Access, Write Mask Control 927 instruction template.

[0096] The same vector friendly instruction format 900 includes the following fields listed in the order shown in Figures 9A-9B:

[0097] Format field 940 - A specific value (instruction format identifier value) in this field specifically identifies the vector-friendly instruction format, and therefore, the occurrence of instructions in the vector-friendly instruction format within the instruction stream. Therefore, this field is selected only when it is not needed by an instruction set belonging to the same vector-friendly instruction format.

[0098] Basic Operations Field 942 - Its content distinguishes different basic operations.

[0099] Scratchpad index field 944 - Its contents, generated directly or via address, indicate the locations of source and destination operands, whether in a scratchpad or in memory. These contain a sufficient number of bits to select N scratchpads from a PxQ (e.g., 32×512, 16×128, 32×1024, 64×1024) scratchpad file. While in one embodiment N can be up to three source and one destination scratchpads, other embodiments may support more or fewer source and destination scratchpads (e.g., up to two sources, one of which can also be a destination; up to three sources, one of which can also be a destination; up to two sources and one destination).

[0100] Modifier field 946 - Its content distinguishes the occurrence of instructions in the same vector instruction format, indicating whether a memory access has occurred or not; that is, between the no memory access 905 instruction template and the memory access 920 instruction template. Memory access operations read and / or write to the memory level (in some cases, using values ​​in registers, indicating source and / or destination addresses), while non-memory access operations do not (e.g., source and destination are registers). Although in one embodiment this field also selects from three modes for performing memory address calculations, in other embodiments, more, fewer, or different modes may be supported for performing memory address calculations.

[0101] Amplified Operation Field 950 – Its content distinguishes which of the various operations will be executed, in addition to basic operations. This field is context-specific. In one embodiment of the invention, this field is divided into a type field 968, an alpha field 952, and a beta field 954. The amplified operation field 950 allows operations of a common group to be executed in a single instruction, rather than in 2, 3, or 4 instructions.

[0102] Scale field 960 - Its contents allow for scaling of the contents of the index field used to generate memory addresses (e.g., for generating addresses using 2 scale * index + base).

[0103] Displacement field 962A - Its contents are used as part of the memory address generation (e.g., for address generation using 2 scale * index + base + displacement).

[0104] The displacement factor field 962B (note that the juxtaposition of displacement field 962A directly above displacement factor field 962B indicates that one or the other is used) – its contents are used as part of address generation; it specifies the displacement factor that will be scaled for the size (N) of the memory access – where N is the number of bytes in the memory access (e.g., for address generation, it uses 2-scale * index + base + scaled displacement). Redundant inefficient bits are ignored, therefore, the contents of the displacement factor field are multiplied by the total size (N) of the memory operands to produce the final displacement used to calculate the effective address. The value of N is determined by the processor hardware at runtime based on the full operand field 974 (as described below) and the data fetch field 954C. It is selected when the instruction templates for displacement field 962A and displacement factor field 962B are not used as the no-memory-access 905 instruction template and / or different embodiments may also implement one or neither.

[0105] Data Element Width Field 964 - Its content distinguishes which of several data element widths will be used (in some embodiments, for all instructions; in other embodiments, only for some instructions). This field is optional and is not required if only one data element width is supported and / or a partial type of operation code supports the data element width.

[0106] Write Mask Field 970 - Its content controls, on a per-data-element basis, whether the data element positions in the target vector operands reflect the results of the basic and augmented operations. Type A instruction templates support merge write masks, while Type B instruction templates support both merge and zero-out write masks. When merged, the vector mask allows any group of elements in the target to be protected from being updated during the execution of any operation (as specified by the basic and augmented operations); in another embodiment, where the old values ​​of the individual elements in the target are preserved when the corresponding mask bit in the target has a 0. Conversely, when the vector mask is zeroed out, it allows any group of elements in the target to be zeroed during the execution of any operation (as specified by the basic and augmented operations); in one embodiment, when the corresponding mask bit has a 0 value, the elements in the target are set to 0. A subgroup of this functionality is the ability to control the vector length of the operations performed (i.e., the interval from the first to the last element is modified), however, these modified elements do not need to be consecutive. Therefore, write mask field 970 allows for some vector operations, including loading, storing, arithmetic, logic, etc. Although embodiments of the invention are described in which the content of write mask field 970 is selected to include one of several write mask registers for the write mask to be used (and, therefore, the content of write mask field 970 indirectly indicates the mask to be performed), other embodiments may instead or additionally allow the content of mask write field 970 to directly indicate the mask to be performed.

[0107] Immediate value field 972 - Its content indicates that an immediate value is allowed. This field is optional when it does not appear in a sibling vector friendly format implementation that does not support immediate values ​​and when it does not appear in an instruction that does not use immediate values.

[0108] Type field 968 - Its content distinguishes different types of instructions. Referring to Figures 9A-B, the content of this field selects between Type A and Type B instructions. In Figures 9A-B, rounded squares are used to indicate a specific value appearing in this field (e.g., in Figures 9A-B, Type A 968A and Type B 968B are used for Type field 968). Type A instruction template

[0109] In the Type A non-memory access 905 instruction template, the Alpha field 952 is interpreted as the RS field 952A, the content of which distinguishes which of the different amplification operation types will be executed (for example, rounding 952A.1 and data conversion 952A.2 are respectively specified for memoryless access rounding type operation 910 and memoryless access data conversion type operation 915 instruction templates), while the Beta field 954 distinguishes which operation of the specified type will be executed. In the memoryless access 905 instruction template, the scale field 960, the shift field 962A, and the shift scale field 962B do not appear. Memoryless access instruction template - full rounding control type operation

[0110] In the instruction template of the no-memory access full rounding control type operation 910, the beta field 954 is interpreted as the rounding control field 954A, the contents of which provide static rounding. Although in the embodiments described in this invention, the rounding control field 954A includes a suppress all floating-point exception (SAE) field 956 and a rounding operation control field 958, other embodiments also support encoding these two concepts into the same field, or only one or the other of these concepts / fields (e.g., only the rounding operation control field 958).

[0111] SAE field 956 - its content distinguishes whether exception reporting should be enabled; when the content of SAE field 956 indicates that suppression is enabled, the given instruction will not report any type of floating-point exception flag and will not start any floating-point exception handler.

[0112] Rounding control field 958 – its contents distinguish which of a group of rounding operations (e.g., round up, round down, round to zero, and round to the nearest value) is performed. Therefore, the rounding control field 958 allows each instruction to proactively change the rounding mode. In one embodiment of the invention, the processor includes a control register to indicate the rounding mode, and the contents of the rounding control field 950 override the value of this register. No memory access instruction template – Data conversion type operation

[0113] In the instruction template of the no memory access data conversion type operation 915, the beta field 954 is interpreted as the data conversion field 954B, the contents of which distinguish which of several data conversions will be executed (e.g., no data conversion, mixing, broadcasting).

[0114] In the Type A memory access 920 instruction template, the alpha field 952 is interpreted as the eviction prompt field 952B, the content of which eviction prompt will be used (in Figure 9A, timing 952B.1 and non-timing 952B.2 are respectively indicated for memory access, timing 925 instruction template and memory access, non-timing 930 instruction template), and the beta field 954 is interpreted as the data transfer field 954C, the content of which distinguishes which of several data transfer operations (also called primitives) will be executed (e.g., no transfer, broadcast, source upscaling, and destination downscaling). The memory access 920 instruction template includes a scale field 960 and a selectable ground shift field 962A or shift scale field 962B.

[0115] Vector memory instructions perform vector loading and storage from memory with translation support. Like regular vector instructions, vector memory instructions transfer data in and out of memory in units of data elements. The actual elements transferred are governed by the vector mask content selected as the write mask. Memory Access Instruction Template - Timing

[0116] Timing data is data that appears to be reusable quickly enough to benefit from fast acquisition. However, this is a hint and different processors may implement it differently, including ignoring the hint entirely. Memory Access Instruction Template - Non-Timing

[0117] Non-sequential data is data that seems too slow to be reused to benefit from the first-order 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. Type B instruction template

[0118] In the type B instruction template, Alpha field 952 is interpreted as write mask control (Z) field 952C, the contents of which are distinguished as whether the write mask controlled by write mask field 970 should be merged or zeroed.

[0119] In the case of the type B non-memory access 905 instruction template, part of the beta field 954 is interpreted as the RL field 957A, the content of which distinguishes which of the different amplification operation types will be executed (for example, rounding 957A.1 and vector length (VSIZE) 957A.2 respectively indicate the rounding control type operation 912 instruction template for the memoryless access write mask control section and the memoryless access write mask control VSIZE type operation 917 instruction template), while the others in the beta field 954 distinguish which operation of the specified type will be executed. In the memoryless access 905 instruction template, the scale field 960, the shift field 962A, and the shift scale field 962B do not appear.

[0120] In the instruction template of the rounding control type operation 910 in the no memory access, write mask control section, the other part of the beta field 954 is interpreted as the rounding operation field 959A and the exception event reporting is disabled (the given instruction does not report any type of floating-point exception flag and does not start any floating-point exception handler).

[0121] Rounding control field 959A – Similar to rounding control field 958, its content distinguishes which of a group of rounding operations (e.g., round up, round down, round to zero, and round to the nearest value) is performed. Therefore, rounding control field 959A allows for per-instruction changes to the rounding mode. In one embodiment of the present invention, where the processor includes a control register for indicating the rounding mode, the content of rounding control field 950 replaces the register value.

[0122] In the VSIZE type operation 917 instruction template for memoryless access write mask control, the remainder of the beta field 954 is interpreted as the vector length field 959B, the contents of which distinguish which of several data vector lengths will be executed (e.g., 128, 256 or 512 bits).

[0123] In the Type B memory access instruction template 920, a portion of beta field 954 is interpreted as broadcast field 957B, the content of which distinguishes whether broadcast type data handling operations are performed, while the remaining portion of beta field 954 is interpreted as vector length field 959B. The memory access instruction template 920 includes scale field 960 and a selectable displacement field 962A or displacement scale field 962B.

[0124] Regarding the same vector friendly instruction format 900, the full opcode field 974 is displayed to include the format field 940, the basic operation field 942, and the data element width field 964. Although in one embodiment the full opcode field 974 is shown to include all of these fields, in embodiments where not all of them are supported, the full opcode field 974 does not include all of these fields. The full opcode field 974 provides the opcode.

[0125] The augmentation operation field 950, the data element width field 964, and the write mask field 970 allow these features to be specified on a per-instruction basis in the same vector-friendly instruction format.

[0126] The combination of the mask field and the data element width field creates a type instruction, which allows the mask to be applied according to different data element widths.

[0127] The various instruction templates found in Type A and Type B are advantageous for different situations. In some embodiments of the invention, different processors or different cores within a processor may support only Type A, Type B, or both. For example, a high-efficiency general-purpose out-of-order core for general computing may support only Type B, a core primarily for graphics and / or scientific (throughput) computing may support only Type A, and a core for both may support both (of course, cores with some mixture of templates and instructions from both types, but not all templates and instructions from both types, are also within the scope of the invention). Meanwhile, a single processor may contain multiple cores, all of which support the same type or different cores supporting different types. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores primarily for graphics and / or scientific computing may support only Type A, while one or more general-purpose cores may be high-efficiency general-purpose cores with out-of-order execution and register renaming for general computing that only support Type B. Another processor that does not have separate graphics cores may contain one or more general-purpose sequential or out-of-order cores that support both Type A and Type B. Of course, features from one type can also be implemented in other types in different embodiments of the invention. Programs written in high-level languages ​​can also be placed (e.g., just-in-time or statically compiled) into various executable forms, including: 1) forms containing only instructions of the types supported by the target processor; or 2) forms containing alternative constants written using different combinations of instructions of all types and control flow code that selects the constant to be executed based on the instructions supported by the processor currently executing the code. Examples of specific vector-friendly instruction formats are provided.

[0128] FIG10A is a block diagram illustrating a specific vector-friendly instruction format according to an embodiment of the present invention. FIG10A shows a specific vector-friendly instruction format 1000, which is characterized by specifying the position, size, interpretation, and order of fields, as well as the values ​​used for some of these fields. This specific vector-friendly instruction format 1000 can be used to extend the x86 instruction set, and therefore, some fields are similar to or the same as those used in existing x86 instruction sets and their extensions (e.g., AVX). This format maintains conformance to the pre-encoded fields, true operand tuple fields, MOD R / M fields, SIB fields, shift fields, and immediate value fields of existing x86 instruction sets with extensions. Fields from FIG10A are mapped to fields from FIG9 and are shown.

[0129] It should be understood that although the embodiments of the present invention are described in the context of a specific vector-friendly instruction format 1000 within the same vector-friendly instruction format 900, the present invention is not limited to the specific vector-friendly instruction format 1000 unless specifically asserted. For example, although the specific vector-friendly instruction format 1000 is displayed with fields of a specific size, the same vector-friendly instruction format 900 takes into account various possible sizes for various fields. As a specific example, although the data element width field 964 is illustrated as a one-bit field in the specific vector-friendly instruction format 1000, the present invention is not limited thereto (i.e., the same vector-friendly instruction format 900 takes into account other sizes of data element width field 964).

[0130] The friendly instruction format 900 for the same vector contains the following fields in the order shown in Figure 10A.

[0131] EVEX Prefix (bytes 0-3) 1002 - is encoded as a 4-byte form.

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

[0133] The second to fourth bytes (EVEX bytes 1-3) contain several bit fields that provide specific capabilities.

[0134] REX field 1005 (EVEX byte 1, bits [7-5]) - consists of EVEX.R bit field (EVEX byte 1, bits [7]-R), EVEX.X bit field (EVEX byte 1, bits [6]-X), and 957BEX byte 1, bits (5)-B). EVEX.R, EVEX.X and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using the complement of 1, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. As is known in the art, the lower 3 bits (rrr, xxx, and bbb) of the other field encoding register indexes of the instruction are used so that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X and EVEX.B.

[0135] REX' field 910 - This is the first part of REX' field 910 and is the EVEX.R' bit field (EVEX byte 1, bit [4]-R'), which is used to encode the upper 16 or lower 16 registers of the 32-register set. In one embodiment of the invention, this bit and the other bits referred to below are stored in bit-inverted format to distinguish (in the known x86 32-bit mode) the BOUND instruction, whose true operand byte is 62, but is not accepted in the MOD R / M field (as described below), the value of 11 in the MOD field; other embodiments of the invention do not store this and another bit indicated in inverted format. The 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 RRR from other fields.

[0136] Operation code mapping field 1015 (EVEX byte 1, byte [3:0]-mmmm) - its content encoding implies the preceding operation code byte (0F, 0F 38, or 0F 3).

[0137] Data element width field 964 (EVEX byte 2, bit [7]-W) - indicates what EVEX.W represents. EVEX.W is used to define the granularity (size) of the data type (32-bit data element or 64-bit data element).

[0138] EVEX.vvvv1020(EVEX byte 2, bits [6:3]-vvvv)-EVEX.vvvv can have the following roles: 1) EVEX.vvvv encodes the first source register operand in inverted (one's complement) form and is valid for instructions with 2 or more source operands; 2) For some vector shifts, EVEX.vvvv encodes the destination register operand in one's complement form; or 3) EVEX.vvvv does not encode any operands, this field is reserved and should contain 1111b. Therefore, the EVEX.vvvv field 1020 encodes the four lower-order bits of the first source register specification stored in inverted (one's complement) form. Depending on the instruction, additional different EVEX bit fields are used to expand the specification size to 32 registers.

[0139] EVEX.U968 Type field (EVEX byte 2, byte [2]-U) - If EVEX.U=0, it represents type A or EVEX.U0; if EVEX.U=1, it represents type B or EVEX.U1.

[0140] Prefix Encoding Field 1025 (EVEX byte 2, bits [1:0]-pp) - Provides additional bits for the base operation field. In addition to providing support for conventional SSE instructions in EVEX prefix format, this also has the advantage of compact SIMD prefixes (requiring no byte to represent a SIMD prefix, whereas an EVEX prefix only requires 2 bits). In one embodiment, to support conventional SSE instructions using SIMD prefixes (66H, F2H, F3H) represented in both conventional and EVEX prefix formats, these conventional SIMD prefixes are encoded as a SIMD prefix encoding field; and during runtime, they are extended into the conventional SIMD prefix before being provided to the PLA in the decoder (so that the PLA can execute these conventional instructions in both conventional and EVEX formats without modification). While newer instructions can be extended directly as operands using the contents of the EVEX prefix encoding field, some embodiments extend them in a similar manner to conform to, but allow for, different meanings that can be indicated by these conventional SIMD prefixes. Another embodiment can also redesign the PLA to support 2-bit SIMD pre-coding, so no expansion is required.

[0141] Alpha field 952 (EVEX byte 3, bit [7]-EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl, and EVEX.N; also exemplified as α) - As previously stated, this field is for a specific context.

[0142] Beta field 954 (EVEX byte 3, bits [6:4]-SSS, also known as EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; also exemplified as βββ) - As previously stated, this field is for a specific context.

[0143] REX' field 910 - This is the remainder of the REX' field and is the EVEX.V' bit field (EVEX byte 3, bit [3] - V'), which is used to encode the higher 16 or lower 16 registers of the expanded 32 register set. This bit is stored in bit-inverted format. A value of 1 is used to encode the lower 16 registers. In other words, V'VVVV is formed by combining EVEX.V' and EVEX.vvvv.

[0144] Write Mask field 970 (EVEX byte 3, bits [2:0]-kkk) - As previously described, its contents indicate 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 suggests no write mask is used for that particular instruction (this can be implemented in various ways, including using write mask all hardwired to 1 or using hardware that bypasses the write mask).

[0145] The actual operand field 1030 (byte 4) is also called the operand byte. A portion of the operand is specified in this field.

[0146] MOD R / M field 1040 (byte 5) includes MOD field 1042, Reg field 1044, and R / M field 1046. As mentioned earlier, the content of MOD field 1042 distinguishes between memory access and non-memory access operations. The role of Reg field 1044 can be summarized into two situations: encoding destination register operands or source register operands, or being regarded as an extension of the operand code and not used to encode any instruction operands. The role of R / M field 1046 can include the following: encoding instruction operands that encode reference memory addresses, or encoding destination register operands or source register operands.

[0147] Scale, Index, Base (SIB) byte (byte 6) - As previously stated, the contents of scale field 950 are used for memory address generation. SIB.xxx 1054 and SIB.bbb 1056 - The contents of these fields have been previously referenced regarding register indices Xxxx and Bbbb.

[0148] Displacement field 962A (bytes 7-10) - When MOD field 1042 contains 10, bytes 7-10 are displacement fields 962A, and they operate in the same way as traditional 32-bit displacement (disp32) and operate at the byte level.

[0149] Shift Factor Field 962B (Byte 7) - When MOD field 1042 contains 0 and 1, byte 7 is the shift factor field 962B. This field is located in the same position as the traditional x86 instruction set 8-bit shift (disp8) and operates at byte granularity. Because disp8 is a signed extension, it can be addressed only between offsets -128 and 137; represented by a 64-byte cache line, disp8 uses 8 bits and can be set to only four actual useful values: -128, -64, 0, and 64; because larger ranges are often required, disp32 is used; however, disp32 requires 4 bytes. The shift factor field 962B is a reinterpretation of disp8 compared to disp8 and disp32; when using the shift factor field 962B, the actual shift is determined by multiplying the content of the shift 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 is used for the displacement, but with a wider range). This compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of memory access; therefore, redundant lower-order bits of the address offset do not need to be encoded. In other words, the displacement factor field 962B replaces the traditional x86 instruction set 8-bit displacement. Therefore, the displacement factor field 962B is encoded in the same way as the x86 instruction set 8-bit displacement (therefore, there is no change in the ModRM / SIB encoding rules), with only one exception: disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules or encoding length, only a change in how the displacement value is interpreted by hardware (which needs to scale the displacement to the size of the memory operand to obtain the address offset in byte units). The immediate value field 972 operates as previously described. Full operand field

[0150] Figure 10B is a block diagram illustrating the fields of a specific vector friendly instruction format 1000, which is made into a full operand code field 974 according to one embodiment of the present invention. Specifically, the full operand code field 974 includes a format field 940, a basic operand field 942, and a data element width (W) field 964. The basic operand field 942 includes a pre-encoding field 1025, an operand code mapping field 1015, and a real operand code field 1030. (Temporary register index field)

[0151] Figure 10C is a block diagram illustrating the fields of a specific vector-friendly instruction format 1000, which is made into a register index field 944 according to one embodiment of the present invention. Specifically, the register index field 944 includes REX field 1005, REX' field 1010, MOD R / M.reg field 1044, MOD R / Mr / m field 1046, VVVV field 1020, xxx field 1054, and bbb field 1056. (Amplification operation field)

[0152] Figure 10D is a block diagram illustrating the fields of a specific vector friendly instruction format 1000, which is made into an augmentation operation field 950 according to an embodiment of the present invention. When the type (U) field 968 contains 0, it represents EVEX.U0 (type A 968A); when it contains 1, it represents EVEX.U1 (type B 968B). When U=0 and the MOD field 1042 contains 11 (representing no memory access operation), the alpha field 952 (EVEX byte 3, bits [7]-EH) is interpreted as the rs field 952A. When the rs field 952A contains 1 (rounding 952A.1), the beta field 954 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the rounding control field 954A. The rounding control field 954A contains a one-bit SAE field 956 and a two-bit rounding operation field 958. When the rs field 952A contains 0 (data conversion 952A.2), the beta field 954 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data conversion field 954B. When U=0 and the MOD field 1042 contains 00, 01 or 10 (representing memory access operation), the alpha field 952 (EVEX byte 3, bits [7]-EH) is interpreted as the eviction prompt (EH) field 952B and the beta field 954 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data dispatch field 954C.

[0153] When U=1, the Alpha field 952 (EVEX byte 3, bit [7]-EH) is interpreted as a write mask control (Z) field 952C. When U=1 and MOD field 1042 contains 11 (indicating no memory access operation), a portion of beta field 954 (EVEX byte 3, bit [4]-S0) is interpreted as RL field 957A; when it contains 1 (rounding 957A.1), the remaining portion of beta field 954 (EVEX byte 3, bit [6-5]-S2-1) is interpreted as rounding operation field 959A, and when RL field 957A contains 0 (VSIZE 957.A2), the remaining portion of beta field 954 (EVEX byte 3, bit [6-5]-S2-1) is interpreted as vector length field 959B (EVEX byte 3, bit [6-5]-L1-0). When U=1 and MOD field 1042 contains 00, 01, or 10 (indicating memory access operations), beta field 954 (EVEX byte 3, bits [6:4]-SSS) is interpreted as vector length field 959B (EVEX byte 3, bits [6-5]-L1-0) and broadcast field 957B (EVEX byte 3, bits [4]-B). Example of a register architecture

[0154] Figure 11 is a block diagram of a register architecture 1100 according to one embodiment of the present invention. In the illustrated embodiment, there are 32 vector registers 1110, each 512 bits wide; these registers are referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers are overlapped on registers ymm0-16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) are overlapped on registers xmm0-15. As illustrated in the table below, a specific vector-friendly instruction format 1000 operates on these overlapped register files. Adjustable vector length type Operations temporary register Instruction template excluding vector length field 959B A (Figure 9A; U=0) 910,915,925,930 zmm temporary register (vector length is 64 bits) B (Figure 9B; U=1) 912 zmm temporary register (vector length is 64 bits) Instruction template including vector length field 959B B (Figure 9B; U=1) 917,927 The zmm, ymm, or xmm register depends on the vector length field 959B (vector length is 64 byte, 32 byte, or 16 byte).

[0155] In other words, the vector length field 959B selects between a maximum length and one or more other shorter lengths, wherein each of these shorter lengths is half the length of the former; and instruction templates without the vector length field 959B operate at the maximum vector length. Furthermore, in one embodiment, the Type B instruction template of a specific vector-friendly instruction format 1000 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 location in the zmm / ymm / xmm register; higher-order data element locations are maintained as before the instruction or, depending on the embodiment, are zeroed out.

[0156] Write Mask Register 1115 - In an exemplary embodiment, there are eight write mask registers (k0 to k7), each with a size of 64 bits. In another embodiment, the write mask register 1115 is 16 bits in size. As previously mentioned, in one embodiment of the invention, the vector mask register k0 cannot be used as a write mask; when the code normally representing k0 is used as a write mask, its hardwired write mask is selected as 0xFFFF, which serves to disable the write mask that can be used for that instruction.

[0157] General-purpose registers 1125 - In the exemplary embodiment, there are sixteen 64-bit general-purpose registers that are used in conjunction with the existing x86 addressing mode to address memory operands. These registers are designated by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0158] Scalar Floating Point Stack Register File (x87 Stack) 1145, on which MMX Compact Integer Flat Register File 1150 is obfuscated - In the illustrated embodiment, the x87 stack is an eight-element stack for performing scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set extension; while the MMX register is used to perform operations on 64-bit compact integer data and to hold operands for some operations performed between the MMX and XMM registers.

[0159] Other embodiments of the present invention also use wider or narrower registers. Additionally, other embodiments of the present invention may use more, fewer, or different register files or registers. Examples include core architectures, processors, and computer architectures.

[0160] Processor cores can be implemented in different ways for different purposes and implemented in different processors. For example, such implementations of cores may include: 1) general-purpose sequential cores intended for general-purpose computing; 2) high-efficiency general-purpose out-of-order cores intended for general-purpose computing; 3) special-purpose cores primarily intended for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU containing one or more general-purpose sequential cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor containing one or more special-purpose cores primarily intended for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate die from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (in this case, this coprocessor is sometimes referred to as special-purpose logic, such as integrated graphics and / or scientific (throughput) logic, or a special-purpose core); and 4) a system chip that may contain the CPU (sometimes called an application core or application processor), the above coprocessors, and other functions on the same die. Illustrated core architectures will be further explained below, followed by illustrative descriptions of processors and computer architectures. Illustrated Core Architecture Sequential and Out-of-Order Core Block Diagrams

[0161] FIG12A is a block diagram illustrating sequential pipelines and register renaming / out-of-order issue / execution pipelines according to an embodiment of the present invention. FIG12B is a block diagram illustrating an embodiment of a sequential architecture core and a register renaming / out-of-order issue / execution architecture core included in a processor according to an embodiment of the present invention. In FIG12A-B, solid blocks illustrate sequential pipelines and sequential cores, while additional dashed blocks illustrate register renaming / out-of-order issue / execution pipelines and cores. It is assumed that a sequential state sample is a first group of out-of-order state samples, and the out-of-order state sample will be described.

[0162] In Figure 12A, the processor pipeline 1200 includes a fetch stage 1202, a length decoding stage 1204, a decoding stage 1206, a configuration stage 1208, a renaming stage 1210, a scheduling (also known as dispatch or issue) stage 1212, a register read / memory read stage 1214, an execution stage 1216, a write-back / memory write stage 1218, an exception handling stage 1222, and a determination stage 1224.

[0163] Figure 12B shows a processor core 1290, including a front-end unit 1230 coupled to an execution engine unit 1250, and both of which are coupled to a memory unit 1270. The core 1290 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 1290 can be a special-purpose core, such as a networking or communications core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, or the like.

[0164] Front-end unit 1230 includes a branch prediction unit 1232 coupled to instruction cache unit 1234, which is coupled to instruction translation lookahead buffer (TLB) 1236, which is coupled to instruction fetch unit 1238, which is coupled to decoding unit 1240. Decoding unit 1240 (or decoder) can decode instructions and generate one or more microoperations, microcode entry points, microinstructions, other instructions, or other control signals decoded, reflected, or derived from the original instructions as output. Decoding unit 1240 can also be implemented using various different 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 1290 includes a microcode ROM or other media for storing microcode of certain macro instructions (e.g., within decoding unit 1240 or otherwise within other front-end units 1230). Decoding unit 1240 is coupled to rename / configurator unit 1252 in execution engine unit 1250.

[0165] The execution engine unit 1250 includes a rename / configurator unit 1252 coupled to a retirement unit 1254 and a group of one or more scheduler units 1256. The scheduler units 1256 represent any number of different schedulers, including reserved stations, central command windows, etc. The scheduler units 1256 are coupled to physical register file units 1258. Each physical register file unit 1258 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 index being the address of the next instruction to be executed), etc. In one embodiment, the physical register file unit 1258 includes vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. Physical register file unit 1258 is overlapped by retirement unit 1254 to illustrate various ways in which register renaming and out-of-order execution can be performed (e.g., using reorder buffers and retirement register files; using future files, history buffers, and retirement register files; using register mappings and register pools; etc.). Retirement unit 1254 and physical register file unit 1258 are coupled to execution cluster 1260. Execution cluster 1260 includes a group of one or more execution units 1262 and a group of one or more memory access units 1264. Execution unit 1262 can perform various operations (e.g., shift, addition, subtraction, multiplication) and is applicable to various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include several execution units dedicated to specific functions or groups of functions, other embodiments may include only one execution unit or multiple execution units, all of which execute all functions. Scheduler unit 1256, physical register file unit 1258, and execution cluster 1260 are shown as possibly multiple, because some embodiments establish separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each having its own scheduler unit, physical register file unit, and / or execution cluster—and in the case of separate memory access pipelines, some embodiments are implemented such that only the execution cluster in this pipeline has memory access unit 1264). It should be understood that when using separate pipelines, one or more of these pipelines can be out-of-order issued / executed and the remainder in sequence.

[0166] The memory access unit 1264 is coupled to the memory unit 1270, which includes a data TLB unit 1272 coupled to the data cache unit 1274, and the data cache unit 1274 coupled to the second-order (L2) cache unit 1276. In one exemplary embodiment, the memory access unit 1264 may include a load unit, a storage address unit, and a storage data unit, each coupled to the data TLB unit 1272 in the memory unit 1270. The instruction cache unit 1234 is further coupled to the second-order (L2) cache unit 1276 in the memory unit 1270. The L2 cache unit 1276 is coupled to one or more other caches and finally coupled to the main memory.

[0167] For example, the illustrated register renaming, out-of-order issue / execution core architecture can implement pipeline 1200 as follows: 1) Instruction fetch 1238 executes fetch and length decoding stages 1202 and 1204; 2) Decoding unit 1240 executes decoding stage 1206; 3) Rename / configurator unit 1252 executes configuration stage 1208 and rename stage 1210; 4) Scheduler unit 1256 executes scheduling stage 1212; 5) Physical register The physical file unit 1258 and memory unit 1270 perform a register read / memory read level 1214, and the execution cluster 1260 performs an execution level 1216; 6) the memory unit 1270 and physical register file unit 1258 perform a write-back / memory write level 1218; 7) various units may be involved in an exception handling level 1222; and 8) the retirement unit 1254 and physical register file unit 1258 perform a determination level 1224.

[0168] Core 1290 may support one or more instruction sets (e.g., x86 instruction set (with some extensions, which have been added in recent versions); MIPS instruction set of MIPS Technologies, Sunnyvale, California, USA; ARM instruction set of ARM Holdings, Sunnyvale, California, USA (with optional additional extensions such as NEON), which include the instructions described herein. In one embodiment, core 1290 includes logic to support compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing computations used by many multimedia applications to be performed using compressed data.

[0169] It should be understood that the core can support multithreading (execute two or more parallel group operations or threads) and can be accomplished in a variety of ways, including time-sharing multithreading, simultaneous multithreading (where a single physical core provides logical cores for each thread, wherein the physical core is simultaneously multithreaded), or a combination thereof (e.g., time-sharing fetching and decoding followed by simultaneous multithreading, for example, in Intel® Hyper-Threading Technology).

[0170] Although register renaming is described in out-of-order execution, it should be understood that register renaming can also be used in sequential architectures. While exemplary embodiments of the processor also include separate instruction and data cache units 1234 / 1274 and a shared L2 cache unit 1276, other embodiments may also have a single internal cache for instructions and data, such as a first-order (L1) internal cache or a multi-order internal cache. In some embodiments, the system may include a combination of internal caches and external caches outside the core and / or processor. Alternatively, all these caches may be outside the core and / or processor. Specific exemplary sequential core architecture

[0171] Figures 13A-B illustrate block diagrams of a more specific sequential core architecture, where the core will be one of several logic blocks in the chip (containing other cores of the same type and / or different types). Depending on the application, these logic blocks communicate with other fixed-function logic, memory I / O interfaces, and other necessary I / O logic via high-bandwidth interconnects (e.g., ring networks).

[0172] Figure 13A is a block diagram of a single processor core according to an embodiment of the present invention, having connections to a local subset of on-die interconnect 1302 and a second-order (L2) cache 1304. In one embodiment, the instruction decoder 1300 supports the x86 instruction set with compressed data instruction set extensions. The L1 cache 1306 allows low-latency access to cache memory into scalar and vector units. Although in one embodiment (for design simplification), scalar units 1308 and vector units 1310 use separate register sets (scalar register 1312 and vector register 1314 respectively) and the data transferred therebetween is written to memory and then read back by the first-order (L1) cache 1306, other embodiments of the present invention may use different methods (e.g., using a single register set or including a communication path that allows data to be transferred between the two register files without being written back and read back).

[0173] The local subsets of the L2 cache 1304 are part of a comprehensive L2 cache that is subdivided into separate local subsets, with one local subset for each processor core. Each processor core has a direct access path to its own local subset of the L2 cache 1304. Data read by a processor core is stored in its L2 cache subset 1304 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 1304 and can be pushed out of other subsets if necessary. The ring network ensures the cohesion of shared data. The ring network is bidirectional to allow, for example, agents of processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0174] FIG13B is an expanded view of a portion of the processor core in FIG13A according to an embodiment of the present invention. FIG13B includes the L1 data cache 1306A portion of L1 cache 1304, and more detailed information regarding vector unit 1310 and vector register 1314. Specifically, vector unit 1310 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1328) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports mixing register inputs with mixing unit 1320, numerical conversion with value conversion units 1322A-B, and copying on memory inputs with copy unit 1324. Write mask register 1326 allows predicted vector writes.

[0175] FIG14 is a block diagram of a processor 1400 according to an embodiment of the present invention, which may have one or more cores, may have an integrated memory controller, and may have integrated graphics. The solid blocks in FIG14 illustrate the processor 1400, which has a single core 1402A, a system agent 1410, a group of one or more bus controller units 1416, while the selected dashed blocks illustrate another processor 1400, which has multiple cores 1402A-N, a group of one or more integrated memory controller units 1414 in the system agent unit 1410, and special purpose logic 1408.

[0176] Therefore, different embodiments of processor 1400 may include: 1) a CPU having special purpose logic 1408 for integrating graphics and / or scientific (throughput) logic (which may include one or more cores), and cores 1402A-N being one or more general-purpose cores (e.g., general-purpose sequential cores, general-purpose out-of-order cores, and combinations thereof); 2) a coprocessor having a large number of special purpose cores 1402A-N primarily for graphics and / or scientific (throughput); and 3) a coprocessor having a large number of general-purpose sequential cores 1402A-N. Thus, processor 1400 can be a general-purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (General-Purpose Graphics Processing Unit), a high-throughput multi-core (MIC) coprocessor (containing 30 or more cores), an embedded processor, or the like. The processor may be implemented on one or more chips. Using several process technologies, such as any of BiCMOS, CMOS or NMOS, the processor 1400 may be part of and / or implemented on one or more substrates.

[0177] The memory hierarchy includes one or more cache levels within the core, a group or one or more shared cache units 1406, and external memory (not shown) coupled to the group of integrated memory controller units 1414. The group of shared cache units 1406 may include one or more intermediate cache levels, such as second-order (L2), third-order (L3), fourth-order (L4), or other order cache levels, last-order cache (LLC), and / or combinations thereof. Although in one embodiment, the ring interconnect unit 1412 interconnects the integrated graphics logic 1408 (integrated graphics logic 1408 is an example of special purpose logic and is also referred to herein as special purpose logic), the group of shared cache units 1406, and the system proxy unit 1410 / integrated memory controller unit 1414, alternative embodiments may use any number of known techniques to interconnect these units. In one embodiment, a cohesive system is maintained between one or more cache units 1406 and the cores 1402A-N.

[0178] In some embodiments, one or more cores 1402A-N are multi-threaded. System agent 1410 includes these elements to coordinate and operate cores 1402A-N. System agent unit 1410 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or include the logic and elements required to regulate the power state of cores 1402A-N and integrated graphics logic 1408. The display unit is used to drive one or more externally connected displays.

[0179] From the perspective of the instruction set architecture, the 1402A-N cores can be homogeneous or heterogeneous. That is, two or more 1402A-N cores may be able to execute the same instruction set, while others may only be able to execute subgroups of that instruction set or different instruction sets. Example computer architecture.

[0180] Figure 15-18 is a block diagram illustrating a computer architecture. Other system designs and architectures known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also applicable. Generally, a wide variety of systems or electronic devices that can incorporate the processors and / or other execution logic disclosed herein are suitable.

[0181] Referring now to FIG15, a block diagram of a system 1500 according to an embodiment of the present invention is shown. System 1500 may include one or more processors 1510, 1515 coupled to a controller hub 1520. In one embodiment, controller hub 1520 includes a graphics memory controller hub (GMCH) 1590 and an input / output hub (IOH) 1550 (which may be on a separate chip); GMCH 1590 includes memory and a graphics controller coupled to memory 1540 and coprocessor 1545; IOH 1550 is used to couple input / output (I / O) device 1560 to GMCH 1590. Alternatively, one or both of the memory and graphics controller are integrated within the processor (as described), with memory 1540 and coprocessor 1545 directly coupled to processor 1510, and controller hub 1520 within a single chip having IOH 1550.

[0182] The selection of the additional processor 1515 is essentially indicated by a broken line in Figure 15. Each processor 1510, 1515 may be contained in one or more of the processing cores described herein, and may have some versions of processor 1400.

[0183] The memory 1540 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 1520 communicates with the processors 1510, 1515 via, for example, a multi-push bus of a front side bus (FSB), a point-to-point interface of a QuickPath interconnect (QPI), or a similar connection 1595.

[0184] In one embodiment, the coprocessor 1545 is a special-purpose processor, such as a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like. In one embodiment, the controller hub 1520 may include an integrated graphics accelerator.

[0185] The various differences between entity resources 1510 and 1515 are represented by a spectrum metric, including architecture, microarchitecture, thermal and power consumption characteristics and the like.

[0186] In one embodiment, processor 1510 executes instructions that control general-type data processing operations. These instructions may include coprocessor instructions. Processor 1510 recognizes these coprocessor instructions as the type to be executed by the attached coprocessor 1545. Therefore, processor 1510 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1545 on the coprocessor bus or other interconnect. Coprocessor 1545 receives and executes the received coprocessor instructions.

[0187] Referring now to FIG16, a block diagram of a first more specific exemplary system 1600 according to an embodiment of the present invention is shown. As shown in FIG16, the multiprocessor system 1600 is a point-to-point interconnect system and includes a first processor 1670 and a second processor 1680 coupled via a point-to-point interconnect 1650. Each processor 1670 and 1680 may be some version of processor 1400. In one embodiment of the present invention, processors 1670 and 1680 are processors 1510 and 1515, respectively, and the coprocessor 1638 is a coprocessor 1545. In another embodiment, processors 1670 and 1680 are processor 1510 and coprocessor 1545, respectively.

[0188] Processors 1670 and 1680 are shown to include integrated memory controller (IMC) units 1672 and 1682, respectively. Processor 1670 also includes a portion of its bus controller unit point-to-point (PP) interfaces 1676 and 1678; similarly, the second processor 1680 includes PP interfaces 1686 and 1688. Processors 1670 and 1680 can exchange information via point-to-point (PP) interface 1650 using PP interface circuits 1678 and 1688. As shown in FIG16, IMCs 1672 and 1682 couple these processors to individual memories, namely memories 1632 and 1634, which may be portions of the main memory locally attached to the individual processors.

[0189] Processors 1670 and 1680 can each exchange information with chipset 1690 via individual PP interfaces 1652 and 1654 using point-to-point interface circuits 1676, 1694, 1686, and 1698. Chipset 1690 can optionally exchange information with coprocessor 1638 via high-efficiency interface 1692. In one embodiment, coprocessor 1638 is a special-purpose processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.

[0190] A shared cache (not shown) may be contained within one of the processors or outside of both processors, while being connected to the processors via a PP interconnect, such that if the processors are in a low-power mode, local cache information of one or both processors can be stored in the shared cache.

[0191] Chipset 1690 may be coupled to first bus 1616 via interface 1696. In one embodiment, first bus 1616 may be a peripheral element interconnect (PCI) bus, or a bus such as a PCI acceleration bus or another third-generation I / O interconnect bus, but the scope of the invention is not limited thereto.

[0192] As shown in FIG. 16, various I / O devices 1614 may be coupled to a first bus 1616 and have a bus bridge 1618 that couples the first bus 1616 to a second bus 1620. In one embodiment, one or more additional processors 1615, such as coprocessors, high-throughput MIC processors, GPGPU accelerators (e.g., graphics accelerators or digital signal processor (DSP) units), field programmable gate arrays, or any other processors, are coupled to the first bus 1616. In one embodiment, the second bus 1620 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1620, including, for example, a keyboard and / or mouse 1622, a communication device 1627, and a storage unit 1628, such as a disk drive or other mass storage device, which may contain instructions / code and data 1630. Furthermore, the audio I / O 1624 can be coupled to the second bus 1620. Note that other architectures are also possible. For example, instead of the point-to-point architecture in Figure 16, the system can also implement a multi-bus architecture or other similar architectures.

[0193] Referring now to FIG17, a block diagram of a second more specific illustrated system 1700 according to an embodiment of the present invention is shown. Similar elements in FIG16 and 17 are represented by similar element symbols, and some features of FIG16 have been omitted from FIG17 to avoid obscuring other features of FIG17.

[0194] Figure 17 illustrates that processors 1670 and 1680 may respectively include integrated memory and I / O control logic (CL) 1672 and 1682. Therefore, CL 1672 and 1682 include an integrated memory controller unit and I / O control logic. Figure 17 illustrates that not only are memories 1632 and 1634 coupled to CL 1672 and 1682, but I / O device 1714 is also coupled to control logic 1672 and 1682. Conventional I / O device 1715 is coupled to chipset 1690.

[0195] Referring now to FIG18, a block diagram of a SoC 1800 according to an embodiment of the present invention is shown. Similar elements in FIG14 have similar element symbols. Meanwhile, dashed blocks represent optional features on more advanced SoCs. In FIG18, interconnect unit 1802 is coupled to: application processor 1810, which includes a group of one or more cores 1402A-N, which includes cache units 1404A-N and a shared cache unit 1406; system proxy unit 1410; bus controller unit 1416; an integrated memory controller unit 1414; a group of one or more coprocessors 1820, which may include integrated graphics logic, image processor, audio processor and video processor; static random access memory (SRAM) unit 1830; direct memory access (DMA) unit 1832; and display unit 1840 for coupling to one or more external displays. In one embodiment, the coprocessor 1820 includes a special purpose processor, such as a network or communications processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, or the like.

[0196] Embodiments of the mechanism disclosed herein may be implemented as hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as a computer program or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

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

[0198] The code can be implemented in a high-level programmable or object-oriented programming language to communicate with the processing system. If desired, the code 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 a compiled or interpreted language.

[0199] One or more embodiments of at least one example can be implemented as representative instructions stored in a machine-readable medium, representing various logics within a processor, which, when read by a machine, cause the machine to manufacture logic to perform the techniques described herein. Such representatives, referred to as "IP cores," can be stored in a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into a manufacturing machine, which actually constitutes the logic or processor.

[0200] This machine-readable storage medium may include, but is not limited to, manufactured objects of non-transitory tangible configuration or objects formed by a machine or apparatus, 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 (ROM), random access memory (RAM), RAM being such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0201] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or design data, such as a Hardware Description Language (HDL), defined as the structures, circuits, devices, processors, and / or system characteristics described herein. These embodiments may also be referred to as program products. Simulation (including binary translation, code gradation, etc.)

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

[0203] Figure 19 is a block diagram illustrating a comparative use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present invention. In the exemplary embodiment, the instruction converter is a software instruction converter, but the instruction converter may be implemented as software, hardware, firmware, or various combinations thereof. Figure 19 shows a program expressed in a high-level language 1902, which can be compiled using an x86 compiler 1904 to produce x86 binary code 1906, which can be natively executed by a processor having at least one x86 instruction set core 1916. A processor having at least one x86 instruction set core 1916 represents any processor capable of performing substantially the same functions as an Intel processor having at least one x86 instruction set core by compatibly 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 for execution on an Intel processor having at least one x86 instruction set core, to achieve substantially the same results as an Intel processor having at least one x86 instruction set core. An x86 compiler 1904 represents a compiler operable to produce x86 binary code 1906 (e.g., object code), which can be executed on a processor 1916 having at least one x86 instruction set core, with or without additional linking processing. Similarly, Figure 19 shows that a program expressed in a high-level language 1902 can be compiled using an alternative instruction set compiler 1908 to produce alternative instruction set binary code 1910, which can be natively executed by a processor 1914 that does not have at least one x86 instruction set core (e.g., a processor with a core that executes the MIPS instruction set of MIPS Technologies, Inc., .C., and / or the ARM instruction set of ARM Holdings, Inc., .C ... Therefore, the instruction converter 1912 represents software, firmware, hardware, or a combination thereof, that, through emulation, simulation, or any other processing, allows a processor or other electronic device to execute x86 binary code 1906 without an x86 instruction set processor or core. Example

[0204] Example 1 provides a processor comprising: a fetching circuit for fetching an instruction from an instruction memory, the instruction format including an opcode, a first source operand identifier, a second source operand identifier, and a destination operand identifier, wherein each identifier is used to identify a location storing compressed data comprising at least one complex element, wherein each complex element location includes a real component and an imaginary component; a decoding circuit for decoding the instruction; a data retrieval circuit for retrieving data relating to the first source operand identifier and the second source operand identifier; and an execution circuit for: cross-multiplying the real component and the imaginary component for each compressed data element location of the identified first and second source operands to generate four products: a product of real components, a product of imaginary components, and two mixed products; generating a complex result by summing the four products according to the instruction; and storing the complex result in the corresponding location of the identified destination operand.

[0205] Example 2 includes the object of Example 1, wherein the instruction includes vector-complex fusion multiplication and addition, and wherein the execution circuitry is configured to: generate the real component of the complex result by subtracting the product of the imaginary components from the product of the real components, generate the imaginary component of the complex result by adding the two fusion products, and write the complex result to the corresponding compressed data element location of the destination operand.

[0206] Example 3 includes the object of Example 1, wherein the instruction includes vector-complex fusion conjugate multiplication and addition, and wherein the execution circuit is used to: generate the real part of the complex result by adding the product of the imaginary part to the product of the real part, generate the imaginary part of the complex result by subtracting the other product of the two mixed products from the first mixed product of the two mixed products, and write the complex result to the corresponding compressed data element position of the destination operand.

[0207] Example 4 includes any of the objects in Examples 1 to 3, wherein the format of the instruction further includes a write mask, wherein each bit of the write mask corresponds to an element position within the identified target operand, wherein when the bit is set to a first value, the resulting real and imaginary portions are written to the element position of the target operand, and when the bit is set to a second value, the corresponding compressed data element position of the target operand remains unchanged.

[0208] Example 5 includes an object of one of Examples 1 to 4, wherein the identified first and second source operands are used to include at least two complex numbers, and wherein the execution circuit is used to generate, in series, the corresponding compressed data element positions of the identified target operands one complex element at a time.

[0209] Example 6 includes an object of one of Examples 1 to 5, wherein the identified first and second source operands are configured to include at least two complex numbers, and wherein the execution circuitry is configured to generate each corresponding compressed data element position of the identified target operand in parallel.

[0210] Example 7 includes the object of Example 6, wherein the execution circuit is used to execute the decoded instruction on the at least two elements in a single clock cycle.

[0211] Example 8 includes the object of Example 2, wherein the identified first and second source operands are scalar values ​​and each contains a single complex number.

[0212] Example 9 includes the object of Example 1, wherein the width of the element of the identified first and second operands and the identified target operand is determined by the preamble of the operand.

[0213] Example 10 includes an object of one of Examples 1 to 9, wherein the number of elements of the identified first and second source operands and the identified destination operand is determined by the operation code.

[0214] Example 11 provides a method comprising: retrieving an instruction from an instruction memory, the instruction format including an operand code, a first source operand identifier, a second source operand identifier, and a destination operand identifier, wherein each identifier is used to identify a location storing compressed data comprising at least one complex number, the complex number comprising a pair of values ​​corresponding to real and imaginary components; decoding the instruction; retrieving data relating to the first source operand identifier and the second source operand identifier; and executing the decoded instruction to cross-multiply the real and imaginary components for each compressed data element location of the identified first and second source operands to generate four products: a product of real components, a product of imaginary components, and two mixed products; generating a complex result by summing the four products according to the instruction; and storing the complex result in the corresponding location of the identified destination operand.

[0215] Example 12 includes the method of Example 11, wherein the instruction includes vector-complex fusion multiplication and addition, and executes the decoded instruction to: generate the real part of the complex result by subtracting the product of the imaginary part from the product of the real part, generate the imaginary part of the complex result by adding the two fusion products, and write the complex result to the corresponding compressed data element location of the destination operand.

[0216] Example 13 includes the method of Example 11, wherein the instruction includes vector-complex fusion multiplication and addition, and wherein the decoded instruction is executed to: generate the real part of the complex result by adding the product of the imaginary part to the product of the real part, generate the imaginary part of the complex result by subtracting the other product of the two mixed products from the first mixed product of the two mixed products, and write the complex result to the corresponding compressed data element location of the destination operand.

[0217] Example 14 includes the method of Example 11, wherein each of the identifiers is used to identify a location storing compressed data comprising at least two complex numbers, and wherein the execution circuit is used to generate the real and imaginary components of the at least two complex elements of the at least two complex elements and to sum the at least two complex numbers to the target operand.

[0218] Example 15 includes the method of Example 14, and further includes executing the decoded instructions in parallel on the at least two complex numbers in a single clock cycle.

[0219] Example 16 includes the method of Example 11, wherein the format of the instruction further includes a write mask, each bit of the write mask corresponding to a component position within the identified destination operand, wherein when the bit is set to a first value, the generated real and imaginary quantities are written to the component position of the destination operand, and when the bit is set to a second value, the corresponding compressed data component position of the destination operand remains unchanged.

[0220] Example 17 provides a non-transitory computer-readable storage medium storing instructions that, when executable by a processor, perform a method comprising: retrieving instructions from an instruction memory, the format of which includes an operand code, a first source operand identifier, a second source operand identifier, and a destination operand identifier, wherein each identifier is used to identify a location storing compressed data comprising at least one complex number, the complex number comprising a pair of values ​​corresponding to a real component and an imaginary component; decoding the instructions; retrieving data relating to the first source operand identifier and the second source operand identifier; and executing the decoded instructions to cross-multiply the real component and the imaginary component for each compressed data element location of the identified first and second source operands to generate four products: a product of real components, a product of imaginary components, and two mixed products; generating a complex result by summing the four products according to the instructions; and storing the complex result in the corresponding location of the identified destination operand.

[0221] Example 18 includes the object of Example 17, wherein each of the identifiers is used to identify a location storing at least one complex compressed data element, and wherein the processor is used to generate four products and side-by-side the at least two complex numbers, and to add the four products to the real and imaginary components of the at least two complex elements of the target operand.

[0222] Example 19 includes the object of Example 18, and further includes executing the decoded instruction on the at least one element in a single clock cycle.

[0223] Example 20 includes the object of Example 18, and further includes executing the decoded instructions in parallel on each of the identified first and second source operands. Although some embodiments disclosed herein involve data processing in the context of hardware execution circuitry, other embodiments may also be implemented with data or instructions stored in a non-transitory machine-readable tangible medium, which, when executed by a machine, causes the machine to perform functions in accordance with at least one embodiment. In one embodiment, the functions of the embodiments of this case are implemented in machine-executable instructions. The instructions may be used to cause a general-purpose or special-purpose processor configured with the instructions to perform the steps of at least one embodiment. The embodiments disclosed herein may be provided as computer program products or software, which may include a machine or computer-readable medium having instructions stored thereon, and be used to configure a computer (or other electronic device) to perform operations according to one or more of at least one embodiment. Alternatively, the steps of the embodiments may also be performed by special hardware components, or any combination of computer components and fixed-function hardware components, which include fixed-function logic for performing these steps.

[0224] Instructions for planning logic to execute at least one embodiment can be stored in memory within the system, such as DRAM, cache, flash memory, or other storage. Furthermore, these instructions can be distributed via a network or other computer-readable media. Therefore, machine-readable media can include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, but is not limited to floppy disks, optical disks, microdisks, CD-ROMs, and magneto-optical disks, ROMs, random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or physical machine-readable storage for information transmission via the Internet through electrical, optical, acoustic, or other forms of signal transmission (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, nontransitory computer-readable media includes any type of tangible machine-readable media suitable for storing or transmitting electronic instructions or information in a form that can be read by a machine (e.g., a computer). [Simplified Explanation of the Diagram]

[0004] The various advantages of the embodiments disclosed herein will become apparent to those skilled in the art upon reading the following specification and the appended claims in conjunction with the accompanying drawings, in which:

[0005] [Figure 1] is a block diagram illustrating a processing element used to execute an instruction to multiply two compressed or scalar complex numbers and sum the results according to an embodiment.

[0006] [Figures 2A-2B] illustrate fields contained in an instruction used, according to some embodiments, to multiply two compressed or scalar complex numbers and sum the results.

[0007] [Figure 2A] illustrates a field contained in an instruction used to multiply two compressed or scalar complex numbers and sum the results according to one embodiment.

[0008] [Figure 2B] illustrates a field contained in an instruction used, according to an embodiment, to multiply two compressed or scalar complex numbers using a write mask and sum the results.

[0009] [Figure 3] is the execution circuit used to implement the VCFMADD instruction, which, according to one embodiment, multiplies two compressed complex numbers and accumulates the result.

[0010] [Figure 4] is the execution circuit used to implement the VCFCMADD instruction, which, according to one embodiment, multiplies two compressed complex numbers and accumulates the result.

[0011] [Figure 5A] is a block flowchart illustrating, according to an embodiment, the execution of an instruction to multiply two compressed complex numbers and sum the results.

[0012] [Figure 5B] is a block flowchart illustrating, according to an embodiment, the execution of an instruction to multiply two compressed complex numbers and sum the results.

[0013] [Figure 5C] is a block flowchart illustrating, according to an embodiment, the execution of an instruction to multiply two compressed complex numbers and sum the results.

[0014] [Figure 6] is a virtual code used to illustrate the operation of the execution circuit to execute the VCFMADD instruction according to an embodiment.

[0015] [Figure 7] is a virtual code used to illustrate the operation of the execution circuit to execute the VCFMADD instruction according to an embodiment.

[0016] [Figure 8] is a virtual code used to illustrate the operation of the execution circuit to execute the VCFCMADD instruction according to an embodiment.

[0017] [Figures 9A-9B] are block diagrams illustrating the same-vector friendly instruction format and its instruction template according to embodiments of the present invention.

[0018] [Figure 9A] is a block diagram illustrating the same-vector friendly instruction format and its type A instruction template according to an embodiment of the present invention.

[0019] [Figure 9B] is a block diagram illustrating the same-vector friendly instruction format and its type B instruction template according to an embodiment of the present invention.

[0020] [Figure 10A] is a block diagram illustrating a special vector-friendly instruction format according to an embodiment of the present invention.

[0021] [Figure 10B] is a block diagram illustrating a field in a special vector-friendly instruction format for creating a full operation code field 974 according to an embodiment of the present invention.

[0022] [Figure 10C] is a block diagram illustrating a field in a special vector-friendly instruction format for creating a register index field 944 according to an embodiment of the present invention.

[0023] [Figure 10D] is a block diagram illustrating a field with a special vector-friendly instruction format for creating an augmentation operation field 950 according to an embodiment of the present invention.

[0024] [Figure 11] is a block diagram of a temporary register architecture according to an embodiment of the present invention.

[0025] [Figure 12A] is a block diagram illustrating both the sequential pipeline and the register renaming and out-of-order issue / execution pipeline according to an embodiment of the present invention.

[0026] [Figure 12B] is a block diagram illustrating an exemplary embodiment of a sequential architecture core included in a processor according to embodiments of the present invention, and an exemplary embodiment of a renamed out-of-order issue / execution architecture core.

[0027] [Figures 13A-B] illustrate a block diagram of a more specific sequential core architecture, the core of which will be one of several logic blocks in the chip (containing other cores of the same type and / or different types).

[0028] [Figure 13A] is a block diagram of a single processor core according to an embodiment of the present invention, and its local subgroup connected to the on-chip interconnect network 1302 and its second-order (L2) cache 1304.

[0029] [Figure 13B] is an expanded view of a portion of the processor core in Figure 13A according to an embodiment of the present invention.

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

[0031] [Figure 15-18] is a block diagram illustrating a computer architecture.

[0032] [Figure 15] is a block diagram of a system according to an embodiment of the present invention.

[0033] [Figure 16] is a block diagram of a first more specific example system according to an embodiment of the present invention.

[0034] [Figure 17] is a block diagram of a second more specific example system according to an embodiment of the present invention.

[0035] [Figure 18] is a block diagram of a SoC according to an embodiment of the present invention, and

[0036] [Figure 19] is a block diagram comparing the use of a software instruction converter to convert binary instructions in the source instruction set into binary instructions in the target instruction set according to an embodiment of the present invention.

Claims

1. A processor comprising: a fetching circuit for fetching a single instruction, the single instruction specifying an opcode and the locations of a first source and a second source containing complex numbers, and a destination vector; the opcode indicating an execution circuit for: generating, in parallel, a product of the real parts, a product of the imaginary parts, and two mixed products of the complex numbers corresponding to each of the first and second sources using individual multiplier circuits, and using the four products to generate complex number results for each corresponding element of the destination vector; a decoding circuit for decoding the single instruction; and the execution circuit for executing the single instruction according to the opcode and storing each of the complex number results in the corresponding element of the destination vector.

2. The processor of claim 1, wherein the arithmetic code includes a first value indicating a vector-complex fused multiply-add (VCFMADD), and when the four products are used, the execution circuitry is configured to: generate the real components of a plurality of complex results by subtracting the product of the imaginary components from the product of the real components; and generate the imaginary components of a plurality of complex results by adding the two mixed products.

3. The processor of claim 2, wherein the arithmetic code includes a second value different from the first value, indicating vector-complex fused conjugate multiply-add (VCFCMADD), and when the four products are used, the execution circuitry is configured to: generate the real portion of a plurality of complex results by adding the product of the imaginary portion to the product of the real portion; and generate the imaginary portion of a plurality of complex results by subtracting one of the mixed products from the other of the mixed products.

4. The processor of claim 1, wherein the arithmetic code includes a value indicating vector-complex fused conjugate multiply-add (VCFCMADD), and when the four products are used, the execution circuitry is configured to: generate the real portion of a plurality of complex results by adding the product of the imaginary portion to the product of the real portion; and generate the imaginary portion of a plurality of complex results by subtracting one of the mixed products from the other of the mixed products.

5. The processor of request item 1, wherein the single instruction further includes a field for indicating a write mask containing a plurality of bits, each bit indicating whether a corresponding element of the destination vector will be masked, wherein the execution circuitry sets the element to zero or leaves the element unchanged.

6. The processor of claim 1, wherein the arithmetic code instructs the execution circuit to, with the individual multiplier circuit, generate, in parallel, a product of their real parts, a product of their imaginary parts, and two mixed products for each corresponding complex number in each of the first and second sources, and use the four products to produce the complex result for each corresponding element of the destination vector.

7. The processor of claim 1, wherein the arithmetic code instructs the execution circuitry to further broadcast, for a single complex number in the first source, the same vector length of the single complex number to the destination vector for use by the execution circuitry executing the single instruction.

8. The processor of request item 1, wherein the width of each element of the first source, the second source, and the destination vector is represented by the preamble of the operation code.

9. A method executed by a processor, the method comprising: fetching a single instruction by a fetching circuit of the processor, the single instruction specifying an operand and the locations of a first source and a second source containing complex numbers, and a destination vector, the operand instructing an execution circuit to: generate, by individual multiplier circuitry, in parallel, a product of the real parts, a product of the imaginary parts, and two mixed products of the respective corresponding complex numbers of the first and second sources, and using the four products to generate complex number results for each corresponding element of the destination vector; decoding the single instruction by a decoding circuit of the processor; and executing the single instruction by the execution circuitry of the processor based on the operand and storing each of the complex number results in the corresponding element of the destination vector.

10. The method of claim 9, wherein the operand includes a first value indicating a vector-complex fusion multiplication-addition (VCFMADD), and the execution using the four products includes: generating the real components of a plurality of complex results by subtracting the product of the imaginary components from the product of the real components; and generating the imaginary components of a plurality of complex results by adding the two mixed products.

11. The method of claim 10, wherein the operand includes a second value different from the first value, indicating vector-complex fusion conjugate multiplication and addition (VCFCMADD), and the execution using the four products includes: generating the real part of a plurality of complex results by adding the product of the imaginary part to the product of the real part; and generating the imaginary part of a plurality of complex results by subtracting another mixture of the two mixtures from one mixture of the two mixtures.

12. The method of claim 9, wherein the operand includes a value indicating vector-complex fusion conjugate multiply-add (VCFCMADD), and the execution using the four products includes: producing the real part of a plurality of complex results by adding the product of the imaginary part to the product of the real part; and producing the imaginary part of a plurality of complex results by subtracting another mixture of the two mixtures from one mixture of the two mixtures.

13. The method of claim 9, wherein the single instruction further includes a field indicating a write mask containing a plurality of bits, each bit indicating whether a corresponding element of the destination vector will be masked, wherein the execution circuitry sets the element to zero or leaves the element unchanged.

14. The method of claim 9, wherein the arithmetic code instructs the execution circuit to generate, with the individual multiplier circuit, a product of the real parts, a product of the imaginary parts, and two mixed products in parallel for each corresponding complex number of a plurality of complex numbers in each of the first and second sources, and to use the four products to produce the complex result for each corresponding element of the destination vector.

15. The method of claim 9, wherein the arithmetic code instructs the execution circuitry to further broadcast, for a single complex number in the first source, the same vector length of the single complex number to the destination vector for use by the execution circuitry executing the single instruction.

16. The method of claim 9, wherein the width of each element of the first source, the second source, and the destination vector is represented by the preamble of the operation code.

17. A method executed by a processor, the method comprising: fetching a single instruction of a first instruction set architecture by a fetching circuit of the processor, the single instruction specifying an operand and the locations of a first source and a second source containing complex numbers, and a destination vector, the operand instructing an execution circuit to: generate, by individual multiplier circuitry, a product of the real parts, a product of the imaginary parts, and two mixed products of the complex numbers corresponding to each of the first and second sources, and using the four products to generate complex results for each corresponding element of the destination vector; translating the single instruction of the first instruction set architecture into one or more instructions of a second instruction set architecture; decoding the one or more instructions of the second instruction set architecture by a decoding circuit of the processor; and executing the one or more instructions of the second instruction set architecture according to the operand and storing each of the complex results in the corresponding element of the destination vector by the execution circuitry of the processor.

18. The method of claim 17, wherein the operand includes a first value indicating a vector-complex fusion multiply-add (VCFMADD), and the execution using the four products includes: generating the real components of a plurality of complex results by subtracting the product of the imaginary components from the product of the real components; and generating the imaginary components of a plurality of complex results by adding the two mixed products.

19. The method of claim 18, wherein the operand includes a second value different from the first value, the indicator vector-complex fusion conjugate multiply-add (VCFCMADD), and the execution using the four products includes: generating the real part of a plurality of complex results by adding the product of the imaginary part to the product of the real part; and generating the imaginary part of a plurality of complex results by subtracting another mixture of the two mixtures from one mixture of the two mixtures.

20. The method of claim 17, wherein the operand includes a value indicating a vector-complex fused conjugate multiply-add (VCFCMADD), and the execution using the four products includes: generating the real part of a plurality of complex results by adding the product of the imaginary part to the product of the real part; and generating the imaginary part of a plurality of complex results by subtracting another mixture of the two mixtures from one mixture of the two mixtures.

21. The method of claim 17, wherein the single instruction further includes a field indicating a write mask comprising a plurality of bits, each bit indicating whether a corresponding element of the destination vector will be masked, wherein the execution circuitry sets the element to zero or leaves the element unchanged.

22. The method of claim 17, wherein the arithmetic code instructs the execution circuit to generate, with the individual multiplier circuit, a product of the real parts, a product of the imaginary parts, and two mixed products in parallel for each corresponding complex number in each of the first and second sources, and to use the four products to produce the complex result for each corresponding element of the destination vector.

23. The method of claim 17, wherein the arithmetic code instructs the execution circuitry to further broadcast, for a single complex number in the first source, the same vector length of the single complex number to the destination vector for use by the execution circuitry executing the single instruction.

24. The method of claim 17, wherein the width of each element of the first source, the second source, and the destination vector is represented by the preamble of the operation code.

Images