Systems, apparatuses, and methods for fused multiply add
Patent Information
- Authority / Receiving Office
- TW · TW
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2017-09-04
- Publication Date
- 2023-03-16
Smart Images
Figure TWG2TA000901192_001 
Figure TWG2TA000901192_002 
Figure TWG2TA000901192_003
Abstract
Description
[Technical Field]
[0001] The field of the present invention generally relates to computer processor architecture, and more specifically, to instructions that, when executed, lead to specific results. [Previous Technology]
[0002] A common operation in linear algebra is multiplication-accumulation (e.g., c = c + a * b). Multiplication-accumulation is often a suboperation in an operation stream, such as the dot product of two vectors, or a single product of rows and columns in matrix multiplication. For example,
[0002] C=0
[0002] Regarding (I)
[0002] C+=A[I]*B[I] [Simplified Explanation of the Diagram]
[0003] The invention is illustrated in the accompanying drawings by way of example rather than limitation, wherein like reference numerals denote similar elements, and wherein:
[0004] Figure 1 illustrates an exemplary execution of a fused multiplication-accumulation instruction using operands of different sizes according to an embodiment;
[0005] Figure 2 shows a SIMD implementation of the power-size according to Embodiment 2, wherein the input size used by the accumulator is larger than the input size of the multiplier;
[0006] Figure 3 illustrates an embodiment of hardware for processing instructions such as fused multiplication-accumulation instructions;
[0007] Figure 4 illustrates an embodiment of a method executed by a processor to process fused multiply-accumulate instructions;
[0008] Figure 5 illustrates an embodiment of a subset of the execution of fused multiplication and accumulation;
[0009] Figure 6 illustrates an embodiment of virtual code used to execute this instruction in hardware;
[0010] Figure 7 illustrates an embodiment of a subset of the execution of fused multiplication and accumulation;
[0011] Figure 8 illustrates an embodiment of virtual code used to execute this instruction in hardware;
[0012] Figure 9 illustrates an embodiment of a subset of the execution of fused multiplication and accumulation;
[0013] Figure 10 illustrates an embodiment of virtual code for executing this instruction in hardware;
[0014] Figure 11 illustrates an embodiment of a subset of the execution of fused multiplication accumulation;
[0015] Figure 12 illustrates an embodiment of virtual code for executing this instruction in hardware;
[0016] Figure 13A is a block diagram illustrating a general vector-friendly instruction format and its category A instruction template according to an embodiment of the present invention;
[0017] Figure 13B is a block diagram illustrating a general vector friendly instruction format and its category B instruction template according to an embodiment of the present invention;
[0018] FIG14A is a block diagram illustrating an exemplary specific vector friendly instruction format according to an embodiment of the present invention;
[0019] Figure 14B is a block diagram showing a field of a specific vector-friendly instruction format constituting a complete operation code field according to an embodiment of the present invention;
[0020] Figure 14C is a block diagram showing a field of a specific vector-friendly instruction format constituting a register index field according to an embodiment of the present invention;
[0021] FIG14D is a block diagram showing a field of a specific vector-friendly instruction format constituting an extended operation field according to an embodiment of the present invention;
[0022] Figure 15 is a block diagram of a temporary register architecture according to an embodiment of the present invention;
[0023] FIG16A is a block diagram illustrating both an exemplary sequential pipeline and an exemplary register renaming, out-of-order dispatch / execution pipeline according to an embodiment of the present invention;
[0024] FIG16B is a block diagram illustrating an exemplary embodiment of a sequential architecture core to be included in a processor according to an embodiment of the present invention and an exemplary register renaming and out-of-order issuance / execution architecture core.
[0025] FIG17A is a single processor core according to an embodiment of the present invention, together with its connection to the on-die interconnect network 1702 and a local subset of its second-order (L2) cache 1704;
[0026] FIG17B is an extended view of a portion of the processor core in FIG17A according to an embodiment of the present invention;
[0027] FIG18 is a block diagram of a processor 1800 according to an embodiment of the present invention, which may have more than one core, may have an integrated memory controller, and may have integrated graphics;
[0028] Figure 19 shows a block diagram of a system according to an embodiment of the present invention;
[0029] FIG20 is a block diagram of a first more specific exemplary system according to an embodiment of the present invention;
[0030] FIG21 is a block diagram of a second more specific exemplary system according to an embodiment of the present invention;
[0031] FIG22 is a block diagram of a SoC according to an embodiment of the present invention; and
[0032] Figure 23 is a block diagram of a comparative method for converting binary instructions in a source instruction set into binary instructions in a target instruction set using a software instruction converter according to an embodiment of the present invention. [Summary of the Invention] [Summary of the Invention] and [Implementation Methods]
[0033] Numerous specific details are set forth in the following description. However, it should be understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0034] References to "an embodiment," "an exemplary embodiment," etc., in the specification indicate that the described embodiment may include specific features, structures, or characteristics, but each embodiment may not necessarily include that specific feature, structure, or characteristic. Furthermore, such terms do not necessarily refer to the same embodiment. In addition, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is assumed that the influence of other embodiments on that feature, structure, or characteristic falls within the knowledge of those skilled in the art, whether or not it is explicitly stated.
[0035] When processing large datasets, memory and computational density can be increased by scaling the data type to be as small as possible. If the input comes from sensor data, 8- or 16-bit integer data is expected as input. Neural network computations can also be encoded to match this dense format, typically with "small" numbers as input. However, accumulators perform summation products, meaning that accumulators should allow twice the number of bits of the input (the nature of multiplication) and possibly more, to avoid overflow or saturation at any point in the computation.
[0036] This document details an embodiment attempting to maintain a small input data size and sum to a larger accumulator in a fused multiply accumulate (FMA) operation chain. Figure 1 illustrates an exemplary execution of fused multiply accumulate instructions using operands of different sizes according to an embodiment. A first source 101 (e.g., a single-input, multiple-data (SIMD), or vector register) and a second source 103 store "half-sized" compressed data elements relative to a third source 105 (e.g., a single-input, multiple-data (SIMD), or vector register) storing full-size compressed data elements for accumulation. Any set of values for the compressed data element size in this manner is supported.
[0037] As shown, the values of compressed data elements stored in the same locations in the first and second sources 101 and 103 are multiplied together. For example, A0*B0, A1*B1, etc. The result of multiplying two such "half-size" compressed data elements is added to the corresponding "full-size" compressed data element from the third source 105. For example, A0*B0+A1*B1+C0, etc.
[0038] The results are stored in a destination 107 (e.g., a SIMD register) having a compressed data element size of at least "full size". In some embodiments, the third source 105 is the same as the destination 107.
[0039] Figure 2 illustrates a SIMD implementation of the exponentiation size according to Embodiment 2, wherein the accumulator uses an input size larger than the multiplier's input size. Note that the source (to the multiplier) and accumulator values can be signed or unsigned. For an accumulator with a 2X input size (in other words, the size of the accumulator input value is twice the size of the source's compressed data element), Table 201 shows different configurations. For a byte-sized source, the accumulator uses a word or a 16-bit half-precision floating-point (HPFP) value. For a word-sized source, the accumulator uses a 32-bit integer or a 32-bit single-precision floating-point (SPFP) value. For SPFP or 32-bit sources, the accumulator uses a 64-bit or 64-bit double-precision floating-point (DPFP) value. Using Figure 1 as an example, when the compressed data element size of source 1 101 and source 2 103 is 8 bits, the accumulator will use a 16-bit data element from source 3 103. When the compressed data element size of source 1 101 and source 2 103 is 16 bits, the accumulator will use a 32-bit data element from source 3 103. When the compressed data element size of source 1 101 and source 2 103 is 32 bits, the accumulator will use a 64-bit data element from source 3 103.
[0040] For accumulators with a 4X input size (in other words, the size of the accumulator input value is four times the size of the source compact data element), Table 203 shows different configurations. For byte-sized sources, the accumulator uses a 32-bit integer or a 32-bit single-precision floating-point (SPFP) value. For word-sized sources, the accumulator uses a 64-bit integer or a 64-bit double-precision floating-point (DPFP) value. Using Figure 1 as an example, when the compact data element size of source 1 101 and source 2 103 is 8 bits, the accumulator will use a 32-bit data element from source 3 103. When the compact data element size of source 1 101 and source 2 103 is 16 bits, the accumulator will use a 64-bit data element from source 3 103.
[0041] For an accumulator with an input size of 8X (in other words, the size of the accumulator input value is eight times the size of the source compact data element), Table 205 shows the configuration. For a byte-sized source, the accumulator uses a 64-bit integer or a 64-bit double-precision floating-point (DPFP) value. Using Figure 1 as an example, when the compact data element size of source 1 101 and source 2 103 is 8 bits, the accumulator will use a 64-bit data element from source 3 103.
[0042] This document details embodiments of instructions and circuitry for fused multiply-accumulate operations. In some embodiments, the fused multiply-accumulate instructions have mixed precision and / or use level reduction, as described herein.
[0043] This document details an embodiment of an instruction that, when executed, causes M N-sized compact data elements from the first and second sources corresponding to the third source compact data element location to be multiplied for each compact data element location at the destination, and adds the result of these multiplications to the full-size (relative to the N-sized compact data element) compact data element at the third source compact data element location, and stores the sum in the destination compact data element location corresponding to the third source compact data element location, where M is equal to the full-size compact data element divided by N. For example, when M equals 2 (e.g., the full-size compact data element is 16 bits and N is 8 bits), consecutive compact data elements from the first source are multiplied by individual consecutive compact data elements from the second source.
[0044] Similarly, this document details an embodiment of an instruction that, when executed, causes a pair of half-size compact data elements from the first and second sources to be multiplied, and the result of these multiplications to be added to a full-size (relative to the half-size compact data element) compact data element from the third source, and the result is stored in a destination. In other words, in some embodiments, for each data element position i from the third source, data from data element position [2i] from the first source is multiplied with data from data element position [2i] from the second source to produce a first result, data from data element position [2i+1] from the first source is multiplied with data from data element position [2i+1] from the second source to produce a second result, and the first and second results are added to data from data element position i from the third source. In some embodiments, a saturation operation is performed at the end of the addition. In some embodiments, the data from the first and / or second sources are sign-expanded before multiplication.
[0045] Furthermore, this document details an embodiment of an instruction that, when executed, causes four (quartet) quarter-size compact data elements from a first and second source to be multiplied, and the result of the multiplication is added to a full-size (relative to the quarter-size compact data element) compact data element from a third source, and the result is stored in a destination. In other words, in some embodiments, for each data element position i from the third source, the data from the data element position [4i] from the first source is multiplied by the data from the data element position [4i] from the second source to produce a first result, the data from the data element position [4i+1] from the first source is multiplied by the data from the data element position [4i+1] from the second source to produce a second result, the data from the data element position [4i+2] from the first source is multiplied by the data from the data element position [4i+2] from the second source to produce a third result, the data from the data element position [4i+3] from the first source is multiplied by the data from the data element position [4i+3] from the second source to produce a fourth result, and the first, second, third, and fourth results are added to the data from the data element position i from the third source. In some embodiments, a saturation operation is performed at the end of the addition. In some embodiments, the data from the first and / or second sources are sign-expanded before multiplication.
[0046] In some implementations of the integer version of the instructions, saturation circuitry is used to preserve the sign of operands when the value of the addition result is too large. Specifically, saturation evaluation occurs between multi-way addition and infinite precision results written to the destination. In some cases, the largest positive or smallest negative number cannot be trusted, as it may reflect computations exceeding container space. However, this can at least be checked. When the accumulator is floating-point and the input items are integers, the question to be answered is how and when to perform the integer product conversion so that there is no double-rounding from the partial items to the final floating-point accumulation. In some embodiments, the sum of the products and the floating-point accumulator are converted to infinite precision values (fixed-point numbers of several hundred bits), the addition is performed, and then a single rounding to the actual accumulator type is performed.
[0047] In some embodiments, when the input is a floating-point arithmetic unit, rounding and handling of special values (infinity and non-numeric (NANs)) are performed, and incorrect ordering in the calculation needs to be addressed in the definition. In some embodiments, an order of operations is simulated and guaranteed to provide for errors in that ordering. Such execution may not avoid multiple roundings during the calculation process. Single-precision multiplication can be fully filled into a double-precision result, regardless of the input value. However, the horizontal addition of two such operations may not fill into a double-precision floating-point number without rounding, and the sum may not fill into the accumulator without additional rounding. In some embodiments, rounding is performed during horizontal summation and once during accumulation.
[0048] Figure 3 illustrates an embodiment of hardware for processing instructions such as fused multiply-accumulate instructions. As shown, memory 303 stores a fused multiply-accumulate instruction 301 to be executed, which, for each compact data element location of the destination, causes M N-sized compact data elements from the first and second sources corresponding to the compact data element locations of the third source to be multiplied, the result of these multiplications to be added to the full-size (relative to the N-sized compact data element) compact data element of the compact data element location of the third source, and the addition result is stored in the compact data element location destination corresponding to the third source compact data element location, where M is equal to the full-size compact data element divided by N.
[0049] Instruction 301 is received by decoding circuitry 305. For example, decoding circuitry 305 receives this instruction from extraction logic / circuit. The instruction includes fields for first, second, and third sources and destinations. In some embodiments, the sources and destinations are registers. Furthermore, in some embodiments, the third source and destination are the same. The operand code and / or prefix of instruction 301 includes an indication of the source and destination data element sizes {B / W / D / Q} for bytes, words, doublewords, and quadwords, as well as the number of iterations.
[0050] More detailed embodiments of at least one instruction format will be described later. Decoding circuit 305 decodes the instruction into one or more operations. In some embodiments, this decoding includes generating a plurality of micro-operations to be performed by execution circuitry (such as execution circuitry 309). Decoding circuit 305 also decodes instruction prefixes.
[0051] In some embodiments, the register renaming, register configuration, and / or scheduling circuitry 307 provides one or more of the following functions: (1) renaming logical operand values to entity operand values (e.g., a register alias table in some embodiments); (2) assigning status bits and flags to decoded instructions; and (3) scheduling decoded instructions for execution on execution circuitry outside the instruction pool (e.g., using a reservation station in some embodiments). The register (register file) and / or memory 308 stores data as operands of instructions to be computed by execution circuitry 309. Exemplary register types include compact data registers, general-purpose registers, and floating-point registers.
[0052] Execution circuit 309 executes the decoded instructions.
[0053] In some embodiments, the write-back / write-back circuit 311 is architecturally committed to the destination register or memory, and a write-back instruction is given.
[0054] An embodiment of the format of the fused multiplication-accumulation instruction is FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}]DSTREG,SRC1,SRC2,SRC3. In some embodiments, FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}] is the instruction's operand code and / or prefix. B / W / D / Q indicates the source / destination data element size as bytes, words, double words, and quad words. DSTREG is a field for the compressed data destination register operand. SRC1, SRC2, and SRC3 are fields for sources such as compressed data registers and / or memory.
[0055] An embodiment of the format of the fused multiplication-accumulation instruction is FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}]DSTREG / SRC3,SRC1,SRC2. In some embodiments, FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}] is the instruction's operand code and / or prefix. B / W / D / Q indicates the source / destination data element size as a byte, word, double word, or quad word. DSTREG / SRC3 is a field for the compressed data destination register operand and the third source operand. SRC1 and SRC2 are fields for sources such as compressed data registers and / or memory.
[0056] In some embodiments, the fused multiplication-accumulation instruction includes fields of the writemask register operand (k) (e.g., FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}]{k}DSTREG / SRC3,SRC1,SRC2 or FMA[SOURCESIZE{B / W / D / Q}][DESTSIZE{B / W / D / Q}]{k}DSTREG,SRC1,SRC2,SRC3). The writemask is used to conditionally control the operation of each element and update the result. Depending on the implementation, the writemask uses merging or zeroing masking. Instructions encoded with predicate (writemask, writemask, or k register) operands use these operands to conditionally control the operation of each element and update the result to the destination operand. Predicate operators are called opmask (write mask) registers. An opmask is a set of architecture registers of size MAX_KL (64 bits). It should be noted that only k1 through k7 of these architecture registers can be addressed as predicate operators. k0 can be used as a regular source or destination, but cannot be encoded as a predicate operator. It should also be noted that predicate operators can be used to enable memory fault tolerance for some instructions with memory operators (sources or destinations). As a predicate operator, the opmask register contains one bit used to manage the operation / update of each data element of the vector register. Generally, the opmask register supports instructions with the following element sizes: single-precision floating-point numbers (float32), integer double words (int32), double-precision floating-point numbers (float64), and integer quad words (int64). The opmask register length MAX_KL is sufficient to handle up to 64 elements, one bit per element, i.e., 64 bits. For a given vector length, each instruction accesses only the minimum number of valid mask bits required according to its data type. The opmask register affects instructions at a per-element granularity. Therefore, per-element updates determine any numerical or non-numerical operation on each data element and intermediate results to the destination operand, as well as on the corresponding bits of the opmask register.In most embodiments, the opmask, as a predicate operator, adheres to the following properties: (1) For elements whose corresponding opmask bits are not set, the instruction operation is not performed (meaning that operations on unmasked-off elements will not cause exceptions or violations, and therefore, no exception flag is updated due to unmasked operations); (2) If the corresponding write mask bit is not set, the destination element is not updated with the result of the operation; instead, the destination element value must be saved (merge masking) or the destination element value must be zeroed (zero masking); (3) For some instructions with memory operators, memory failures are suppressed for elements with a mask bit of 0. It should be noted that this feature provides a general structure for implementing control flow assertions, as the masking effectively provides merge behavior for vector register destinations. Alternatively, the masking can be used for zeroing instead of merging, thus updating the masked element with 0 instead of retaining the old value. Zeroing behavior is provided to remove implicit dependencies of the old value when they are not needed.
[0057] In an embodiment, the instruction encoding includes a scale-index-base (SIB) type memory addressing operator that indirectly identifies multiple indexed destination locations in memory. In one embodiment, the SIB type memory operator may include encoding that identifies a base address register. The contents of the base address register may represent a base address in memory from which the address of a specific destination location in memory can be calculated. For example, the base address may be the address of a first location in a block of potential destination locations for an extended vector instruction. In one embodiment, the SIB type memory operator may include encoding that identifies an index register. Each element of the index register may specify an index or offset value that can be used to calculate the address of an individual destination location within a block of potential destination locations from the base address. In one embodiment, the SIB type memory operator may include encoding that specifies a scaling factor that is applied to each index value when calculating an individual destination address. For example, if the scaling factor is 4 in the SIB type memory operand, then each index value obtained from the index register can be multiplied by 4 and then added to the base address to calculate the destination address.
[0058] In one embodiment, memory operators of type SIB in the form vm32{x,y,z} can recognize a vector array of memory operators specified using SIB-type memory addressing. In this example, an array of memory addresses is specified using a common base register, a constant scaling factor, and a vector index register containing multiple individual elements, each with a 32-bit index value. The vector index register can be an XMM register (vm32x), a YMM register (vm32y), or a ZMM register (vm32z). In another embodiment, memory operators of type SIB in the form vm64{x,y,z} can recognize a vector array of memory operators specified using SIB-type memory addressing. In this example, an array of memory addresses is specified using a common base register, a constant scaling factor, and a vector index register containing multiple individual elements, each with a 64-bit index value. Vector index registers can be XMM registers (vm64x), YMM registers (vm64y), or ZMM registers (vm64z).
[0059] Figure 4 illustrates an embodiment of a method executed by a processor to process fused multiplication-accumulation instructions.
[0060] At 401, fetch the instruction. For example, fetch the fused multiply-accumulate instruction. The fused multiply-accumulate instruction includes an operand, and fields for compressed data source operands and compressed data destination operands, as detailed above. In some embodiments, the fused multiply-accumulate instruction includes a write mask operand. In some embodiments, the instruction is fetched from the instruction cache.
[0061] The extracted instruction is decoded at 403. For example, the extracted fused multiplication-accumulation instruction is decoded by the decoding circuit, as detailed herein.
[0062] At 405, the data value associated with the source operand of the decoded instruction is retrieved.
[0063] At 407, the decoded instructions are executed by the execution circuit (hardware), as detailed herein. For the fused multiplication-accumulation instruction, the execution will, for each compact data element location of the destination, result in the multiplication of M N-sized compact data elements from the first and second sources corresponding to the compact data element locations of the third source, add the results of these multiplications to the full-size (relative to the N-sized compact data element) compact data element of the third source compact data element location, and store the sum in the destination of the compact data element location corresponding to the third source compact data element location, where M is equal to the full-size compact data element divided by N.
[0064] In some embodiments, the commit or retire instruction is given at 409.
[0065] Figure 5 illustrates an embodiment of a subset of the execution of fused multiplication-accumulation. In particular, this shows the execution circuitry for an iteration of a compressed data element location at the destination. In this embodiment, fused multiplication-accumulation is performed on a source with a positive or negative sign, where the accumulator is twice the size of the input data. Figure 6 illustrates an embodiment of the virtual code used to execute this instruction in hardware.
[0066] The first signed source (source 1 501) and the second signed source (source 2 503) each have four compressed data elements. Each of these compressed data elements stores signed data such as floating-point data. The third signed source 509 (source 3) has two compressed data elements, each of which stores signed data. The size of the first and second signed sources 501 and 503 is half the size of the third signed source 509. For example, the first and second signed sources 501 and 503 may have 32-bit compressed data elements (e.g., single-precision floating-point numbers), and the third signed source 509 may have 64-bit compressed data elements (e.g., double-precision floating-point numbers).
[0067] In this illustration, only the two most significant compressed data element positions of the first and second sources 501 and 503 with positive and negative signs, and the most significant compressed data element position of the third source 509 with positive and negative signs are shown. Of course, other compressed data element positions will also be processed.
[0068] As shown, compressed data elements are processed in pairs. For example, multiplier circuit 505 multiplies the data from the highest effective compressed data element locations of the first and second signed sources 501 and 503, and multiplier circuit 507 multiplies the data from the second highest effective compressed data element locations of the first and second signed sources 501 and 503. In some embodiments, these multiplier circuits 505 and 507 are reused for other compressed data element locations. In other embodiments, additional multiplier circuitry is used such that compressed data elements are processed in parallel. In some cases, parallel processing is accomplished using a channel of size 509 from a third signed source. Adder circuit 511 adds the results of each multiplication.
[0069] The sum of the multiplication results is added to the data from the highest effective compressed data element position of the source 3 509 with a positive or negative sign (using a different adder 513 or the same adder 511).
[0070] Finally, the result of the second addition is stored in the signed destination 515 of the compact data element location corresponding to the compact data element location used by the signed third source 509. In some embodiments, a write mask is applied to this memory such that if the corresponding write mask (bit) is set, storage occurs, and if it is not set, storage does not occur.
[0071] Figure 7 illustrates an embodiment of a subset of the execution of fused multiplication-accumulation. In particular, this shows the execution circuitry for an iteration of a compressed data element location at the destination. In this embodiment, fused multiplication-accumulation is performed on a source with a positive or negative sign, where the accumulator is twice the size of the input data. Figure 8 illustrates an embodiment of the virtual code used to execute this instruction in hardware.
[0072] The first signed source (source 1 701) and the second signed source (source 2 703) each have four compact data elements. Each of these compact data elements stores signed data such as integer data. The third signed source 709 (source 3) has two compact data elements, each of which stores signed data. The size of the first and second signed sources 701 and 703 is half the size of the third signed source 709. For example, the first and second signed sources 701 and 703 may have 32-bit compact data elements (e.g., single-precision floating-point numbers), and the third signed source 709 may have 64-bit compact data elements (e.g., double-precision floating-point numbers).
[0073] In this illustration, only the positions of the two most effective compressed data elements from sources 701 and 703 with the first and second signs are shown, and the position of the most effective compressed data element from source 709 with the third sign is shown. Of course, other compressed data element positions will also be processed.
[0074] As shown, compressed data elements are processed in pairs. For example, multiplier circuit 705 multiplies the data at the most effective compressed data element locations of the first and second positive and negative sources 701 and 703, and multiplier circuit 707 multiplies the data at the second most effective compressed data element locations of the first and second positive and negative sources 701 and 703. In some embodiments, these multiplier circuits 705 and 707 are reused for other compressed data element locations. In other embodiments, additional multiplier circuitry is used such that compressed data elements are processed in parallel. In some cases, parallel processing is accomplished using a channel of size 709 with a positive and negative third source. Addition / saturation circuit 711 adds the result of each multiplication to the positive and negative third source 709.
[0075] The adder / saturation (accumulator) circuit 711 preserves the sign of the operands when the addition results in a value that is too large. In particular, saturation evaluation occurs on the infinite-precision result between the multi-way add and the write to the signed destination 715. When the accumulator 711 is a floating-point number and the input is an integer, the sum of the product and the floating-point accumulator input value are converted to an infinite-precision value (a fixed-point number of several hundred bits), the multiplication result is added to the third input, and a single rounding is performed to the actual accumulator type.
[0076] The result of the addition and saturation check is stored in the signed destination 715 of the compact data element location corresponding to the compact data element location used by the signed third source 709. In some embodiments, a write mask is applied to this memory such that if the corresponding write mask (bit) is set, storage occurs, and if it is not set, storage does not occur.
[0077] Figure 9 illustrates an embodiment of a subset of the execution of fused multiplication-accumulation. Specifically, it shows the execution circuitry for an iteration of a compressed data element location at the destination. In this embodiment, fused multiplication-accumulation is performed on both signed and unsigned sources, where the accumulator is four times the size of the input data. Figure 10 illustrates an embodiment of the virtual code used to execute this instruction in hardware.
[0078] The first signed source (source 1 901) and the second unsigned source (source 2 903) each have four compressed data elements. Each of these compressed data elements stores data such as floating-point numbers or integer data. The third signed source (source 3 915) has one compressed data element that stores signed data. The size of the first and second sources 901 and 903 is one-quarter the size of the third signed source 915. For example, the first and second sources 901 and 903 may have 16-bit compressed data elements (e.g., words), while the third signed source 915 may have 64-bit compressed data elements (e.g., double-precision floating-point numbers or 64-bit integers).
[0079] This diagram shows the four most effective compressed data element positions of the first and second sources 901 and 903, and the most effective compressed data element position of the third source 915 with a plus or minus sign. Of course, if there are other compressed data element positions, those other compressed data element positions will also be processed.
[0080] As shown, compressed data elements are processed in groups of four. For example, multiplier circuit 905 multiplies the data from the highest effective compressed data element positions of the first and second sources 901 and 903, multiplier circuit 907 multiplies the data from the second highest effective compressed data element positions of the first and second sources 901 and 903, multiplier circuit 909 multiplies the data from the third highest effective compressed data element positions of the first and second sources 901 and 903, and multiplier circuit 911 multiplies the data from the lowest effective compressed data element positions of the first and second sources 901 and 903. In some embodiments, before multiplication, the signed compressed data elements of the first source 901 are sign-extended, and the unsigned compressed data elements of the second source 903 are zero-extended.
[0081] In some embodiments, these multiplier circuits 905-911 are reused at other compressed data element locations. In other embodiments, additional multiplier circuitry is used to allow the compressed data elements to be processed in parallel. In some cases, parallel processing is accomplished using a channel of size 915 with a sign. The results of each multiplication are added together using adder circuit 912.
[0082] The sum of the multiplication results is added to the data from the highest effective compressed data element position of the source 3 915 with a positive or negative sign (using a different adder 913 or the same adder 912).
[0083] Finally, the result of the second addition is stored in the signed destination 919 of the compact data element location corresponding to the compact data element location used by the signed third source 909. In some embodiments, a write mask is applied to this memory such that if a corresponding write mask (bit) is set, storage occurs, and if not set, storage does not occur.
[0084] Figure 11 illustrates an embodiment of a subset of the execution of fused multiplication-accumulation. In particular, this shows the execution circuitry for the iteration of a compressed data element location at the destination. In this embodiment, fused multiplication-accumulation is performed on both signed and unsigned sources, where the accumulator is four times the size of the input data. Figure 12 illustrates an embodiment of the virtual code used to execute this instruction in hardware.
[0085] The first signed source (source 1 1101) and the second unsigned source (source 2 1103) each have four compressed data elements. Each of these compressed data elements stores data such as floating-point numbers or integer data. The third signed source (source 3 1115) has one compressed data element that stores signed data. The size of the first and second sources 1101 and 1103 is one-quarter the size of the third signed source 1115. For example, the first and second sources 1101 and 1103 may have 16-bit compressed data elements (e.g., words), while the third signed source 1115 may have 64-bit compressed data elements (e.g., double-precision floating-point numbers or 64-bit integers).
[0086] This diagram shows the four most effective compressed data element positions of the first and second sources 1101 and 1103, and the most effective compressed data element position of the third source 1115 with a plus or minus sign. Of course, if there are other compressed data element positions, those other compressed data element positions will also be processed.
[0087] As shown, compressed data elements are processed in groups of four. For example, multiplier circuit 1105 multiplies the data from the highest effective compressed data element locations of the first and second sources 1101 and 1103, multiplier circuit 1107 multiplies the data from the second highest effective compressed data element locations of the first and second sources 1101 and 1103, multiplier circuit 1109 multiplies the data from the third highest effective compressed data element locations of the first and second sources 1101 and 1103, and multiplier circuit 1111 multiplies the data from the lowest effective compressed data element locations of the first and second sources 1101 and 1103. In some embodiments, before multiplication, the signed compressed data elements of the first source 1101 are sign-extended, and the unsigned compressed data elements of the second source 1103 are zero-extended.
[0088] In some embodiments, multiplier circuits 1105-1111 are reused at other compressed data element locations. In other embodiments, additional multiplier circuitry is used to allow compressed data elements to be processed in parallel. In some cases, parallel processing is accomplished using a channel of size 1115 with a sign. The result of each multiplication is added to the sign-signed third source 1115 using an add / saturate circuit 1113.
[0089] The adder / saturation (accumulator) circuit 1113 preserves the sign of the operands when the addition results in a value that is too large. In particular, saturation evaluation occurs on the infinite precision result between the multiplexed addition and the write to the destination 1119. When the accumulator 1113 is a floating point and the input is an integer, the sum of the product and the floating-point accumulator input value are converted to an infinite precision value (a fixed-point number of several hundred bits), the multiplication result is added to the third input, and a single rounding to the actual accumulator type is performed.
[0090] The result of the addition and saturation check is stored in the signed destination 1119 of the compact data element location corresponding to the compact data element location used by the signed third source 1115. In some embodiments, a write mask is applied to this memory such that if the corresponding write mask (bit) is set, storage occurs, and if it is not set, storage does not occur.
[0091] The following figures describe in detail exemplary architectures and systems that implement the above embodiments. In some embodiments, one or more hardware components and / or instructions described above are emulated as follows, or implemented as software modules.
[0092] An exemplary embodiment includes a processor comprising a decoder for decoding a single instruction having an operand code, a destination field representing a destination operand, and fields for first, second, and third compressed data source operands, wherein the compressed data elements of the first and second compressed data source operands have a first size, which differs from a second size of the compressed data element of the third compressed data operand; a register file having a plurality of compressed data registers, including registers for source and destination operands; and execution circuitry for executing the decoded single instruction to perform, for each compressed data element location of the destination operand, M N-sized compressed data elements from the first and second compressed data sources corresponding to the compressed data element location of the third compressed data source, adding the results of these multiplications to a full-size compressed data element at the compressed data element location of the third compressed data source, and storing the addition result in a compressed data element location destination corresponding to the compressed data element location of the third compressed data source, wherein M is equal to the full-size compressed data element divided by N.
[0093] In some embodiments, one or more of the following apply: the instruction defines the size of the compressed data elements; before multiplication, the execution circuit expands the compressed data element from the second source by zero and expands the compressed data element from the first source by a sign; when the first size is half of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; when the first size is half of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration; when the first size is one-quarter of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; and / or when the first size is one-quarter of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration.
[0094] An exemplary embodiment includes a method for decoding a single instruction having an operand code, a destination field representing a destination operand, and fields for first, second, and third compressed data source operands, wherein the compressed data elements of the first and second compressed data source operands have a first size, which is different from the second size of the compressed data element of the third compressed data operand; a register file having a plurality of compressed data registers, including registers for source and destination operands; and executing the decoded single instruction to perform, for each compressed data element position of the destination operand, M N-sized compressed data elements from the first and second compressed data sources corresponding to the compressed data element position of the third compressed data source, adding the results of these multiplications to the full-size compressed data element of the compressed data element position of the third compressed data source, and storing the addition result in a compressed data element position destination corresponding to the compressed data element position of the third compressed data source, wherein M is equal to the full-size compressed data element divided by N.
[0095] In some embodiments, one or more of the following apply: the instruction defines the size of the compressed data elements; before multiplication, the execution circuit expands the compressed data element from the second source by zero and expands the compressed data element from the first source by a sign; when the first size is half of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; when the first size is half of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration; when the first size is one-quarter of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; and / or when the first size is one-quarter of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration.
[0096] An exemplary embodiment includes a non-transitory machine-readable medium storing instructions, and a method for decoding a single instruction when the instructions are executed, the single instruction having an operand, a destination field representing a destination operand, and fields for first, second, and third compressed data source operands, wherein the compressed data elements of the first and second compressed data source operands have a first size, which differs from the second size of the compressed data element of the third compressed data operand; a register file having a plurality of compressed data registers, including registers for source and destination operands. The device; and executes a single decoded instruction to perform multiplication of M N-sized compressed data elements from the first and second compressed data sources corresponding to the compressed data element positions of the third compressed data source for each compressed data element position of the destination operand, add the results of these multiplications to the full-size compressed data element of the compressed data element position of the third compressed data source, and store the addition results in the destination of the compressed data element position corresponding to the compressed data element position of the third compressed data source, where M is equal to the full-size compressed data element divided by N.
[0097] In some embodiments, one or more of the following apply: the instruction defines the size of the compressed data elements; before multiplication, the execution circuit expands the compressed data element from the second source by zero and expands the compressed data element from the first source by a sign; when the first size is half of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; when the first size is half of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration; when the first size is one-quarter of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; and / or when the first size is one-quarter of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration.
[0098] An exemplary embodiment includes a system including memory and a processor, the processor including a decoder for decoding a single instruction having an operand, a destination field representing a destination operand, and fields for first, second, and third compressed data source operands, wherein the compressed data elements of the first and second compressed data source operands have a first size, which differs from the second size of the compressed data element of the third compressed data operand; a register file having a plurality of compressed data registers, including registers for source and destination operands; and An execution circuit is used to execute a decoded single instruction to perform multiplication of M N-sized compressed data elements from the first and second compressed data sources corresponding to the compressed data element location of the third compressed data source for each compressed data element location of the destination operand. The result of these multiplications is added to the full-size compressed data element of the compressed data element location of the third compressed data source, and the addition result is stored in the destination of the compressed data element location corresponding to the compressed data element location of the third compressed data source, where M is equal to the full-size compressed data element divided by N.
[0099] In some embodiments, one or more of the following apply: the instruction defines the size of the compressed data elements; before multiplication, the execution circuit expands the compressed data element from the second source by zero and expands the compressed data element from the first source by a sign; when the first size is half of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; when the first size is half of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration; when the first size is one-quarter of the second size, a first addition is performed on each multiplication, and a second addition is performed on the result of the first addition and the result from the previous iteration; and / or when the first size is one-quarter of the second size, a single addition and saturation check are performed on each of the multiplications and the result from the previous iteration.
[0100] Embodiments of the instructions described in detail above can be embodied in the "generic vector friendly instruction format," which will be described in detail below. In other embodiments, such a format is not used; instead, another instruction format is used. However, the following descriptions of writing to mask registers, various data transformations (swizzling, broadcasting, etc.), addressing, etc., are generally applicable to the description of embodiments of the instructions above. Furthermore, exemplary systems, architectures, and pipelines will be described in detail below. Embodiments of the instructions above can be executed on such systems, architectures, and pipelines, but are not limited to those detailed herein.
[0100] Instruction Set
[0101] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit position) to specify, among which, the operation to be performed (e.g., operand) and one or more operands to be performed on it and / or one or more other data fields (e.g., mask). Some instruction formats are further subdivided through the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of that instruction format (the fields included are generally in the same order, but at least some have different bit positions because they contain fewer fields) and / or defined as having given fields interpreted in different ways. Thus, each instruction of an instruction set architecture (ISA) is represented using a given instruction format (and, if defined, a given instruction template of that instruction format), and the instruction includes fields for specifying operations and operands. For example, an exemplary ADD instruction has a specific operand and instruction format, which includes an operand field specifying the operand and an operand field for selecting operands (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field for selecting specific operands. A set of SIMD extended instruction sets, referred to as Advanced Vector Extensions (AVX) (AVX1 and AVX2), has been released and / or disclosed using the Vector Extensions (VEX) encoding scheme (see, for example, the Intel® 64 and IA-32 Architectures Software Developer's Manual, September 2014; and the Intel® Advanced Vector Extensions Programming Reference, October 2014).
[0101] Exemplary instruction format
[0102] Embodiments of the instructions described herein may be embodied in different formats. Furthermore, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the instructions that can be executed on such systems, architectures, and pipelines are not limited to those detailed herein.
[0102] General Vector Friendly Command Format
[0103] The vector-friendly instruction format is an instruction format suitable for vector instructions (e.g., having certain fields specifically for vector operations). Although an embodiment supporting both vector and scalar operations through the vector-friendly instruction format has been described, alternative embodiments use only the vector-friendly instruction format for vector operations.
[0104] Figures 13A-13B are block diagrams illustrating a general vector-friendly instruction format and its instruction templates according to embodiments of the present invention. Figure 13A is a block diagram illustrating a general vector-friendly instruction format and its category A instruction template according to embodiments of the present invention; while Figure 13B is a block diagram illustrating a general vector-friendly instruction format and its category B instruction template according to embodiments of the present invention. Specifically, category A and category B instruction templates are defined for the general vector-friendly instruction format 1300, both of which include a no-memory access 1305 instruction template and a memory access 1320 instruction template. In the context of vector-friendly instruction format, the term generally refers to an instruction format that is not limited to any particular instruction set.
[0105] While it will be described that in embodiments of the present invention, the vector-friendly instruction format supports the following: 64-bit vector operand lengths (or dimensions) having a 32-bit (4-byte) or 64-bit (8-byte) data element width (or size) (therefore, a 64-bit vector consists of 16 double-word-sized elements, or 8 quad-word-sized elements); 64-bit vector operand lengths (or dimensions) having a 16-bit (2-byte) or 8-bit (1-byte) data element width (or size); 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte) data element widths (or sizes); 32-byte vector operand lengths (or sizes) with a data element width (or size) of 32 bits (4 bytes), 64 bits (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte); and 16-byte vector operand lengths (or sizes) with a data element width (or size) of 32 bits (4 bytes), 64 bits (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte); however, alternative embodiments may support more, fewer, and / or different vector operand sizes (e.g., 256-byte vector operands) with more, fewer, or different data element widths (e.g., 128-bit (16-byte) data element widths).
[0106] The category A instruction template in Figure 13A includes: (1) within the no memory access 1305 instruction template, showing the no memory access, full round control type operation 1310 instruction template and the no memory access, data conversion type operation 1315 instruction template; and (2) within the memory access 1320 instruction template, showing the memory access, temporary 1325 instruction template and the memory access, non-temporary 1330 instruction template. The category B instruction template in Figure 13B includes: (1) within the no memory access 1305 instruction template, showing the no memory access, write mask control, partial round control type operation 1312 instruction template and the no memory access, write mask control, vsize type operation 1317 instruction template; and (2) within the memory access 1320 instruction template, showing the memory access, write mask control 1327 instruction template.
[0107] The general vector friendly instruction format 1300 includes the fields listed below in the order shown in Figures 13A-13B.
[0108] Format field 1340 - A specific value (instruction format identifier value) in this field uniquely identifies the vector-friendly instruction format and thus the occurrence of instructions in the vector-friendly instruction format within the instruction stream. Therefore, this field is optional, as instruction sets with only the general vector-friendly instruction format do not require it.
[0109] Base Operations Field 1342 - Its content differs from different base operations.
[0110] Scratchpad index field 1344 - Its contents directly specify or are generated via addresses to specify the location of source and destination operands, regardless of whether the source and destination operands are located in a scratchpad or in memory. These include enough bits to select N scratchpads from a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) scratchpad file. While in one embodiment N can be up to three source and one destination scratchpads, alternative embodiments may support more or fewer source and destination scratchpads (e.g., up to two sources, where one of these sources is also used as a destination; up to three sources, where one of these sources is also used as a destination; up to two sources and one destination).
[0111] Modifier field 1346 - Its content is distinguished by the presence of instructions in the generic vector instruction format that specifies memory access and the presence of instructions in the generic vector instruction format that does not specify memory access; that is, it identifies the no-memory-access instruction template 1305 and the memory-access instruction template 1320. Memory access operations read and / or write to the memory hierarchy (in some cases, using values in a register to specify the source and / or destination addresses), while no-memory-access operations do not do so (e.g., the source and destination are registers). Although in one embodiment, this field also selects from three different ways of performing memory address calculations, alternative embodiments may support more, fewer, or different ways of performing memory address calculations.
[0112] Extended Operation Field 1350 – Its content distinguishes which of the various operations to be performed besides the base operation. This field is context-specific. In one embodiment of the invention, this field is divided into category field 1368, α field 1352, and β field 1354. The extended operation field 1350 allows a common group of operations to be performed in a single instruction, rather than in 2, 3, or 4 instructions.
[0113] Scale field 1360 - Its contents allow scaling the contents of the index field for memory address generation (e.g., for address generation using 2scale * index + base).
[0114] Displacement field 1362A - Its contents are used as part of the memory address generation (e.g., for address generation using 2scale * index + base + displacement).
[0115] Shift factor field 1362B (note that shift field 1362A is directly above shift factor field 1362B, indicating that one of these two is used) - its contents are used as part of address generation; it specifies the shift factor scaled by the size (N) of the memory access - where N is the number of bytes in the memory access (e.g., for address generation using 2scale * index + base + scaled shift). Redundant low-order bits are ignored, and therefore the contents of the shift factor field are multiplied by the total size (N) of the memory operands to produce the final shift used when calculating the effective address. The value of N is determined by the processor hardware at runtime based on the full operation code field 1374 (described later in this document) and the data operation field 1354C. Displacement field 1362A and displacement factor field 1362B are optional, in respect of the fact that they are not used in the memoryless access 1305 instruction template and / or different embodiments may implement only one of them or neither of them.
[0116] Data Element Width Field 1364 - Its content distinguishes which of the various data element widths to use (in some embodiments for all instructions; in other embodiments for only some instructions). This field is optional, meaning it is not needed if only one data element width is supported and / or if certain states of the operation code are used to support the data element width.
[0117] Write Mask Field 1370 - Its content controls whether the position of the data element in the destination vector operand reflects the results of the base operation and the augmentation operation, based on the position of each data element. Category A instruction templates support merge write masking, while Category B instruction templates support both merge and zero-masking. When merged, vector masking allows protecting any set of elements in the destination from updates during the execution of any operation (specified by the base operation and the augmentation operation); in another embodiment, the old value of each element in the destination with a corresponding mask bit of 0 is preserved. Conversely, when zero-masking, vector masking allows zeroing any set of elements in the destination during the execution of any operation (specified by the base operation and the augmentation operation); in one embodiment, the element in the destination is set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation performed (i.e., the span from the first to the last modified element); however, the modified elements are not necessarily contiguous. Therefore, the write mask field 1370 allows for vector operations, including loading, storing, arithmetic, logic, etc. While embodiments of the invention have been described in which the content of the write mask field 1370 selects one of a plurality of write mask registers containing the write mask to be used (and thus the content of the write mask field 1370 indirectly identifies the mask to be performed), alternative embodiments alternatively or additionally allow the content of the write mask field 1370 to directly specify the mask to be performed.
[0118] Immediate value field 1372 - Its contents allow specifying an immediate value. This field is optional, meaning it does not exist in implementations of the generic vector-friendly format that do not support immediate values, nor in instructions that do not use immediate values.
[0119] Category field 1368 - Its content distinguishes different instruction categories. Referring to Figures 13A-B, the content of this field is selected between Category A and Category B instructions. In Figures 13A-B, rounded rectangles are used to indicate that a specific value exists in the field (e.g., Category A 1368A and Category B 1368B are used for Category field 1368 in Figures 13A-B, respectively).
[0119] Instruction template for Category A
[0120] In the case of the no-memory access 1305 instruction template of category A, field α 1352 is interpreted as field RS 1352A, the content of which distinguishes which of the different extended operation types to be performed (for example, specifying rounding 1352A.1 and data conversion 1352A.2 for no-memory access, rounding type operation 1310 and no-memory access, data conversion type operation 1315 instruction templates respectively), while field β 1354 distinguishes which of the specified type of operation to be performed. In the no-memory access 1305 instruction template, the scaling field 1360, the shift field 1362A, and the shift / scaling field 1362B do not exist.
[0120] No Memory Access Instruction Template - Full Rounding Control Type Operations
[0121] In the instruction template of the no-memory access full rounding control type operation 1310, the β field 1354 is interpreted as the rounding control field 1354A, the contents of which provide static rounding. Although in the embodiments described in this invention, the rounding control field 1354A includes the suppress all floating point exceptions (SAE) field 1356 and the rounding operation control field 1358, alternative embodiments may support encoding these two concepts into the same field, or having only one of these two concepts / fields (e.g., only the rounding operation control field 1358).
[0122] SAE field 1356 - Its content distinguishes whether to disable exception reporting; when the content of SAE field 1356 indicates that suppression is enabled, a given instruction will not report any kind of floating-point exception flag and will not invoke any floating-point exception handler.
[0123] Rounding operation control field 1358 – its contents distinguish which of the group of rounding operations to be performed (e.g., Round-up, Round-down, Round-towards-zero, and Round-to-nearest). Therefore, rounding operation control field 1358 allows the rounding mode to be changed according to each instruction. In one embodiment of the present invention, the processor includes a control register for specifying the rounding mode, the contents of rounding operation control field 1358 overwrite the register value.
[0123] No memory access instruction template - Data type conversion operation
[0124] In the instruction template of No Memory Access Data Conversion Type Operation 1315, β field 1354 is interpreted as data conversion field 1354B, the contents of which distinguish which of the various data conversions to be performed (e.g., no data conversion, rearrangement, broadcast).
[0125] In the case of the memory access 1320 instruction template of category A, field 1352 is interpreted as eviction hint field 1352B, the content of which distinguishes which eviction hint to use (in Figure 13A, temporary 1352B.1 and non-temporary 1352B.2 are specified for memory access, temporary 1325 instruction template and memory access, non-temporary 1330 instruction template, respectively), while field 1354 is interpreted as data operation field 1354C, the content of which distinguishes which of the various data processing operations (also called primitives) to be performed (e.g., no processing; broadcasting; source up conversion; and destination down conversion). The memory access 1320 instruction template includes scaling field 1360, and optional displacement field 1362A or displacement-scaling field 1362B.
[0126] Vector memory instructions execute the loading of vectors from memory and the storage of vectors into memory, and support conversion. Like regular vector instructions, vector memory instructions transfer data to / from memory on a per-data-element basis, and the actual transferred element is indicated by the content of the vector mask selected as the write mask.
[0126] Memory Access Instruction Template - Temporary
[0127] Temporary data is data that can be reused quickly enough to benefit from caching. However, this is a hint, and different processors may implement it differently, including ignoring the hint entirely.
[0127] Memory Access Instruction Template - Non-Temporary
[0128] Non-temporary data is data that cannot be reused quickly enough to benefit from the cache in the first-order cache and should be given eviction priority. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint completely.
[0128] Instruction Template for Category B
[0129] In the case of the instruction template of category B, α field 1352 is interpreted as write mask control (Z) field 1352C, the content of which distinguishes whether the write mask controlled by write mask field 1370 should be merged or zeroed.
[0130] In the case of the no-memory access 1305 instruction template of category B, a portion of the β field 1354 is interpreted as the RL field 1357A, the content of which distinguishes which of the different extended operation types to be performed (for example, specifying rounding 1357A.1 and vector length (VSIZE) 1357A.2 for the no-memory access, write mask control, partial rounding control type operation 1312 instruction template and the no-memory access, write mask control, VSIZE type operation 1317 instruction template, respectively), while the remaining portion of the β field 1354 distinguishes which of the specified types of operations to be performed. In the no-memory access 1305 instruction template, the scaling field 1360, the shift field 1362A, and the shift scaling field 1362B are not present.
[0131] In the instruction template of No Memory Access, Write Mask Control, Partial Rounding Control type operation 1312, the remainder of β field 1354 is interpreted as rounding operation field 1359A, and exception event reporting is disabled (a given instruction will not report any kind of floating-point exception flag and will not invoke any floating-point exception processor).
[0132] Rounding operation control field 1359A – Just like rounding operation control field 1358, its content distinguishes which of the group of rounding operations to be performed (e.g., round up, round down, round towards zero, and round to the nearest value). Therefore, rounding operation control field 1359A allows the rounding mode to be changed according to each instruction. In one embodiment of the present invention, where the processor includes a control register for specifying the rounding mode, the content of rounding operation control field 1350 overwrites the register value.
[0133] In the instruction template of No Memory Access, Write Mask Control, VSIZE type operation 1317, the remainder of the β field 1354 is interpreted as the vector length field 1359B, the contents of which distinguish which of the multiple data vector lengths to be executed (e.g., 128, 256, or 512 bits).
[0134] In the case of the memory access 1320 instruction template of category B, a portion of the β field 1354 is interpreted as the broadcast field 1357B, the content of which distinguishes whether a broadcast type data processing operation is to be performed, while the remaining portion of the β field 1354 is interpreted as the vector length field 1359B. The memory access 1320 instruction template includes a scaling field 1360, and optionally a displacement field 1362A or a displacement-scaling field 1362B.
[0135] Regarding the general vector-friendly instruction format 1300, a complete opcode field 1374 is shown, including a format field 1340, a base operation field 1342, and a data element width field 1364. Although one embodiment is shown in which the complete opcode field 1374 includes all of these fields, the complete opcode field 1374 may include fewer than these fields in embodiments that do not support all of them. The complete opcode field 1374 provides the opcode.
[0136] The expanded operation field 1350, data element width field 1364, and write mask field 1370 allow these features to be specified for each instruction in the general vector friendly instruction format.
[0137] The combination of the write mask field and the data element width field establishes a variety of instructions because they allow masks to be applied based on different data element widths.
[0138] Various instruction templates established within Category A and Category B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only Category A, only Category B, or both. For example, a high-efficiency general-purpose out-of-order core designed for general-purpose computing may support only Category B, a core designed primarily for graphics and / or scientific (throughput) computing may support only Category A, and a core designed for both may support both (of course, cores having some mixture of templates and instructions from both categories, but not all templates and instructions from both categories, are within the scope of the invention). Furthermore, a single processor may include multiple cores, wherein all cores support the same category or wherein different cores support different categories. For example, in a processor having separate graphics and general-purpose cores, one of the graphics cores designed primarily for graphics and / or scientific computing may support only Category A, while one or more of the general-purpose cores may be a high-efficiency general-purpose core designed for general-purpose computing with out-of-order execution and register renaming, which supports only Category B. Another processor, which does not have a separate graphics core, may include one or more general-purpose sequential or out-of-order cores that support both category A and category B. Of course, in different embodiments of the invention, features from one category may also be implemented in another. Programs written in high-level languages will be placed in various executable forms (e.g., just-in-time or statically compiled), including: (1) forms containing only instructions from one or more categories supported by the target processor; or (2) forms containing alternative routines written using different combinations of instructions from all categories, and forms containing control flow code that selects the routine to be executed based on the instructions supported by the processor currently executing the code.
[0138] Exemplary Specific Vector Friendly Instruction Format
[0139] FIG14A is a block diagram illustrating an exemplary vector-friendly instruction format according to an embodiment of the present invention. FIG14A illustrates a vector-friendly instruction format 1400, which is specific in that it specifies the position, size, interpretation, and order of fields, as well as the values of some of those fields. The vector-friendly instruction format 1400 can be used to extend the x86 instruction set, so some fields are similar to or the same as those used in existing x86 instruction sets and their extensions (e.g., AVX). This format is consistent with the prefix-coded fields, actual operand tuple fields, MOD R / M fields, SIB fields, shift fields, and immediate value fields of existing x86 extended instruction sets. The fields of FIG14A are shown as mapped to the fields of FIG13.
[0140] It should be understood that although embodiments of the invention are described with reference to a specific vector-friendly instruction format 1400 in the context of a general vector-friendly instruction format 1300 for illustrative purposes, the invention is not limited to the specific vector-friendly instruction format 1400 except as described in the claims. For example, the general vector-friendly instruction format 1300 takes into account various possible sizes of fields, but the specific vector-friendly instruction format 1400 is displayed as fields with a specific size. As a specific example, although the data element width field 1364 is displayed as a one-bit field in the specific vector-friendly instruction format 1400, the invention is not limited to this (i.e., the general vector-friendly instruction format 1300 takes into account other sizes of data element width fields 1364).
[0141] The general vector friendly instruction format 1300 includes the fields listed below in the order shown in Figure 14A.
[0142] The EVEX prefix (bytes 0-3) 1402- is encoded in 4-byte form.
[0143] Format field 1340 (EVEX byte 0, bits [7:0]) - The first byte (EVEX byte 0) is format field 1340 and contains 0x62 (a unique value used in one embodiment of the invention to distinguish vector friendly instruction formats).
[0144] The second to fourth bytes (EVEX bytes 1-3) include several bit fields that provide specific capabilities.
[0145] REX field 1405 (EVEX bit 1, bit [7-5]) - consists of the EVEX.R bit field (EVEX bit 1, bit [7]-R), the EVEX.X bit field (EVEX bit 1, bit [6]-X), and the EVEX.B bit field (EVEX bit 1, bit [5]-B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using complement form, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. As is known in the art, the other fields of the instruction encode the three lower bits (rrr, xxx, and bbb) of the register index so that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.
[0146] REX' field 1410 - This is the first part of REX' field 1410 and is the EVEX.R' bit field (EVEX byte 1, bit [4]-R') used to encode the higher 16 or lower 16 of the extended set of 32 registers. In one embodiment of the invention, this bit, along with the other bits indicated below, is stored in bit-inverted format to distinguish it from the BOUND instruction (in the conventional x86 32-bit mode), which has an actual operand byte of 62 but does not accept the value 11 in the MOD R / M field (described below); an alternative embodiment of the invention does not store this bit and the other bits indicated below in inverted format. The lower 16 registers are encoded using the value 1. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and other RRRs from other fields.
[0147] Operation code mapping field 1415 (EVEX byte 1, byte [3:0]-mmmm) - its content encodes the implicit leading operation code byte (0F, 0F 38, or 0F 3).
[0148] Data element width field 1364 (EVEX byte 2, bit [7]-W) - represented by the symbol EVEX.W. EVEX.W is used to define the granularity (size) of the data type (32-bit data element or 64-bit data element).
[0149] EVEX.vvvv 1420 (EVEX byte 2, bits [6:3]-vvvv)-EVEX.vvvv may have the following functions: (1) EVEX.vvvv encodes the first source register operands specified in reverse (two's complement) form and is valid for instructions with two or more source operands; (2) EVEX.vvvv encodes the destination register operands specified in two's complement form for certain vector shifts; or (3) EVEX.vvvv does not encode any operands, the field is reserved and should contain 1111b. Therefore, EVEX.vvvv field 1420 encodes the four lower-order bits of the first source register specifier stored in reverse (two's complement) form. Depending on the instruction, an additional different EVEX bit field is used to expand the specifier size to 32 registers.
[0150] EVEX.U 1368 Category field (EVEX byte 2, byte [2]-U) - If EVEX.U=0, it indicates category A or EVEX.U0; if EVEX.U=1, it indicates category B or EVEX.U1.
[0151] Prefix Encoding Field 1425 (EVEX byte 2, bits [1:0]-pp) - Provides additional bits to the base operation field. In addition to supporting conventional SSE instructions in EVEX prefix format, this also has the benefit of compressing the SIMD prefix (without requiring a single byte to represent the SIMD prefix, whereas the EVEX prefix only requires 2 bits). In one embodiment, to support conventional SSE instructions using SIMD prefixes (66H, F2H, F3H) in both conventional and EVEX prefix formats, these conventional SIMD prefixes are encoded into the SIMD prefix encoding field; and at execution time, they are first expanded to the conventional SIMD prefix before being provided to the decoder's PLA (therefore the PLA can execute these conventional instructions in both conventional and EVEX formats without modification). While newer instructions can use the contents of the EVEX prefix encoding field directly as operand expansion, some embodiments expand in a similar manner for consistency, but allow these conventional SIMD prefixes to specify different meanings. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encoding, thus eliminating the need for expansion.
[0152] α field 1352 (EVEX byte 3, bit [7]-EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl, and EVEX.N; also shown as α) - As previously stated, this field is context-specific.
[0153] β field 1354 (EVEX byte 3, bits [6:4]-SSS, also known as EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; also indicated as βββ) - As previously stated, this field is context-specific.
[0154] REX' field 1410 - This is the remainder of the REX' field and is the EVEX.V' bit field (EVEX byte 3, bit [3]-V') that can be used to encode either the higher 16 or the lower 16 of the expanded set of 32 registers. This bit is stored in reverse format. The lower 16 registers are encoded using a value of 1. In other words, V'VVVV is formed by merging EVEX.V' and EVEX.vvvv.
[0155] Write mask field 1370 (EVEX byte 3, bits [2:0]-kkk) - its content specifies the index of the register in the write mask register, as previously described. In one embodiment of the invention, the specific value EVEX.kkk=000 has the special behavior of implying that no write mask is used for a specific instruction (this can be implemented in various ways, including using write masks that are fixed to all hardware or bypassing the mask hardware).
[0156] The actual operand code field 1430 (byte 4) is also called the operand code byte. Part of the operand code is specified in this field.
[0157] MOD R / M field 1440 (byte 5) includes MOD field 1442, Reg field 1444, and R / M field 1446. As previously described, the content of MOD field 1442 distinguishes between memory access and no memory access operations. The function of Reg field 1444 can be summarized in two cases: encoding the destination register operand or the source register operand, or being regarded as an operand extension and not used to encode any instruction operand. The function of R / M field 1446 may include the following: encoding the instruction operand of the reference memory address, or encoding the destination register operand or the source register operand.
[0158] Scaling, Indexing, Base (SIB) Bytes (Byte 6) - As previously mentioned, the contents of scaling field 1360 are used for memory address generation. SIB.xxx 1454 and SIB.bbb 1456 - The contents of these fields have been previously mentioned with respect to register indices Xxxx and Bbbb.
[0159] Displacement field 1362A (bytes 7-10) - When MOD field 1442 contains 10, bytes 7-10 are displacement field 1362A, and they operate in the same way as traditional 32-bit displacement (disp32), and operate at the byte granularity.
[0160] Displacement Factor Field 1362B (Byte 7) - Byte 7 is the displacement factor field 1362B when MOD field 1442 contains 01. This field is located in the same position as the traditional x86 instruction set 8-bit displacement (disp8), operating at the byte granularity. Because disp8 is sign-extended, it can only be addressed between byte offsets of -128 and 127; for 64-byte cache lines, disp8 uses 8 bits that can be set to only four practically useful values: -128, -64, 0, and 64; since a larger range is typically required, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, the shift factor field 1362B is a reinterpretation of disp8; when using the shift factor field 1362B, the actual shift is determined by multiplying the contents of the shift factor field by the size of the memory operand access (N). This type of shift is called disp8*N. This reduces the average instruction length (a single byte is used for the shift but with a larger range). This compressed shift is based on the assumption that the effective shift is a multiple of the granularity of the memory access; therefore, redundant low-order bits of the address offset do not need to be encoded. In other words, the shift factor field 1362B replaces the traditional x86 instruction set 8-bit shift. Therefore, the encoding method of the shift factor field 1362B is the same as that of the x86 instruction set 8-bit shift (so it is not changed in the ModRM / SIB encoding rules), the only exception being that disp8 is overloaded to disp8*N. In other words, the encoding rules or encoding length remain unchanged, but the interpretation of the displacement values via hardware has changed (it requires scaling the displacement through the size of memory operands to obtain byte-wise address offsets). Immediate value field 1372 operates as previously described.
[0160] Complete Operation Code Field
[0161] FIG14B is a block diagram illustrating the fields constituting a specific vector-friendly instruction format 1400 of a complete operation code field 1374 according to an embodiment of the present invention. Specifically, the complete operation code field 1374 includes a format field 1340, a base operation field 1342, and a data element width (W) field 1364. The base operation field 1342 includes a prefix encoding field 1425, an operation code mapping field 1415, and a real operation code field 1430.
[0161] Temporary Memory Index Field
[0162] FIG14C is a block diagram illustrating the fields of a specific vector-friendly instruction format 1400 constituting a register index field 1344 according to an embodiment of the present invention. Specifically, the register index field 1344 includes a REX field 1405, a REX' field 1410, a MODR / M.reg field 1444, a MODR / Mr / m field 1446, a VVVV field 1420, an xxx field 1454, and a bbb field 1456.
[0162] Expand the calculation field
[0163] Figure 14D is a block diagram showing the fields of a specific vector-friendly instruction format 1400 constituting an extended operation field 1350 according to an embodiment of the present invention. When the category (U) field 1368 contains 0, it represents EVEX.U0 (category A 1368A); when the category (U) field 1368 contains 1, it represents EVEX.U1 (category B 1368B). When U=0 and the MOD field 1442 contains 11 (indicating no memory access operation), the α field 1352 (EVEX byte 3, bits [7]-EH) is interpreted as the rs field 1352A. When the rs field 1352A contains 1 (rounded 1352A.1), the β field 1354 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the rounding control field 1354A. The rounding control field 1354A includes a one-bit SAE field 1356 and a two-bit rounding operation field 1358. When the rs field 1352A contains 0 (data conversion 1352A.2), the β field 1354 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data conversion field 1354B. When U=0 and the MOD field 1442 contains 00, 01, or 10 (indicating memory access operation), the α field 1352 (EVEX byte 3, bits [7]-EH) is interpreted as the eviction instruction (EH) field 1352B and the β field 1354 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data operation field 1354C.
[0164] When U=1, α field 1352 (EVEX byte 3, bit [7]-EH) is interpreted as written to mask control (Z) field 1352C. When U=1 and MOD field 1442 contains 11 (indicating no memory access operation), a portion of β field 1354 (EVEX byte 3, bit [4]-S0) is interpreted as RL field 1357A; when it contains 1 (rounding 1357A.1), the remainder of β field 1354 (EVEX byte 3, bit [6-5]-S2-1) is interpreted as rounding operation field 1359A, and when RL field 1357A contains 0 (VSIZE 1357.A2), the remainder of β field 1354 (EVEX byte 3, bit [6-5]-S2-1) is interpreted as vector length field 1359B (EVEX byte 3, bit [6-5]-L1-0). When U=1 and MOD field 1442 contains 00, 01, or 10 (indicating memory access operation), β field 1354 (EVEX byte 3, bits [6:4]-SSS) is interpreted as vector length field 1359B (EVEX byte 3, bits [6-5]-L1-0) and broadcast field 1357B (EVEX byte 3, bits [4]-B).
[0164] Exemplary temporary register architecture
[0165] Figure 15 is a block diagram of a register architecture 1500 according to one embodiment of the present invention. In the illustrated embodiment, there are 32 vector registers 1510, each 512 bits wide; these registers are referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers overlay registers ymm0-16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) overlay registers xmm0-15. A specific vector-friendly instruction format 1400 operates on these overlaid register files as shown in the table below.
[0165]
[0166] In other words, the vector length field 1359B selects between a maximum length and one or more other shorter lengths, each of which is half the length of the previous length; and no instruction template with the vector length field 1359B operates on the maximum vector length. Furthermore, in one embodiment, the category B instruction template of the specific vector-friendly instruction format 1400 operates on compressed or scalar single / double precision floating-point data and compressed or scalar integer data. Scalar operations are performed on the lowest-order data element location in the zmm / ymm / xmm register; depending on the embodiment, the higher-order data element locations are kept the same as before the instruction, or zeroed out.
[0167] Write Mask Register 1515 - In the illustrated embodiment, there are eight write mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, the write mask register 1515 is 16 bits in size. As previously stated, in one embodiment of the invention, the vector mask register k0 cannot be used as a write mask; when the encoding of the normal indicator k0 is used for the write mask, it selects a fixed-line write mask of 0xFFFF, effectively disabling the write mask for that instruction.
[0168] General-purpose registers 1525 - In the illustrated embodiment, there are 16 64-bit general-purpose registers, which, together with the existing x86 addressing mode, are used to address memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.
[0169] Scalar floating-point stacked register file (x87 stack) 1545, on which MMX compressed integer flat register file 1550 is overlaid - In the illustrated embodiment, the x87 stack is an eight-element stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions; while the MMX register is used to perform operations on 64-bit compressed integer data, and to store operands for certain operations performed between the MMX and XMM registers.
[0170] Alternative embodiments of the present invention may use wider or narrower registers. Furthermore, alternative embodiments of the present invention may use more, fewer, or different register files and registers.
[0170] Exemplary core architecture, processor, and computer architecture
[0171] The processor core can be implemented in different ways, for different purposes, and in different processors. For example, such core implementations may include: (1) a general-purpose sequential core for general-purpose computing; (2) a high-performance general-purpose out-of-order core for general-purpose computing; and (3) a dedicated core primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include: (1) a CPU, including one or more general-purpose sequential cores for general-purpose computing and / or one or more general-purpose out-of-order cores for general-purpose computing; and (2) a coprocessor, including one or more dedicated cores primarily for graphics and / or scientific (throughput) computing. This variety of processors leads to 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, such a coprocessor is sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or a dedicated core); and (4) a system-on-a-chip (SoC) that may include the CPU (sometimes referred to as an application core or application processor), the aforementioned coprocessors, and additional functionality on the same die. An exemplary core architecture will be described next, followed by exemplary processors and computer architectures.
[0171] Exemplary Core Architecture
[0171] Sequential and Randomized Core Block Diagram
[0172] Figure 16A is a block diagram illustrating an exemplary in-order pipeline and exemplary register renaming and out-of-order issue / execution pipeline according to an embodiment of the present invention. Figure 16B is a block diagram illustrating an exemplary embodiment of an in-order architecture core to be included in a processor according to an embodiment of the present invention and exemplary register renaming and out-of-order issue / execution pipeline. Solid boxes in Figures 16A-B show in-order pipelines and in-order cores, while optional additional dashed boxes show register renaming, out-of-order issue / execution pipelines and cores. The out-of-order pattern will be described assuming that the in-order pattern is a subset of the out-of-order pattern.
[0173] In Figure 16A, the processor pipeline 1600 includes a fetch phase 1602, a length decoding phase 1604, a decoding phase 1606, an allocation phase 1608, a renaming phase 1610, a scheduling (also known as dispatch or issue) phase 1612, a register read / memory read phase 1614, an execution phase 1616, a write-back / memory write phase 1618, an exception handling phase 1622, and a commit phase 1624.
[0174] Figure 16B shows a processor core 1690, including a front-end unit 1630 coupled to an execution engine unit 1650, and both the execution engine unit 1650 and the front-end unit 1630 are coupled to a memory unit 1670. Core 1690 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, core 1690 can be a dedicated core, such as a networking or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.
[0175] Front-end unit 1630 includes branch prediction unit 1632, which is coupled to instruction cache unit 1634. Instruction cache unit 1634 is coupled to instruction translation lookaside buffer (TLB) 1636, which is coupled to instruction fetch unit 1638. Instruction fetch unit 1638 is coupled to decoding unit 1640. Decoding unit 1640 (or decoder) can decode instructions and generate one or more micro-operations, microcode entry points, micro-instructions, other instructions, or other control signals as outputs, which are decoded from, reflect, or derived from the original instructions. Various different mechanisms can be used to implement decoding unit 1640. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), etc. In one embodiment, core 1690 includes a microcode ROM or other media storing microcode for certain macro instructions (e.g., in decoding unit 1640 or within front-end unit 1630). Decoding unit 1640 is coupled to renaming / allocator unit 1652 in execution engine unit 1650.
[0176] The execution engine unit 1650 includes a renaming / allocator unit 1652 coupled to the retirement unit 1654 and a collection of one or more scheduler units 1656. The scheduler units 1656 represent any number of different schedulers, including reserved stations, central command windows, etc. The scheduler units 1656 are coupled to physical register file units 1658. Each of the physical register file units 1658 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, which is the address of the next instruction to be executed), etc. In one embodiment, the physical register file unit 1658 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 1658 is overlapped by retirement unit 1654 to illustrate various ways in which register renaming and out-of-order execution can be performed (e.g., using a reorder buffer and retirement register file; using a future file, a history buffer, and retirement register file; using register mapping and register pools; etc.). Retirement unit 1654 and physical register file unit 1658 are coupled to execution cluster 1660. Execution cluster 1660 includes a set of one or more execution units 1662 and a set of one or more memory access units 1664. Execution units 1662 can perform various operations (e.g., offset, addition, subtraction, multiplication) and various data types (e.g., scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers). While some embodiments may include several execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Scheduler unit 1656, physical register file unit 1658, and execution cluster 1660 are shown as possibly multiple, because some embodiments establish separate pipelines for certain data / operation types (e.g., scalar integer pipeline, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipeline, and / or memory access pipeline, 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 where only the execution cluster of this pipeline has memory access unit 1664). It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be out-of-order issued / executed, while others are sequential.
[0177] A set of memory access units 1664 is coupled to a memory unit 1670, which includes a data TLB unit 1672, which is coupled to a data cache unit 1674, which is coupled to a second-order (L2) cache unit 1676. In an exemplary embodiment, the memory access unit 1664 may include a load unit, a storage address unit, and a storage data unit, each of which is coupled to the data TLB unit 1672 in the memory unit 1670. An instruction cache unit 1634 is further coupled to the second-order (L2) cache unit 1676 in the memory unit 1670. The L2 cache unit 1676 is coupled to one or more other-order caches and is ultimately coupled to main memory.
[0178] As an example, the exemplary register renaming, out-of-order issuance / execution core architecture can implement pipeline 1600 as follows: (1) Instruction fetch 1638 executes fetch and length decoding stages 1602 and 1604; (2) Decoding unit 1640 executes decoding stage 1606; (3) Rename / allocator unit 1652 executes allocation stage 1608 and renaming stage 1610; (4) Scheduler unit 1656 executes scheduling stage 1612; (5) (6) The physical register file unit 1658 and the memory unit 1670 perform the register read / memory read phase 1614; the execution cluster 1660 performs the execution phase 1616; (7) the memory unit 1670 and the physical register file unit 1658 perform the write-back / memory write phase 1618; (8) the various units may involve the exception handling phase 1622; and (9) the retirement unit 1654 and the physical register file unit 1658 perform the commit phase 1624.
[0179] Core 1690 may support one or more instruction sets (e.g., the x86 instruction set (with extensions added with newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California; the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California (with optional additional extensions such as NEON)), which include the instructions described herein. In one embodiment, core 1690 includes logic for supporting compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing the use of compressed data to perform operations used by many multimedia applications.
[0180] It should be understood that the core can support multithreading (execution of two or more parallel groups of operations or thread groups) and can be performed in a variety of ways, including time-sliced multithreading, simultaneous multithreading (where a single physical core provides a logical core to each thread that is being simultaneously multithreaded by the physical core), or a combination thereof (e.g., time-sliced fetching and decoding followed by simultaneous multithreading, such as in Intel® Hyperthreading technology).
[0181] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in sequential architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units 1634 / 1674 and a shared L2 cache unit 1676, alternative embodiments may have a single internal cache for both instructions and data, such as a first-order (L1) internal cache, or multiple-order internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be located outside the core and / or processor.
[0181] Specific exemplary sequential core architecture
[0182] Figures 17A-B show block diagrams of a more specific exemplary sequential core architecture, the core of which will be one of several logic blocks in the chip (including other cores of the same type and / or different types). Depending on the application, these logic blocks communicate with some fixed functional logic, memory I / O interfaces and other necessary I / O logic through a high-bandwidth interconnect network (e.g., a ring network).
[0183] Figure 17A is a single-processor core according to an embodiment of the present invention, its connection to the on-die interconnect 1702, and a local subset 1704 of its second-order (L2) cache. In one embodiment, the instruction decoder 1700 supports the x86 instruction set with Compact Data Instruction Set Extensions. The L1 cache 1706 allows low-latency access to cache memory into scalar and vector units. Although in one embodiment (for simplicity), scalar unit 1708 and vector unit 1710 use separate sets of registers (scalar register 1712 and vector register 1714, respectively) and transfer data between them to memory, and then read back from the first-order (L1) cache 1706, alternative embodiments of the present invention may use different methods (e.g., using a single set of registers or including a communication path that allows data to be transferred between two register files without writing and reading back).
[0184] The local subset 1704 of the L2 cache is part of the global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset 1704 of the L2 cache. Data read by a processor core is stored in its L2 cache subset 1704 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 1704 and is cleared from other subsets if necessary. The ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches, and other logical blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.
[0185] FIG17B is an extended view of a portion of the processor core in FIG17A according to an embodiment of the present invention. FIG17B includes L1 data cache 1706A, a portion of L1 cache 1706, and further details regarding vector unit 1710 and vector register 1714. Specifically, vector unit 1710 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1728) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports rearranging integer inputs using rearrangement unit 1720, performing numerical conversions using value conversion units 1722A-B, and copying memory inputs using copy unit 1724. Write mask register 1726 allows assertion result vector writing.
[0186] FIG18 is a block diagram of a processor 1800 according to an embodiment of the present invention, which may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid boxes in FIG18 show a processor 1800 having a single core 1802A, a system agent 1810, and a group of one or more bus controller units 1816, while the dashed boxes optionally show alternative processors 1800 having multiple cores 1802A-N, a group of one or more integrated memory controller units 1814 in the system agent units 1810, and dedicated logic 1808.
[0187] Therefore, different implementations of the processor 1800 may include: (1) a CPU, wherein the dedicated logic 1808 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and the cores 1802A-N are one or more general-purpose cores (e.g., general-purpose sequential cores, general-purpose out-of-order cores, or a combination of both); (2) a coprocessor, wherein the cores 1802A-N are a large number of dedicated cores primarily used for graphics and / or scientific (throughput); and (3) a coprocessor, wherein the cores 1802A-N are a large number of general-purpose sequential cores. Therefore, the processor 1800 may be a general-purpose processor, a coprocessor, or a dedicated processor, such as a network or communications processor, a compression engine, a graphics processor, a GPGPU (General-Purpose Graphics Processing Unit), a high-throughput multi-integral-core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. The processor 1800 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of process technologies such as BiCMOS, CMOS or NMOS.
[0188] The memory hierarchy includes one or more levels of caches within the core, a group or one or more shared cache units 1806, and external memory (not shown) coupled to the group of integrated memory controller units 1814. The group of shared cache units 1806 may include one or more intermediate-level caches, such as second-order (L2), third-order (L3), fourth-order (L4), or other-order caches, final-order caches (LLC), and / or combinations thereof. Although in one embodiment, ring-based interconnect units 1812 interconnect integrated graphics logic 1808 (integrated graphics logic 1808 is an example of dedicated logic and is also referred to herein as dedicated logic), the group of shared cache units 1806, and system proxy units 1810 / integrated memory controller units 1814, alternative embodiments may use any known technology to interconnect these units. In one embodiment, consistency between one or more cache units 1806 and cores 1802-AN is maintained.
[0189] In some embodiments, one or more of the cores 1802A-N are capable of multithreaded processing. System agent 1810 includes those elements that coordinate and operate the cores 1802A-N. System agent unit 1810 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or may include the logic and elements required to regulate the power states of the cores 1802A-N and integrated graphics logic 1808. The display unit is used to drive one or more externally connected displays.
[0190] The 1802A-N cores can be homogeneous or heterogeneous in terms of their instruction sets; that is, two or more of the 1802A-N cores can execute the same instruction set, while others can execute only a subset of that instruction set or a different instruction set.
[0190] Exemplary Computer Architecture
[0191] Figures 19-22 are block diagrams of exemplary computer architectures. Other system designs and configurations known in the art for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video gaming devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally, a wide variety of systems or electronic devices capable of incorporating processors and / or other execution logic as described herein are generally suitable.
[0192] Referring now to FIG19, a block diagram of a system 1900 according to one embodiment of the present invention is shown. The system 1900 may include one or more processors 1910, 1915 coupled to a controller hub 1920. In one embodiment, the controller hub 1920 includes a graphics memory controller hub (GMCH) 1990 and an input / output hub (IOH) 1950 (which may be on different chips); the GMCH 1990 includes memory and a graphics controller, to which memory 1940 and a coprocessor 1945 are coupled; the IOH 1950 couples an input / output (I / O) device 1960 to the GMCH 1990. Alternatively, one or both of the memory and graphics controller are integrated within the processor (as described herein), with memory 1940 and coprocessor 1945 directly coupled to processor 1910, and controller hub 1920 in a single chip with IOH 1950.
[0193] In Figure 19, the optional properties of the additional processor 1915 are indicated by dashed lines. Each processor 1910, 1915 may include one or more of the processing cores described herein, and may be a version of processor 1800.
[0194] Memory 1940 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of both. In at least one embodiment, controller hub 1920 communicates with processors 1910, 1915 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a fast path interconnect (QPI), or a similar connection 1995.
[0195] In one embodiment, the common processor 1945 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc. In one embodiment, the controller hub 1920 may include an integrated graphics accelerator.
[0196] In terms of the range of measures including advantages such as architecture, microarchitecture, thermal, and power consumption characteristics, there can be various differences between entity resources 1910 and 1915.
[0197] In one embodiment, processor 1910 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 1910 identifies these coprocessor instructions as types to be executed by the attached coprocessor 1945. Therefore, processor 1910 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1945 on the coprocessor bus or other interconnect. Coprocessor 1945 receives and executes the received coprocessor instructions.
[0198] Referring now to FIG. 20, a block diagram of a first more specific exemplary system 2000 according to an embodiment of the present invention is shown. As shown in FIG. 20, the multiprocessor system 2000 is a point-to-point interconnect system and includes a first processor 2070 and a second processor 2080 coupled via a point-to-point interconnect 2050. Each of processors 2070 and 2080 may be a version of processor 1800. In one embodiment of the invention, processors 2070 and 2080 are processors 1910 and 1915, respectively, and a coprocessor 2038 is a coprocessor 1945. In another embodiment, processors 2070 and 2080 are processor 1910 and coprocessor 1945, respectively.
[0199] Processors 2070 and 2080 are shown to include integrated memory controller (IMC) units 2072 and 2082, respectively. Processor 2070 also includes point-to-point (PP) interfaces 2076 and 2078 as part of its bus controller unit; similarly, the second processor 2080 includes PP interfaces 2086 and 2088. Processors 2070 and 2080 can exchange information via point-to-point (PP) interface 2050 using PP interface circuitry 2078 and 2088. As shown in FIG20, IMCs 2072 and 2082 couple the processors to individual memories, namely memories 2032 and 2034, which can be localized to portions of the main memory connected to those individual processors.
[0200] Processors 2070 and 2080 can exchange information with chipset 2090 via point-to-point interface circuits 2076, 2094, 2086, and 2098 through their respective PP interfaces 2052 and 2054. Chipset 2090 can optionally exchange information with coprocessor 2038 via high-performance interface 2092. In one embodiment, coprocessor 2038 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc.
[0201] A shared cache (not shown) may be included in either processor or external to both processors but still connected to them via a PP interconnect, such that if one processor is in a low-power mode, local cache information of either or both processors may be stored in the shared cache.
[0202] Chipset 2090 may be coupled to first bus 2016 via interface 2096. In one embodiment, first bus 2016 may be a peripheral component interconnect (PCI) bus, or a bus such as a fast peripheral component interconnect (PCI Express) bus or another third-generation I / O interconnect bus, although the scope of the invention is not limited thereto.
[0203] As shown in FIG20, various I / O devices 2014 may be coupled to the first bus 2016, in addition to the bus bridge 2018 that couples the first bus 2016 to the second bus 2020. In one embodiment, one or more additional processors 2015, such as coprocessors, high-throughput MIC processors, GPGPU accelerators (e.g., graphics accelerators or digital signal processing (DSP) units), field-programmable gate arrays, or any other processors, are coupled to the first bus 2016. In one embodiment, the second bus 2020 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 2020, including, for example, a keyboard and / or mouse 2022, a communication device 2027, and a storage unit 2028 such as a disk drive or other mass storage device, which may include instruction / code and data 2030. Furthermore, audio I / O 2024 may be coupled to the second bus 2020. It should be noted that other architectures are possible. For example, instead of the point-to-point architecture in Figure 20, the system can be implemented as a multi-point bus or other similar architectures.
[0204] Referring now to FIG. 21, a block diagram of a second more specific exemplary system 2100 according to an embodiment of the present invention is shown. Similar elements in FIG. 20 and 21 have similar reference numerals, and certain aspects of FIG. 20 are omitted in FIG. 21 so as not to obscure other aspects of FIG. 21.
[0205] Figure 21 shows that processors 2070 and 2080 may include integrated memory and I / O control logic (“CL”) 2072 and 2082, respectively. Therefore, CL 2072 and 2082 include integrated memory controller units and I / O control logic. Figure 21 shows that not only are memories 2032 and 2034 coupled to CL 2072 and 2082, but I / O devices 2114 are also coupled to control logic 2072 and 2082. Conventional I / O devices 2115 are coupled to chipset 2090.
[0206] Referring now to FIG. 22, a block diagram of an SoC 2200 according to an embodiment of the present invention is shown. Similar elements in FIG. 18 have similar reference numerals. Similarly, dashed boxes represent optional features on more advanced SoCs. In FIG. 22, interconnect unit 2202 is coupled to: application processor 2210, which includes one or more cores 1802A-N containing cache units 1804A-N, and a shared cache unit 1806; system proxy unit 1810; bus controller unit 1816; integrated memory controller unit 1814; one or more coprocessors 2220, which may include integrated graphics logic, a video processor, an audio processor, and a video processor; static random access memory (SRAM) unit 2230; direct memory access (DMA) unit 2232; and display unit 2240 for coupling to one or more external displays. In one embodiment, one or more coprocessors 2220 include dedicated processors, such as network or communication processors, compression engines, GPGPUs, high-throughput MIC processors, embedded processors, and so on.
[0207] Embodiments of the means disclosed herein may be implemented in hardware, software, firmware, or a combination of these methods. 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.
[0208] Code, such as code 2030 shown in FIG20, 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 known ways. For the purposes of this application, the processing system includes any system having a processor such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.
[0209] The code can be implemented in a high-level program or object-oriented programming language to communicate with the processing system. If necessary, the code can also be implemented in composition language or machine language. In fact, the methods described herein are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.
[0210] One or more embodiments of at least one example may be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, causing the machine to manufacture the logic to perform the techniques described herein when the instructions are read by the machine. Such a representative, referred to as an "IP core," may be stored on a tangible, machine-readable medium and provided to various customers or manufacturers for loading into manufacturing machines that produce the actual manufacturing logic or processor.
[0211] Such machine-readable storage media may include, but is not limited to, non-transitory, tangible configurations of objects made or formed by a machine or apparatus, including storage media such as hard disks, including floppy disks, optical disks, read-only optical disk memory (CD-ROM), rewritable optical disks (CD-RW), and any other type of magnetic optical disks, semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
[0212] Therefore, embodiments of the present invention also include non-transient, tangible machine-readable media containing instructions or design data, such as hardware description languages (HDLs), which define the architectures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products.
[0212] Emulation (including binary translation, code transformation, etc.)
[0213] In some cases, an instruction translator can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can translate (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), morph, emulate, or translate instructions into one or more other instructions that will be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on the processor, off the processor, or partially on the processor and partially off the processor.
[0214] FIG23 is a block diagram comparing the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present invention. In the illustrated embodiment, the instruction converter is a software instruction converter, although the instruction converter may alternatively be implemented in software, hardware, or various combinations thereof. FIG23 shows that a program of a high-level language 2302 can be compiled using an x86 compiler 2304 to produce x86 binary code 2306, which can be natively executed by a processor 2316 having at least one x86 instruction set core. A processor 2316 having at least one x86 instruction set core represents any processor capable of substantially performing the same functions as an Intel processor having at least one x86 instruction set core, wherein such performance is achieved by compatiblely executing or processing (1) a large portion of the instruction set of the Intel x86 instruction set core, or (2) a version of the object code of an application or other software intended to run on an Intel processor having at least one x86 instruction set core, in order to achieve substantially the same results as an Intel processor having at least one x86 instruction set core. x86 compiler 2304 represents a compiler operable to produce x86 binary code 2306 (e.g., object code) executable on a processor 2316 having at least one x86 instruction set core, with or without additional linking processing. Similarly, Figure 23 shows that an alternative instruction set compiler 2308 can be used to compile a program of high-level language 2302 to produce alternative instruction set binary code 2310, which can be natively executed by a processor 2314 that does not have at least one x86 instruction set core (e.g., a processor with a core executing the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California, and / or the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California, USA). An instruction translator 2312 is used to translate the x86 binary code 2306 into code executable natively by the processor 2314 that does not have an x86 instruction set core. The converted code is unlikely to be the same as the alternative instruction set binary code 2310, because it would be difficult to manufacture an instruction converter capable of doing so; however, the converted code will perform general operations and consists of instructions from the alternative instruction set. Therefore, the instruction converter 2312 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without an x86 instruction set processor or core to execute x86 binary code 2306 via emulation, simulation, or any other processing.
Claims
1. An apparatus comprising: The decoder is used to decode a single instruction that has an operand field and four operand fields, the four operand fields including: The first operand field is used to indicate the first source compressed data register, which is used to store first source compressed data elements. The second operand field is used to indicate the second source compressed data register, which is used to store second source compressed data elements. The third operand field indicates the source and destination (source / destination) compressed data register, which stores the third source compressed data element and the result compressed data element. The fourth operand field is used to indicate the write mask register, which is used to store multiple bit values to conditionally control the operation of each element indicated by the single instruction. Wherein, the first and second source compressed material elements are material elements of a first size, which are different from the second size of the third source compressed material element and the resulting compressed material element; The register file includes the first source compressed data register, the second source compressed data register, and the source / destination compressed data register; and The execution circuit is used to execute the decoded single instruction to compress the data element for each result: If the corresponding bit value in the write mask register is set to the first value, then either save the existing value of the result compressed data element or set the result compressed data element to zero; and If the corresponding bit value in the write mask register is set to the second value, then: Multiply the first quantity of the first source compressed data element by the corresponding compressed data element of the second source compressed data element to produce the first quantity of product. The product of the first quantity is added to the corresponding compressed data element from the third source compressed data element to produce the resulting compressed data element of the second size at the corresponding position in the source / destination compressed data register.
2. The apparatus of claim 1, wherein the first quantity is equal to the second dimension divided by the first dimension.
3. The apparatus of claim 1 or 2, wherein the first value includes a value of 0 and the second value includes a value of 1.
4. The apparatus of claim 1, wherein the resulting compressed data element includes a compressed 32-bit floating-point value.
5. The apparatus of claim 1, wherein the first dimension and the second dimension are based on the arithmetic code value.
6. The apparatus of claim 1, wherein the first dimension is half or a quarter of the second dimension.
7. The apparatus of claim 1, wherein the register file further includes the write mask register.
8. A method comprising: Decode a single instruction, which has an operand field and four operand fields, the four operand fields including: The first operand field is used to indicate the first source compressed data register, which is used to store first source compressed data elements. The second operand field is used to indicate the second source compressed data register, which is used to store second source compressed data elements. The third operand field indicates the source and destination (source / destination) compressed data register, which stores the third source compressed data element and the result compressed data element. The fourth operand field is used to indicate the write mask register, which is used to store multiple bit values to conditionally control the operation of each element indicated by the single instruction. Wherein, the first and second source compressed material elements are material elements of a first size, which are different from the second size of the third source compressed material element and the resulting compressed material element; Execute the single instruction following the decoding to compress the data element for each result: If the corresponding bit value in the write mask register is set to the first value, then either save the existing value of the result compressed data element or set the result compressed data element to zero; and If the corresponding bit value in the write mask register is set to the second value, then: Multiply the first quantity of the first source compressed data element by the corresponding compressed data element of the second source compressed data element to produce the first quantity of product. The product of the first quantity is added to the corresponding compressed data element from the third source compressed data element to produce the resulting compressed data element of the second size at the corresponding position in the source / destination compressed data register.
9. The method of request item 8, wherein the first quantity is equal to the second dimension divided by the first dimension.
10. The method of request item 8 or 9, wherein the first value includes a value of 0 and the second value includes a value of 1.
11. The method of request item 8, wherein the resulting compressed data element includes a compressed 32-bit floating-point value.
12. The method of request item 8, wherein the first dimension and the second dimension are based on the arithmetic code value.
13. The method of claim 8, wherein the first dimension is half or a quarter of the second dimension.
14. A computer program product, comprising instructions that, when executed by a processor, cause the processor to perform a method as described in any one of claims 8 to 13.
15. A computer-readable storage medium having a computer program product as claimed in claim 14 stored thereon.