Processing unit, method, computer program product, and machine-readable storage medium for calculating scalar products of nibbles in operands from two tiles

Abstract

Processing unit (3000) comprising: a circuit arrangement for performing operations according to an instruction (2102), the instruction (2102) specifying a first matrix with M rows by K columns of 32-bit elements each having eight 4-bit data elements, a second matrix with K rows by N columns of 32-bit elements each having eight 4-bit data elements, and a third matrix with M rows by N columns, the instruction having a first indicator for indicating whether the 4-bit data elements of the first matrix are signed or unsigned, and a second indicator for indicating whether the 4-bit data elements of the second matrix are signed or unsigned, the operations including: for each row m of the M rows of the first matrix and for each column n of the N columns of the second matrix: for each of the K 32-bit elements of row m of the first matrix: Multiplying eight 4-bit data elements of the 32-bit element of row m of the first matrix by corresponding ones of eight 4-bit data elements of a corresponding 32-bit element of column n of the second matrix to produce eight products; and Storing a 32-bit result data item in a row m of the M rows and a column n of the N columns of the third matrix, the 32-bit result data item being based on accumulation of the eight products generated for each of the K 32-bit elements of row m of the first matrix with a 32-bit data item of row m of the first matrix and column n of the second matrix.

Description

FIELD OF THE INVENTION

[0001] The field of the invention relates generally to a computer processor architecture, and more particularly to a processing unit, a method, a computer program product, and a machine-readable storage medium for computing dot products of nibbles in operands from two tiles. STATE OF THE ART

[0002] Matrices are becoming increasingly important in many computational tasks, such as machine learning and other processing of mass data.

[0003] US 2016 / 0179523 A1 describes an apparatus and method for performing a vector broadcast and a logical XORAND instruction in a computer processor.By way of example, the described processor includes: fetch logic to fetch an instruction from memory specifying a packed destination data operand, a first packed source data operand, a second packed source data operand, and an immediate operand, and execution logic to determine a bit in the second packed source data operand based on a position corresponding to the immediate value, perform a bitwise AND between the first packed source data operand and the determined bit to produce an intermediate result, perform a bitwise XOR between the packed destination data operand and the intermediate result to produce a final result, and store the final result at a memory location specified by the packed destination data operand. SUMMARY OF THE INVENTION

[0004] It can therefore be considered an object of the present invention to propose a processing unit, a method, a computer program product and a machine-readable storage medium for determining a dot product for tiles with improved efficiency and flexibility.

[0005] The above object is achieved according to the invention with the processing unit according to the main claim 1, the method according to the independent claim 14, the computer program product according to the independent claim 25 and the machine-readable storage medium according to the independent claim 26. The dependent claims define further developments of the solutions according to the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present invention is illustrated by way of example, but not by way of limitation, in the figures of the accompanying drawings, in which like references indicate similar elements and in which: Fig. 1A illustrates one embodiment of configured tiles; Fig. 1B illustrates an embodiment of configured tiles; Fig. Figure 2 illustrates several examples of matrix storage; Fig. 3 illustrates an embodiment of a system employing an accelerator for matrix operations (tile operations); Fig. 4 and Fig. 5 various embodiments show how memory is shared using a matrix accelerator; Fig. 6 illustrates an embodiment of a matrix multiply-accumulate operation using tiles (“TMMA”); Fig. 7 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction; Fig.8 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction; Fig. 9 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction; Fig. 10 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction; Fig. 11 illustrates SIMD implementations sized to a power of two, according to one embodiment, where the accumulators use input sizes larger than the inputs to the multipliers; Fig. 12 illustrates an embodiment of a system employing matrix operation circuitry; Fig. 13 illustrates an embodiment of a processor core pipeline that supports matrix operations using tiles; Fig. 14 illustrates an embodiment of a processor core pipeline that supports matrix operations using tiles; Fig. 15 illustrates an example of a matrix expressed in row-by-row format and in column-by-column format; Fig. 16 illustrates an example of the use of matrices (tiles); Fig. 17 illustrates an embodiment of a method for using matrices (tiles); Fig. 18 illustrates support for configuring the use of tiles according to one embodiment; Fig. 19 illustrates an embodiment of a description of the matrices (tiles) to be supported; Fig. 20(A)-(D) illustrate examples of a register(s); Fig. 21 illustrates an example execution of a TILELOADQPAIR instruction; Fig.22 illustrates an embodiment of a processor executing a TILELOADQPAIR instruction; Fig. 23 illustrates a more detailed description of an execution of a TILELOADQPAIR instruction; Fig. 24A is exemplary pseudocode describing one embodiment of a processor executing a TILELOADQPAIR instruction; Fig. 24B is exemplary pseudocode describing one embodiment of helper functions used by a processor executing a TILELOADQPAIR instruction; Fig. 25A-25B are block diagrams illustrating a generic vector-friendly instruction format and instruction templates thereof according to embodiments of the invention; Fig. 25A is a block diagram illustrating a generic vector-friendly instruction format and Class A instruction templates thereof according to embodiments of the invention; Fig.25B is a block diagram illustrating the generic vector-friendly instruction format and Class B instruction templates thereof according to embodiments of the invention; Fig. 26A is a block diagram illustrating an exemplary specific vector-friendly instruction format according to embodiments of the invention; Fig. 26B is a block diagram illustrating the fields of the specific vector-friendly instruction format that form the complete opcode field according to one embodiment of the invention; Fig. 26C is a block diagram illustrating the fields of the specific vector-friendly instruction format that form the register index field according to one embodiment of the invention; Fig. 26D is a block diagram illustrating the fields of the specific vector-friendly instruction format that form the operation overlay field according to one embodiment of the invention; Fig. 27 is a block diagram of a register architecture according to an embodiment of the invention; Fig. 28A is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to embodiments of the invention; Fig. 28B is a block diagram illustrating both an embodiment of an in-order architecture core and a register renaming, out-of-order issue / execution architecture core to be included in a processor according to embodiments of the invention; Fig. 29A-B illustrate a block diagram of a more specific example in-order core architecture, where the core would be one of several logical blocks (including other cores of the same type and / or other types) in a chip; Fig.29A is a block diagram of a single processor core, along with its connection to the on-chip interconnect network and its local subset of Level 2 (L2) cache, according to embodiments of the disclosure; Fig. 29B an expanded view of a portion of the processor core in Fig. 29A is according to embodiments of the invention; Fig. 30 is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to embodiments of the invention; Fig. 31-34 are block diagrams of example computer architectures; Fig. 31 shows a block diagram of a system in accordance with an embodiment of the present invention; Fig.32 is a block diagram of a first more specific exemplary system in accordance with an embodiment of the present invention; Fig. 33 is a block diagram of a second, more specific exemplary system in accordance with an embodiment of the present invention; Fig. 34 is a block diagram of a system-on-chip (SoC) in accordance with an embodiment of the present invention; and Fig. 35 is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a destination instruction set according to embodiments of the invention. DETAILED DESCRIPTION

[0007] In many commercially available processors, matrices are a difficult and / or instruction-intensive task. For example, rows of a matrix might be placed into multiple packed data registers (e.g., SIMD or vector registers) and then processed individually. For example, adding two 8x2 matrices might require one load or be accumulated into four packed data registers, depending on data sizes. A first addition of packed data registers corresponding to a first row of each matrix is ​​performed, and a second addition of packed data registers corresponding to a second row of each matrix is ​​performed. The resulting packed data registers are then flushed back into memory. While this scenario may be acceptable for small matrices, it is often unacceptable for larger matrices. I. HIGH-LEVEL MEETING

[0008] This document describes mechanisms for supporting matrix operations in computer hardware such as central processing units (CPUs), graphics processing units (GPUs), and accelerators. The matrix operations employ 2-dimensional (2D) data structures that represent one or more packed memory regions such as registers. Throughout this description, these 2D data structures are referred to as tiles. Note that a matrix can be smaller than a tile (using less than the entirety of a tile) or can use multiple tiles (the matrix is ​​larger than the size of a tile). Throughout this description, matrix language (tile) is used to indicate operations performed using tiles that affect a matrix; whether that matrix is ​​larger than a tile or not is typically not relevant.

[0009] Various operations can operate on each tile, such as those described in detail herein and including, but not limited to: matrix multiplication (tile multiplication), tile addition, tile subtraction, tile diagonal, tile zeroing, tile transposition, tile dot product, tile transfer, tile row transfer, tile column transfer, tile multiplication, tile multiplication and accumulation, tile movement, etc. Additionally, support for operators such as using scaling and / or offsetting may be used with these operations or to support future non-numeric applications, such as "local memory" for OpenCL, data compression / decompression, etc.

[0010] Sections of memory (such as memory (non-volatile and volatile), registers, cache, etc.) are arranged in tiles with various horizontal and vertical dimensions. A tile can have a horizontal dimension of 4 (e.g., four rows of a matrix) and a vertical dimension of 8 (e.g., 8 columns of the matrix). Typically, the horizontal dimension is associated with element sizes (e.g., 2-, 4-, 8-, 16-, 32-, 64-, 128-bit, etc.). Multiple data types (single-precision floating-point, double-precision floating-point, integer, etc.) may be supported. A. EXAMPLE USE OF CONFIGURED TILES

[0011] In some embodiments, tile parameters can be configured. For example, a particular tile can be configured to provide tile options. Example tile options include, but are not limited to: a number of rows of the tile, a number of columns of the tile, whether the tile is VALID, and whether the tile consists of a PAIR of equal-sized tiles.

[0012] Fig.1A illustrates one embodiment of configured tiles. As shown, 4 KB of application memory 102 has 4 1 KB tiles stored thereon: tile 0 104, tile 1 106, tile 2 108, and tile 3 110. In this example, the 4 tiles are not in pairs and each has elements arranged in rows and columns. Tile t0 104 and tile t1 106 have K rows and N columns of 4-byte elements (e.g., single-precision data), where K equals 8 and N = 32. Tile t2 108 and tile t3 110 have K rows and N / 2 columns of 8-byte elements (e.g., double-precision data). Because the double-precision operands are twice the width of the single-precision ones, this configuration is compatible with a palette used to provide tiling options, providing at least 4 identifiers with a total memory of at least 4 kB.In operation, tiles can be loaded from and stored in memory using load and store operations. Depending on the instruction coding scheme used, the amount of available application memory, as well as the size, number, and configuration of available tiles, varies.

[0013] Fig.1B illustrates one embodiment of configured tiles. As shown, 4 KB of application memory 122 has two pairs of 1 KB tiles stored thereon, the first pair consisting of tile t4L 124 and tile t4R 126, and the second pair consisting of tile t5L 128 and tile t5R 130. As shown, the tile pairs are divided into a left tile and a right tile. In other embodiments, the tile pairs are divided into an even tile and an odd tile. In this example, the four tiles each have elements arranged in rows and columns. Tile t4L 124 and tile t4R 126 have K rows and N columns of 4-byte elements (e.g., single-precision data), where K equals 8 and N equals 32. Tile t5L 128 and tile t5R 130 have K rows and N / 2 columns of 8-byte elements (e.g., double-precision data).Because the double-precision operands are twice the width of the single-precision ones, this configuration is compatible with a palette used to provide tiling options, providing at least two identifiers with a total storage of at least 4 KB. The four tiles of . Fig. 1A uses 4 identifiers, each naming a 1-kB tile, where the 2 tile pairs in Fig. 1B 2 identifiers to specify the paired tiles. In some embodiments, tiling instructions accept a paired tile identifier as an operand. In operation, the tiles can be loaded from and stored in memory using load and store operations. Depending on the instruction encoding scheme used, the amount of available application memory, as well as the size, number, and configuration of available tiles, varies.

[0014] In some embodiments, tile parameters can be defined. For example, a "palette" is used to provide tile options. Example options include, but are not limited to: the number of tile identifiers, the number of bytes in a memory line, the number of rows and columns in a tile, etc. For example, a maximum "height" (number of rows) of a tile can be defined as follows:

[0015] Max. tile rows = memory architecture / (number of palette identifiers * number of bytes per row).

[0016] As such, an application can be written so that a fixed use of identifiers can take advantage of different memory sizes across implementations.

[0017] Tile configuration is performed using a tile configuration statement ("TILECONFIG"), where a specific tile usage is defined in a selected palette. This declaration includes the number of tile names to use, the requested number of rows and columns per identifier (tile), and, in some embodiments, the requested data type of each tile. In some embodiments, consistency checks are performed during the execution of a TILECONFIG statement to determine that it conforms to the constraints of the palette entry. B. EXAMPLE TILE STORAGE TYPES

[0018] Fig.Figure 2 illustrates several examples of matrix storage. In (A), a tile is stored in memory. As shown, each "row" consists of four packed data elements. A stride value is used to move to the next "row." Note that rows can be stored consecutively in memory. A stride-by-step memory access allows access to one row and then the next if the tile storage does not map to the row width of the underlying memory array.

[0019] Tile loads and stores to memory are typically step-by-step accesses from application memory to packed data rows. Example TILELOAD and TILESTORE instructions, or other instruction references to application memory as a TILE operand in load operation instructions, may be restarted in some embodiments to handle (up to) 2*rows of page faults, unmasked floating-point exceptions, and / or interrupts per instruction.

[0020] In (B), a matrix is ​​stored in a tile consisting of a plurality of registers, such as packed data registers (single instruction, multiple data (SIMD), or vector registers). In this example, the tile is overlaid on three physical registers. Typically, consecutive registers are used, but this is not necessary.

[0021] In (C), a matrix in a tile is stored in a non-register memory accessible via a fused multiply-accumulate (FMA) circuit used in tiling operations. This memory may be located within or adjacent to an FMA. Furthermore, in some embodiments discussed below, the memory may be for a data element rather than an entire row or tile.

[0022] The supported parameters for the TMMA architecture are reported via CPUID. In some embodiments, the list of information includes a maximum height and a maximum SIMD dimension. Configuring the TMMA architecture requires specifying the dimensions for each tile, the element size for each tile, and the palette identifier. This configuration is accomplished by executing the TILECONFIG statement.

[0023] Successful execution of a TILECONFIG instruction enables subsequent TILE operations. A TILERELEASEALL instruction clears the tile configuration and disables TILE operations (until the next TILECONFIG instruction is executed). In some embodiments, XSAVE, XSTORE, etc., are used during a context switch using tiles. In some embodiments, two XCR0 bits are used during XSAVE, one for TILECONFIF metadata and one bit corresponding to actual tile payload data.

[0024] TILECONFIG not only configures tile usage but also sets a state variable indicating that the program is in a region of code with configured tiles. An implementation can list restrictions on other instructions that can be used with a tile region, such as not using an existing register set, etc.

[0025] Leaving a tiled space is typically accomplished with the TILERELEASEALL statement. It takes no parameters and quickly invalidates all tiles (indicating that the data no longer needs to be saved or restored) and clears the internal state corresponding to an arrangement within a tiled space.

[0026] In some embodiments, tile operations zero all rows and all columns beyond the dimensions specified by the tile configuration. For example, tile operations zero the data beyond the configured number of columns (taking into account the size of the elements) as each row is written. For example, with 64-byte rows and a tile configured with 10 rows and 12 columns, an operation that writes FP32 elements would write each of the first 10 rows with 12*4 bytes of output / result data and zero the remaining 4*4 bytes in each row. Tile operations also completely zero all rows after the first 10 configured rows. Using 1K tiles with 64-byte rows, there would be 16 rows, so the last 6 rows would also be zeroed in this example.

[0027] In some embodiments, context recovery (e.g., XRSTOR) enforces data loading by persisting data beyond the configured rows for a tile as null. If there is no valid configuration, all rows are set to null. An XRSTOR of the tile data may load garbage into columns beyond those configured. It should not be possible for XRSTOR to delete beyond the configured number of columns, since no element width is associated with the tile configuration.

[0028] A context save operation (e.g., XSAVE) frees the entire tile memory area when the operation writes it to memory. If XRSTOR has loaded garbage data into the rightmost part of a tile, XSAVE saves that data. XSAVE writes zeros for rows beyond the number specified for each tile.

[0029] In some embodiments, tile instructions can be restarted. Operations that access memory allow restart after page faults. Computational instructions that perform floating-point operations also allow unmasked floating-point exceptions, with exception masking controlled by a control and / or status register.

[0030] To support restart instructions after these events, the instructions store information in the startup registers, which are discussed in detail below. II. SYSTEMS FOR MATRIX OPERATIONS (TILE OPERATIONS) A. EXEMPLARY HARDWARE SUPPORT

[0031] Fig.Figure 3 illustrates one embodiment of a system employing a matrix (tile) operation accelerator. In this illustration, a host processor / processing system 301 communicates instructions 311 (e.g., matrix manipulation operations such as arithmetic or matrix manipulation operations, or load and store operations) to a matrix operation accelerator 307. However, this is depicted this way only for purposes of discussion. As discussed in detail later, this accelerator 307 may be part of a processing core. Typically, instructions 311, which are tile manipulation operator instructions, refer to tiles in register-to-register ("reg-reg") or register-to-memory ("reg-mem") format. Other instructions such as TILESTORE, TILELOAD, TILECONFIG, etc., do not perform data operations on a tile. Instructions may be decoded instructions (e.g., micro-ops) or macro instructions that the accelerator 307 has to handle.

[0032] In this example, a coherent memory interface 303 is coupled to the host processor / processing system 301 and the matrix operation accelerator 307 so that they can share memory. Fig. 4 and Fig. 5 illustrate various embodiments of how memory is shared using a matrix accelerator. As shown in Fig. 4, the host processor 401 and the matrix operation accelerator circuit 405 share the same memory 403. Fig.Figure 5 illustrates an embodiment in which host processor 501 and matrix operation accelerator 505 do not share memory, but can each access each other's memory. For example, processor 501 can access tile memory 507 and use its host memory 503 as usual. Similarly, matrix operation accelerator 505 can access host memory 503, but typically uses its own memory 507. Note that these memories can be different types.

[0033] In some embodiments, matrix operation accelerator 307 includes a plurality of FMAs 309 coupled to data buffers 305 (in some embodiments, one or more of these buffers 305 are stored in the FMAs of the grid, as shown). Data buffers 305 buffer tiles loaded from memory and / or tiles to be stored in memory (e.g., using a tile load or tile store instruction). The data buffers may, for example, be a plurality of registers. Typically, these FMAs are arranged as a grid of concatenated FMAs 309 that can read and write tiles. In this example, matrix operation accelerator 307 is to perform a matrix multiplication operation using tiles T0, T1, and T2. At least one of the tiles is located in FMA grid 309. In some embodiments, all tiles in an operation are stored in the FMA grid 309.In other embodiments, only a subset is stored in the FMA grid 309. As shown, T1 is accommodated, and T0 and T2 are not. Note that A, B, and C denote the matrices of these tiles, which may or may not occupy the entire space of the tile.

[0034] Fig. Figure 6 illustrates an embodiment of a matrix multiply-accumulate operation using tiles (“TMMA”).

[0035] The number of rows in the matrix (TILE A 601) corresponds to the number of serial (chained) FMAs, which comprise the computation latency. An implementation can freely traverse a smaller-height grid, but the computation remains the same.

[0036] The source / destination vector comes from a tile with N rows (TILE C 605), and the grid of FMAs 611 performs N vector-matrix operations, resulting in a complete instruction that performs matrix multiplication of tiles. Tile B 603 is the other vector source and provides "transfer" terms to the FMAs at each phase.

[0037] In operation, in some embodiments, the elements of matrix B (stored in a tile B 603) are distributed across the rectangular grid of FMAs. Matrix B (stored in tile A 601) has its row elements transposed to match the column dimension of the rectangular grid of FMAs. At each FMA in the grid, an element of A and B is multiplied and added to the incoming summand (from the top of the figure), and the outgoing sum is passed to the next row of FMAs (or the final output).

[0038] The latency of a single step is proportional to K (the row height of matrix B), and dependent TMMAs typically have sufficient source-destination rows (either in a single tile or across tiles) to hide this latency. An implementation can also divide the SIMD dimension (the dimension of the packed data element) M (the row height of matrix A) across time steps, but this simply changes the constant by which K is multiplied. If a program specifies a smaller K than the maximum specified by the TMACC, an implementation can freely implement it through "masking" or "early outputs."

[0039] The latency of an entire TMMA is proportional to N*K. The repetition rate is proportional to N. The number of MACs per TMMA instruction is N*K*M.

[0040] Fig.Figure 7 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction. Specifically, it illustrates an execution circuit of an iteration of a packed data element position of the target. In this embodiment, the chained fused multiply accumulate operates on signed sources, with the accumulator having twice the size of the input data.

[0041] A first signed source (Source 1 701) and a second signed source (Source 2 703) each have four packed data elements. Each of these packed data elements stores signed data, such as floating-point data. A third signed source (Source 3 709) has two packed data elements, each of which stores signed data. The sizes of the first and second signed sources 701 and 703 are half of the third signed source (initial value or preceding result) 709. For example, the first and second signed sources 701 and 703 could have 32-bit packed data elements (e.g., single-precision floating-point), while the third signed source 709 could have 64-bit packed data elements (e.g., double-precision floating-point).

[0042] In this illustration, only the two most significant packed data element positions of the first and second signed sources 701 and 703 and the most significant packed data element position of the third signed source 709 are shown. Of course, the other packed data element positions would also be processed.

[0043] As illustrated, packed data elements are processed in pairs. For example, the data of the most significant positions of the packed data elements of the first and second signed sources 701 and 703 are multiplied using a multiplication circuit 705, and the data of the next most significant positions of the packed data elements of the first and second signed sources 701 and 703 are multiplied using a multiplication circuit 707. In some embodiments, these multiplication circuits 705 and 707 are reused for other positions of the packed data elements. In other embodiments, additional multiplication circuits are used so that the packed data elements are processed in parallel. In some contexts, parallel execution occurs using lanes that are the size of the third signed source 709.The results of each of the multiplications are added using addition circuit 711.

[0044] The result of the addition of the results of the multiplications is added to the data of the most significant position of the packed data elements of the signed source 3 709 (using another addition unit 713 or the same addition unit 711).

[0045] Finally, the result of the second addition is either stored in the signed destination 715 in a packed data element position corresponding to the packed data element position used from the signed third source 709, or passed to the next iteration, if there is one. In some embodiments, a write mask is applied to this storage, such that if a corresponding write mask (bit) is set, a store occurs, and if it is not set, no store occurs.

[0046] Fig.Figure 8 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction. Specifically, it illustrates an execution circuit of an iteration of a packed data element position of the target. In this embodiment, the chained fused multiply accumulate operates on signed sources, with the accumulator having twice the size of the input data.

[0047] A first signed source (Source 1 801) and a second signed source (Source 2 803) each have four packed data elements. Each of these packed data elements stores signed data such as integer data. A third signed source (Source 3 809) has two packed data elements, each of which stores signed data. The sizes of the first and second signed sources 801 and 803 are half the size of the third signed source 809. For example, the first and second signed sources 801 and 803 could have 32-bit packed data elements (e.g., single-precision floating point), and the third signed source 809 could have 64-bit packed data elements (e.g., double-precision floating point).

[0048] In this illustration, only the two most significant packed data element positions of the first and second signed sources 801 and 803 and the most significant packed data element position of the third signed source 809 are shown. Of course, the other packed data element positions would also be processed.

[0049] As illustrated, packed data elements are processed in pairs. For example, the data of the most significant positions of the packed data elements of the first and second signed sources 801 and 803 are multiplied using a multiplication circuit 805, and the data of the next most significant positions of the packed data elements of the first and second signed sources 801 and 803 are multiplied using a multiplication circuit 807. In some embodiments, these multiplication circuits 805 and 807 are reused for other positions of the packed data elements. In other embodiments, additional multiplication circuits are used so that the packed data elements are processed in parallel.In some contexts, parallel execution occurs using lanes that have the size of the third signed source (the initial value or the result of the previous iteration) 809. The results of each of the multiplications are added to the signed third source 809 using addition / saturation circuitry 813.

[0050] The addition / saturation (accumulator) circuit 813 preserves the sign of an operand if the addition results in a value that is too large. Specifically, a saturation evaluation occurs on the infinite-precision result between the multi-way addition and the write to the destination or the next iteration. If the accumulator 813 is of floating-point type and the input terms are integers, the product sum and the input value to the floating-point accumulator are converted to infinite-precision values ​​(fixed-point numbers consisting of hundreds of bits), the addition of the multiplication results and the third input is performed, and a single rounding to the actual accumulator type is performed.

[0051] Unsigned saturation means that the output values ​​are limited to an unsigned maximum number for that element width (all 1). Signed saturation means that a value is limited to a range between a negative minimum number and a positive maximum number for that element width (for example, the range for bytes is -128 (= -2^7) to 127 (= 2^7-1)).

[0052] The result of the addition and saturation check is stored in the signed destination 815 in a packed data element position corresponding to the packed data element position used from the signed third source 809, or passed to the next iteration, if there is one. In some embodiments, a write mask is applied to this storage, such that if a corresponding write mask (bit) is set, a store occurs, and if it is not set, no store occurs.

[0053] Fig.Figure 9 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction. Specifically, it illustrates an execution interconnect of an iteration of a packed data element position of the target. In this embodiment, the chained fused multiply-accumulate operates on a signed source and an unsigned source, with the accumulator having a size 4 times the input data.

[0054] A first signed source (Source 1 901) and a second unsigned source (Source 2 903) each have four packed data elements. Each of these packed data elements has data such as floating-point or integer data. A third signed source (Initial Value or Result 915) has one packed data element that stores signed data. The sizes of the first and second sources 901 and 903 are one-quarter of the third signed source 915. For example, the first and second sources 901 and 903 could have 16-bit packed data elements (e.g., a word), and the third signed source 915 could have 64-bit packed data elements (e.g., double-precision floating-point or a 64-bit integer).

[0055] This illustration shows the four most significant packed data element positions of the first and second sources 901 and 903 and the most significant packed data element position of the third signed source 915. Of course, the other packed data element positions would also be processed, if they exist.

[0056] As illustrated, packed data elements are processed in groups of four. For example, the data of the most significant positions of the packed data elements of the first and second sources 901 and 903 are multiplied using a multiplication circuit 905, data of the next most significant positions of the packed data elements of the first and second sources 901 and 903 are multiplied using a multiplication circuit 907, data of the third most significant positions of the packed data elements of the first and second sources 901 and 903 are multiplied using a multiplication circuit 909, and data of the least significant positions of the packed data elements of the first and second sources 901 and 903 are multiplied using a multiplication circuit 911.In some embodiments, the signed data elements of the first source 901 are sign-extended before the multiplications, and the unsigned packed data elements of the second source 903 are zero-extended.

[0057] In some embodiments, these multiplication circuits 905-911 are reused for other positions of the packed data elements. In other embodiments, additional multiplication circuits are used so that the packed data elements are processed in parallel. In some contexts, parallel execution occurs using lanes that are the size of the third signed source 915. The results of each of the multiplications are added using addition circuitry 911.

[0058] The result of the addition of the results of the multiplications is added to the data of the most significant position of the packed data elements of the signed source 3 915 (using another addition unit 913 or the same addition unit 911).

[0059] Finally, the result 919 of the second addition is either stored in the signed destination in a packed data element position corresponding to the packed data element position used from the signed third source 915, or passed to the next iteration. In some embodiments, a write mask is applied to this storage, such that if a corresponding write mask (bit) is set, a store occurs, and if it is not set, no store occurs.

[0060] Fig.Figure 10 illustrates an embodiment of a subset of the execution of an iteration of a chained fused multiply-accumulate instruction. Specifically, it illustrates an execution interconnect of an iteration of a packed data element position of the target. In this embodiment, the chained fused multiply-accumulate operates on a signed source and an unsigned source, with the accumulator having a size 4 times the input data.

[0061] A first signed source (Source 1 1001) and a second unsigned source (Source 2 1003) each have four packed data elements. Each of these packed data elements stores data such as floating-point or integer data. A third signed source (initial value or previous result 1015) has one packed data element that stores signed data. The sizes of the first and second sources 1001 and 1003 are one-quarter of the third signed source 1015. For example, the first and second sources 1001 and 1003 could have 16-bit packed data elements (e.g., a word), and the third signed source 1015 could have 64-bit packed data elements (e.g., double-precision floating-point or a 64-bit integer).

[0062] This illustration shows the four most significant packed data element positions of the first and second sources 1001 and 1003 and the most significant packed data element position of the third signed source 1015. Of course, the other packed data element positions would also be processed, if they exist.

[0063] As illustrated, packed data elements are processed in groups of four. For example, the data of the most significant positions of the packed data elements of the first and second sources 1001 and 1003 are multiplied using a multiplication circuit 1005, data of the next most significant positions of the packed data elements of the first and second sources 1001 and 1003 are multiplied using a multiplication circuit 1007, data of the third most significant positions of the packed data elements of the first and second sources 1001 and 1003 are multiplied using a multiplication circuit 1009, and data of the least significant positions of the packed data elements of the first and second sources 1001 and 1003 are multiplied using a multiplication circuit 1011.In some embodiments, the signed data elements of the first source 1001 are sign-extended before the multiplications, and the unsigned packed data elements of the second source 1003 are zero-extended.

[0064] In some embodiments, these multiplication circuits 1005-1011 are reused for other positions of the packed data elements. In other embodiments, additional multiplication circuits are used so that the packed data elements are processed in parallel. In some contexts, parallel execution occurs using lanes that are the size of the third signed source 1015. The result of summing the results of the multiplications is added to the data of the most significant position of the packed data elements of the signed source 3 1015 using the add / saturate circuit 1013.

[0065] The add / saturate (accumulator) circuit 1013 preserves the sign of an operand when the addition results in a value too large or too small for signed saturation. Specifically, a saturation evaluation occurs on the infinite-precision result between the multi-way addition and the write to the destination. If the accumulator 1013 is a floating-point type and the input terms are integers, the product sum and the input value to the floating-point accumulator are converted to infinite-precision values ​​(fixed-point numbers consisting of hundreds of bits), the addition of the multiplication results and the third input is performed, and a single rounding to the actual accumulator type is performed.

[0066] The result 1019 of the addition and saturation check is stored in the signed destination in a packed data element position corresponding to the packed data element position used from the signed third source 1015, or passed to the next iteration. In some embodiments, a write mask is applied to this storage, such that if a corresponding write mask (bit) is set, a store occurs, and if it is not set, no store occurs.

[0067] Fig.Figure 11 illustrates SIMD implementations sized to a power of two, according to one embodiment, where the accumulators use input sizes larger than the inputs to the multipliers. Note that the source (for the multipliers) and the accumulator values ​​can be signed or unsigned values. Table 1101 illustrates various configurations for an accumulator with 2X input sizes (in other words, the accumulator input value is twice the size of the packed data element sizes of the sources). For byte-sized sources, the accumulator uses word or half-precision floating-point (HPFP) values, which are 16 bits in size. For word-sized sources, the accumulator uses 32-bit integer or single-precision floating-point (SPFP) values, which are 32 bits in size.For sources with SPFP or 32-bit integer size, the accumulator uses 64-bit integer or double-precision floating-point (DPFP) values.

[0068] Table 1103 illustrates various configurations for an accumulator with 4X input sizes (in other words, the accumulator input value is four times the size of the packed data element sizes of the sources). For byte-sized sources, the accumulator uses 32-bit integer or single-precision floating-point (SPFP) values, which are 32 bits in size. For word-sized sources, the accumulator uses 64-bit integer or double-precision floating-point (DPFP) values, which in some embodiments are 64 bits in size.

[0069] Table 1105 illustrates a configuration for an accumulator with 8X input sizes (in other words, the accumulator input value is eight times the size of the sources' packed data elements). For byte-sized sources, the accumulator uses 64-bit integers.

[0070] As mentioned above, a matrix operation circuit can be included in a core or as an external accelerator. Fig. Figure 12 illustrates one embodiment of a system employing matrix operation interconnection. In this illustration, a plurality of entities are coupled to a ring interconnect 1245.

[0071] A plurality of cores 1201, 1203, 1205, and 1207 provide support for non-tile-based instructions. In some embodiments, matrix operation circuitry 1251 is provided in core 1203, and in other embodiments, matrix operation circuitry 1211 and 1213 may be accessed from ring interconnect 1245.

[0072] In addition, one or more memory controllers 1223-1225 are provided to communicate with the memory 1233 and 1231 on behalf of the cores and / or the matrix operation circuitry.

[0073] Fig.13 illustrates one embodiment of a processor core pipeline that supports matrix operations using tiles. Branch prediction and decode circuitry 1303 performs branch prediction of instructions, decoding of instructions, and / or both of instructions stored in instruction memory 1301. For example, instructions discussed in detail herein may be stored in instruction memory. In some implementations, separate circuitry is used for branch prediction, and in some embodiments, at least some instructions are converted into one or more micro-operations, microcode entry points, micro-instructions, other instructions, or other control signals using microcode 1305. Branch prediction and decode circuitry 1303 may be implemented using various different mechanisms.Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), read-only microcode ROMs, etc.

[0074] Branch prediction and decode circuitry 1303 is coupled to rename / allocation circuitry 1307, which in some embodiments is coupled to scheduling circuitry 1309. In some embodiments, this circuitry provides register renaming, register allocation, and / or scheduling functionality by performing one or more of the following: 1) renaming logical operand values ​​to physical operand values ​​(e.g., in some embodiments, a register alias table), 2) associating status bits and flags with the decoded instruction, and 3) scheduling the decoded instruction for execution on an execution circuit from an instruction pool (e.g., in some embodiments, using a reservation station).

[0075] The scheduling interconnection 1309 represents any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduling unit(s) scheduling interconnection 1309 is coupled to or includes physical register file(s) 1315. Each of the physical register file(s) 1315 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), tiles, etc. In one embodiment, the physical register file(s) 1315 include vector register interconnection, write mask register interconnection, and scalar register interconnection.These register circuits may provide architectural vector registers, vector mask registers, and general-purpose registers. The physical register file(s) 1315 is / are overlapped by a quiescing circuit 1317 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a quiescing register file(s); using a future file(s), a history buffer(s), and a quiescing register file(s); using a register map and a pool of registers; etc.). The quiescing circuit 1317 and the physical register file(s) 1315 are coupled to the execution circuit(s) 1311.

[0076] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in an in-order architecture. While the illustrated embodiment of the processor may also include separate instruction and data cache units and a shared L2 cache unit, alternative embodiments may include a single internal cache for both instructions and data, such as an internal Level 1 (L1) cache or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or the processor. Alternatively, the entire cache may be external to the core and / or the processor.

[0077] Execution circuitry 1311 includes a set of one or more execution circuits 1321, 1323, and 1327 and a set of one or more memory access circuits 1325. Execution circuits 1321, 1323, and 1327 perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various data types (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions.The scalar circuit 1321 performs scalar operations, the vector / SIMD circuit 1323 performs vector / SIMD operations, and the matrix operation circuit 1327 performs the matrix operations (tile operations) described in detail herein.

[0078] For example, the example register renaming, out-of-order issue / execution core architecture may implement a pipeline as follows: 1) an instruction fetch circuit performs fetch and length decode phases; 2) branch and decode circuitry 1303 performs a decode phase; 3) rename / map circuitry 1307 performs a map phase and a rename phase; 4) scheduling circuitry 1309 performs a scheduling phase; 5) a physical register file(s) (coupled to or included in scheduling circuitry 1309 and rename / map circuitry 1307)are) and a memory unit perform a register read / memory read phase; the execution circuitry 1311 performs an execute phase; 6) a memory unit and the physical register file unit(s) perform a write back / memory write phase; 7) various units may participate in the exception handling phase; and 8) a quiesce unit and the physical register file unit(s) perform a commit phase.

[0079] The core may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set from MIPS Technologies in Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings in Sunnyvale, CA) that include the instruction(s) described herein. In one embodiment, the core 1390 includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), allowing the operations used by many multimedia applications to be performed using packed data.

[0080] It should be understood that the core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of ways, including sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core to each of the threads that the physical core is simultaneously executing concurrently), or a combination thereof (e.g., time-sliced ​​fetching and decoding followed by simultaneous multithreading as in Intel® Hyperthreading Technology).

[0081] Fig.14 illustrates one embodiment of a processor core pipeline that supports matrix operations using tiles. Branch prediction and decode circuitry 1403 performs branch prediction of instructions, decoding of instructions, and / or both of instructions stored in instruction memory 1401. Instructions discussed in detail herein may, for example, be stored in instruction memory. In some implementations, separate circuitry is used for branch prediction, and in some embodiments, at least some instructions are converted into one or more micro-operations, microcode entry points, micro-instructions, other instructions, or other control signals using microcode 1405. Branch prediction and decode circuitry 1403 may be implemented using various different mechanisms.Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), read-only microcode ROMs, etc.

[0082] Branch prediction and decode circuitry 1403 is coupled to rename / allocation circuitry 1407, which in some embodiments is coupled to scheduling circuitry 1409. In some embodiments, this circuitry provides register renaming, register allocation, and / or scheduling functionality by performing one or more of the following: 1) renaming logical operand values ​​to physical operand values ​​(e.g., in some embodiments, a register alias table), 2) associating status bits and flags with the decoded instruction, and 3) scheduling the decoded instruction for execution onto an execution circuit from an instruction pool (e.g., in some embodiments, using a reservation station).

[0083] The scheduling interconnection 1409 represents any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduling unit(s) scheduling interconnection 1409 is coupled to or includes physical register file(s) 1415. Each of the physical register file(s) 1415 represents one or more physical register files, various of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), tiles, etc. In one embodiment, the physical register file(s) 1415 include vector register interconnection, write mask register interconnection, and scalar register interconnection.These register circuits may provide architectural vector registers, vector mask registers, and general-purpose registers. The physical register file(s) 1415 is / are overlapped by a quiescing circuit 1417 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a quiescing register file(s); using a future file(s), a history buffer(s), and a quiescing register file(s); using a register map and a pool of registers; etc.). The quiescing circuit 1417 and the physical register file(s) 1415 are coupled to the execution circuit(s) 1411.

[0084] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in an in-order architecture. While the illustrated embodiment of the processor may also include separate instruction and data cache units and a shared L2 cache unit, alternative embodiments may include a single internal cache for both instructions and data, such as an internal Level 1 (L1) cache or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or the processor. Alternatively, the entire cache may be external to the core and / or the processor.

[0085] The execution circuitry 1411 includes a set of one or more execution circuits 1427 and a set of one or more memory access circuits 1425. The execution circuits 1427 perform matrix operations (tile operations) described in detail herein.

[0086] For example, the example register renaming, out-of-order issue / execution core architecture may implement a pipeline as follows: 1) an instruction fetch circuit performs fetch and length decode phases; 2) branch and decode circuitry 1403 performs a decode phase; 3) rename / map circuitry 1407 performs a map phase and a rename phase; 4) scheduling circuitry 1409 performs a scheduling phase; 5) a physical register file(s) (coupled to or included in scheduling circuitry 1407 and rename / map circuitry 1407)are) and a memory unit perform a register read / memory read phase; the execution circuitry 1411 performs an execute phase; 6) a memory unit and the physical register file unit(s) perform a write back / memory write phase; 7) various units may participate in the exception handling phase; and 8) a quiesce unit and the physical register file unit(s) perform a commit phase.

[0087] The core may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set from MIPS Technologies in Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings in Sunnyvale, CA) that include the instruction(s) described herein. In one embodiment, core 1490 includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), allowing the operations used by many multimedia applications to be performed using packed data.

[0088] It should be understood that the core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of ways, including sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core to each of the threads that the physical core is simultaneously executing concurrently), or a combination thereof (e.g., time-sliced ​​fetching and decoding followed by simultaneous multithreading as in Intel® Hyperthreading Technology). B. LAYOUT

[0089] Throughout this description, data is expressed using a row-by-row data layout. Users should translate terms based on their alignment. Fig.Figure 15 illustrates an example of a matrix expressed in row-by-row and column-by-column formats. As shown, matrix A is a 2x3 matrix. When this matrix is ​​stored in a row-by-row format, the data elements of a row are consecutive. When this matrix is ​​stored in a column-by-column format, the data elements of a column are consecutive. Matrices have a well-known property that A T * B T = (BA) T , where the superscript T means transposed. Reading column-wise data as row-wise data results in the matrix looking like the transposed matrix.

[0090] In some embodiments, row-wise semantics are used in hardware, and column-wise data must flip the operand order, with the result being a transpose of the matrix, but for subsequent column-wise reads from memory, it is the correct, untransposed matrix.

[0091] For example, if two column-wise matrices are to be multiplied: a bg i kag+bhai+bjak+blc d * hjl=cg+dhci+djck+dle f(3×2)(2×3)(3×3)

[0092] The input matrices would be stored in linear memory (column-wise) as follows: acebdf and ghijk l.

[0093] If these matrices are read row by row with dimensions 2x3 and 3x2, they would look like this: ac eundg hb d fi jk l

[0094] Reversing the order and matrix multiplying: g ha c eag+bhcg+dheg+fhi j*bdf=ai+bjci+djei+fjk lak+blck+dlak+fl

[0095] The transposed matrix is ​​output and can then be stored in row-by-row order: ag+bh cg+dh eg+fh ai+bj ci+dj ei+fj ak+bl ck+dl ek+fl and when used in subsequent column-wise calculations, it is the correct, non-transposed matrix: ag+bhai+bjak+blcg+dhci+djck+dleg+fhei+fjek+fl III. EXEMPLARY USE

[0096] Fig.Figure 16 illustrates an example of using matrices (tiles). In this example, matrix C 1601 contains two tiles, matrix A 1603 contains one tile, and matrix B 1605 contains two tiles. This figure shows an example of the inner loop of an algorithm for calculating a matrix multiplication. In this example, two result tiles, tmm0 and tmm1, from matrix C 1601 are used to collect the intermediate results. A tile from matrix A 1603 (tmm2) is reused twice because it is multiplied by two tiles from matrix B 1605. Pointers to load a new A tile and two new B tiles from the directions are indicated by the arrows. An outer loop, not shown, adjusts the pointers for the C tiles.

[0097] The example code includes the use of a tile configuration directive as shown and is executed to configure tile usage, load tiles, loop to process the tiles, save tiles to memory, and release tile usage.

[0098] Fig. Figure 17 illustrates an example of using matrices (tiles). At 1701, tile usage is configured. For example, a TILECONFIG statement is executed to configure tile usage, which includes specifying a number of rows and columns per tile. Typically, at least one matrix (tile) is loaded from memory at 1703. At least one matrix operation (tile operation) is performed using the matrices (tiles) at 1705. At least one matrix (tile) is stored in memory at 1707, and a context switch may occur at 1709. IV. Example Configuration A. Tile Configuration Hardware Support

[0099] As discussed above, tile utilization typically needs to be configured prior to use. For example, full utilization of all rows and columns may not be necessary. Configuring these rows and columns not only saves power in some embodiments, but the configuration can also be used to determine whether an operation will generate an error. For example, a matrix multiplication of the form (NxM) * (L*N) typically does not work if M and L are not equal.

[0100] Before using matrices using tiles, in some embodiments, tile support must be configured. For example, the number of rows and columns to use per tile, the tiles to use, etc. are configured. A TILECONFIG instruction is an enhancement to a computer itself because it provides support for configuring the computer to use a matrix accelerator (either as part of a processor core or as an external device). In particular, execution of the TILECONFIG instruction causes a configuration to be retrieved from memory and applied to matrix settings (tile settings) within a matrix accelerator. i. Configuration of tile usage

[0101] Fig.Figure 18 illustrates support for configuring the use of tiles according to one embodiment. A memory 1801 contains the description of the matrices (tiles) to be supported 1803.

[0102] The execution circuitry 1811 of a processor / core 1805 stores aspects of a tile description 1803 in tile configurations 1817. The tile configurations 1817 describe in detail which tiles are configured for a palette (the number of rows and columns in each tile) and an indicator that matrix support is being used. In particular, instruction execution resources 1811 are configured to use tiles as specified by the tile configuration 1817. The instruction execution resources may also include a machine-specific register or a configuration register to indicate tile usage. Additional values ​​such as usage and initial values ​​are also specified. The tile configurations 1817 employ one or more registers 1819 to store tile usage and configuration information.

[0103] Fig.Figure 19 illustrates one embodiment of a description of the matrices (tiles) to be supported. This is the description to be stored after execution of an STTILECFG instruction. In this example, each field is a byte. A palette ID 1901 is stored in byte[0]. The palette ID is used to index a palette table 1813, which stores, per palette ID, a number of bytes in a tile and bytes per row of tiles associated with that ID, as defined by the configuration.

[0104] Byte 1 stores a value to be stored in a "startRow" register 1903, and byte 2 stores a value to be stored in a "startP" register 1905. To support restart instructions after these events, the instructions store information in these registers. To support restart instructions after interrupt events, such as those discussed in detail above, the instructions store information in these registers. The startRow value indicates the row to be used for the restart. The startP value indicates the position within the row for memory operations when pairs are used, and in some embodiments indicates the bottom half of the row (in the lower tile of a pair) or the top half of the row (in the higher tile of a pair). Generally, the position within the row (the column) is not needed.

[0105] With the exception of TILECONFIG and STTILECFG, successful execution of matrix (tile) instructions sets both startRow and StartP to zero.

[0106] Whenever an interrupted array (tile) instruction is not restarted, software is responsible for setting the startRow and startP values ​​to zero. For example, unmasked floating-point exception handlers may decide to terminate the operation in software and change the program counter value to another instruction, usually the next instruction. In this case, the software exception handler must set the startRow and startP values ​​in the exception presented to it by the operating system to zero before resuming the program. The operating system then reloads these values ​​using a recovery instruction.

[0107] Byte 3 stores a reference to pairs (1 b per tile) of tiles 1907.

[0108] Bytes 16-17 store the number of rows 1913 and columns 1915 for tile 0, bytes 18-19 store the number of rows and columns for tile 1, and so on. In other words, each 2-byte group specifies the number of rows and columns for a tile. If no 2-byte group is used to specify tile parameters, they should have the value zero. Specifying tile parameters for more tiles than the implementation limit or the palette limit results in an error. Unconfigured tiles are set to an initial state of 0 rows and 0 columns.

[0109] Finally, the configuration in memory usually ends with an end delimiter, such as all zeros for several consecutive bytes. ii. Example tile and tile configuration storage

[0110] Fig. 20(A)-(D) illustrate examples of a register or registers in 1819. Fig.Figure 20(A) illustrates a plurality of registers 1819. As shown, each tile (TMM0 2001 ... TMMN 2003) has a separate register, with each register storing a row and column size for that particular tile. StartP and StartRow are stored in separate registers 2011 and 2013. One or more status registers 2015 are set (e.g., TILES_CONFIGURED = 1) to indicate that tiles are configured for use.

[0111] Fig. Figure 20(B) illustrates a plurality of registers 1819. As shown, each tile has separate registers for its rows and columns. For example, TMM0 row configuration 2021, TMM0 column configuration 2023, StartP, and StartRow are stored in separate registers 2011 and 2013. One or more status registers 2015 are set (e.g., TILES_CONFIGURED = 1) to indicate that tiles are configured for use.

[0112] Fig.Figure 20(C) illustrates a single register 1819. As shown, this register stores tile configurations (rows and columns per tile) 2031. StartP 2011 and StartRow 2013 are stored in a single register as packed data registers. One or more status registers 2015 are set (e.g., TILES_CONFIGURED = 1) to indicate that tiles are configured for use.

[0113] Fig. 20(D) illustrates a plurality of registers 1819. As shown, a single register stores tile configurations (rows and columns per tile) 2031. StartP and StartRow are stored in separate registers 2011 and 2013. One or more status registers 2015 are set (e.g., TILES_CONFIGURED = 1) to indicate that tiles are configured for use.

[0114] Other combinations are contemplated, such as combining the start registers into a single register where they are shown separately, etc. B. TDP4BIT

[0115] A common matrix operation is a dot product, for example, between elements of two tiles stored in a register set or in memory. Embodiments of a TDP4BIT instruction and their execution are discussed in detail herein. A TDP4BIT instruction is an improvement to a computer itself because it provides support for performing a dot product between elements of two matrices within a matrix (tile) with a single instruction. Specifically, the TDP4BIT instruction performs a dot product between the elements of a first source matrix (tile) and a second source matrix (tile) and stores the results in a destination matrix (tile). The size of the data elements to be loaded can vary depending on the instruction and tile support. Example sizes include, but are not limited to: 16-bit, 32-bit, 64-bit, 128-bit, 256-bit, etc.However, the TDP4BIT instruction operates on nibbles within quadword elements. In some embodiments, elements of rows of the destination matrix (tile) that do not have corresponding columns in the source matrix (tile) are set to zero. I. EXEMPLARY IMPLEMENTATION

[0116] Fig.Figure 21 illustrates an example execution of a TDP4BIT instruction. The TDP4BIT instruction format includes fields for an opcode and a first source, second source, and destination identifier, each of which identifies a matrix (tile) with a PAIR parameter set to FALSE. The identified destination matrix (tile) has M rows and N columns of elements. The identified first source matrix (tile) has M rows and K columns, and the identified second source matrix (tile) has K rows and N columns.As shown, a decoded TDP4BIT instruction 2102 is received by execution circuitry 2108, which in some embodiments uses a grid of FMAs 2110 to perform a sequence K times for each element (M,N) of the identified destination matrix 2118, the sequence including generating eight products by using multipliers 2112A-H to multiply each nibble of a double-word element (M,K) of the identified first source matrix by a corresponding nibble of a double-word element (K,N) of the identified second source matrix; and using accumulator 2114 to accumulate and using saturation circuitry 2116 to saturate the eight products with previous contents of the double-word element (M,N) of the identified destination matrix.

[0117] In some embodiments, multipliers 2112A-H perform all of the multiplications in parallel. In some embodiments, multipliers 2112A-H perform all of the multiplications serially over one or more additional cycles.

[0118] In some embodiments, execution circuitry 2108 periodically saves state so that if an error occurs mid-operation, execution circuitry 2108 can resume execution after the error has been recovered and continue where it left off. In such embodiments, the saved state includes one or more of a row pointer, a block pointer, a byte pointer, and an element pointer to identify the currently loaded target tile element.

[0119] As discussed in detail previously, the source and destination matrices (tiles) can be loaded into a collection of registers, into memory locations, or into other locations accessible by the execution circuitry. However, as shown, the identified source and destination matrices (tiles) are stored in a collection of registers.

[0120] As shown, instruction 2102 includes a TDP4BIT opcode, a destination tile identifier, “tdest,” and first and second source tile identifiers, “tsrc1” and “tsrc2,”

[0121] In some embodiments, a matrix (tile) is configured to use only a subset of the possible rows and columns. For example, a matrix (tile) may have up to 16 usable rows and columns, but only use 4 at a time. The configuration of each matrix (tile) is typically accomplished by executing a configuration statement prior to matrix (tile) usage. II. EXAMPLE INSTRUCTION FORMAT(S)

[0122] One embodiment of a format for a TDP4BIT instruction is TDP4BIT tdest, tsrc1, tsrc2. In some embodiments, TDP4BIT is the instruction's opcode mnemonic, where "4BIT" indicates that 4-bit data nibbles are operated on. In some embodiments, the tdest field is an R / M value (such as 2546 of the Fig. 25A-B), the tsrc1 field is REG 2544 of the Fig. 25A-B. In some embodiments, the TDP4BIT opcode includes indicators, such as [U, S] [U, S] prefixes or suffixes, to indicate whether the first and second identified sources are signed or unsigned, respectively.

[0123] In some embodiments, encodings of the instruction include a scale-index-base (SIB) type memory address operand that indirectly identifies multiple indexed target locations in memory (e.g., field 2550 of the Fig.25A-B). In one embodiment, a SIB-type memory operand may include an encoding that identifies a base address register. The contents of the base address register may represent a base address in memory from which the addresses of the particular target locations in memory are calculated. The base address may, for example, be the address of the first location in a block of possible target locations for an extended vector instruction. In one embodiment, a SIB-type memory operand may include an 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 an address of a respective target location within a block of possible target locations from the base address.In one embodiment, a SIB-type memory operand may include an encoding specifying a scaling factor to be applied to each index value when calculating a respective destination address. For example, if a scaling factor of four is encoded in the SIB-type memory operand, each index value obtained from an element of the index register may be multiplied by four and then added to the base address to calculate a destination address.

[0124] In one embodiment, a SIB-type memory operand of the form vm32{x, y, z} may identify a vector array of memory operands specified using SIB-type memory addressing. In this example, the array of memory addresses is specified using a common base register, a constant scaling factor, and a vector index register containing individual elements, each of which is a 32-bit index value. The vector index register may be a 128-bit register (e.g., XMM) (vm32x), a 256-bit register (e.g., YMM) (vm32y), or a 512-bit register (e.g., ZMM) (vm32z). In another embodiment, a SIB-type memory operand of the form vm64{x, y, z} may identify a vector array of memory operands specified under SIB-type memory addressing.In this example, the array of memory addresses is specified using a common base register, a constant scaling factor, and a vector index register containing individual elements, each of which is a 64-bit index value. The vector index register can be a 128-bit register (e.g., XMM) (vm64x), a 256-bit register (e.g., YMM) (vm64y), or a 512-bit register (e.g., ZMM) (vm64z). III. EXEMPLARY IMPLEMENTATION PROCEDURE(S)

[0125] Fig.Figure 22 illustrates one embodiment of a processor executing a TDP4BIT instruction. At 2201, an instruction is fetched. For example, a TDP4BIT instruction is fetched that includes fields for an opcode, a destination identifier to identify an M-by-N destination matrix, a first source identifier to identify a first M-by-K source matrix, and a second source identifier to identify a second K-by-N source matrix, each of the matrices including double-word elements. In some embodiments, the instruction is fetched from an instruction buffer by fetch circuitry. The opcode of the TDP4BIT instruction indicates performing a packed dot product of element positions of the first and second identified source matrices (tiles). The source matrices include double-word elements, each of which is partitioned into 8 logical 4-bit nibbles.

[0126] The fetched instruction is decoded at 2203. The fetched TDP4BIT instruction is decoded, for example, by a decode circuit such as that described herein.

[0127] Execution of the decoded instruction is scheduled at 2205 (if needed), which is an optional step (as indicated by its dashed border) in that it may occur at a different time or not at all.

[0128] At 2207, the decoded TDP4BIT instruction is executed by execution circuitry (hardware) such as that described herein. For the TDP4BIT instruction, execution causes the execution circuitry to execute the decoded instruction by performing a flow K times for each element (M, N) of the identified destination matrix, the flow comprising generating eight products by multiplying each nibble of a double-word element (M, K) of the identified first source matrix by a corresponding nibble of a double-word element (K, N) of the identified second source matrix; and accumulating and saturating the eight products with previous contents of the double-word element (M, N) of the identified destination matrix.In some embodiments, the instruction is committed or quiesced at 2209, which is an optional step (as indicated by its dashed border) in that it may occur at a different time or not at all.

[0129] Fig. Figure 23 illustrates a more detailed description of the execution of a TDP4BIT instruction. Typically, this is accomplished through an execution circuit like the one described above.

[0130] At 2302, a TDP4BIT instruction is fetched having fields for an opcode and a first source, second source, and destination identifier, each identifying a matrix (tile) with a PAIR parameter set to FALSE.

[0131] At 2304 a determination is made as to whether ALL of the following are true, whether one or more errors are detected, if so an error is generated at 2306.

[0132] When all error checks tested at 2304 have been completed, the execution circuitry executes a flow K times at 2308 for each element (M, N) of the identified destination matrix to execute the remaining blocks of the flow. At 2310, the execution circuitry generates eight products by multiplying each nibble of a double-word element (M, K) of the identified first source matrix by a corresponding nibble of a double-word element (K, N) of the identified second source matrix and accumulates and saturates the eight products with previous contents of the double-word element (M, N) of the identified destination matrix. At 2312, N is incremented and, if columns remain, execution returns to 2308 to process the next column. Otherwise, at 2314, K is incremented and, if K remain, execution returns to 2308 to process the next K.Otherwise, at 2316, M is incremented and, if rows remain, execution returns to 2308 to process the next M. Otherwise, the process ends. IV. EXAMPLE PSEUDOCODE

[0133] Fig. 24A is exemplary pseudocode describing one embodiment of a processor executing a TDP4BIT instruction. As shown in pseudocode 2400, the TDP4BIT instruction includes an opcode, TDP4BIT, a destination matrix identifier (tile identifier) ​​to identify an M-by-N destination matrix (tile), "tdest," a first source matrix identifier (tile identifier), "tsrc1," to identify a first M-by-K source matrix (tile), and a second source matrix identifier (tile identifier), "tsrc2," to identify a second K-by-N source matrix (tile).

[0134] In some embodiments, the identified first and second source matrices and the destination matrices each use either a collection of registers or a plurality of memory locations to represent a matrix.

[0135] As shown, pseudocode 2400 first causes the execution circuit to generate an error if any of several error checks fail. For example, an error is generated if any of tdest, tsrc1, and tsrc2 have a PAIR parameter set to TRUE.

[0136] Pseudocode 2400 further defines an "extend_src" macro to sign-extend a signed source data value or zero-extend an unsigned source data value. Pseudocode 2400 further defines a "saturation_fn" macro to perform unsigned saturation if both source data values ​​are unsigned and signed saturation if one or both of the source data values ​​are signed. For signed saturation, if a single result exceeds the range of a signed double-word integer (that is, greater than 7FFF_FFFFH or less than 8000_0000H), the saturated value of 7FFF_FFFFH or 8000_0000H, respectively, is written to the destination operand.For unsigned saturation, if a single result value exceeds the range of an unsigned double word (that is, is greater than FFFFF_FFFFH), the saturated unsigned integer double word value of FFFF_FFFFH is stored in the double word destination.

[0137] Pseudocode 2400, when executed by a processor, causes the processor to calculate the dot product of two double-word operands, each containing eight 4-bit elements (nibbles), with double-word accumulation and saturation. As explained above, the 4-bit elements are signed or unsigned, and the saturation is signed if one of the operands is signed.Pseudocode 2400 causes the processor to perform a number of nested for loops to perform a process K times for each element (M, N) of the identified destination matrix, the process including generating eight products by multiplying each signed-extended or zero-extended nibble of a double-word element (M, K) of the identified first source matrix by a corresponding signed-extended or zero-extended nibble of a double-word element (K, N) of the identified second source matrix. The result of each nibble multiplication is stored in a double-word, tprod[b], and therefore maintains exact precision. Pseudocode 2400 further causes the processor to accumulate and saturate the eight products with previous contents of the double-word element (M, N) of the identified destination matrix (signed or unsigned).Pseudocode 2400 causes the processor to set all remaining configured rows of the target matrix (tile) to zero and reset pointers for a next call to the function.

[0138] In some embodiments, the execution circuitry stores a state after performing the flow on each element (M, N) of the identified target matrix and, in case of a fault, uses the stored state after recovering from the fault to continue execution, wherein the state comprises at least a target matrix row pointer and a target matrix element pointer.

[0139] Fig.Figure 24B is exemplary pseudocode describing one embodiment of auxiliary functions used by a processor executing a TDP4BIT instruction. Pseudocode 2450 defines the function "write_row_and_zero(treg, r, data, nbytes)." Pseudocode 2452 defines the function "zero_upper_rows(treg, r)." Pseudocode 2454 defines the function "zero_tileconfig_start()."

[0140] The pseudocode in Fig. 24A and Fig. 24B documents itself based on the function names and variable names it contains. MORE EXAMPLES

[0141] Example 1 provides a processor including: decode circuitry to generate a tile dot product instruction having fields for an opcode, a destination identifier to identify an M-by-N destination matrix, a first source identifier to identify a first M-by-K source matrix, and a second source identifier to identify a second K-by-N source matrix, each of the matrices to include double-word elements, and execute circuitry to execute the decoded instruction by performing a flow K times for each element (M, N) of the identified destination matrix, the flow including: generating eight products by multiplying each nibble of a double-word element (M, K) of the identified first source matrix by a corresponding nibble of a double-word element (K, N) of the identified second source matrix;and accumulating and saturating the eight products with preceding contents of the double word element (M,N) of the identified target matrix.;

[0142] Example 2 includes the subject matter of the example processor of Example 1, wherein the execution circuitry is further to generate an error when an error condition occurs, the error condition including one or more of: one or more of the first and second identified source matrices have a PAIR parameter set to TRUE, one or more of the first and second identified source matrices have a VALID parameter not set to TRUE, the identified destination matrix has a number of rows different from a number of rows of the identified first source matrix, the identified destination matrix has a number of columns different from a number of columns of the identified second source matrix, and one or more of the identified first source, second source, and destination matrices have dimensions that exceed maximum dimensions,where the dimensions contain numbers of matrix rows and columns.,

[0143] Example 3 includes the subject matter of the example processor of Example 1, wherein the execution circuitry further extends each nibble being multiplied based on the sign of the nibble, either signed or zero.

[0144] Example 4 includes the subject matter of the example processor of Example 1, wherein the saturating includes either signed saturation or unsigned saturation, depending on the sign of the eight products.

[0145] Example 5 includes the subject matter of the exemplary processor of Example 1, wherein a result of each multiplication of nibbles is stored in a double-word register.

[0146] Example 6 includes the subject matter of the example processor of any of Examples 1-5, where M is one of 2, 4, 8, and 16, N is one of 2, 4, 8, 16, and 32, and K is one of 1, 2, 4, 8, and 16.

[0147] Example 7 includes the subject matter of the exemplary processor of any of Examples 1-5, wherein the execution circuitry stores state after performing the flow on each element (M, N) of the identified target matrix, and in the event of a fault, uses the stored state after recovering from the fault to continue execution of the K flows; wherein the state includes at least a target matrix row pointer and a target matrix element pointer.

[0148] Example 8 includes the subject matter of the example processor of any of Examples 1-5, wherein the identified first and second source matrices each use either a collection of registers or a plurality of memory locations to represent a matrix.

[0149] Example 9 includes the subject matter of the example processor of any of Examples 1-5, wherein the identified target matrix uses either a collection of registers or a plurality of memory locations to represent a matrix.

[0150] Example 10 includes the subject matter of the example processor of any of Examples 1-5, wherein the opcode further indicates whether each of the first and second source matrices includes signed or unsigned elements.

[0151] Example 11 provides a method including: decoding, by decoding circuitry, a tile dot product instruction having fields for an opcode, a destination identifier to identify an M-by-N destination matrix, a first source identifier to identify a first M-by-K source matrix, and a second source identifier to identify a second K-by-N source matrix, each of the matrices to include double-word elements, and executing, by execution circuitry, the decoded instruction by performing a flow K times for each element (M, N) of the identified destination matrix, the flow including: generating eight products by multiplying each nibble of a double-word element (M, K) of the identified first source matrix by a corresponding nibble of a double-word element (K, N) of the identified second source matrix;and accumulating and saturating the eight products with preceding contents of the double word element (M,N) of the identified target matrix.;

[0152] Example 12 includes the subject matter of the exemplary method of Example 11, further including generating an error by the execution circuitry when an error condition occurs, wherein the error condition includes one or more of: one or more of the first and second identified source matrices have a PAIR parameter set to TRUE, one or more of the first and second identified source matrices have a VALID parameter not set to TRUE, the identified destination matrix has a number of rows different from a number of rows of the identified first source matrix, the identified destination matrix has a number of columns different from a number of columns of the identified second source matrix, and one or more of the identified first source, second source, and destination matrices have dimensions that exceed maximum dimensions,where the dimensions contain numbers of matrix rows and columns.,

[0153] Example 13 includes the subject matter of the exemplary method of Example 11, further including extending, by the execution circuitry, each nibble being multiplied based on the sign of the signed or zero nibble.

[0154] Example 14 includes the subject matter of the exemplary method of Example 11, wherein the saturating includes either signed saturation or unsigned saturation, depending on the sign of the eight products.

[0155] Example 15 includes the subject matter of the exemplary method of Example 11, further including storing, by the execution circuitry, a result of each multiplication of nibbles in a double-word register.

[0156] Example 16 includes the subject matter of the exemplary method of any of Examples 11-15, wherein M is one of 2, 4, 8, and 16, N is one of 2, 4, 8, 16, and 32, and K is one of 1, 2, 4, 8, and 16.

[0157] Example 17 includes the subject matter of the exemplary method of any of Examples 11-15, further including, after performing the operation on each element (M, N) of the identified target matrix, storing a state and, in the event of a fault, using the stored state after recovering from the fault to continue execution of the K operations; wherein the state includes at least a target matrix row pointer and a target matrix element pointer.

[0158] Example 18 includes the subject matter of the exemplary method of any of Examples 11-15, wherein the identified first and second source matrices each use either a collection of registers or a plurality of memory locations to represent a matrix.

[0159] Example 19 includes the subject matter of the exemplary method of any of Examples 11-15, wherein the identified target matrix uses either a collection of registers or a plurality of memory locations to represent a matrix.

[0160] Example 20 includes the subject matter of the exemplary method of any of Examples 11-15, wherein the opcode further indicates whether each of the first and second source matrices includes signed or unsigned elements.

[0161] Example 21 provides a system including: a memory and a processor including: decode circuitry to generate a tiled dot product instruction having fields for an opcode, a destination identifier to identify an M-by-N destination matrix, a first source identifier to identify a first M-by-K source matrix, and a second source identifier to identify a second K-by-N source matrix, each of the matrices to include doubleword elements, and execution circuitry to execute the decoded instruction by performing a flow K times for each element (M,N) of the identified destination matrix, the flow including: generating eight products by multiplying each nibble of a doubleword element (M,K) of the identified first source matrix by a corresponding nibble of a doubleword element (K,N) of the identified second source matrix;and accumulating and saturating the eight products with preceding contents of the double word element (M,N) of the identified target matrix.;

[0162] Example 22 includes the subject matter of the exemplary system of Example 21, wherein the execution circuitry is further to generate an error when an error condition occurs, the error condition including one or more of: one or more of the first and second identified source matrices have a PAIR parameter set to TRUE, one or more of the first and second identified source matrices have a VALID parameter not set to TRUE, the identified destination matrix has a number of rows different from a number of rows of the identified first source matrix, the identified destination matrix has a number of columns different from a number of columns of the identified second source matrix, and one or more of the identified first source, second source, and destination matrices have dimensions that exceed maximum dimensions,where the dimensions contain numbers of matrix rows and columns.,

[0163] Example 23 includes the subject matter of the example system of Example 21, wherein the execution circuitry further either extends each nibble that is multiplied based on the sign of the nibble, either signed or zero extended.

[0164] Example 24 includes the subject matter of the exemplary system of Example 21, wherein the saturating includes either signed saturation or unsigned saturation, depending on the sign of the eight products.

[0165] Example 25 includes the subject matter of the exemplary system of Example 21, wherein a result of each multiplication of nibbles is stored in a double-word register.

[0166] Example 26 includes the subject matter of the exemplary system of any of Examples 21-25, where M is one of 2, 4, 8, and 16, N is one of 2, 4, 8, 16, and 32, and K is one of 1, 2, 4, 8, and 16.

[0167] Example 27 includes the subject matter of the exemplary system of any of Examples 21-25, wherein the execution circuitry stores a state after performing the flow on each element (M, N) of the identified target matrix, and in the event of a fault, uses the stored state after recovering from the fault to continue execution of the K flows; wherein the state includes at least a target matrix row pointer and a target matrix element pointer.

[0168] Example 28 includes the subject matter of the example system of any of Examples 21-25, wherein the identified first and second source matrices each use either a collection of registers or a plurality of memory locations to represent a matrix.

[0169] Example 29 includes the subject matter of the example system of any of Examples 21-25, wherein the identified target matrix uses either a collection of registers or a plurality of memory locations to represent a matrix.

[0170] Example 30 includes the subject matter of the example processor of any of Examples 21-25, wherein the opcode further indicates whether each of the first and second source matrices includes signed or unsigned elements.

[0171] Example 31 provides a non-transitory machine-readable medium including instructions that, when executed by a processor, cause the processor to: decode, through decode circuitry, a tile dot product instruction having fields for an opcode, a destination identifier to identify an M-by-N destination matrix, a first source identifier to identify a first M-by-K source matrix, and a second source identifier to identify a second K-by-N source matrix, each of the matrices to include doubleword elements, and execute, through execution circuitry, the decoded instruction by performing a flow K times for each element (M, N) of the identified destination matrix, the flow including: generating eight products by multiplying each nibble of a doubleword element (M, K) of the identified first source matrix by a corresponding nibble of a doubleword element (K,N) of the identified second source matrix; and accumulating and saturating the eight products with preceding contents of the double-word element (M,N) of the identified target matrix.

[0172] Example 32 includes the subject matter of the example non-transitory machine-readable medium of Example 31, further including instructions that, when executed by the processor, cause the processor to generate an error when an error condition occurs, the error condition including one or more of: one or more of the first and second identified source matrices have a PAIR parameter set to TRUE, one or more of the first and second identified source matrices have a VALID parameter not set to TRUE, the identified destination matrix has a number of rows different from a number of rows of the identified first source matrix, the identified destination matrix has a number of columns different from a number of columns of the identified second source matrix, and one or more of the identified first source, second source, and destination matrices have dimensions,exceed the maximum dimensions, where the dimensions include numbers of matrix rows and columns.,

[0173] Example 33 includes the subject matter of the example non-transitory machine-readable medium of Example 31, further including instructions that, when executed by the processor, cause the processor to extend each nibble that is multiplied based on the sign of the nibble with a signed or zero extension.

[0174] Example 34 includes the subject matter of the example non-transitory machine-readable medium of Example 31, wherein the saturating includes either a signed saturation or an unsigned saturation, depending on the sign of the eight products.

[0175] Example 35 includes the subject matter of the example non-transitory machine-readable medium of Example 31, further including instructions that, when executed by the processor, cause the processor to store a result of each multiplication of nibbles in a double-word register.

[0176] Example 36 includes the subject matter of the exemplary non-transitory machine-readable medium of any of Examples 31-35, where M is one of 2, 4, 8, and 16, N is one of 2, 4, 8, 16, and 32, and K is one of 1, 2, 4, 8, and 16.

[0177] Example 37 includes the subject matter of the example non-transitory machine-readable medium of any of Examples 31-35, further including instructions that, when executed by the processor, cause the processor to store state on each element (M,N) of the identified destination matrix after performing the flow and, in the event of a fault, to use the stored state after recovering from the fault to continue execution of the K flows; wherein the state includes at least a destination matrix row pointer and a destination matrix element pointer.

[0178] Example 38 includes the subject matter of the example non-transitory machine-readable medium of any of Examples 31-35, wherein the identified first and second source matrices each use either a collection of registers or a plurality of memory locations to represent a matrix.

[0179] Example 39 includes the subject matter of the example non-transitory machine-readable medium of any of Examples 31-35, wherein the identified target array uses either a collection of registers or a plurality of memory locations to represent an array.

[0180] Example 40 includes the subject matter of the example non-transitory machine-readable medium of any of Examples 31-35, wherein the opcode further indicates whether each of the first and second source matrices includes signed or unsigned elements. V. DETAILED EXAMPLE SYSTEMS, PROCESSORS AND EMULATION

[0181] Examples of hardware, software, etc., are listed here to execute the instructions described above. What is described below, for example, describes details of instruction execution, including various pipeline stages such as fetch, decode, scheduling, execution, quiesce, etc. Instruction sets

[0182] An instruction set may contain one or more instruction formats. A particular instruction format may define various fields (e.g., number of bits, position of bits) to specify, among other things, the operation to be performed (e.g., opcode) and the operand(s) on which this operation is to be performed, and / or another data field(s) (e.g., a mask). Some instruction formats are further broken down by the definition of instruction templates (or subformats). For example, the instruction templates of a particular instruction format may be defined to contain different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because fewer fields are included), and / or may be defined to contain a particular field differently.Therefore, each instruction of an ISA is expressed using a specific instruction format (and, if defined, in a specific one of that instruction format's instruction templates) and contains fields for specifying the operation and operands. For example, an exemplary ADD instruction has a specific opcode and an instruction format that includes an opcode field to specify that opcode and operand fields to select operands (Source 1 / Destination and Source 2); and an occurrence of this ADD instruction in an instruction stream will have specific contents in the operand fields that select specific operands. A set of SIMD extensions called Advanced Vector Extensions (AVX) (AVX1 and AVX2), which use the Vector Extensions (VEX) coding scheme, has been released and / or published (see, for example,Intel® 64 and IA-32 Architecture Software Developer's Guide, September 2014; and see Advanced Vector Extensions Programming Reference for Intel® Architecture, October 2014). Example instruction formats

[0183] Embodiments of the instruction(s) described herein may be implemented in various formats. Additionally, exemplary systems, architectures, and pipelines are discussed in detail below. Embodiments of the instruction(s) may be implemented on such systems, architectures, and pipelines, but are not limited to those discussed. Generic vector-friendly instruction format

[0184] A vector-friendly instruction format is an instruction format suitable for vector instructions (e.g., there are certain fields specific to vector operations). While embodiments are described in which both vector and scalar operations are supported by the vector-friendly instruction format, alternative embodiments employ the vector-friendly instruction format only for vector operations.

[0185] Fig. 25A-25B are block diagrams illustrating a generic vector-friendly instruction format and instruction templates thereof according to embodiments of the invention. Fig. 25A is a block diagram illustrating a generic vector-friendly instruction format and Class A instruction templates thereof according to embodiments of the invention; while Fig.25B is a block diagram illustrating the generic vector-friendly instruction format and Class B instruction templates thereof, according to embodiments of the invention. More specifically, a generic vector-friendly instruction format 2500 for which Class A and Class B instruction templates are defined, both of which include non-memory access instruction templates 2505 and memory access instruction templates 2520. The term generic, in the context of the vector-friendly instruction format, refers to the fact that the instruction format is not tied to a particular instruction set.

[0186] While embodiments of the invention are described in which the vector-friendly instruction format supports: a vector operand length (or size) of 64 bytes with 32-bit (4-byte) or 64-bit (8-byte) data element widths (or sizes) (and therefore a 64-byte vector consists of either 16 double-word sized elements or alternatively 8 quad-word sized elements); a vector operand length (or size) of 64 bytes with 16-bit (2-byte) or 8-bit (1-byte) data element widths (or sizes); a vector operand length (or size) of 32 bytes with 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte) or 8-bit (1-byte) data element widths (or sizes); and a vector operand length (or size) of 16 bytes with 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element widths (or sizes); alternative embodiments may use 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).

[0187] The Class A instruction templates in Fig. 25A include: 1) in the instruction templates without memory access 2505, a non-memory access operation instruction template 2510 of the full rounding control type and a non-memory access operation instruction template 2515 of the data transformation type are shown; and 2) in the instruction templates with memory access 2520, a temporal memory access instruction template 2525 and a non-temporal memory access instruction template 2530 are shown. The instruction templates of class B in Fig.25B include: 1) in the no-memory instruction templates 2505, a no-memory operation instruction template 2512 of the full writemask control and partial rounding control type and a no-memory operation instruction template 2517 of the writemask control vsize type are shown; and 2) in the memory access instruction templates 2520, a writemask control instruction template 2527 with memory access is shown.

[0188] The generic vector-friendly instruction format 2500 contains the following fields, which are shown below in the Fig. 25A-25B are listed in the order illustrated.

[0189] Format field 2540 - A specific value (an instruction format identifier field) in this field uniquely identifies the vector-friendly instruction format and therefore the occurrence of instructions in the vector-friendly instruction format in instruction streams. As such, this field is optional in the sense that it is not required for an instruction set that only has the generic vector-friendly instruction format.

[0190] Basic operation field 2542 - Its content distinguishes various basic operations.

[0191] Register Index Field 2544 - Its contents, directly or through address generation, specify the locations of the source and destination operands, in registers or in memory. These contain a sufficient number of bits to select N registers from a PxQ register file (e.g., 32x512, 16x128, 32x1024, 64x1024). While in one embodiment, N can be up to three source and one destination registers, alternative embodiments can support more or fewer source and destination registers (e.g., they can support up to two sources, where one of these sources also serves as the destination, they can support up to three sources, where one of these sources also serves as the destination, they can support up to two sources and one destination).

[0192] Modification field 2546 - Its content distinguishes occurrences of instructions in the generic vector instruction format that specify a memory access from those that do not; that is, between instruction templates without memory access 2505 and instruction templates with memory access 2520. Memory access operations read and / or write to the memory hierarchy (in some cases specifying the source and / or destination addresses using values ​​in registers), while non-memory access operations do not (e.g., the source and destinations are registers). While in one embodiment, this field also selects between three different ways of performing memory address calculations, alternative embodiments may support more, fewer, or different ways of performing memory address calculations.

[0193] Operation suffix field 2550 - Its content distinguishes which of a variety of different operations are to be performed in addition to the base operation. This field is context-specific. In one embodiment of the invention, this field is divided into a class field 2568, an alpha field 2552, and a beta field 2554. The operation suffix field 2550 allows common groups of operations to be performed in a single instruction instead of two, three, or four instructions.

[0194] Scaling field 2560 - Its content allows scaling the contents of the index field to generate a memory address (e.g., to generate addresses that are 2 Skalierung * Index + base used).

[0195] Offset field 2562A - Its content is used as part of the memory address generation (e.g. for address generation, which 2 Skalierung * Index + Base + Offset used).

[0196] Offset factor field 2562B (it should be noted that the juxtaposition of the offset field 2562A directly above the offset factor 2562B indicates that one or the other is used) - Its content is used as part of the address generation; it specifies an offset factor that is to be scaled with the size of a memory access (N) - where N is the number of bytes in the memory access (e.g., for an address generation that uses 2 Skalierung* Index + base + scaled offset used). Redundant low-order bits are ignored, and therefore the contents of the offset factor field are multiplied by the total size of the memory operand (N) to generate the final offset to be used to calculate an effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 2574 (described later herein) and the data manipulation field 2554C. The offset field 2562A and the offset factor field 2562B are optional in the sense that they are not used for the no-memory instruction templates 2505 and / or other embodiments may implement only one or neither.

[0197] Data Element Width Field 2564 - Its content distinguishes which of a number of data element widths to use (in some embodiments, for all instructions; in other embodiments, only for some of the instructions). The field is optional in the sense that it is not needed if only one data element width is supported and / or data element widths are supported using an opcode aspect.

[0198] Write mask field 2570 - Its content controls, on a per-data-element-position basis, whether that data-element position in the destination vector operand reflects the result of the base operation and the auxiliary operation. Class A instruction templates support write mask application with merge, while Class B instruction templates support both write mask application with merge and write mask application with zeroing. When merging, vector masks allow any set of elements in the destination to be protected from updates during the execution of any operation (specified by the base operation and the auxiliary operation); in another embodiment, the old value of any element of the destination is protected where the corresponding mask bit is 0.In contrast, vector masks, when set to zero, allow any set of elements in the destination to be set to zero during the execution of any operation (specified by the base operation and the additional operation); in one embodiment, an element of the destination is set to 0 if the corresponding mask bit has a 0 value. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the range of elements being modified, from first to last); however, it is not necessary that the elements being modified be consecutive. Therefore, the write mask field 2570 partially enables vector operations, including loads, stores, arithmetic, logical operations, etc.While embodiments of the invention are described in which the contents of the writemask field 2570 select one of a number of writemask registers containing the writemask to be used (and therefore the contents of the writemask field 2570 indirectly identify that masking to be performed), alternative embodiments instead or in addition allow the contents of the writemask field 2570 to directly indicate the masking to be performed.

[0199] Immediate field 2572 - Its contents allow the specification of an immediate operand. This field is optional in the sense that it is not present in an implementation of the generic vector-friendly format that does not support an immediate operand, and it is not present in instructions that do not use an immediate operand.

[0200] Class field 2568 - Its content distinguishes between different instruction classes. With reference to the Fig.25A-B, the content of this field selects between Class A and Class B instructions. In the Fig. 25A-B, squares with rounded corners are used to indicate that a certain value is present in a field (e.g. Class A 2568A or Class B 2568B for the class field 2568 in the Fig. 25A-B). Class A instruction templates

[0201] In the case of the Class A instruction templates without memory access 2505, the alpha field 2552 is interpreted as an RS field 2552A, whose content distinguishes which of the various additional operation types is to be performed (e.g., rounding 2552A.1 and data transformation 2552A.2 are specified for the two operation instruction templates of the rounding type without memory access 2510 and the operation instruction template of the data transformation type without memory access 2515, respectively), while the beta field 2554 distinguishes which of the specified type operations is to be performed. In the instruction templates without memory access 2505, the scaling field 2560, the offset field 2562A, and the offset scaling field 2562B are not present. Instruction templates without memory access - Full rounding control type operations

[0202] In the full rounding control type operation instruction template with no memory access 2510, the beta field 2554 is interpreted as a rounding control field 2554A, whose contents provide(s) static rounding. While the rounding control field 2554A in the described embodiments of the invention includes a suppress all floating-point exceptions (SAE) field 2556 and a rounding operation control field 2558, alternative embodiments may encode both of these concepts in the same field or include only one or the other of these concepts / fields (e.g., may include only the rounding operation control field 2558).

[0203] SAE field 2556 - Its content distinguishes whether exception event reporting is to be disabled or not; if the content of SAE field 2556 indicates that suppression is enabled, a particular instruction does not report any type of floating-point exception flag and does not start a floating-point exception handler.

[0204] Rounding Operation Control Field 2558 - Its contents distinguish which of a group of rounding operations are to be performed (e.g., round up, round down, round to zero, and round to the nearest integer). Therefore, the rounding operation control field 2558 allows the rounding mode to be changed on a per-instruction basis. In one embodiment of the invention in which a processor includes a control register for specifying rounding modes, the contents of the rounding operation control field 2550 override this register value. Statement templates without memory access - Data transformation type operations

[0205] In the operation instruction template of the data transformation type without memory access 2515, the beta field 2554 is interpreted as a data transformation field 2554B, the content of which distinguishes which of a number of data transformations is to be performed (e.g., no data transformation, swizzling, broadcast).

[0206] In the case of an instruction template with memory access 2520 of class A, the alpha field 2552 is interpreted as a removal hint field 2552B, the content of which distinguishes which of the removal hints is to be used (in Fig.25A, temporal 2552B.1 and non-temporal 2552B.2 are specified for temporal memory access instruction template 2525 and non-temporal memory access instruction template 2530, respectively), while the beta field 2554 is interpreted as a data manipulation field 2554C, the contents of which distinguishes which of a number of data manipulation operations (also known as primitives) is to be performed (e.g., no manipulation; broadcast; upconversion of a source; and downconversion of a destination). The memory access instruction templates 2520 include the scaling field 2560 and, optionally, the offset field 2562A or the offset scaling field 2562B.

[0207] Vector memory instructions perform vector loads from memory and vector stores to memory, with conversion support. Like regular vector instructions, memory instructions transfer data to / from memory one data element at a time, with the actual elements transferred being determined by the contents of the vector mask selected as the write mask. Memory access instruction templates - temporal

[0208] Temporal data is data that is likely to be reused soon enough that caching is beneficial. However, this is a hint, and different processors can implement it in different ways, including completely ignoring the hint. Memory access instruction templates - non-temporal

[0209] Non-temporal data is data that isn't likely to be reused soon enough to benefit from caching in the Level 1 cache, and should be given priority for eviction. However, this is a hint, and different processors may implement it in different ways, including completely ignoring the hint. Class B instruction templates

[0210] In the case of Class B instruction templates, the alpha field 2552 is interpreted as a write mask control (Z) field 2552C, the content of which distinguishes whether the write mask controlled by the write mask field 2570 should be a merge or a zeroing.

[0211] In the case of the non-memory access instruction templates 2505 of class B, part of the beta field 2554 is interpreted as an RL field 2557A, the contents of which distinguishes which of the various additional operation types are to be performed (e.g., the rounding 2557A.1 and the vector length (VSIZE) 2557A.2 are specified for the non-memory access operation instruction template 2512 of the full write mask control and partial rounding control type, and the non-memory access operation instruction template 2517 of the write mask control VSIZE type, respectively), while the remainder of the beta field 2554 distinguishes which of the specified type operations is to be performed. In the non-memory access instruction templates 2505, the scaling field 2560, the offset field 2562A, and the offset scaling field 2562B are not present.

[0212] In the full rounding control type operation instruction template with no memory access 2510, the remainder of the beta field 2554 is interpreted as a rounding operation field 2559A, and exception event reporting is disabled (a given instruction does not report any type of floating-point exception flag and does not start a floating-point exception handler).

[0213] Rounding Operation Control Field 2559A - Like Rounding Operation Control Field 2558, its contents distinguish which of a group of rounding operations (e.g., round up, round down, round to zero, and round to the nearest integer) are to be performed. Therefore, Rounding Operation Control Field 2559A allows the rounding mode to be changed on a per-instruction basis. In one embodiment of the invention in which a processor includes a control register for specifying rounding modes, the contents of Rounding Operation Control Field 2550 override this register value.

[0214] In the operation instruction template 2517 without memory access of the write mask control VSIZE type, the remainder of the beta field 2554 is interpreted as a vector length field 2559B, the contents of which distinguishes on which of a number of data vector lengths the operation is to be performed (e.g., 128, 256, or 512 bytes).

[0215] In the case of a class B memory access instruction template 2520, a portion of the beta field 2554 is interpreted as a broadcast field 2557B, the content of which distinguishes whether the data manipulation is to be performed of the broadcast type or not, while the remainder of the beta field 2554 is interpreted as the vector length field 2559B. The memory access instruction templates 2520 contain the scaling field 2560 and optionally the offset field 2562A or the offset scaling field 2562B.

[0216] With respect to the generic vector-friendly instruction format 2500, a full opcode field 2574 is shown, which includes the format field 2540, the base operation field 2542, and the data element width field 2564. While an embodiment is shown in which the full opcode field 2574 includes all of these fields, the full opcode field 2574 includes fewer than all of these fields in embodiments that do not support all of them. The full opcode field 2574 provides the operation code (opcode).

[0217] The operation override field 2550, the data element width field 2564, and the write mask field 2570 allow these functions to be specified per instruction in generic vector-friendly instruction format.

[0218] The combination of the write mask field and the data element width field creates typed instructions that allow the mask to be applied based on different data element widths.

[0219] The different instruction templates found within Class A and Class B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only Class A, only Class B, or both classes. For example, a high-performance, out-of-order general-purpose core for general-purpose computing purposes may support only Class B, a core intended primarily for graphics and / or scientific (throughput) computing may support only Class A, and a core intended for both may support both (of course, a core having a mix of templates and instructions from both classes, but not all templates and instructions from both classes, is within the scope of the invention).A single processor may also contain multiple cores, all of which support the same class, or where different cores support different classes. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores, intended primarily for graphics and / or scientific computing, may support only Class A, while one or more of the general-purpose cores may be high-performance general-purpose cores with out-of-order execution and register renaming, intended for general-purpose computing and supporting only Class B. Another processor, which does not have a separate graphics core, may contain one or more general-purpose in-order or out-of-order cores that support both Class A and Class B. Of course, in various embodiments of the invention, features of one class may also be implemented in the other class.Programs written in a high-level programming language would be put into a variety of different executable forms (e.g., just-in-time compiled or statically compiled), including: 1) a form containing only instructions of the class(es) supported by the target processor for execution; or 2) a form with alternative routines written using various combinations of the instructions of all classes and including flow control code that selects the routines to be executed based on the instructions supported by the processor currently executing the code. Example specific vector-friendly instruction format

[0220] Fig. 26A is a block diagram illustrating an exemplary specific vector-friendly instruction format according to embodiments of the invention. Fig.Figure 26A shows a specific vector-friendly 2600 instruction format, which is specific in the sense that it specifies the position, size, interpretation, and order of the fields, as well as values ​​for some of these fields. The specific vector-friendly 2600 instruction format can be used to extend the x86 instruction set, and therefore some of the fields are similar to or the same as those used in the existing x86 instruction set and extensions (e.g., AVX). This format remains compatible with the prefix encoding field, real opcode byte field, MOD-R / M field, SIB field, offset field, and immediate fields of the existing x86 instruction set with extensions. The fields of Fig. 25, into which the fields of Fig. 26A are illustrated.

[0221] It should be understood that although embodiments of the invention are described with reference to the specific vector-friendly instruction format 2600 in the context of the generic vector-friendly instruction format 2500 for illustrative purposes, the invention is not limited to the specific vector-friendly instruction format 2600, except where claimed. For example, the generic vector-friendly instruction format 2500 contemplates a variety of possible sizes for the various fields, while the specific vector-friendly instruction format 2600 is shown as having fields of specific sizes. As a specific example, while the data element with field 2564 is illustrated as a one-bit field in the specific vector-friendly instruction format 2600, the invention is not so limited (i.e., the generic vector-friendly instruction format 2500 contemplates other sizes of the data element width field 2564).

[0222] The generic vector-friendly instruction format 2500 contains the following fields, which are shown below in the Fig. 26A are listed in the order illustrated.

[0223] EVEX prefix (bytes 0-3) 2602 - is encoded in a four-byte form.

[0224] Format Field 2540 (EVEX Byte 0, Bits [7:0]) - The first byte (EVEX Byte 0) is the format field 2540 and it contains 0x62 (the unique value used to distinguish the vector-friendly instruction format in one embodiment of the invention).

[0225] The bytes from the second to the fourth (EVEX bytes 1-3) contain a number of bit fields that provide a specific capability.

[0226] REX field 2605 (EVEX byte 1, bits [7-5]) - consists of an EVEX.R bit field (EVEX byte 1, bit [7] - R), an EVEX.X bit field (EVEX byte 1, bit [6] - X), and an EVEX.B byte 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 a 1's complement form, i.e., ZMM0 is encoded as 1111B, ZMM15 is encoded as 0000B. Other fields of the instructions encode the lower three bits of the register indices, as known in the art (rrr, xxx and bbb), so that Rrrr, Xxxx and Bbbb can be formed by adding EVEX.R, EVEX.X and EVEX.B.

[0227] REX' Field 2510 - This is the first part of the REX' field 2510 and is the EVEX.R' bit field (EVEX byte 1, bit [4] - R'), which is used to encode either the upper 16 or the lower 16 of the extended 32-register set. In one embodiment of the invention, this bit, along with others as indicated below, is stored in bit-inverted format to distinguish it (in well-known x86 32-bit mode) from the BOUND instruction, whose real opcode byte is 62 but, in the MOD R / M field (described below), does not accept the value of 11 in the MOD field; alternative embodiments of the invention do not store this and the other bits indicated below in inverted format. A value of 1 is used to encode the lower 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R and the other RRR from other fields.

[0228] The opcode mapping field 2615 (EVEX byte 1, bits [3:0] - mmmm) - Its contents encode an implied leading opcode byte (0F, 0F 38 or 0F 3).

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

[0230] EVEX.vvvv 2620 (EVEX byte 2, bits [6:3]-vvvv) - The role of EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand, specified in inverted (1's complement) form and valid for instructions with 2 or more source operations; 2) EVEX.vvvv encodes the destination register operand, specified in 1's complement form for certain vector shifts; or 3) EVEX.vvvv encodes no operand; the field is reserved and should contain 1111b. Therefore, the EVEX.vvvv field 2620 encodes the 4 bits of the first low-order source register specifier, stored in inverted (1's complement) form. Depending on the instruction, an additional different EVEX bit field is used to extend the specifier size to 32 registers.

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

[0232] Prefix encoding field 2625 (EVEX byte 2, bits [1:0]-pp) - provides additional bits for the base operation field. In addition to providing support for Alt-SSE instructions in EVEX prefix format, this also has the advantage of compacting the SIMD prefix (instead of requiring a byte to express the SIMD prefix, the EVEX prefix requires only 2 bits). In one embodiment, to support Alt-SSE instructions that use a SIMD prefix (66H, F2H, F3H) in both Alt and EVEX prefix formats, these Alt-SIMD prefixes are encoded in the SIMD prefix encoding field and expanded at runtime into the Alt-SIMD prefix before being provided to the decoder's PLA (so that the PLA can execute both the Alt and EVEX formats of these Alt instructions without modification).Although newer instructions might use the contents of the EVEX prefix encoding field directly as an opcode extension, certain embodiments extend in a similar manner for continuity, but allow different meanings to be specified by these legacy SIMD prefixes. An alternative embodiment may redesign the PLA to support the 2-bit SIMD prefix encodings and therefore not require the extension.

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

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

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

[0236] Write Mask Field 2570 (EVEX Byte 3, Bits [2:0]-kkk) - Its contents specify the index of a register in the write mask register as previously described. In one embodiment of the invention, the specific value EVEX.kkk=000 has a special behavior that implies that no write mask is used for the particular instruction. (This can be implemented in a variety of ways, including using a write mask hardwired to all or hardware that bypasses the masking hardware.)

[0237] The real opcode field 2630 (byte 4) is also known as the opcode byte. A portion of the opcode is specified in this field.

[0238] MOD R / M field 2640 (byte 5) contains MOD field 2642, Reg field 2644, and R / M field 2646. As previously described, the contents of MOD field 2642 distinguish between memory-accessible and non-memory-accessible operations. The role of Reg field 2644 can be summarized in two situations: encoding either the destination register operand or a source register operand, or treating it as an opcode extension and not being used to encode any instruction operand. The role of R / M field 2646 can include encoding the instruction operand that references a memory address, or encoding either the destination register operand or a source register operand.

[0239] Scaling Index Base (SIB) Byte (Byte 6) - As previously described, the contents of the scaling field 2550 are used for memory address generation. SIB.xxx 2654 and SIB.bbb 2656 - The contents of these fields were already referenced in relation to the register indices Xxxx and Bbbb.

[0240] Offset field 2562A (bytes 7-10) - If the MOD field 2642 contains 10, bytes 7-10 are the offset field 2562A and it works in the same way as the alt 32-bit offset (disp32) and operates at the byte granularity level.

[0241] Offset Factor Field 2562B (Byte 7) - If the MOD field 2642 contains 01, byte 7 is the offset factor field 2562B. The position of this field is the same as that of the 8-bit offset (disp8) of the legacy x86 instruction set, which operates at the byte granularity level. Because disp8 is signed-extended, it can only address offsets between -128 and 127 bytes; in the form of 64-byte buffer lines, disp8 uses 8 bits, which can be set to only four actually useful values: -128, -64, 0, and 64; because a larger range is often needed, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, the offset factor field 2562B is a reinterpretation of disp8; When the offset factor field 2562B is used, the actual offset is determined by multiplying the contents of the offset factor field by the size of the memory operand access (N). This type of offset is referred to as disp8*N.This reduces the average instruction length (a single byte is used for the offset, but with a much larger range). Such a compressed offset is based on the assumption that the effective offset is a multiple of the granularity of the memory access, and therefore the redundant, low-order bits of the address offset do not need to be encoded. In other words, the 2562B offset factor field substitutes for the 8-bit offset of the legacy x86 instruction set. Therefore, the 2562B offset factor field is encoded in the same way as an 8-bit offset of an x86 instruction set (hence no changes in the ModRM / SIB encoding rules), with the only exception that disp8 is overloaded to disp8*N.In other words, there are no changes in the coding rules or coding lengths, only in the hardware's interpretation of the offset value (which must scale the offset with the size of the memory operand to obtain a byte-wise address offset). The 2572 immediate field operates as previously described. Full opcode field

[0242] Fig. Figure 26B is a block diagram illustrating the fields of the specific vector-friendly instruction format 2600 that comprise the full opcode field 2574 according to one embodiment of the invention. More specifically, the full opcode field 2574 includes the format field 2540, the base operation field 2542, and the data element width (W) field 2564. The base operation field 2542 includes the prefix encoding field 2625, the opcode mapping field 2615, and the real opcode field 2630. Register index field

[0243] Fig.26C is a block diagram illustrating the fields of the specific vector-friendly instruction format 2600 that form the register index field 2544 according to one embodiment of the invention. Specifically, the register index field 2544 includes the REX field 2605, the REX' field 2610, the MODR / M.reg field 2644, the MODR / Mr / m field 2646, the VVVV field 2620, the xxx field 2654, and the bbb field 2656. Additional operation field

[0244] Fig.Figure 26D is a block diagram illustrating the fields of the specific vector-friendly instruction format 2600 that make up the operation override field 2550 according to one embodiment of the invention. If the class (U) field 2568 contains 0, it means EVEX.U0 (Class A 2568A); if it contains 1, it means EVEX.U1 (Class B 2568B). If U = 0 and the MOD field 2642 contains 11 (signifying a non-memory access operation), the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the rs field 2552A. If the rs field 2552A contains a 1 (rounding 2552A.1), the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the rounding control field 2554A. The rounding control field 2554A contains a one-bit SAE field 2556 and a two-bit rounding operation field 2558. If the rs field 2552A contains a 0 (data transformation 2552A.2), the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a three-bit data transformation field 2554B. If U = 0 and the MOD field 2642 contains 00, 01, or 10 (signifying a memory access operation), the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the distance hint (EH) field 2552B, and the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a three-bit data manipulation field 2554C.

[0245] If U = 1, the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the write mask control field (Z) 2552C. If U = 1 and the MOD field 2642 contains 11 (which means a non-memory access operation), part of the beta field 2554 (EVEX byte 3, bit [4] - S0) is interpreted as the RL field 2557A; if it contains a 1 (rounding 2557A.1), the remainder of the beta field 2554 (EVEX byte 3, bits [6-5] - S 2-1) is interpreted as the rounding operation field 2559A, whereas if the RL field 2557A contains a 0 (VSIZE 2557.A2), the remainder of the beta field 2554 (EVEX byte 3, bit [6-5]- S 2-1 ) is interpreted as the vector length field 2559B (EVEX byte 3, bit [6-5]- L 1-0 ). If U = 1 and the MOD field 2642 contains 00, 01, or 10 (which means a memory access operation), the beta field 2554 (EVEX byte 3, bits [6:4]-SSS) is used as the vector length field 2559B (EVEX byte 3, bits [6-5]-L 1-0 ) and the broadcast field 2557B (EVEX byte 3, bit [4]-B) are interpreted. Example register architecture

[0246] Fig.27 is a block diagram of a register architecture 2700 according to one embodiment of the invention. In the illustrated embodiment, there are 32 vector registers 2710 that are 512 bits wide; these registers are referred to as zmm0 through zmm31. The 256 low-order bits of the lower 16 zmm registers are overlaid on registers ymm0-16. The 128 low-order bits of the lower 16 zmm registers (the 128 low-order bits of the ymm registers) are overlaid on registers xmm0-15. The specific vector-friendly instruction format 2600 operates on this overlaid register file, as illustrated in the tables below. Adjustable vector length Class Operations register Instruction templates that do not contain the vector length field 2559B A(Figure25A;U=0) 2510, 2515,2525, 2530 zmm register (The vector length is 64 bytes.) B(Figure25B;U=1) 2512 zmm register (The vector length is 64 bytes.) Instruction templates containing the vector length field 2559B B(Figure25B;U=1) 2517, 2527 zmm, ymm, or xmm register (the vector length is 64 bytes, 32 bytes, or 16 bytes), depending on the vector length field 2559B

[0247] In other words, the vector length field 2559B selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the previous length; and instruction templates without the vector length field 2559B operate on the maximum vector length. Further, in one embodiment, the class B instruction templates of the specific vector-friendly instruction format 2600 operate on packed or scalar single / double precision floating-point data and packed or scalar integer data. Scalar operations are operations performed on the least significant data element position in a zmm / ymm / xmm register; with the more significant data element positions either left as they were before the instruction or set to zero, depending on the embodiment.

[0248] Write Mask Register 2715 - In the illustrated embodiment, there are 8 write mask registers (k0 through k7), each 64 bits in size. In an alternative embodiment, write mask registers 2715 are 16 bits in size. As previously described, in one embodiment of the invention, vector mask register k0 cannot be used as a write mask; when the encoding that would normally indicate k0 is used for a write mask, it selects a hard-coded write mask of 0xFFFF, effectively disabling write masking for that instruction.

[0249] General-Purpose Register 2725 - In the illustrated embodiment, there are sixteen 64-bit general-purpose registers used in conjunction with existing x86 addressing modes to address memory operands. These registers are referred to as RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0250] Scalar floating-point stack register file (x87 stack) 2745, on which the MMX packed integer flat register file 2750 is aliased - 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 the x87 instruction set extension; while the MMX registers are used to perform operations on 64-bit packed integer data, as well as to hold operands for some operations performed between the MMX and XMM registers.

[0251] Alternative embodiments of the invention may use wider or narrower registers. Additionally, alternative embodiments of the invention may use more, fewer, or different register files and registers. Example core architectures, processors and computer architectures

[0252] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core intended primarily for graphics and / or scientific computing (throughput computing). Implementations of different processors may include: 1) a CPU containing one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor containing one or more special-purpose cores intended primarily for graphics and / or scientific computing (throughput).Such different processors result in different computer system architectures, which may include: 1) the coprocessor on a separate chip from the CPU; 2) the coprocessor on a separate chip in the same package as a CPU; 3) the coprocessor on the same chip as a CPU (in this case, such a coprocessor is sometimes referred to as special-purpose logic, such as integrated graphics and / or scientific logic (throughput logic, or as special-purpose cores); and 4) a single-chip system, which may include the described CPU (sometimes referred to as the application core(s) or the application processor(s), the coprocessor described above, and additional functionality on the same chip. Example core architectures are described next, followed by descriptions of example processors and computer architectures. Example core architecturesBlock diagram for in-order and out-of-order cores

[0253] Fig. 28A is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to embodiments of the invention. Fig. Figure 28B is a block diagram illustrating both an embodiment of an in-order architecture core and a register renaming, out-of-order issue / execution architecture core to be included in a processor according to embodiments of the invention. The solid-bordered boxes in the Fig.Figures 28A-B illustrate the in-order pipeline and the in-order core, while the optional addition of the dashed-bordered boxes illustrates the register renaming, out-of-order issue / execution pipeline and the register renaming, out-of-order issue / execution core. Since the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect is described.

[0254] In Fig. 28A, a processor pipeline 2800 includes a fetch phase 2802, a length decode phase 2804, a decode phase 2806, an allocation phase 2808, a rename phase 2810, a scheduling phase (also known as a dispatch or issue phase) 2812, a register read / memory read phase 2814, an execution phase 2816, a write-back / memory write phase 2818, an exception handling phase 2822, and a commit phase 2824.

[0255] Fig.28B shows a processor core 2890 including a front-end unit 2830 coupled to an execution engine unit 2850, both coupled to a memory unit 2870. The core 2890 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 2890 may be a special-purpose core, such as a networking or communications core, a compression engine, a coprocessor core, a general-purpose graphics processing unit (GPGPU) core, a graphics core, or the like.

[0256] The front-end unit 2830 includes a branch prediction unit 2832 coupled to an instruction cache unit 2834, which is coupled to an instruction translation lookaside buffer (TLB) 2836, which is coupled to an instruction fetch unit 2838, which is coupled to a decode unit 2840. The decode unit 2840 (or decoder) can decode instructions and generate as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from, or otherwise reflect, or are derived from the original instructions. The decode unit 2840 can be implemented using various different mechanisms. Examples of suitable mechanisms include lookup tables, hardware implementations, programmable logic arrays (PLAs), read-only microcode ROMs, etc., but are not limited thereto. In one embodiment, core 2890 includes a microcode ROM or other medium that stores microcode for specific macroinstructions (e.g., in decode unit 2840 or otherwise within front-end unit 2830). Decode unit 2840 is coupled to a rename / map unit 2852 in execution engine unit 2850.

[0257] The execution engine unit 2850 includes the rename / allocate unit 2852 coupled to a quiesce unit 2854 and a set of one or more scheduling units 2856. The scheduling unit(s) 2856 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduling unit(s) 2856 is / are coupled to the physical register file unit(s) 2858. Each of the physical register file unit(s) 2858 represents one or more physical register files, various of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc.In one embodiment, the physical register file unit 2858 includes a vector register unit, a write mask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and general-purpose registers. The physical register file unit(s) 2858 is / are overlapped by the quiesce unit 2854 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and quiesce register file(s); using a future file(s), a history buffer(s) and a quiesce register file(s); using a register map and a pool of registers; etc.). The quiesce unit 2854 and the physical register file unit(s) 2858 are connected to thethe execution clusters 2860 are coupled. The execution cluster(s) 2860 includes a set of one or more execution units 2862 and a set of one or more memory access units 2864. The execution units 2862 can perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various data types (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions.The scheduling unit(s) 2856, physical register file unit(s) 2858, and execution cluster(s) 2860 are shown as potentially plural, as certain embodiments create separate pipelines for specific types of data / operations (e.g., a scalar integer pipeline, a scalar floating-point / packed integer / packed floating-point / vector integer / vector floating-point pipeline, and / or a memory access pipeline, each having its own scheduling unit, physical register file unit, and / or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented where only that pipeline's execution cluster includes the memory access unit(s) 2864). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution pipelines, and the rest may be in-order pipelines.

[0258] The set of memory access units 2864 is coupled to the memory unit 2870, which includes a data TLB unit 2872 coupled to a data cache unit 2874, which is coupled to a Level 2 (L2) cache unit 2876. In one embodiment, the memory access units 2864 may include a load unit, an address store unit, and a data store unit, each of which is coupled to the data TLB unit 2872 in the memory unit 2870. The instruction cache unit 2834 is further coupled to a Level 2 (L2) cache unit 2876 in the memory unit 2870. The L2 cache unit 2876 is coupled to one or more other cache levels and ultimately to main memory.

[0259] For example, the example register renaming, out-of-order issue / execution core architecture may implement pipeline 2800 as follows: 1) instruction fetch 2838 performs the fetch and length decode phases 2802 and 2804; 2) decode unit 2840 performs decode phase 2806; 3) rename / allocate unit 2852 performs allocate phase 2808 and rename phase 2810; 4) scheduler unit(s) 2856 execute(s).perform the scheduling phase 2812; 5) the physical register file unit(s) 2858 and the memory unit 2870 perform the register read / memory read phase 2814; the execution cluster 2860 performs the execution phase 2816; 6) the memory unit 2870 and the physical register file unit(s) 2858 perform the write back / memory write phase 2818; 7) various units may participate in the exception handling phase 2822; and 8) the quiesce unit 2854 and the physical register file unit(s) 2858 perform the commit phase 2824.

[0260] The 2890 core may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set from MIPS Technologies in Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings in Sunnyvale, CA) that include the instruction(s) described herein. In one embodiment, the 2890 core includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), allowing the operations used by many multimedia applications to be performed using packed data.

[0261] It should be understood that the core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of ways, including sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core to each of the threads that the physical core is simultaneously executing concurrently), or a combination thereof (e.g., time-sliced ​​fetching and decoding followed by simultaneous multithreading as in Intel® Hyperthreading Technology).

[0262] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. While the illustrated embodiment of the processor also includes separate instruction and data cache units 2834 / 2874 and a shared L2 cache unit 2876, alternative embodiments may include a single internal cache for both instructions and data, such as an internal Level 1 (L1) cache or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or the processor. Alternatively, the entire cache may be external to the core and / or the processor. A specific example in-order core architecture

[0263] Fig. 29A-B illustrate a block diagram of a more specific example in-order core architecture, where the core would be one of several logical blocks (containing other cores of the same type and / or different types) in a chip. The logical blocks communicate via a high-bandwidth interconnect network (e.g., a ring network) with some fixed-function logic, memory I / O interfaces, and other necessary I / O logic, depending on the application.

[0264] Fig.29A is a block diagram of a single processor core, along with its connection to the on-chip interconnect network 2902 and its local subset of the Level 2 (L2) cache 2904, according to embodiments of the invention. In one embodiment, an instruction decoder 2900 supports the x86 instruction set with an extension for packed data instruction sets. An L1 cache 2906 allows low-latency accesses to cache memories in the scalar and vector units. While in one embodiment (to simplify the design) a scalar unit 2908 and a vector unit 2910 use separate register sets (scalar registers 2912 and vector registers 2914, respectively), and data transferred between them is written to memory and subsequently read from a Level 1 (L1) cache 2906, alternative embodiments of the invention may use a different approach (e.g.,use a single register set or include a communication path that allows data to be transferred between the two register files without writing and rereading).

[0265] The local subset of the L2 cache 2904 is part of a global L2 cache, which is divided into separate local subsets, one per processor core. Each processor core has a direct access path to its own local subset of the L2 cache 2904. Data read by a processor core is stored in its L2 cache subset 2904 and can be quickly accessed 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 2904 and is flushed from other subsets as necessary. The ring network ensures coherence for shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip.Each ring data path is 1012 bits wide per direction.

[0266] Fig. 29B is an expanded view of a portion of the processor core in Fig. 29A according to embodiments of the invention. Fig. Figure 29B includes an L1 data buffer 2906A, a portion of the L1 buffer 2904, and more details regarding the vector unit 2910 and the vector registers 2914. Specifically, the vector unit 2910 is a 16-wide vector processing unit (VPU) (see the 16-wide ALU 2928) that executes one or more of the following instructions: integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports swizzling of register inputs with swizzle unit 2920, numeric conversion with numeric conversion units 2922A-B, and replication with replication unit 2924 on the memory input. Write mask registers 2926 allow comparison of resulting vector writes.

[0267] Fig. 30 is a block diagram of a processor 3000 that, according to embodiments of the invention, may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid-bordered boxes in Fig. 30 illustrate a processor 3000 with a single core 3002A, a system agent 3010, a set of one or more bus controller units 3016, while the optional addition of the dashed-bordered boxes illustrates an alternative processor 3000 with multiple cores 3002AN, a set of one or more integrated memory controller units 3014 in the system agent unit 3010, and special-purpose logic 3008.

[0268] Therefore, various implementations of the processor 3000 may include: 1) a CPU, where the special-purpose logic 3008 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and the cores 3002A-N are one or more general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, a combination of the two); 2) a coprocessor, where the cores 3002A-N are a large number of special-purpose cores primarily intended for graphics and / or scientific (throughput); and 3) a coprocessor, where the cores 3002A-N are a large number of general-purpose in-order cores.Therefore, processor 3000 may be a general-purpose processor, coprocessor, or special-purpose processor, such as a network or communications processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a high-throughput many-integrated-core (MIC) coprocessor (containing 30 or more cores), an embedded processor, or the like. The processor may be implemented on one or more chips. Processor 3000 may be a part of one or more substrates and / or may be implemented on one or more substrates using a number of process techniques, such as BiCMOS, CMOS, or NMOS.

[0269] The memory hierarchy includes one or more levels of caches within the cores, a set of one or more shared cache units 3006, and external memory (not shown) coupled to the set of integrated memory controller units 3014. The set of shared cache units 3006 may include one or more mid-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other cache levels, a last-level cache (LLC), and / or combinations thereof. While in one embodiment, a ring-based interconnect unit 3012 interconnects the integrated graphics logic 3008 (the integrated graphics logic 3008 is an example of, and is also referred to herein as, special-purpose logic), the set of shared cache units 3006, and the system agent unit 3010 / theWhile the integrated memory controller unit(s) 3014 connects the integrated memory controller unit(s) 3014, alternative embodiments may utilize any number of well-known techniques for connecting such units. In one embodiment, coherence is maintained between one or more cache units 3006 and the cores 3002-AN.

[0270] In some embodiments, one or more of the cores 3002A-N are multithreaded. The system agent 3010 includes these components, which coordinate and operate the cores 3002A-N. The system agent unit 3010 may include, for example, a power control unit (PCU) and a display unit. The PCU may include logic and components required to regulate the power state of the cores 3002A-N and the integrated graphics logic 3008. The display unit is for driving one or more externally connected displays.

[0271] The cores 3002A-N may be homogeneous or heterogeneous with respect to an architectural instruction set; that is, two or more of the cores 3002A-N may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set. Example computer architectures

[0272] Fig.31-34 are block diagrams of example computer architectures. Other system designs and configurations known in the art for laptops, desktops, portable PCs, organizers, development workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, wearable devices, and various other electronic devices are also suitable. In general, an enormous variety of systems or electronic devices that can incorporate a processor and / or other execution logic as disclosed herein are suitable.

[0273] Now on Fig.Referring to Figure 31, a block diagram of a system 3100 according to an embodiment of the present invention is shown. System 3100 may include one or more processors 3110, 3115 coupled to a controller hub 3120. In one embodiment, controller hub 3120 includes a graphics memory controller hub (GMCH) 3190 and an input / output hub (IOH) 3150 (which may be on separate chips); GMCH 3190 includes memory and graphics controllers to which memory 3140 and a coprocessor 3145 are coupled; The IOH 3150 couples input / output (I / O) devices 3160 to the GMCH 3190. Alternatively, one or both of the memory and graphics controllers are integrated into the processor (as described herein), the memory 3140 and the coprocessor 3145 are directly coupled to the processor 3110, and the controller hub 3120 is integrated into a single chip with the IOH 3150.

[0274] The optional nature of the additional 3115 processors is explained in Fig. 31 is indicated by dashed lines. Each processor 3110, 3115 may include one or more of the processing cores described herein and may be a version of processor 3000.

[0275] Memory 3140 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of the two. For at least one embodiment, controller hub 3120 communicates with processor(s) 3110, 3115 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a QuickPath Interconnect (QPI), or a similar interconnect 3195.

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

[0277] There may be a variety of differences between the physical resources 3110, 3115 with respect to a spectrum of performance metrics, including architectural, microarchitectural, thermal, energy consumption characteristics, and the like.

[0278] In one embodiment, processor 3110 executes instructions that control data processing operations of a general type. Coprocessor instructions may be embedded within the instructions. Processor 3110 detects that these coprocessor instructions are of a type to be executed by the attached coprocessor 3145. Accordingly, processor 3110 issues these coprocessor instructions (or control signals representing the coprocessor instructions) to coprocessor 3145 on a coprocessor bus or other connection. Coprocessor(s) 3145 accept and execute the received coprocessor instructions.

[0279] Now on Fig. Referring to Figure 32, a block diagram of a first more specific exemplary system 3200 is shown in accordance with an embodiment of the present invention. As shown in Fig.32, multiprocessor system 3200 is a point-to-point interconnect system and includes a first processor 3270 and a second processor 3280 coupled via a point-to-point interconnect 3250. Each of processors 3270 and 3280 may be a version of processor 3000. In one embodiment of the invention, processors 3270 and 3280 are processors 3110 and 3115, respectively, while coprocessor 3238 is coprocessor 3145. In another embodiment, processors 3270 and 3280 are processor 3110 and coprocessor 3145, respectively.

[0280] Processors 3270 and 3280 are shown including integrated memory controller (IMC) units 3272 and 3282, respectively. Processor 3270 also includes point-to-point (PP) interfaces 3276 and 3278 as part of its bus control units; similarly, the second processor 3280 includes PP interfaces 3286 and 3288. Processors 3270, 3280 may exchange information via a point-to-point (PP) interface 3250 using PP interface circuits 3278, 3288. As shown in Fig. 32, the IMCs 3272 and 3282 couple the processors to respective memories, namely a memory 3232 and a memory 3234, which may be portions of main memory locally attached to the respective processors.

[0281] Processors 3270, 3280 may each exchange information with a chipset 3290 via individual PP interfaces 3252, 3254 using point-to-point interface circuits 3276, 3294, 3286, 3298. Chipset 3290 may optionally exchange information with coprocessor 3238 via a high-performance interface 3292. In one embodiment, coprocessor 3238 is a special-purpose processor, such as a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0282] A shared cache (not shown) may be included in one of the two processors or external to both processors, but connected to the processors via a PP interconnect, so that the local cache information of one or both processors can be stored in the shared cache when one processor is placed in a low power mode.

[0283] Chipset 3290 may be coupled to a first bus 3216 via an interface 3296. In one embodiment, first bus 3216 may be a Peripheral Component Interconnect (PCI) bus or a bus such as a PCI Express bus or other third-generation I / O interconnect bus, although the scope of the present invention is not limited thereby.

[0284] As in Fig.32, various I / O devices 3214 may be coupled to the first bus 3216 along with a bus bridge 3218 that couples the first bus 3216 to a second bus 3220. In one embodiment, one or more additional processors 3215, such as coprocessors, high-throughput MIC processors, GPGPUs, accelerators (such as graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processors, are coupled to the first bus 3216. In one embodiment, the second bus 3220 may be a low-pin-count (LPC) bus. Various devices may be coupled to a second bus 3220, including, for example, a keyboard and / or mouse 3222, communication devices 3227, and a data storage unit 3228, such as a disk drive or other mass storage device, which in one embodiment may contain instructions / code and data 3230.Furthermore, an audio I / O 3224 may be coupled to the second bus 3220. Note that other architectures are possible. For example, a system may use a multi-core processor instead of the point-to-point architecture of . Fig. 32 implement a multipoint bus or other such architecture.

[0285] Now on Fig. Referring to Figure 33, a block diagram of a second, more specific exemplary system 3300 is shown in accordance with an embodiment of the present invention. Like elements in the Fig. 32 and Fig. 33 have the same reference numbers, and certain aspects of Fig. 32 were Fig. 33 omitted to avoid obscuring other aspects of Fig. 33 to be avoided.

[0286] Fig.Figure 33 illustrates that processors 3270, 3280 may include integrated memory and I / O control logic ("CL") 3272, 3282, respectively. Therefore, CLs 3272, 3282 include integrated memory controller units and include I / O control logic. Fig. Figure 33 illustrates that not only are the memories 3232, 3234 coupled to the CL 3272, 3282, but also that I / O devices 3314 are also coupled to the control logic 3272, 3282. Legacy I / O devices 3315 are coupled to the chipset 3290.

[0287] Now on Fig. Referring to Figure 34, a block diagram of an SoC 3400 in accordance with an embodiment of the present invention is shown. Similar elements in Fig. 30 have the same reference numbers. Dashed-bordered boxes are also optional features on more advanced SoCs. Fig.34 is an interconnect unit(s) 3402 coupled to: an application processor 3410 including a set of one or more cores 3002A-N including cache units 3004A-N, and a shared cache unit(s) 3006; a system agent unit 3010; a bus controller unit(s) 3016; an integrated memory controller unit(s) 3014; a set of one or more coprocessors 3420, which may include integrated graphics logic, a graphics processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 3430; a direct memory access (DMA) unit 3432; and a display unit 3440 for coupling to one or more external displays. In one embodiment, the application processor(s) include(s).the coprocessor(s) 3420 comprise a special-purpose processor, such as a network or communications processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, or the like.

[0288] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments of the invention may be implemented as computer programs or program code executing on programmable systems comprising at least one process, a memory system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0289] Program code, such as the one in Fig.Code 3230 illustrated in Figure 32 may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system that includes a processor, such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0290] The program code may be implemented in a high-level procedural or object-oriented programming language to communicate with a processing system. The program code may also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

[0291] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within the processor that, when read by a machine, causes the machine to generate logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and delivered to various customers or manufacturing facilities for loading into the manufacturing machines that actually manufacture the logic or processor.

[0292] Such machine-readable storage media may include non-transitory, tangible assemblies manufactured or formed by a machine or device containing storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disc read-only memories (CD-ROMs), rewritable compact discs (CD-RWs) and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), phase change memories (PCMs), magnetic or optical cards or any other type of media suitable for storing electronic instructions,but are not limited to this.

[0293] Accordingly, embodiments of the invention also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as hardware description language (HDL), that defines structures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products. Emulation (including binary translation, code morphing, etc.)

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

[0295] Fig.Figure 35 is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a destination instruction set according to embodiments of the invention. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Fig.35 shows that a high-level language program 3502 can be compiled using an x86 compiler 3504 to generate x86 binary code 3506 that can be natively executed by a processor having at least one x86 instruction set core 3516. The processor having at least one x86 instruction set core 3516 represents any processor that can perform substantially the same functions as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise processing: (1) a substantial portion of the instruction set of the Intel x86 instruction set core, or (2) object code versions of applications or other software intended to run on an Intel processor having at least one x86 instruction set core to achieve substantially the same result as an Intel processor having at least one x86 instruction set core.The x86 compiler 3504 represents a compiler operable to generate x86 binary code 3506 (e.g., object code) that can be executed with or without additional link processing on the processor having at least one x86 instruction set core 3516. Likewise, . Fig.35, that the high-level language program 3502 can be compiled using an alternative instruction set compiler 3508 to generate alternative instruction set binary code 3510 that can be natively executed by a processor without at least one x86 instruction set core 3514 (e.g., a processor with cores that execute the MIPS instruction set from MIPS Technologies in Sunnyvale, CA and / or that execute the ARM instruction set from ARM Holdings in Sunnyvale, CA). The instruction converter 3512 is used to convert the x86 binary code 3506 into code that can be natively executed by the processor without an x86 instruction set core 3514.This converted code is unlikely to be the same as the binary code of an alternative instruction set 3510, since an instruction converter capable of doing so would be difficult to manufacture; nevertheless, the converted code will achieve the general operation and consist of instructions from the alternative instruction set. Therefore, the instruction converter 3512 represents software, firmware, hardware, or a combination thereof that, through emulation, simulation, or any other process, allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code 3506.

Claims

[1] Processing unit (3000) comprising: a circuit arrangement for performing operations according to an instruction (2102), the instruction (2102) specifying a first matrix with M rows by K columns of 32-bit elements each having eight 4-bit data elements, a second matrix with K rows by N columns of 32-bit elements each having eight 4-bit data elements, and a third matrix with M rows by N columns, the instruction having a first indicator for indicating whether the 4-bit data elements of the first matrix are signed or unsigned, and a second indicator for indicating whether the 4-bit data elements of the second matrix are signed or unsigned, the operations including: for each row m of the M rows of the first matrix and for each column n of the N columns of the second matrix: for each of the K 32-bit elements of row m of the first matrix: Multiplying eight 4-bit data elements of the 32-bit element of row m of the first matrix by corresponding ones of eight 4-bit data elements of a corresponding 32-bit element of column n of the second matrix to produce eight products; and Storing a 32-bit result data item in a row m of the M rows and a column n of the N columns of the third matrix, the 32-bit result data item being based on accumulation of the eight products generated for each of the K 32-bit elements of row m of the first matrix with a 32-bit data item of row m of the first matrix and column n of the second matrix. [2] The processing unit (3000) of claim 1, wherein the operations further comprise performing saturation to generate the 32-bit result data item. [3] The processing unit (3000) of claim 2, wherein performing saturation comprises performing signed saturation. [4] Processing unit (3000) according to one of claims 1 to 3, wherein K is equal to 4. [5] Processing unit (3000) according to claim 4, wherein M is one of the values ​​2, 4, 8 and 16. [6] Processing unit (3000) according to one of claims 1 to 5, wherein the first matrix is ​​to be stored in a plurality of registers of the processing unit (3000), and wherein the second matrix is ​​to be stored in a plurality of registers of the processing unit (3000). [7] Processing unit (3000) according to one of claims 1 to 6, comprising: a variety of memory controllers (3014); a level two cache memory, L2 cache memory, (3006) coupled to the plurality of memory controllers (3014); and a plurality of cores (3002) coupled to the plurality of memory controllers (3014) and to the L2 cache memory (3006), the plurality of cores (3002) comprising the circuitry. [8] The processing unit (3000) of claim 7, further comprising a connection interface (3012) coupled to the plurality of cores (3002). [9] The processing unit (3000) of claim 7 or 8, further comprising a bus controller interface (3016) coupled to the plurality of cores (3002). [10] Processing unit (3000) according to one of claims 7 to 9, wherein the plurality of cores (3002) comprise graphics cores. [11] The processing unit (3000) of claim 10, wherein the plurality of cores (3002) comprise heterogeneous graphics cores. [12] The processing unit (3000) of any one of claims 7 to 11, further comprising an instruction converter to convert the instruction (2102) into one or more instructions of another instruction set that can be executed by the plurality of cores (3002). [13] The processing unit (3000) of any one of claims 1 to 12, wherein the 4-bit data elements of one of the first matrix and the second matrix are signed and the 4-bit data elements of another of the first matrix and the second matrix are unsigned. [14] Method comprising: Processing data with a processing unit, including performing operations according to an instruction, the instruction specifying a first matrix having M rows by K columns of 32-bit elements each having eight 4-bit data elements, a second matrix having K rows by N columns of 32-bit elements each having eight 4-bit data elements, and a third matrix having M rows by N columns, the instruction having a first indicator indicating whether the 4-bit data elements of the first matrix are signed or unsigned, and a second indicator indicating whether the 4-bit data elements of the second matrix are signed or unsigned, the operations including: for each row m of the M rows of the first matrix and for each column n of the N columns of the second matrix: for each of the K 32-bit elements of row m of the first matrix: Multiplying eight 4-bit data elements of the 32-bit element of row m of the first matrix by corresponding ones of eight 4-bit data elements of a corresponding 32-bit element of column n of the second matrix to produce eight products; and Storing a 32-bit result data item in a row m of the M rows and a column n of the N columns of the third matrix, the 32-bit result data item being based on accumulation of the eight products generated for each of the K 32-bit elements of row m of the first matrix with a 32-bit data item of row m of the first matrix and column n of the second matrix. [15] The method of claim 14, wherein the operations further comprise performing saturation to generate the 32-bit result data item. [16] The method of claim 15, wherein performing saturation comprises performing signed saturation. [17] A method according to any one of claims 14 to 16, wherein K is 4. [18] The method of claim 17, wherein M is one of 2, 4, 8 and 16. [19] The method of any one of claims 14 to 18, further comprising accessing the first array of a plurality of registers of the processing unit and accessing the second array of a plurality of registers of the processing unit. [20] A method according to any one of claims 14 to 19, further comprising: Accessing the memory using a plurality of memory controllers; and Storing data in a level two cache (L2 cache). [21] The method of claim 20, wherein the processing unit comprises a plurality of cores and the plurality of cores comprises heterogeneous graphics cores. [22] The method of claim 21, further comprising converting the instruction into one or more instructions of a different instruction set that can be executed by the plurality of cores. [23] A method according to any one of claims 14 to 22, wherein the 4-bit data elements of one of the first matrix and the second matrix are signed and the 4-bit data elements of another of the first matrix and the second matrix are unsigned. [24] Apparatus comprising means for carrying out the method according to any one of claims 14 to 23. [25] A computer program product containing instructions which, when executed by one or more machines, cause the one or more machines to perform the method of any one of claims 14 to 23. [26] A machine-readable storage medium on which the computer program product according to claim 25 is stored.

Images