Apparatus and method for vector instructions for large integer arithmetic

An apparatus is described that includes a semiconductor chip having an instruction execution pipeline having one or more execution units with respective logic circuitry to: a) execute a first instruction that multiplies a first input operand and a second input operand and presents a lower portion of the result, where, the first and second input operands are respective elements of first and second input vectors; b) execute a second instruction that multiplies a first input operand and a second input operand and presents an upper portion of the result, where, the first and second input operands are respective elements of first and second input vectors; and, c) execute an add instruction where a carry term of the add instruction's adding is recorded in a mask register.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is a U.S. National Phase Application under 35 U.S.C. §371 of International Application No. PCT/US2011/067165, filed Dec. 23, 2011, entitled APPARATUS AND METHOD FOR VECTOR INSTRUCTIONS FOR LARGE INTEGER ARITHMETIC.

BACKGROUND

1. Field of Invention

The present invention pertains to the computing sciences generally, and, more specifically to an apparatus and method for vector instructions for large integer arithmetic.

FIG. 1shows a high level diagram of a processing core100implemented with logic circuitry on a semiconductor chip. The processing core includes a pipeline101. The pipeline consists of multiple stages each designed to perform a specific step in the multi-step process needed to fully execute a program code instruction. These typically include at least: 1) instruction fetch and decode; 2) data fetch; 3) execution; 4) write-back. The execution stage performs a specific operation identified by an instruction that was fetched and decoded in prior stage(s) (e.g., in step 1) above) upon data identified by the same instruction and fetched in another prior stage (e.g., step 2) above). The data that is operated upon is typically fetched from (general purpose) register storage space102. New data that is created at the completion of the operation is also typically “written back” to register storage space (e.g., at stage 4) above).

The logic circuitry associated with the execution stage is typically composed of multiple “execution units” or “functional units”103_1to103_N that are each designed to perform its own unique subset of operations (e.g., a first functional unit performs integer math operations, a second functional unit performs floating point instructions, a third functional unit performs load/store operations from/to cache/memory, etc.). The collection of all operations performed by all the functional units corresponds to the “instruction set” supported by the processing core100.

Two types of processor architectures are widely recognized in the field of computer science: “scalar” and “vector”. A scalar processor is designed to execute instructions that perform operations on a single set of data, whereas, a vector processor is designed to execute instructions that perform operations on multiple sets of data.FIGS. 2A and 2Bpresent a comparative example that demonstrates the basic difference between a scalar processor and a vector processor.

FIG. 2Ashows an example of a scalar AND instruction in which a single operand set, A and B, are ANDed together to produce a singular (or “scalar”) result C (i.e., AB=C). By contrast,FIG. 2Bshows an example of a vector AND instruction in which two operand sets, A/B and D/E, are respectively ANDed together in parallel to simultaneously produce a vector result C, F (i.e., A.AND.B=C and D.AND.E=F). As a matter of terminology, a “vector” is a data element having multiple “elements”. For example, a vector V=Q, R, S, T, U has five different elements: Q, R, S, T and U. The “size” of the exemplary vector V is five (because it has five elements).

FIG. 1also shows the presence of vector register space104that is different that general purpose register space102. Specifically, general purpose register space102is nominally used to store scalar values. As such, when, the any of execution units perform scalar operations they nominally use operands called from (and write results back to) general purpose register storage space102. By contrast, when any of the execution units perform vector operations they nominally use operands called from (and write results back to) vector register space107. Different regions of memory may likewise be allocated for the storage of scalar values and vector values.

Note also the presence of masking logic104_1to104_N and105_1to105_N at the respective inputs to and outputs from the functional units103_1to103_N. In various implementations, only one of these layers is actually implemented—although that is not a strict requirement. For any instruction that employs masking, input masking logic104_1to104_N and/or output masking logic105_1to105_N may be used to control which elements are effectively operated on for the vector instruction. Here, a mask vector is read from a mask register space106(e.g., along with input data vectors read from vector register storage space107) and is presented to at least one of the masking logic104,105layers.

Over the course of executing vector program code each vector instruction need not require a full data word. For example, the input vectors for some instructions may only be 8 elements, the input vectors for other instructions may be 16 elements, the input vectors for other instructions may be 32 elements, etc. Masking layers104/105are therefore used to identify a set of elements of a full vector data word that apply for a particular instruction so as to effect different vector sizes across instructions. Typically, for each vector instruction, a specific mask pattern kept in mask register space106is called out by the instruction, fetched from mask register space and provided to either or both of the mask layers104/105to “enable” the correct set of elements for the particular vector operation.

DETAILED DESCRIPTION

Overview

Detailed Description

FIG. 3athroughFIG. 3cshow a mathematical perspective for the multiplication of two large numbers that forms the basis for vector integer instructions described in more detail further below. For simplicity, the integers being multiplied inFIG. 3aare not very large and, moreover, are expressed in base 10 form (ten possible digits 0 through 9) rather than in base 2 form (two possible digits 0 and 1). Nevertheless, they are sufficient to bring forward pertinent aspects of the instructions described herein which are capable of multiplying much larger numbers expressed in base 2 form.

As observed inFIG. 3a, a multiplicand B=765 is multiplied301by a multiplier A=834. The summation of partial products302is consistent with elementary mathematics and shows the final result to be 638,010. Notably, the three partial products302a,302b,302bcan be viewed akin to a “right-wise staircase” structure303, where: 1) the lowest ordered partial product302acorresponds to the multiplication of the lowest ordered digit of the multiplier A[0]=4 by all three digits of the multiplicand B[2:0]=765; 2) the middle ordered partial product302bis shifted to the left one place relative to the lowest ordered partial product302aand corresponds to the multiplication of the middle ordered digit of the multiplier A[1]=3 by all three digits of the multiplicand B[2:0]=765; and, 3) the highest ordered partial product302cis shifted to the left one place relative to the middle ordered partial product302band corresponds to the multiplication of the highest ordered digit of the multiplier A[2]=8 by all three digits of the multiplicand B[2:0]=765.

As such, the three partial products can be expressed as: 1) A[0]*B[2:0] for the lowest ordered partial product302a;2) A[1]*B[2:0] for the middle ordered partial product302b; and, 3) A[2]*B[2:0] for the highest ordered partial product302c.

FIG. 3bshows a perspective for the determination of the partial products. Specifically, the calculation of each of the partial products302a,b,ccan also be viewed as a respective right-wise staircase structure much the same as discussed just above. For example, the lowest ordered partial product302acan be determined by summing over three sub-partial products304a,b,c. Here, the first sub-partial product304acorresponds to A[0]*B[0] (i.e., 4*5=20), the second sub-partial product304bcorresponds to A[0]*B[1] (i.e., 4*6=24) shifted left one digit location relative the first sub-partial product304a, and, the third sub-partial product304ccorresponds to A[0]*B[2] (i.e., 4*7=28) shifted left one digit location relative to the second sub-partial product304b.

The partial product302ais determined by adding the sub-partial products consistent with their alignment as indicated by arrows305a-d. Note that carry terms are respected as indicated by carry term306. The remaining partial products302band302care determined in like manner as observed in insets307and308.

FIG. 3cshows a flow diagram that illustrates a method of multiplication consistent with some of the principles discussed above. Partial product digits are accumulated in a storage element S320. For the recursion330of the first partial product term, the storage element S is initialized with a value of 0 for all digits320_1. A first partial product is determined by selecting a lowest ordered digit in a multiplier (A[0]) and multiplying310it with the lowest ordered digit in a multiplicand (B[0]). The lowest ordered digit in the multiplier A[0] is then multiplied311against the next higher ordered multiplicand (B[1]). The least significant digit of the two sub partial products is added with its corresponding (aligned) digit in storage element S320_1and re-stored in storage element S320_2. The pair of digits of the two sub-partial products having overlapping alignment are added 313 with their corresponding (aligned) digit of storage element S320_1. The results of addition313are kept in storage element320_2.

The lowest ordered digit in the multiplier A[0] is next multiplied314against the next higher digit in the multiplicand314(B[2)) and the result is added 315 with the highest ordered bit of sub partial product311and their corresponding (aligned) digit in storage element S. The result of addition315is re-stored in storage element S320_2. Note that a carry term is generated316with addition315.

Because the B[2] term is the highest ordered digit in the multiplicand, the highest ordered digit of sub-partial product314is added 317 to its corresponding (aligned) digit in storage element S and the carry term. At this point, the first partial product is stored in storage element S320_2. Those of ordinary skill will appreciate that various “kernels” of multiplication, alignment, addition and storage processes can be devised that are repeated for multiple additional digit locations depending on the size of the multiplicand.

With the first partial product being stored in storage element320_2, a substantially similar process as that of process330is used to calculate the second partial product A[1]*B[2:0] with the resulting accumulation of partial products being left in storage element S320_3. As with the calculation of the first partial product, for each digit in the multiplicand B, there is a multiplication with the multiplier term (A[1] in this case), the resultant is properly aligned and aligned digits of two consecutive products are added. An additional feature of the calculation of the second partial product is that its “rightwise staircase” structure is aligned one digit to the left relative to the “rightwise staircase” structure of the previous (first) partial product.

The third partial product is calculated with the same approach and the final result of the multiplication is stored in storage element320_4. Those of ordinary skill will recognize that, although only three iterations are shown (because the multiplicand only has three digits), the recursion described above can be extended to include more or less iterations depending on the size of the multiplicand.

FIGS. 4a,band5a,bpertain to an instruction set and variations thereof for implementation in a semiconductor processing unit (e.g. a processing core of a multi-core CPU). Here, two large integer values A and B are to be multiplied. In an embodiment, A and B can each be as large as 512 bits. In a further embodiment, each “digit” of A and B is viewed as a 64 bit value within the overall 512 bit structure. As such, each of A and B can be viewed as being as large as an 8 element vector where each element in the vector represents a digit, and, each digit is 64 bits.

According to this perspective, the partial product recursions take the form of A[i]*B[7:0] where A[i] represents a particular digit in the multiplicand A and B[7:0] represents each digit in the multiplier B. As described in further detail below, similar to the approach just discussed above, the multiplication of A*B is performed by determining the partial product A[i]*B[7:0] for each value of i where i represents a different digit in the multiplicand A. Also similar to the approach just discussed above, aligned digits of a same partial product recursion are added together along with a value along the same alignment position that was stored from the previously calculated partial product recursion. These and other features will be more apparent through discussion of the immediately following example.

FIG. 4ashows an instruction sequence401that calculates a partial product for the A[0] multiplier term. Here, the instruction sequence can be viewed as calculating the product of A[0]*B[j] for each of j recursions where j=0 to 7 (for a maximum sized multiplicand B). Because both the A[0] and the B[j] term corresponds to a 64 bit digit, 128 bits are allocated for the product of the two.FIG. 4ashows the right-wise stair case structure effected by the instruction sequence. Each sub-partial product is represented by a 128 bit data structure consisting of a 64 bit lower half (“Lo”) and a 64 bit upper half (“Hi”).

The instruction sequence401relies on a class of multiplication instructions that return the low half or upper half of a sub partial product A[i] *B [j] term. A first instruction411VPMUL_LO calculates the first sub partial product term (A[0] *B [0]) and returns its lower half (Lo_0) in resultant register R_Lo. Partial product terms, as opposed to sub-partial product terms, are accumulated in register S. Here, S is a vector where each element in vector S corresponds to a 64 bit digit in the accumulated partial product value contained in vector S. Instruction sequence401corresponds to the initial recursion (i.e., the recursion for the A[0] term), thus vector S is initialized beforehand with a value 0 for all digits.

The second instruction412performs aligned addition by adding the contents of R_Lo with the lowest ordered element/digit in S (S[0]=0) and re-storing it in S. Instructions411and412serve as an initial, special sequence to calculate the lowest ordered value in the recursion. A “kernel” of operation420that can be looped over multiple values of j for the first partial product calculation is presented immediately below.

The third instruction413VPMUL_HI calculates the first sub partial product term (A[0]*B[0]; j=0) and returns its higher half (Hi_0) in resultant register R_Hi. A fourth instruction VPMUL_LO414calculates the second sub partial product term (A[0]*B[1]; j=1) and returns its lower half (Lo_1) in resultant register R_Lo. A fifth instruction415performs aligned addition by adding the contents of R_Lo, R_Hi and their corresponding (aligned) element/digit in S (S[1]=0) and re-storing it in S.

Sequence413,414and415corresponds to a “kernel”420that can be looped for j=1 through 7. For example, continuing with the next j=2 incursion, a sixth instruction416VPMUL_HI calculates the second sub partial product term (A[0]*B[1]; j=1) and returns its higher half (Hi_1) in resultant register R_Hi. A seventh instruction VP_MUL417calculates the third sub partial product term (A[0]*B[2]; j=2) and returns its lower half (Lo_2) in resultant register R_Lo. An eighth instruction418performs aligned addition by adding the contents of R_Lo, R_Hi and their corresponding (aligned) element/digit in S (S[1]=0) and re-storing it in S.

The kernel can continue to loop through j=7. After the j=7 loop is performed, the digits in S have been calculated through element S[7]. A final sequence to complete the recursion for the first partial product is to execute a last VPMUL_HI instruction421which calculates the eighth sub partial product term (A[0]*B[7]; j=7) and returns its higher half (Hi_7) to R_Hi, and, execute a last instruction422that performs an aligned add 423 of the contents of R_Hi with the highest ordered digit in S (S[8]) and re-storing the result in S. At this point, S contains the first partial product.

Each subsequent partial product can then be calculated as substantially as described above. Two noteworthy features are the initial value of S will no longer be zero but rather contain an accumulation of the previously calculated partial products. Also, the alignment of each partial product needs to move one digit to the left as compared to the previously calculated partial product (similar to the alignment relationship of staircase structures inFIG. 3b).

Note that S is a nine element vector. That is, S has nine 64 bit values to represent the accumulated partial product terms. In an embodiment where the maximum vector size is 512 bits and digits of S are represented by 64 bit values, the size of S exceeds 512 bits by 128 bits. As such, two vectors S1 and S2 may be used by the instruction sequence where S1 keeps elements S[7:0] and S2 keeps S[8]. In this case, S1 is read from//written to for all instructions described above except instructions425and427which write to S2.

FIG. 5ashows another approach having a different operational pattern in the kernel. As will be described in more detail below, the repeatable kernel of the approach ofFIG. 5aincludes two ADD instructions to help accumulate terms for neighboring elements in S.

For the initial j=0 recursion, a VPMUL_Lo instruction is executed511to determine the lower half of A[0]*B[0] (Lo_0) and the resultant is stored in R_Lo, and, a VPMUL_Hi instruction is executed512to determine the upper half of A[0]*B[0] (Hi_0) and the resultant is stored in R_Hi. An ADD instruction513then adds the S[0] term (which is initially zero as is all digits of S for the initial j=0 recursion) to the R_Lo value and stored back in S[0]. Another ADD instruction514adds the S[1] term to the R_Hi value and the result is stored back in S[1].

For the next, j=1 recursion, again VPMUL_Lo and VPMUL_Hi instructions are executed515,516with respective results being stored in R_Lo and R_Hi respectively. A first subsequent ADD instruction adds 517 the contents of S[j]=S[1] to the contents of R_Lo and stores the result back in S[j]=S[1]. A second subsequent ADD instruction adds 518 the contents of S[j+1]=S[2] to the contents of R_Hi and stores the result back in S[j+1]=S[2].

Steps511through514(or515through518) correspond to a kernel that is repeated for each of the following recursions for j=2 through j=7. At the end of the j=7 cycle, each of digits S[2] through S[8] have been written to, which, corresponds to the partial product of A[0]*B[7:0]. The same sequence as described above for the A[0] multiplier is then repeated for each of A[1] through A[7]. Here, the accumulated partial product(s) of the previously determined partial product are updated/accumulated in S. The alignment of each subsequent iteration for a multiplier term should be aligned one digit to the left as compared to the alignment of the recursion performed for the preceding multiplier term.

Other recursion patterns than those presented inFIGS. 4aand 5amay be possible.FIGS. 4aand 5aalso may utilize a unique approach with respect to the handling of the carry terms of the various ADD operations. Specifically, mask vector register space may be used to handle any mathematical carries that may be ancillary to the resultant of an ADD instruction.

FIG. 4bshows a more detailed implementation of an embodiment of the kernel420ofFIG. 4a. With respect to the approach ofFIG. 4b, the ADD instructions observed therein include an additional input k which corresponds to a mask register that is used to keep carry terms. Here, any carry term to be incorporated into the addition of the ADD instruction is received through mask register k and any carry term generated from the addition is “written back” to the mask register k. That is, mask register k is specified as containing both a source operand430and resultant431. As envisioned, the source operand k430holds the carry term from the ADD instruction of the immediately preceding recursion. The carry term is added into the addition performed by ADD instruction432. Any carry term that is generated from the addition performed by ADD instruction432is stored back into k as the resultant carry term431for use by the ADD instruction of the immediately following recursion.

A mathematical artifact of adding three operands is that the carry term may be larger than one bit. For example, if three 64 bit operands are added, the result may be 66 bits wide. As such, in this case, the carry term may be two bits rather than one bit. In an embodiment, rather than numerically add these carry terms in the ADD instruction of the next recursion, the carry terms are simply “written” as the least significant bits of the summation resultant. That is, the logic circuitry that implements ADD instruction432is designed to write the contents of the k source operand430as the lowest ordered bits of the ADD resultant (not the carry resultant431) that is stored in S.

The approach ofFIG. 5adoes not utilize a “three input operand” ADD instruction. Instead, a two input operand ADD instruction is used. Nevertheless, three terms are being added in each recursion. As such, the mathematical artifact referred to just above still applies. That is, at least for 64 bit digits, the addition performed to completely calculate each S[j] term may mathematically generate a two bit carry term. In order to address this feature, two different carry terms k0, k1 are separately tracked in mask register space as observed in the more detailed recursion flow ofFIG. 5b.

Essentially, as any addition may generate a carry term for the “next addition to the left”, as long as carry terms are forwarded in this manner the mathematical results will be accurate. Careful observation of the instruction flow reveals that both of the resultant k0, k1 carry terms are used as source operands for their respective “next addition to the left”.

Note that in the case where the instruction sequences ofFIGS. 4a, 4b, 5a, 5bare performed on a vector processor having 512 bit input operands which can be granularized to eight elements of 64 bits per element, the instruction sequences ofFIGS. 4a, 4b, 5aand 5bare capable of supporting a procedure that simultaneously multiplies eight large multiplicands by eight respective large multipliers. That is, for example, a first input vector may be created having 8 64 bit elements where each element corresponds to a specific digit in eight different multiplicands, and, a second input input vector may be created having 8 64 bit elements where each element corresponds to a specific digit in eight different multipliers. With these and similarly structured vectors, the operations observed inFIGS. 4a, 4b, 5aand 5bcan simultaneously multiply eight multiplicand and multiplier pairs.

FIG. 4cshows a logic design for an execution unit that can perform the VPMUL_LO and VPMUL_HI instructions as described above. The logic design ofFIG. 4ccan be used to support the multiplication instructions ofFIG. 4a, 4b, 5aor5b. As observed inFIG. 4c, a multiplier450receives a first input operand from a first input operand register451and receives a second input operand from a second input operand register452. Input operand registers451,452may be part of vector register space, an output of a data fetch stage of an instruction execution pipeline, or, an input of the execution unit. Multiplexer logic circuitry453selects either the low half or the right half of the full multiplication output. Whether the low half or right half is selected is determined from the instruction fetch and decode stage of the instruction execution pipeline (specifically, the decoding of the instruction opcode that specifies whether the instruction is VPMUL_LO or VPMUL_HI).

The selected half is presented to write mask circuitry454. A mask vector stored in mask vector register455is applied as an input to write mask circuitry454. Mask write circuitry454applies the mask to the selected half and the result is written to resultant register456. Resultant register456may be in vector register space or at the output of the execution unit. Additional features may be included to the base design ofFIG. 4csuch as support for different “digit” bit widths. In one embodiment, the granularity of the multiplier, the selection logic and the write mask circuitry is such that the digit width can be any size of 2nprovided it is equal to or less than maximum vector input operand size (e.g., 512 bits). For example, if n=4, the digit width is 16 bits which corresponds to a capability of simultaneously multiplying 32 different multiplicands and respective multipliers for a 512 bit input operand size.

FIG. 4dshows a logic design for a three input operand ADD instruction that uses mask register space to handle carry terms. The logic design ofFIG. 4dcan be used by an execution unit that supports the ADD instructions ofFIGS. 4aand 4b. As observed inFIG. 4d, three input operands are respectively provided to an adder circuit464by way of input operand registers461,462and463. Input operand registers461,462,463may be from vector register space, an output of a data fetch stage of an instruction execution pipeline or an input of the execution unit. A mask input register465receives, potentially, mask vectors for other instructions supported by the execution unit. Consequently, outputs of the mask input register465flow to write mask circuitry466. The mask input register465may be part of vector register space, an output of a data fetch stage or an input of the execution unit. To support the three input ADD instruction, however, the mask register465also supplies carry terms that are provided to the carry input of the adder464. Alternatively, as described above, signal lines carrying the carry input from register465may be directly routed to the lowest ordered bits of the resultant. A carry output from the adder464is provided to an output mask register467whose contents may write over whatever register sourced the carry terms in register465.

FIG. 5cshows a logic design for a two input operand ADD instruction that uses mask register space to handle carry terms. The logic design ofFIG. 5ccan be used by an execution unit that supports the ADD instructions ofFIGS. 5aand 5b. As observed inFIG. 5c, two input operands are respectively provided to an adder circuit564by way of input operand registers562and563. Input operand registers562,563may be from vector register space, an output of a data fetch stage of an instruction execution pipeline or an input of the execution unit. A mask input register565receives, potentially, mask vectors for other instructions supported by the execution unit. Consequently, outputs of the mask input register565flow to write mask circuitry566. The mask input register565may be part of vector register space, an output of a data fetch stage or an input of the execution unit. To support the two input ADD instruction, however, the mask register565also supplies carry terms that are provided to the carry input of the adder564. A carry output from the adder564is provided to an output mask register567whose contents may write over whatever register sourced the carry terms in register565.

Exemplary Instruction Formats

Embodiments of the instruction(s) described herein may be embodied in different formats. For example, the instruction(s) described herein may be embodied as a VEX, generic vector friendly, or other format. Details of VEX and a generic vector friendly format are discussed below. Additionally, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instruction(s) may be executed on such systems, architectures, and pipelines, but are not limited to those detailed.

VEX Instruction Format

VEX encoding allows instructions to have more than two operands, and allows SIMD vector registers to be longer than 128 bits. The use of a VEX prefix provides for three-operand (or more) syntax. For example, previous two-operand instructions performed operations such as A=A+B, which overwrites a source operand. The use of a VEX prefix enables operands to perform nondestructive operations such as A=B+C.

FIG. 6Aillustrates an exemplary AVX instruction format including a VEX prefix602, real opcode field630, Mod RIM byte640, SIB byte650, displacement field662, and IMM8672.FIG. 6Billustrates which fields fromFIG. 6Amake up a full opcode field674and a base operation field642.FIG. 6Cillustrates which fields fromFIG. 6Amake up a register index field644.

VEX Prefix (Bytes 0-2)602is encoded in a three-byte form. The first byte is the Format Field640(VEX Byte 0, bits [7:0]), which contains an explicit C4 byte value (the unique value used for distinguishing the C4 instruction format). The second-third bytes (VEX Bytes 1-2) include a number of bit fields providing specific capability. Specifically, REX field605(VEX Byte 1, bits [7-5]) consists of a VEX.R bit field (VEX Byte 1, bit [7]-R), VEX.X bit field (VEX byte 1, bit [6]-X), and VEX.B bit field (VEX byte 1, bit[5]-B). Other fields of the instructions encode the lower three bits of the register indexes as is known in the art (rrr, xxx, and bbb), so that Rrrr, Xxxx, and Bbbb may be formed by adding VEX.R, VEX.X, and VEX.B. Opcode map field615(VEX byte 1, bits [4:0]-mmmmm) includes content to encode an implied leading opcode byte. W Field664(VEX byte 2, bit [7]-W)—is represented by the notation VEX.W, and provides different functions depending on the instruction. The role of VEX.vvvv620(VEX Byte 2, bits [6:3]-vvvv) may include the following: 1) VEX.vvvv encodes the first source register operand, specified in inverted (1s complement) form and is valid for instructions with 2 or more source operands; 2) VEX.vvvv encodes the destination register operand, specified in is complement form for certain vector shifts; or 3) VEX.vvvv does not encode any operand, the field is reserved and should contain 1111b. If VEX.L668Size field (VEX byte 2, bit [2]-L)=0, it indicates 128 bit vector; if VEX.L=1, it indicates 256 bit vector. Prefix encoding field625(VEX byte 2, bits [1:0]-pp) provides additional bits for the base operation field.

Real Opcode Field630(Byte 3) is also known as the opcode byte. Part of the opcode is specified in this field.

MOD R/M Field640(Byte 4) includes MOD field642(bits [7-6]), Reg field644(bits [5-3]), and R/M field646(bits [2-0]). The role of Reg field644may include the following: encoding either the destination register operand or a source register operand (the rrr of Rrrr), or be treated as an opcode extension and not used to encode any instruction operand. The role of R/M field646may include the following: encoding the instruction operand that references a memory address, or encoding either the destination register operand or a source register operand.

Scale, Index, Base (SIB)—The content of Scale field650(Byte 5) includes SS652(bits [7-6]), which is used for memory address generation. The contents of SIB.xxx654(bits [5-3]) and SIB.bbb656(bits [2-0]) have been previously referred to with regard to the register indexes Xxxx and Bbbb.

The Displacement Field662and the immediate field (IMM8)672contain address data.

Generic Vector Friendly Instruction Format

FIGS. 7A-7Bare block diagrams illustrating a generic vector friendly instruction format and instruction templates thereof according to embodiments of the invention.FIG. 7Ais a block diagram illustrating a generic vector friendly instruction format and class A instruction templates thereof according to embodiments of the invention; whileFIG. 7Bis a block diagram illustrating the generic vector friendly instruction format and class B instruction templates thereof according to embodiments of the invention. Specifically, a generic vector friendly instruction format700for which are defined class A and class B instruction templates, both of which include no memory access705instruction templates and memory access720instruction templates. The term generic in the context of the vector friendly instruction format refers to the instruction format not being tied to any specific instruction set.

The class A instruction templates inFIG. 7Ainclude: 1) within the no memory access705instruction templates there is shown a no memory access, full round control type operation710instruction template and a no memory access, data transform type operation715instruction template; and 2) within the memory access720instruction templates there is shown a memory access, temporal725instruction template and a memory access, non-temporal730instruction template. The class B instruction templates inFIG. 7Binclude: 1) within the no memory access705instruction templates there is shown a no memory access, write mask control, partial round control type operation712instruction template and a no memory access, write mask control, vsize type operation717instruction template; and 2) within the memory access720instruction templates there is shown a memory access, write mask control727instruction template.

The generic vector friendly instruction format700includes the following fields listed below in the order illustrated inFIGS. 7A-7B. In conjunction with the discussions above ofFIGS. 4a,b,c,dand5,a,b,cin an embodiment, referring to the format details provided below inFIGS. 7A-Band8, either a non memory access instruction type705or a memory access instruction type720may be utilized. Addresses for the read mask(s), input vector operand(s) and destination may be identified in register address field744described below. In a further embodiment, the write mask is specified in write mask field770.

Base operation field742—its content distinguishes different base operations.

Modifier field746—its content distinguishes occurrences of instructions in the generic vector instruction format that specify memory access from those that do not; that is, between no memory access705instruction templates and memory access720instruction templates. Memory access operations read and/or write to the memory hierarchy (in some cases specifying the source and/or destination addresses using values in registers), while non-memory access operations do not (e.g., the source and destinations are registers). While in one embodiment this field also selects between three different ways to perform memory address calculations, alternative embodiments may support more, less, or different ways to perform memory address calculations.

Augmentation operation field750—its content distinguishes which one of a variety of different operations to be performed in addition to the base operation. This field is context specific. In one embodiment of the invention, this field is divided into a class field768, an alpha field752, and a beta field754. The augmentation operation field750allows common groups of operations to be performed in a single instruction rather than 2, 3, or 4 instructions.

Scale field760—its content allows for the scaling of the index field's content for memory address generation (e.g., for address generation that uses 2scale*index+base).

Displacement Field762A—its content is used as part of memory address generation (e.g., for address generation that uses 2scale*index+base+displacement).

Displacement Factor Field762B (note that the juxtaposition of displacement field762A directly over displacement factor field762B indicates one or the other is used)—its content is used as part of address generation; it specifies a displacement factor that is to be scaled by the size of a memory access (N)—where N is the number of bytes in the memory access (e.g., for address generation that uses 2scale*index+base+scaled displacement). Redundant low-order bits are ignored and hence, the displacement factor field's content is multiplied by the memory operands total size (N) in order to generate the final displacement to be used in calculating an effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field774(described later herein) and the data manipulation field754C. The displacement field762A and the displacement factor field762B are optional in the sense that they are not used for the no memory access705instruction templates and/or different embodiments may implement only one or none of the two.

Class field768—its content distinguishes between different classes of instructions. With reference toFIGS. 7A-B, the contents of this field select between class A and class B instructions. InFIGS. 7A-B, rounded corner squares are used to indicate a specific value is present in a field (e.g., class A768A and class B768B for the class field768respectively inFIGS. 7A-B).

Instruction Templates of Class A

In the case of the non-memory access705instruction templates of class A, the alpha field752is interpreted as an RS field752A, whose content distinguishes which one of the different augmentation operation types are to be performed (e.g., round752A.1and data transform752A.2are respectively specified for the no memory access, round type operation710and the no memory access, data transform type operation715instruction templates), while the beta field754distinguishes which of the operations of the specified type is to be performed. In the no memory access705instruction templates, the scale field760, the displacement field762A, and the displacement scale filed762B are not present.

In the no memory access full round control type operation710instruction template, the beta field754is interpreted as a round control field754A, whose content(s) provide static rounding. While in the described embodiments of the invention the round control field754A includes a suppress all floating point exceptions (SAE) field756and a round operation control field758, alternative embodiments may support may encode both these concepts into the same field or only have one or the other of these concepts/fields (e.g., may have only the round operation control field758).

SAE field756—its content distinguishes whether or not to disable the exception event reporting; when the SAE field's756content indicates suppression is enabled, a given instruction does not report any kind of floating-point exception flag and does not raise any floating point exception handler.

In the no memory access data transform type operation715instruction template, the beta field754is interpreted as a data transform field754B, whose content distinguishes which one of a number of data transforms is to be performed (e.g., no data transform, swizzle, broadcast).

In the case of a memory access720instruction template of class A, the alpha field752is interpreted as an eviction hint field752B, whose content distinguishes which one of the eviction hints is to be used (inFIG. 7A, temporal752B.1and non-temporal752B.2are respectively specified for the memory access, temporal725instruction template and the memory access, non-temporal730instruction template), while the beta field754is interpreted as a data manipulation field754C, whose content distinguishes which one of a number of data manipulation operations (also known as primitives) is to be performed (e.g., no manipulation; broadcast; up conversion of a source; and down conversion of a destination). The memory access720instruction templates include the scale field760, and optionally the displacement field762A or the displacement scale field762B.

Memory Access Instruction Templates—Temporal

Memory Access Instruction Templates—Non-Temporal

Instruction Templates of Class B

In the case of the instruction templates of class B, the alpha field752is interpreted as a write mask control (Z) field752C, whose content distinguishes whether the write masking controlled by the write mask field770should be a merging or a zeroing.

In the case of the non-memory access705instruction templates of class B, part of the beta field754is interpreted as an RL field757A, whose content distinguishes which one of the different augmentation operation types are to be performed (e.g., round757A.1and vector length (VSIZE)757A.2are respectively specified for the no memory access, write mask control, partial round control type operation712instruction template and the no memory access, write mask control, VSIZE type operation717instruction template), while the rest of the beta field754distinguishes which of the operations of the specified type is to be performed. In the no memory access705instruction templates, the scale field760, the displacement field762A, and the displacement scale filed762B are not present.

In the no memory access, write mask control, partial round control type operation710instruction template, the rest of the beta field754is interpreted as a round operation field759A and exception event reporting is disabled (a given instruction does not report any kind of floating-point exception flag and does not raise any floating point exception handler).

Round operation control field759A—just as round operation control field758, its content distinguishes which one of a group of rounding operations to perform (e.g., Round-up, Round-down, Round-towards-zero and Round-to-nearest). Thus, the round operation control field759A allows for the changing of the rounding mode on a per instruction basis. In one embodiment of the invention where a processor includes a control register for specifying rounding modes, the round operation control field's750content overrides that register value.

In the no memory access, write mask control, VSIZE type operation717instruction template, the rest of the beta field754is interpreted as a vector length field759B, whose content distinguishes which one of a number of data vector lengths is to be performed on (e.g., 128, 256, or 512 byte).

In the case of a memory access720instruction template of class B, part of the beta field754is interpreted as a broadcast field757B, whose content distinguishes whether or not the broadcast type data manipulation operation is to be performed, while the rest of the beta field754is interpreted the vector length field759B. The memory access720instruction templates include the scale field760, and optionally the displacement field762A or the displacement scale field762B.

With regard to the generic vector friendly instruction format700, a full opcode field774is shown including the format field740, the base operation field742, and the data element width field764. While one embodiment is shown where the full opcode field774includes all of these fields, the full opcode field774includes less than all of these fields in embodiments that do not support all of them. The full opcode field774provides the operation code (opcode).

The augmentation operation field750, the data element width field764, and the write mask field770allow these features to be specified on a per instruction basis in the generic vector friendly instruction format.

Exemplary Specific Vector Friendly Instruction Format

FIG. 8is a block diagram illustrating an exemplary specific vector friendly instruction format according to embodiments of the invention.FIG. 8shows a specific vector friendly instruction format800that is specific in the sense that it specifies the location, size, interpretation, and order of the fields, as well as values for some of those fields. The specific vector friendly instruction format800may be used to extend the x86 instruction set, and thus some of the fields are similar or the same as those used in the existing x86 instruction set and extension thereof (e.g., AVX). This format remains consistent with the prefix encoding field, real opcode byte field, MOD R/M field, SIB field, displacement field, and immediate fields of the existing x86 instruction set with extensions. The fields fromFIG. 7into which the fields fromFIG. 8map are illustrated.

It should be understood that, although embodiments of the invention are described with reference to the specific vector friendly instruction format800in the context of the generic vector friendly instruction format700for illustrative purposes, the invention is not limited to the specific vector friendly instruction format800except where claimed. For example, the generic vector friendly instruction format700contemplates a variety of possible sizes for the various fields, while the specific vector friendly instruction format800is shown as having fields of specific sizes. By way of specific example, while the data element width field764is illustrated as a one bit field in the specific vector friendly instruction format800, the invention is not so limited (that is, the generic vector friendly instruction format700contemplates other sizes of the data element width field764).

The generic vector friendly instruction format700includes the following fields listed below in the order illustrated inFIG. 8A.

Format Field740(EVEX Byte 0, bits [7:0])—the first byte (EVEX Byte 0) is the format field740and it contains 0x62 (the unique value used for distinguishing the vector friendly instruction format in one embodiment of the invention).

The second-fourth bytes (EVEX Bytes 1-3) include a number of bit fields providing specific capability.

Data element width field764(EVEX byte 2, bit [7]-W)—is represented by the notation EVEX.W. EVEX.W is used to define the granularity (size) of the datatype (either 32-bit data elements or 64-bit data elements).

EVEX.U768Class field (EVEX byte 2, bit [2]-U)—If EVEX.U=0, it indicates class A or EVEX.U0; if EVEX.U=1, it indicates class B or EVEX.U1.

Alpha field752(EVEX byte 3, bit [7]-EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.write mask control, and EVEX.N; also illustrated with α)—as previously described, this field is context specific.

Real Opcode Field830(Byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

MOD R/M Field840(Byte 5) includes MOD field842, Reg field844, and R/M field846. As previously described, the MOD field's842content distinguishes between memory access and non-memory access operations. The role of Reg field844can be summarized to two situations: encoding either the destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand. The role of R/M field846may include the following: encoding the instruction operand that references a memory address, or encoding either the destination register operand or a source register operand.

Scale, Index, Base (SIB) Byte (Byte 6)—As previously described, the scale field's750content is used for memory address generation. SIB.xxx854and SIB.bbb856—the contents of these fields have been previously referred to with regard to the register indexes Xxxx and Bbbb.

Displacement field762A (Bytes 7-10)—when MOD field842contains 10, bytes 7-10 are the displacement field762A, and it works the same as the legacy 32-bit displacement (disp32) and works at byte granularity.

Immediate field772operates as previously described.

Full Opcode Field

FIG. 8Bis a block diagram illustrating the fields of the specific vector friendly instruction format800that make up the full opcode field774according to one embodiment of the invention. Specifically, the full opcode field774includes the format field740, the base operation field742, and the data element width (W) field764. The base operation field742includes the prefix encoding field825, the opcode map field815, and the real opcode field830.

Register Index Field

FIG. 8Cis a block diagram illustrating the fields of the specific vector friendly instruction format800that make up the register index field744according to one embodiment of the invention. Specifically, the register index field744includes the REX field805, the REX′ field810, the MODR/M.reg field844, the MODR/M.r/m field846, the VVVV field820, xxx field854, and the bbb field856.

Augmentation Operation Field

FIG. 8Dis a block diagram illustrating the fields of the specific vector friendly instruction format800that make up the augmentation operation field750according to one embodiment of the invention. When the class (U) field768contains 0, it signifies EVEX.U0 (class A768A); when it contains 1, it signifies EVEX.U1 (class B768B). When U=0 and the MOD field842contains 11 (signifying a no memory access operation), the alpha field752(EVEX byte 3, bit [7]-EH) is interpreted as the rs field752A. When the rs field752A contains a 1 (round752A.1), the beta field754(EVEX byte 3, bits [6:4]-SSS) is interpreted as the round control field754A. The round control field754A includes a one bit SAE field756and a two bit round operation field758. When the rs field752A contains a 0 (data transform752A.2), the beta field754(EVEX byte 3, bits [6:4]-SSS) is interpreted as a three bit data transform field754B. When U=0 and the MOD field842contains 00, 01, or 10 (signifying a memory access operation), the alpha field752(EVEX byte 3, bit [7]-EH) is interpreted as the eviction hint (EH) field752B and the beta field754(EVEX byte 3, bits [6:4]-SSS) is interpreted as a three bit data manipulation field754C.

When U=1, the alpha field752(EVEX byte 3, bit [7]-EH) is interpreted as the write mask control (Z) field752C. When U=1 and the MOD field842contains 11 (signifying a no memory access operation), part of the beta field754(EVEX byte 3, bit [4]-S0) is interpreted as the RL field757A; when it contains a 1 (round757A.1) the rest of the beta field754(EVEX byte 3, bit [6-5]-S2-1) is interpreted as the round operation field759A, while when the RL field757A contains a 0 (VSIZE757.A2) the rest of the beta field754(EVEX byte 3, bit [6-5]-S2-1) is interpreted as the vector length field759B (EVEX byte 3, bit [6-5]-L1-0). When U=1 and the MOD field842contains 00, 01, or 10 (signifying a memory access operation), the beta field754(EVEX byte 3, bits [6:4]-SSS) is interpreted as the vector length field759B (EVEX byte 3, bit [6-5]-L1-0) and the broadcast field757B (EVEX byte 3, bit [4]-B).

Exemplary Register Architecture

FIG. 9is a block diagram of a register architecture900according to one embodiment of the invention. In the embodiment illustrated, there are 32 vector registers910that are 512 bits wide; these registers are referenced as zmm0 through zmm31. The lower order 256 bits of the lower 16 zmm registers are overlaid on registers ymm0-16. The lower order 128 bits of the lower 16 zmm registers (the lower order 128 bits of the ymm registers) are overlaid on registers xmm0-15. The specific vector friendly instruction format800operates on these overlaid register file as illustrated in the below tables.

In other words, the vector length field759B selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the preceding length; and instructions templates without the vector length field759B operate on the maximum vector length. Further, in one embodiment, the class B instruction templates of the specific vector friendly instruction format800operate on packed or scalar single/double-precision floating point data and packed or scalar integer data. Scalar operations are operations performed on the lowest order data element position in an zmm/ymm/xmm register; the higher order data element positions are either left the same as they were prior to the instruction or zeroed depending on the embodiment.

Write mask registers915—in the embodiment illustrated, there are 8 write mask registers (k0 through k7), each 64 bits in size. In an alternate embodiment, the write mask registers915are 16 bits in size. As previously described, in one embodiment of the invention, the vector mask register k0 cannot be used as a write mask; when the encoding that would normally indicate k0 is used for a write mask, it selects a hardwired write mask of 0xFFFF, effectively disabling write masking for that instruction.

Exemplary Core Architectures

In-Order and Out-of-Order Core Block Diagram

InFIG. 10A, a processor pipeline1000includes a fetch stage1002, a length decode stage1004, a decode stage1006, an allocation stage1008, a renaming stage1010, a scheduling (also known as a dispatch or issue) stage1012, a register read/memory read stage1014, an execute stage1016, a write back/memory write stage1018, an exception handling stage1022, and a commit stage1024.

FIG. 10Bshows processor core1090including a front end unit1030coupled to an execution engine unit1050, and both are coupled to a memory unit1070. The core1090may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core1090may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like.

The front end unit1030includes a branch prediction unit1032coupled to an instruction cache unit1034, which is coupled to an instruction translation lookaside buffer (TLB)1036, which is coupled to an instruction fetch unit1038, which is coupled to a decode unit1040. The decode unit1040(or decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decode unit1040may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. In one embodiment, the core1090includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in decode unit1040or otherwise within the front end unit1030). The decode unit1040is coupled to a rename/allocator unit1052in the execution engine unit1050.

The execution engine unit1050includes the rename/allocator unit1052coupled to a retirement unit1054and a set of one or more scheduler unit(s)1056. The scheduler unit(s)1056represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s)1056is coupled to the physical register file(s) unit(s)1058. Each of the physical register file(s) units1058represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register file(s) unit1058comprises a vector registers unit, a write mask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) unit(s)1058is overlapped by the retirement unit1054to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.). The retirement unit1054and the physical register file(s) unit(s)1058are coupled to the execution cluster(s)1060. The execution cluster(s)1060includes a set of one or more execution units1062and a set of one or more memory access units1064. The execution units1062may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. The scheduler unit(s)1056, physical register file(s) unit(s)1058, and execution cluster(s)1060are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s)1064). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

The set of memory access units1064is coupled to the memory unit1070, which includes a data TLB unit1072coupled to a data cache unit1074coupled to a level 2 (L2) cache unit1076. In one exemplary embodiment, the memory access units1064may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit1072in the memory unit1070. The instruction cache unit1034is further coupled to a level 2 (L2) cache unit1076in the memory unit1070. The L2 cache unit1076is coupled to one or more other levels of cache and eventually to a main memory.

By way of example, the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline1000as follows: 1) the instruction fetch1038performs the fetch and length decoding stages1002and1004; 2) the decode unit1040performs the decode stage1006; 3) the rename/allocator unit1052performs the allocation stage1008and renaming stage1010; 4) the scheduler unit(s)1056performs the schedule stage1012; 5) the physical register file(s) unit(s)1058and the memory unit1070perform the register read/memory read stage1014; the execution cluster1060perform the execute stage1016; 6) the memory unit1070and the physical register file(s) unit(s)1058perform the write back/memory write stage1018; 7) various units may be involved in the exception handling stage1022; and 8) the retirement unit1054and the physical register file(s) unit(s)1058perform the commit stage1024.

The core1090may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.), including the instruction(s) described herein. In one embodiment, the core1090includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2, and/or some form of the generic vector friendly instruction format (U=0 and/or U=1) previously described), thereby allowing the operations used by many multimedia applications to be performed using packed data.

Specific Exemplary in-Order Core Architecture

FIG. 11Ais a block diagram of a single processor core, along with its connection to the on-die interconnect network1102and with its local subset of the Level 2 (L2) cache1104, according to embodiments of the invention. In one embodiment, an instruction decoder1100supports the x86 instruction set with a packed data instruction set extension. An L1 cache1106allows low-latency accesses to cache memory into the scalar and vector units. While in one embodiment (to simplify the design), a scalar unit1108and a vector unit1110use separate register sets (respectively, scalar registers1112and vector registers1114) and data transferred between them is written to memory and then read back in from a level 1 (L1) cache1106, alternative embodiments of the invention may use a different approach (e.g., use a single register set or include a communication path that allow data to be transferred between the two register files without being written and read back).

FIG. 11Bis an expanded view of part of the processor core inFIG. 11Aaccording to embodiments of the invention.FIG. 11Bincludes an L1 data cache1106A part of the L1 cache1104, as well as more detail regarding the vector unit1110and the vector registers1114. Specifically, the vector unit1110is a 16-wide vector processing unit (VPU) (see the 16-wide ALU1128), which executes one or more of integer, single-precision float, and double-precision float instructions. The VPU supports swizzling the register inputs with swizzle unit1120, numeric conversion with numeric convert units1122A-B, and replication with replication unit1124on the memory input. Write mask registers1126allow predicating resulting vector writes.

Processor with Integrated Memory Controller and Graphics

FIG. 12is a block diagram of a processor1200that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to embodiments of the invention. The solid lined boxes inFIG. 12illustrate a processor1200with a single core1202A, a system agent1210, a set of one or more bus controller units1216, while the optional addition of the dashed lined boxes illustrates an alternative processor1200with multiple cores1202A-N, a set of one or more integrated memory controller unit(s)1214in the system agent unit1210, and special purpose logic1208.

The memory hierarchy includes one or more levels of cache within the cores, a set or one or more shared cache units1206, and external memory (not shown) coupled to the set of integrated memory controller units1214. The set of shared cache units1206may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof. While in one embodiment a ring based interconnect unit1212interconnects the integrated graphics logic1208, the set of shared cache units1206, and the system agent unit1210/integrated memory controller unit(s)1214, alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, coherency is maintained between one or more cache units1206and cores1202-A-N.

In some embodiments, one or more of the cores1202A-N are capable of multi-threading. The system agent1210includes those components coordinating and operating cores1202A-N. The system agent unit1210may include for example a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed for regulating the power state of the cores1202A-N and the integrated graphics logic1208. The display unit is for driving one or more externally connected displays.

Exemplary Computer Architectures

Referring now toFIG. 13, shown is a block diagram of a system1300in accordance with one embodiment of the present invention. The system1300may include one or more processors1310,1315, which are coupled to a controller hub1320. In one embodiment the controller hub1320includes a graphics memory controller hub (GMCH)1390and an Input/Output Hub (IOH)1350(which may be on separate chips); the GMCH1390includes memory and graphics controllers to which are coupled memory1340and a coprocessor1345; the IOH1350is couples input/output (I/O) devices1360to the GMCH1390. Alternatively, one or both of the memory and graphics controllers are integrated within the processor (as described herein), the memory1340and the coprocessor1345are coupled directly to the processor1310, and the controller hub1320in a single chip with the IOH1350.

The optional nature of additional processors1315is denoted inFIG. 13with broken lines. Each processor1310,1315may include one or more of the processing cores described herein and may be some version of the processor1200.

The memory1340may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one embodiment, the controller hub1320communicates with the processor(s)1310,1315via a multi-drop bus, such as a frontside bus (FSB), point-to-point interface such as QuickPath Interconnect (QPI), or similar connection1395.

In one embodiment, the coprocessor1345is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one embodiment, controller hub1320may include an integrated graphics accelerator.

There can be a variety of differences between the physical resources1310,1315in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like.

In one embodiment, the processor1310executes instructions that control data processing operations of a general type. Embedded within the instructions may be coprocessor instructions. The processor1310recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor1345. Accordingly, the processor1310issues these coprocessor instructions (or control signals representing coprocessor instructions) on a coprocessor bus or other interconnect, to coprocessor1345. Coprocessor(s)1345accept and execute the received coprocessor instructions.

Referring now toFIG. 14, shown is a block diagram of a first more specific exemplary system1400in accordance with an embodiment of the present invention. As shown inFIG. 14, multiprocessor system1400is a point-to-point interconnect system, and includes a first processor1470and a second processor1480coupled via a point-to-point interconnect1450. Each of processors1470and1480may be some version of the processor1200. In one embodiment of the invention, processors1470and1480are respectively processors1310and1315, while coprocessor1438is coprocessor1345. In another embodiment, processors1470and1480are respectively processor1310coprocessor1345.

Processors1470and1480are shown including integrated memory controller (IMC) units1472and1482, respectively. Processor1470also includes as part of its bus controller units point-to-point (P-P) interfaces1476and1478; similarly, second processor1480includes P-P interfaces1486and1488. Processors1470,1480may exchange information via a point-to-point (P-P) interface1450using P-P interface circuits1478,1488. As shown inFIG. 14, IMCs1472and1482couple the processors to respective memories, namely a memory1432and a memory1434, which may be portions of main memory locally attached to the respective processors.

Processors1470,1480may each exchange information with a chipset1490via individual P-P interfaces1452,1454using point to point interface circuits1476,1494,1486,1498. Chipset1490may optionally exchange information with the coprocessor1438via a high-performance interface1439. In one embodiment, the coprocessor1438is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.

Chipset1490may be coupled to a first bus1416via an interface1496. In one embodiment, first bus1416may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present invention is not so limited.

As shown inFIG. 14, various I/O devices1414may be coupled to first bus1416, along with a bus bridge1418which couples first bus1416to a second bus1420. In one embodiment, one or more additional processor(s)1415, such as coprocessors, high-throughput MIC processors, GPGPU's, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus1416. In one embodiment, second bus1420may be a low pin count (LPC) bus. Various devices may be coupled to a second bus1420including, for example, a keyboard and/or mouse1422, communication devices1427and a storage unit1428such as a disk drive or other mass storage device which may include instructions/code and data1430, in one embodiment. Further, an audio I/O1424may be coupled to the second bus1420. Note that other architectures are possible. For example, instead of the point-to-point architecture ofFIG. 14, a system may implement a multi-drop bus or other such architecture.

Referring now toFIG. 15, shown is a block diagram of a second more specific exemplary system1500in accordance with an embodiment of the present invention. Like elements inFIGS. 14 and 15bear like reference numerals, and certain aspects ofFIG. 14have been omitted fromFIG. 15in order to avoid obscuring other aspects ofFIG. 15.

FIG. 15illustrates that the processors1470,1480may include integrated memory and I/O control logic (“CL”)1472and1482, respectively. Thus, the CL1472,1482include integrated memory controller units and include I/O control logic.FIG. 15illustrates that not only are the memories1432,1434coupled to the CL1472,1482, but also that I/O devices1514are also coupled to the control logic1472,1482. Legacy I/O devices1515are coupled to the chipset1490.

Referring now toFIG. 16, shown is a block diagram of a SoC1600in accordance with an embodiment of the present invention. Similar elements inFIG. 12bear like reference numerals. Also, dashed lined boxes are optional features on more advanced SoCs. InFIG. 16, an interconnect unit(s)1602is coupled to: an application processor1610which includes a set of one or more cores202A-N and shared cache unit(s)1206; a system agent unit1210; a bus controller unit(s)1216; an integrated memory controller unit(s)1214; a set or one or more coprocessors1620which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an static random access memory (SRAM) unit1630; a direct memory access (DMA) unit1632; and a display unit1640for coupling to one or more external displays. In one embodiment, the coprocessor(s)1620include a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like.