System and method for loading a pair of slice registers

Abstract

Embodiments detailed herein relate to systems and methods for loading a pair of slice registers. In one example, a processor includes: a decode circuit to decode a load matrix pair instruction, the load instruction having fields for an opcode, a source identifier, and a destination identifier, the source and destination identifiers to identify a source matrix and a destination matrix, respectively, each matrix having a PAIR parameter equal to true; and an execution circuit to execute the decoded load matrix pair instruction to load each element of a left slice and a right slice of the identified destination matrix from corresponding element locations of a left slice and a right slice of the identified source matrix, respectively, wherein execution operates on one row of the identified destination matrix at a time starting with a first row.

Description

[0001] This application is a continuation-in-part of the invention patent application entitled "System and Method for Loading Tile Register Pairs" having application number 201811452229.3, filed on November 30, 2018. TECHNICAL FIELD

[0002] The field of the invention relates generally to computer processor architecture, and more specifically to systems and methods for loading tile register pairs. BACKGROUND

[0003] Matrices are becoming increasingly important in computing tasks such as machine learning and other batch data processing. BRIEF DESCRIPTION OF DRAWINGS

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

[0005] Figure 1A An embodiment of a configured tile is illustrated;

[0006] Figure 1B An embodiment of a configured tile is illustrated;

[0007] Figure 2 Several examples of matrix storage are illustrated;

[0008] Figure 3 An embodiment of a system utilizing a matrix (tile) operation accelerator is illustrated;

[0009] Figure 4 And Figure 5 Different embodiments of how to share memory using a matrix operation accelerator are illustrated;

[0010] Figure 6 An embodiment of a matrix multiply accumulate ("TMMA") operation using a tile is illustrated;

[0011] Figure 7 An embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction is illustrated;

[0012] Figure 8 An embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction is illustrated;

[0013] Figure 9 An embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction is illustrated;

[0014] Figure 10 An embodiment of a subset of the execution of an iteration of a chained fused multiply accumulate instruction is illustrated;

[0015] Figure 11Figure illustrates a SIMD implementation of size a power of two, where the accumulator uses an input size that is larger than the size of the input to the multiplier, according to an embodiment;

[0016] Figure 12 Figure illustrates an embodiment of a system utilizing matrix operation circuitry;

[0017] Figure 13 Figure illustrates an embodiment of a processor core pipeline that supports matrix operations using tiles;

[0018] Figure 14 Figure illustrates an embodiment of a processor core pipeline that supports matrix operations using tiles;

[0019] Figure 15 Figure illustrates an example of a matrix expressed in row-major format and column- major format;

[0020] Figure 16 Figure illustrates an example of the use of a matrix (tile);

[0021] Figure 17 Figure illustrates an embodiment of a method of the use of a matrix (tile);

[0022] Figure 18 Figure illustrates support for configuration of the use of tiles according to an embodiment;

[0023] Figure 19 Figure illustrates an embodiment of a description of a matrix (tile) that will be supported;

[0024] Figures 20(A)-20(D) Figure illustrates an example of a register(s);

[0025] Figure 21 Figure illustrates an example execution of a TILELOADQPAIR instruction;

[0026] Figure 22 Figure illustrates an embodiment of a processor that executes a TILELOADQPAIR instruction;

[0027] Figure 23 Figure illustrates a more detailed description of the execution of a TILELOADQPAIR instruction;

[0028] Figure 24A is example pseudocode that describes an embodiment of a processor that executes a TILELOADQPAIR instruction;

[0029] Figure 24B is example pseudocode that describes an embodiment of a helper function used by a processor that executes a TILELOADQPAIR instruction;

[0030] Figures 25A-25Bis a block diagram illustrating a generic vector friendly instruction format and its instruction templates according to an embodiment of the application;

[0031] Figure 25A is a block diagram illustrating a generic vector friendly instruction format and its class A instruction templates according to an embodiment of the application;

[0032] Figure 25B is a block diagram illustrating a generic vector friendly instruction format and its class B instruction templates according to an embodiment of the application;

[0033] Figure 26A is a block diagram illustrating an exemplary specific vector friendly instruction format according to an embodiment of the application;

[0034] Figure 26B is a block diagram illustrating the fields of a specific vector friendly instruction format that make up the full opcode field according to one embodiment of the application;

[0035] Figure 26C is a block diagram illustrating the fields of a specific vector friendly instruction format that make up the register index field according to one embodiment of the application;

[0036] Figure 26D is a block diagram illustrating the fields of a specific vector friendly instruction format that make up the extended operation field according to one embodiment of the application;

[0037] Figure 27 is a block diagram of a register architecture according to one embodiment of the application;

[0038] Figure 28A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming out-of-order issue / execution pipeline according to embodiments of the application;

[0039] Figure 28B is a block diagram illustrating exemplary embodiments of an in-order architecture core and an exemplary register renaming out-of-order issue / execution architecture core to be included in a processor according to embodiments of the application;

[0040] Figures 29A-29B is a block diagram illustrating a more specific exemplary in-order core that will be one of several logical blocks (including other cores of the same or different type) in a chip;

[0041] Figure 29A is a block diagram of a single processor core according to an embodiment of the application and its connection to an on-die interconnection network and a local subset of its level 2 (L2) cache;

[0042] Figure 29B is a block diagram of a processor according to an embodiment of the application; Figure 29Aa diagram of a portion of a processor core in the

[0043] Figure 30 is a block diagram of a processor that can have more than one core, that can have an integrated memory controller, and that can have an integrated graphics device, in accordance with embodiments of the present application;

[0044] Figures 31-34 is a block diagram of an exemplary computer architecture;

[0045] Figure 31 shows a block diagram of a system in accordance with one embodiment of the present application;

[0046] Figure 32 is a block diagram of a first more specific exemplary system in accordance with an embodiment of the present application;

[0047] Figure 33 is a block diagram of a second more specific exemplary system in accordance with an embodiment of the present application;

[0048] Figure 34 is a block diagram of a system-on-a-chip (SoC) in accordance with an embodiment of the present application; and

[0049] Figure 35 is a block diagram of converting binary instructions in a source instruction set into binary instructions in a target instruction set using a software instruction translator, in accordance with an embodiment of the present application. DETAILED DESCRIPTION

[0050] In the following description, numerous specific details are set forth. However, it is understood that embodiments of the application can be practiced without the specific details. In other instances, well-known circuits, structures and techniques have not been shown to avoid obscuring the understanding of this description.

[0051] References in the specification to "one embodiment," "an embodiment,” "an example embodiment,” etc. indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of those skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described or claimed. As used herein, the term "exemplary” and variations thereof mean an example and is not intended to convey an indication of a preferred or ideal embodiment.

[0052] In many mainstream processors, handling matrices is a difficult and / or instruction intensive task. For example, multiple rows of a matrix can be packed into multiple packed data (e.g., SIMD or vector) registers, and then multiple rows of the matrix can be operated on individually. For example, adding two 8x2 matrices can require loading or packing into four packed data registers, depending on the data size. Then, a first addition is performed on the packed data registers corresponding to the first row from each matrix, and a second addition is performed on the packed data registers corresponding to the second row from each matrix. Then, the resulting packed data registers are scattered back to memory. While this scenario can be acceptable for small matrices, it is generally not acceptable for larger matrices.

[0053] I. High Level Discussion

[0054] Detailed herein are mechanisms for supporting matrix operations in computer hardware such as central processing units (CPUs), graphics processing units (GPUs), and accelerators. Matrix operations utilize 2-dimensional (2-D) data representing one or more packed regions of memory such as registers. Throughout this specification, these 2-D data are referred to as tiles. Note that a matrix can be smaller than a tile (use fewer than all tiles), or can utilize multiple tiles (the matrix is larger than the size of any tile). Throughout this specification, the language of matrix (tile) is used to indicate operations performed using tiles that affect a matrix; whether the matrix is larger than any tile is generally irrelevant.

[0055] Each tile can be acted upon by different operations such as those detailed herein, including but not limited to: matrix (tile) multiplication, tile addition, tile subtraction, tile diagonal, tile zero, tile transpose, tile electrode, tile broadcast, tile row broadcast, tile column broadcast, tile multiply, tile multiply and accumulate, tile move, etc. In addition, support for operations such as using a scaler and / or a bias, or support for non-numeric applications, e.g., OpenCL, "local memory", data compression / decompression, etc., can be used with these operations in the future.

[0056] Multiple portions of storage such as (non-volatile and volatile) memory, registers, caches, etc. are arranged as tiles having different lateral and longitudinal dimensions. For example, a tile can have a lateral dimension of 4 (e.g., four rows of a matrix) and a longitudinal dimension of 8 (e.g., 8 columns of a matrix). Typically, the lateral dimension is the relevant element size (e.g., 2 bits, 4 bits, 8 bits, 16 bits, 32 bits, 64 bits, 128 bits, etc.). Multiple data types can be supported (single precision floating point, double precision floating point, integer, etc.).

[0057] A. Example Use of Configured Tiles

[0058] In some embodiments, tile parameters can be configurable. For example, a given tile can be configured to provide tile options. Exemplary tile options include, but are not limited to, the number of rows of the tile, the number of columns of the tile, whether the tile is valid, and whether the tile is composed of pairs of equal size tiles.

[0059] Figure 1A An embodiment of configured tiles is illustrated. As shown, 4 kB of application memory 102 has 1 kB of tiles stored thereon - tile 0 104, tile 1 106, tile 2 108, and tile 3 110. In this example, the 4 tiles are not composed of pairs, and each tile has elements arranged in rows and columns. Tile t0 104 and tile tl 106 have K rows and N columns of 4 byte elements (e.g., single precision data), where K = 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). Since the width of a double precision operand is twice that of a single precision operand, this configuration is consistent with the palette for providing tile options, providing at least 4 kB of total storage to at least 4 names. In operation, tiles can be loaded from memory and stored to memory using load and store operations. The amount of application memory available, as well as the size, number, and configuration of tiles available, varies depending on the instruction encoding scheme used.

[0060] Figure 1B An embodiment of configured tiles is illustrated. As shown, 4 kB of application memory 122 can have 2 pairs of 1 kB of tiles stored thereon, the first pair being tile t4L 124 and tile t4R 126, and the second pair being tile t5L 128 and tile t5R 130. As shown, the tile pairs are divided into left and right tiles. In other embodiments, the tile pairs are divided into even and odd tiles. In this example, the 4 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 = 8 and N = 32. Tile t5L 128 and tile t5R 130 have K rows and N / 2 columns of 8 byte elements (e.g., double precision data). Since the width of a double precision operand is twice that of a single precision operand, this configuration is consistent with the palette for providing tile options, providing at least 4 kB of total storage to at least 2 names. Figure 1A The four tiles of FIG. 1 use 4 names, each naming a tile of 1 kB, while Figure 1B The pairs of tiles in FIG. 2 can use 2 names to specify the paired tiles. In some embodiments, a tile instruction accepts the names of the paired tiles as operands. In operation, tiles can be loaded from memory and stored to memory using load and store operations. The amount of application memory available, as well as the size, number, and configuration of tiles available, varies depending on the instruction encoding scheme used.

[0061] In some embodiments, tile parameters can be configurable. For example, a "palette" is used to provide tile options. Exemplary options include, but are not limited to: number of tile names, number of bytes in a stored row, number of rows and columns in a tile, etc. For example, the maximum "height" (number of rows) of a tile can be defined as:

[0062] Tile Max Rows = constructed storage / (number of palette names / number of bytes per row)

[0063] Thus, the application can be written so that the fixed use of names will be able to take advantage of different storage sizes across implementations.

[0064] Configuration of a tile is accomplished using a tile configuration ("TILECONFIG") instruction, which defines a particular tile usage in the selected palette. The declaration includes the number of tile names to use, the requested number of rows and columns for each name (tile), and in some embodiments, the requested data type for each tile. In some embodiments, a consistency check is performed during execution of the TILECONFIG instruction to determine that it matches the restrictions of the palette entry.

[0065] B. Exemplary Tile Storage Types

[0066] Figure 2 Several examples of matrix storage are illustrated. In (A), a tile is stored in memory. As shown, each "row" consists of four packed data elements. To reach the next "row," a stride value is used. Note that the rows can be stored contiguously in memory. When tile storage does not map the underlying memory array row width, a strided memory access allows access to one row and then to the next row.

[0067] Loading from memory and storing to memory is typically a strided access from application memory to packed data rows. Exemplary TILELOAD and TILESTORE instructions or other instructions reference application memory as a TILE (tile) operand in the load operation instruction, and in some embodiments are restartable to handle (up to) 2*row page faults, unmasked floating point exceptions, and / or per-instruction interrupts.

[0068] In (B), a matrix is stored in a tile consisting of multiple 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, contiguous registers are used, however, this need not be the case.

[0069] In (C), the matrix is stored in a non-register-stored tile that is accessible by a fused multiply accumulate (FMA) circuit used in the tile operation. The storage can be internal to the FMA, or adjacent to the FMA. Further, in some embodiments, as discussed below, the storage can be for data elements, rather than an entire row of a tile.

[0070] Parameters supported by the TMMA architecture are reported via CPUID. In some embodiments, the information list includes a maximum height and a maximum SIMD size. Configuring the TMMA architecture requires specifying the size of each tile, the element size of each tile, and a palette identifier. This is done by executing a TILECONFIG instruction.

[0071] Successful execution of the 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 in context switches that use tiles. In some embodiments, 2 XCE0 bits are used in total by XSAVE, one for the TILECONFIF metadata, and one bit corresponding to the actual tile payload data.

[0072] TILECONFIG not only configures tile usage, but also sets a state variable that indicates that the program is in a code region with tiles configured. Implementations can enumerate restrictions on other instructions that can be used with tile regions, such as no use of existing register groups, etc.

[0073] Exiting a tile region is typically done with a TILERELEASEALL instruction. This instruction takes no parameters and quickly invalidates all tiles (indicating that data elements no longer need any saving and restoring), and clears the internal state corresponding to being in a tile region.

[0074] In some embodiments, a tile operation will zero out any rows and any columns that are beyond the size specified by the tile configuration. For example, as each row is written, the tile operation will zero out data beyond the configured number of columns, taking into account the size of the elements. For example, for a 64 byte row and a tile configured with 10 rows and 12 columns, an operation that writes FP32 elements will write 12*4 bytes of output / result data forward into each of the 10 rows, and zero out the remaining 4*4 bytes in each row. The tile operation also zeros out completely any rows after the first 10 configured rows. When using a 1K tile with 64 byte rows, there will be 16 rows, so in this example, the last 6 rows will also be zeroed out.

[0075] In some embodiments, when loading data, context restore (e.g., XRSTOR) forces the data type beyond the configured rows of a tile to be maintained as zero. If not validly configured, all rows are zeroed. XRSTOR of a tile of data loads garbage in the columns beyond those configured. It should not be possible for XRSTOR to clear beyond the configured number of columns, as there is no element width associated with the tile configuration.

[0076] When writing the entire TILE storage area to memory, context save (e.g., XSAVE) exposes the entire TILE storage area. If XRSTOR loads garbage into the rightmost portion of a tile, that data will be saved by XSAVE. For rows beyond the number specified for each tile, XSAVE will write zeros.

[0077] In some embodiments, tile instructions are restartable. Operations that access memory allow for restarts after page faults. Computation instructions that handle floating point operations also allow for unmasked floating point exceptions, by virtue of the masking of exceptions controlled by control and / or status registers.

[0078] To support restarting instructions after these events, instructions store information in start registers, detailed below.

[0079] II. Matrix (Tile) Operation System

[0080] A. Exemplary Hardware Support

[0081] Figure 3 An embodiment of a system utilizing a matrix (tile) operation accelerator is illustrated. In this illustration, a host processor / processing system 301 passes commands 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 shown in this manner for discussion purposes only. As detailed later, accelerator 307 can be part of a processing core. Typically, commands 311 that are tile manipulation operator instructions refer to tiles in register-register ("reg-reg") or register-memory ("reg-mem") format. Other commands, such as TILESTORE, TILELOAD, TILECONFIG, etc., do not perform data operations on tiles. The commands can be decoded instructions (e.g., micro-operations) or macro- instructions for accelerator 307 to handle.

[0082] In this example, a coherent memory interface 303 is coupled to host processor / processing system 301 and matrix operation accelerator 307, enabling them to share memory. Figure 4 and Figure 5 Different embodiments of how to share memory using a matrix operation accelerator are illustrated. As illustrated in Figure 1, a host processor / processing system 301 can be coupled to a matrix operation accelerator 307 via a coherent memory interface 303.Figure 4 As shown in the middle, the host processor 401 and the matrix operation accelerator 405 share the same memory 403. Figure 5 An embodiment is illustrated in which the host processor 501 and the matrix operation accelerator 505 do not share memory, but can access each other's memory. For example, the processor 501 can access the tile memory 507, and as usual utilize its host memory 503. Similarly, the matrix operation accelerator 505 can access the host memory 503, but more typically use its own memory 507. Note that these memories can be of different types.

[0083] In some embodiments, the matrix operation accelerator 307 includes a plurality of FMAs 309 coupled to data buffers 305 (in some implementations, one or more of these buffers 305 are stored in the grid of FMAs as shown). The data buffers 305 buffer tiles loaded from memory (e.g., using tile load or tile store instructions) and / or tiles stored to memory. The data buffers can be, for example, a plurality of registers. Typically, these FMAs are arranged in a grid of chained FMAs 309 capable of reading and writing tiles. In this example, the matrix operation accelerator 307 is used to perform a matrix multiplication operation using tiles TO, Tl, and T2. At least one of the tiles is housed in the FMA grid 309. In some embodiments, all of the tiles in the operation are stored in the FMA grid 309. In other embodiments, only a subset is stored in the FMA grid 309. As shown, Tl is housed, while TO and T2 are not. Note that A, B, and C refer to matrices of these tiles, which can or can not occupy the entire space of tiles.

[0084] Figure 6 An embodiment is illustrated using a matrix multiplication accumulation ("TMMA") operation using tiles.

[0085] The number of rows of the matrix (tile A 601) matches the number of (chained) FMAs in series, including the latency of the computation. Implementations are free to recirculate on a grid of smaller height, but the computation remains the same.

[0086] The source / destination vector is from an N-row tile (tile C 605), and the grid 611 of FMAs performs N vector-matrix operations, resulting in a complete instruction to perform a matrix multiplication of tiles. Tile B 603 is another vector source and provides a "broadcast" term to the FMA in each stage.

[0087] In operation, the elements of matrix B (stored in tile B 603) in some embodiments are spread across the rectangular grid of FMAs. Matrix B (stored in tile A 601) has its elements of a row transposed to match the column dimension of the matrix grid of the FMAs. At each FMA in the grid, the elements of A and B are multiplied, and added to the summand (from above in the diagram), and passed out and to the next row of FMAs (or final output).

[0088] The latency of a single step is proportional to K (the row height of matrix B), and a slave TMMA typically has enough source-destination rows (in a single tile or across tiles) to hide this latency. Implementations can also split the SIMD (packed data element) dimension M (the row height of matrix A) across time steps, but this only changes the constant by which K is multiplied. When the program specifies a K that is less than the maximum enumerated by the TMACC, implementations are free to do this using "masking" or "early-out."

[0089] The latency of the 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.

[0090] Figure 7 An embodiment illustrating a subset of the iterative execution of a chained fused multiply-accumulate instruction. In particular, Figure 7 An embodiment illustrating the iterative execution circuitry for one packed data element location of the destination. In this embodiment, the chained fused multiply-accumulate operates on multiple signed sources, with the accumulator 2x the input data size.

[0091] The first signed source (source 1 701) and the 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. The third signed source (source 3 709) has two packed data elements, each of which stores signed data. The size of the first signed source 701 and the size of the second signed source 703 are half the size of the third signed source (initial value or previous result) 709. For example, the first signed source 701 and the second signed source 703 can have 32-bit packed data elements (e.g., single precision floating point), while the third signed source 709 can have 64-bit packed data elements (e.g., double precision floating point).

[0092] In this illustration, only the most significant two packed data element locations of the first signed source 701 and the second signed source 703, and the most significant packed data element location of the third signed source 709 are shown. Of course, the other packed data element locations will also be processed.

[0093] As shown, the packed data elements are processed in pairs. For example, the data in the most significant packed data element position of the first signed source 701 and the second signed source 703 are multiplied using multiplier circuit 705, and the data in the next most significant packed data element position of the first signed source 701 and the second signed source 703 are multiplied using multiplier circuit 707. In some embodiments, these multiplier circuits 705 and 707 are reused for other packed data element positions. In other embodiments, additional multiplier circuits are used so that the packed data elements are processed in parallel. In some contexts, the parallel execution is accomplished using a lane of size equal to the size of the signed third source 709. The results of each of these multiplications are added using add circuit 711.

[0094] The result of the addition of these multiplication results is added (using a different adder 713 or the same adder 711) to the data in the most significant packed data element position from the signed source 3 709.

[0095] Finally, the result of the second addition is stored into the signed destination 715 in the packed data element position corresponding to the packed data element position from the signed third source 709, or if there is a next iteration, the result of the second addition is passed on to the next iteration. In some embodiments, a write mask is applied to this storage so that if the corresponding mask (bit) is set, the storage occurs, and if the corresponding mask (bit) is not set, the storage does not occur.

[0096] Figure 8 An embodiment illustrating a subset of the execution of an iteration of a chained fused multiply accumulate instruction. In particular, Figure 8 An execution circuit for an iteration of one packed data element position of a destination. In this embodiment, the chained fused multiply accumulate is operating on signed sources where the accumulator is twice the size of the input data.

[0097] The first signed source (source 1 801) and the 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. The third signed source (source 3 809) has two packed data elements, each of which stores signed data. The size of the first signed source 801 and the size of the second signed source 803 is half the size of the third signed source 809. For example, the first signed source 801 and the second signed source 803 can have 32-bit packed data elements (e.g., single precision floating point), while the third signed source 809 can have 64-bit packed data elements (e.g., double precision floating point).

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

[0099] As shown, the compact data elements are processed in pairs. For example, the data of the most significant compact data element positions of the first signed source 801 and the second signed source 803 are multiplied using multiplier circuit 805, and the data of the next most significant compact data element positions of the first signed source 801 and the second signed source 803 are multiplied using multiplier circuit 807. In some embodiments, these multiplier circuits 805 and 807 are reused for the other compact data element positions. In other embodiments, additional multiplier circuits are used so that the compact data elements are processed in parallel. In some contexts, the parallel execution is accomplished using lanes of a size that is the size of the signed third source (initial value or previous iteration result) 809. The results of each of the multiplications are added to the signed third source 809 using add / saturate circuit 813.

[0100] When the addition results in an excessively large value, the add / saturate (accumulator) circuit 813 preserves the sign of the operand. Specifically, for a multiway addition with an infinite precision result between the write to the destination or next iteration, a saturation evaluation occurs. When the accumulator 813 is floating point and the input term is integer, the sum of the products and the floating point accumulator input value are converted to an infinite precision value (hundreds of bits of fixed point), the addition of the multiplication result with the third input is performed, and a single round to the actual accumulator type is performed.

[0101] Unsigned saturation means that the input value is limited to the maximum unsigned number (all ones) of that element width. Signed saturation means that the value is limited to be in the range between the minimum complex number and the maximum integer of that element width (e.g., for a byte, the range is from -128 (= -2^7) to 127 (= 2^7 - 1)).

[0102] Finally, the result of the addition and saturation check is stored into the signed result 815 in the compact data element position corresponding to the compact data element position of the self signed third source 809, or if there is a next iteration, the result is passed on to the next iteration. In some embodiments, a write mask is applied to this storage so that if the corresponding mask (bit) is set, the storage occurs, and if the corresponding mask (bit) is not set, the storage does not occur.

[0103] Figure 9 An embodiment illustrating a subset of the execution of an iteration of a chained fused multiply-add instruction. Specifically, Figure 9An execution circuit for one iteration of a packed data element position of a destination is illustrated. In this embodiment, chained fused multiply accumulate is operating on signed and unsigned sources, where the accumulator is four times the size of the input data.

[0104] The first signed source (source 1 901) and the second unsigned source (source 2 903) each have four packed data elements with packed data. Each of these packed data elements has data such as floating point data or integer data. The third signed source (initial value or result 915) has packed data elements storing packed data. The size of the first source 901 and the size of the second source 903 are one quarter the size of the third signed source 915. For example, the first source 901 and the second source 903 can have 16-bit packed data elements (e.g., words), while the third signed source 915 can have 64-bit packed data elements (e.g., double precision floating point or 64-bit integer).

[0105] In this illustration, only the most significant four packed data element positions of the first source 901 and the second source 903 and the most significant packed data element position of the third signed source 915 are shown. Of course, if there are any other packed data element positions, those are also processed.

[0106] As shown, the packed data elements are processed in quads. For example, the data of the most significant packed data element positions of the first source 901 and the second source 903 are multiplied using multiplier circuit 905, the data of the next most significant packed data element positions of the first source 901 and the second source 903 are multiplied using multiplier circuit 907, the data of the third most significant packed data element positions of the first source 901 and the second source 903 are multiplied using multiplier circuit 909, and the data of the least significant packed data element positions of the first source 901 and the second source 903 are multiplied using multiplier circuit 911. In some embodiments, the signed packed data elements of the first source 901 are sign extended and the unsigned packed data elements of the second source 903 are zero extended prior to multiplication.

[0107] In some embodiments, these multiplier circuits 905-911 are reused for other packed data element positions. In other embodiments, additional multiplier circuits are used so that the packed data elements are processed in parallel. In some contexts, this parallel execution is accomplished using lanes that are the size of the signed third source 915. The results of each of these multiplications are added using add circuit 911.

[0108] The result of the addition of these multiplication results is added (using a different adder 913 or the same adder 911) to the data of the most significant packed data element position from the signed source 9 915.

[0109] Finally, the result of the second addition 919 is stored into the signed destination in the packed data element location corresponding to the packed data element location of the third source 915 with the native sign, or passed to the next iteration. In some embodiments, a write mask is applied to this store, such that if the corresponding mask (bit) is set, the store occurs, and if the corresponding mask (bit) is not set, the store does not occur.

[0110] Figure 10 An embodiment illustrating a subset of the execution of an iteration of a chained fused multiply accumulate instruction. In particular, Figure 10 An iteration execution circuit for one packed data element location of a destination. In this embodiment, the chained fused multiply accumulate is operating on signed and unsigned sources, where the accumulator is four times the size of the input data.

[0111] The first signed source (source 1 1001) and the second unsigned source (source 2 1003) each have four packed data elements with four packed data elements storing data such as floating point data or integer data. The third signed source (initial value or previous result 1015) has a packed data element storing packed data. The size of the first source 1001 and the size of the second source 1003 are one quarter the size of the third signed source 1015. For example, the first source 1001 and the second source 1003 can have 16-bit packed data elements (e.g., words), while the third signed source 1015 can have 64-bit packed data elements (e.g., double precision floating point or 64-bit integers).

[0112] In this illustration, only the most significant four packed data element locations of the first source 1001 and the second source 1003 and the most significant packed data element location of the third signed source 1015 are shown. Of course, if there are any other packed data element locations, those are also processed.

[0113] As shown, the packed data elements are processed in quads. For example, the data of the most significant packed data element locations of the first source 1001 and the second source 1003 are multiplied using multiplier circuit 1005, the data of the next most significant packed data element locations of the first source 1001 and the second source 1003 are multiplied using multiplier circuit 1007, the data of the third most significant packed data element locations of the first source 1001 and the second source 1003 are multiplied using multiplier circuit 1009, and the data of the least significant packed data element locations of the first source 1001 and the second source 1003 are multiplied using multiplier circuit 1011. In some embodiments, prior to multiplication, the signed packed data elements of the first source 1001 are sign extended and the unsigned packed data elements of the second source 1003 are zero extended.

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

[0115] When the addition results in a value that is too large or too small for the signed saturation, the add / saturate (accumulator) circuit 1013 preserves the sign of the operand. Specifically, for the multiway addition, the saturation evaluation occurs between the infinite precision result and the write to the destination. When the accumulator 1013 is floating point and the input terms are integers, the sum of the products and the floating point accumulator input value are converted to infinite precision values (hundreds of bits of fixed point), the addition of the multiplication results and the third input is performed, and a single round to the actual accumulator type is performed.

[0116] Finally, the result 1019 of the addition and saturation check is stored into the signed destination in the packed data element position corresponding to the packed data element position with the signed third source 1015, or passed to the next iteration. In some embodiments, a write mask is applied to this store so that if the corresponding mask (bit) is set, the store occurs, and if the corresponding mask (bit) is not set, the store does not occur.

[0117] Figure 11 Figure illustrates a SIMD implementation where the accumulator uses an input size that is larger than the size of the inputs to the multipliers, according to an embodiment. Note that the sources (to the multipliers) and accumulator values can be signed or unsigned values. For an accumulator with a 2X input size (in other words, the size of the accumulator input values is twice the size of the packed data elements of the source), table 1101 illustrates different configurations. For a source of byte size, the accumulator uses a word of size 16 bits or half-precision floating point (HPFP) values. For a source of word size, the accumulator uses 32-bit integers or single-precision floating point (SPFP) values of size 32 bits. For a source of SPFP or 32-bit integer size, the accumulator uses 64-bit integers or double-precision floating point (SPFP) values of size 64 bits.

[0118] For accumulators with 4X input size (in other words, the size of the accumulator input value is 4 times the size of the packed data elements of the source), table 1103 illustrates the different configurations. For a byte size source, the accumulator uses a 32-bit integer or single precision floating point (SPFP) value that is 32 bits in size. For a word size source, the accumulator uses a 64-bit integer or double precision floating point (DPFP) value that is 64 bits in size.

[0119] For accumulators with 8X input size (in other words, the size of the accumulator input value is 8 times the size of the packed data elements of the source), table 1105 illustrates the configurations. For a byte size source, the accumulator uses a 64-bit integer.

[0120] As hinted previously, the matrix operation circuitry can be included in the core, or can be an external accelerator. Figure 12 Embodiments of a system utilizing matrix operation circuitry are illustrated. In this illustration, a number of entities are coupled with a ring interconnect 1245.

[0121] The number of cores 1201, 1203, 1205, and 1207 provide non-tile based instruction support. In some embodiments, the matrix operation circuitry 1251 is located in core 1203, in other embodiments, the matrix operation circuitry 1211 and 1213 are accessible on the ring interconnect 1245.

[0122] 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.

[0123] Figure 13 An embodiment of a processor core pipeline is illustrated that supports matrix operations using tiles. Branch prediction and decode circuitry 1303 performs branch prediction for instructions stored in instruction storage 1301, decodes the instructions, and / or both. For example, the instructions detailed herein can be stored in the instruction storage. In some implementations, separate circuitry is used for branch prediction, and in some embodiments, at least some instructions are decoded into one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals using microcode 1305. The branch prediction and decode circuitry 1303 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), etc.

[0124] Branch prediction and decode circuit 1303 is coupled to a rename / allocator 1307 which is, in some embodiments, coupled to an issue circuit 1309. In some embodiments, these circuits provide register renaming, allocation, and / or scheduling functionality. In some embodiments, an instruction window, also known as an instruction queue, stores instructions pending execution. In some embodiments, the instruction window is part of the scheduler circuitry. In some embodiments, the scheduler circuitry includes a reservation station, which is a type of instruction window.

[0125] Scheduler circuit(s) 1309 represent any number of different schedulers, including a reservation station, a central instruction window, etc. Scheduler circuit(s) 1309 are coupled to physical register file(s) 1315, or include physical register file(s) 1315. Each of physical register file(s) 1315 represents one or more physical register files, where different physical register files store one or more different data types, such as scalar integer, scalar floating point, packed data (e.g., vector integer, vector floating point), state (e.g., instruction pointer stack data), slices, etc. In one embodiment, physical register file(s) 1315 include vector register circuitry, write mask register circuitry, and scalar register circuitry. These register circuitries can provide architectural vector registers, vector mask registers, and general purpose registers. Physical register file(s) 1315 are overlaid by a retirement circuit 1317 to illustrate the various ways in which register renaming and out-of-order execution can be implemented (such as with a re-order buffer(s) and a retirement register file(s), with a future file(s), a history buffer(s), a retirement register file(s), with register mapping and register pooling, etc.). Retirement circuit 1317 and physical register file(s) 1315 are coupled to execution circuit(s) 1311.

[0126] Although register renaming is described in the context of out-of-order execution, it should be appreciated that register renaming can be used in in-order architectures. While the illustrated embodiment of the processor can also include separate instruction and data cache units as well as a shared L2 cache unit, alternative embodiments can have a single internal cache for both instructions and data, such as for example, a unified L2 cache, or multiple levels of cache. In some embodiments, the system can include a combination of internal caches and external caches outside of the core and / or processor. Alternatively, all of the caching can be external to the core and / or processor.

[0127] The execution circuit 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. The execution circuits 1321, 1323, and 1327 perform various operations (e.g., shifts, additions, subtractions, multiplications) and on various data types (e.g., scalar float, packed integer, packed float, vector integer, vector float). While some embodiments can include multiple execution units dedicated to specific functions or sets of functions, other embodiments can include only one execution unit or multiple execution units that together perform all functions. Scalar circuit 1321 performs scalar operations, vector / SIMD circuit 1323 performs vector / SIMD operations, and matrix operation circuit 1327 performs matrix (tile) operations as detailed herein.

[0128] As an example, an exemplary register-renamed, out-of-order issue / execution core can implement the pipeline as described below. In this example, the core can have five stages for pipeline navigation:1) an instruction fetch circuit that handles instruction fetching and length decoding;2) a branch and decode circuit 1303 that handles instruction decoding and scheduling;3) a rename / allocator circuit 1307 that performs instruction renaming and allocation;4) a scheduler circuit 1309 that schedules instruction delivery (not shown);5) one or more physical register files that store instructions and operands; an execution circuit 1311 that includes a set of execution units to perform the operations specified by the instructions;6) a memory access circuit that implements a memory hierarchy; and7) a writeback circuit 1313 that performs write back actions when instructed to do so by the scheduler circuit 1309.

[0129] The core can support one or more instruction sets (e.g., a set of Intel®IA-32 instructions (with some extensions that have been added with newer versions); a

[0130] It should be understood that the core can support multithreading (executing two or more parallel sets of threads concurrently) and can do so in any variety of ways, including time sliced multithreading, simultaneous multithreading (where a single physical core provides multiple logical cores each executing threads), or a combination thereof (e.g., time sliced simultaneous multithreading).

[0131] Figure 14 An embodiment of a processor core pipeline is illustrated that supports matrix operations using tiles. Branch prediction and decode circuitry 1403 performs branch prediction for instructions stored in instruction storage 1401, decodes the instructions, and / or both. For example, instructions detailed herein can be stored in instruction storage. In some implementations, separate circuitry is used for branch prediction, and in some embodiments, at least some instructions are decoded into one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals using microcode 1405. Branch prediction and decode circuitry 1403 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), etc.

[0132] Branch prediction and decode circuitry 1403 is coupled to a rename allocator circuit 1407, which is coupled to a scheduler circuit 1409 in some embodiments. In some embodiments, these circuits provide register renaming, allocation, and / or scheduling functionality. In some embodiments, these circuits function together to provide register renaming, allocation, and / or scheduling functionality. For example, in some embodiments, the circuits provide one or more of the following: 1) renaming of logical operator values to physical operator values (e.g., a register alias table in some embodiments); 2) allocation of state bits and flags to decoded instructions; and 3) scheduling of decoded instructions for execution on execution circuitry outside of the instruction pool (e.g., using a reservation station in some embodiments).

[0133] The scheduler circuit(s) 1409 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler unit(s) scheduler circuit(s) 1409 are coupled to or include the physical register file(s) 1415. Each of the physical register file(s) 1415 represents one or more physical register files, where different physical register files 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 as an address of a next instruction to be executed), slices, etc. In one embodiment, the physical register file(s) 1415 include vector register circuitry, write mask register circuitry, and scalar register circuitry. These register circuitries can provide architected vector registers, vector mask registers, and general purpose registers. The physical register file(s) 1415 are covered by a retirement unit 1417 to illustrate various ways in which register renaming and out-of-order execution can be implemented, such as using reorder buffers and retirement register file(s), using future files, history buffers, retirement register file(s), using register mapping and register pooling, etc. The retirement circuitry 1417 and the physical register file(s) 1415 are coupled to the execution circuitry (s) 1411.

[0134] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in in-order architectures. Although the illustrated embodiment of the processor can also include separate instruction and data cache units and a shared L2 cache unit, alternative embodiments can have a single internal cache for both instructions and data, such as for example, a first level (LI) internal cache, or multiple levels of internal caches. In some embodiments, the system can include a combination of internal caches and external caches outside of the core and / or processor. Alternatively, all of the caching can be external to the core and / or processor.

[0135] The execution circuitry 141411 includes a set of one or more execution circuitries 1427 and a set of one or more memory access circuitries 1325. The execution circuitries 1427 perform the vector (slice) operations detailed herein.

[0136] As an example, an exemplary register-renamed, out-of-order issue / execution core architecture can implement the pipeline as described below. In an example embodiment, the processor can have a front end unit to fetch instructions, decode the instructions, and queue the decoded instructions until the front end unit can dispatch them to an execution engine, e.g., an in-order front end with an out-of-order execution core (such as to provide parallelism, speculatively, etc.). For example, the instructions 1401 can be fetched from memory 1402 and passed through a decode stage 1403 to be decoded into micro-operations or other appropriate executable instructions. The micro-operations or other appropriate executable instructions can be passed through a scheduler 1405, to a physical register file 1407 in an execution engine, e.g., to be executed.

[0137] The core can support one or more instruction sets (e.g., an x86 instruction set (with some extensions that have been added with newer versions); MIPS instruction set; ARM instruction set (with optional additional extensions such as NEON)); including the (multiple) instruction(s) described herein. In one embodiment, the core 1490 includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), which can allow operations used by many multimedia applications to be performed using packed data.

[0138] It should be understood that a core can support multithreading (executing two or more parallel sets of threads concurrently) and can do so in any variety of ways as taught herein. For example, some embodiments can support multithreading via time sliced multithreading, simultaneous multithreading, or otherwise.

[0139] B. Layout

[0140] Throughout this specification, data is expressed in a row-major data layout. Users who are column-major should transform the items according to the orientation of the items. Figure 15 An example of a matrix expressed in row-major format and column-major format is illustrated. As shown, matrix A is a 2x3 matrix. When the matrix is stored in row-major format, the data elements of the rows are contiguous. When the matrix is stored in column-major format, the data elements of the columns are contiguous. T *B T = (BA) T is a well-known property of matrices, where the superscript T denotes transpose. Reading column-major data as row-major data results in a matrix that looks like the transpose matrix.​

[0141] In some embodiments, the semantics of the column-major are exploited in hardware, and the column-major data will swap the operands in order and make the result a transpose of the matrix, but for the subsequent column-major reads from memory, it is the correct non-transposed matrix.

[0142] For example, if there are two column-major matrices to be multiplied:

[0143] a b g i k ag+bh ai+bj ak+bl

[0144] c d*h j l = cg+dh ci+dj ck+dl

[0145] e f eg+fh ei+fj ek+fl

[0146] (3x2) (2x3) (3x3)

[0147] The data matrices will be stored in linear memory (column-major) as follows:

[0148] a c e b d f

[0149] and

[0150] g h i j k l.

[0151] Reading those matrices as column-major with dimensions 2x3 and 3x2, they appear as:

[0152] a c e and g h

[0153] b d f i j

[0154] k l

[0155] Swapping order and matrix multiplication:

[0156] g h a c e ag+bh cg+dh eg+fh

[0157] i j b d f = ai+bj ci+dj ei+fj

[0158] k l ak+bl ck+dl ek+fl

[0159] The transpose matrix is moved out, and can be stored subsequently in row-major order:

[0160] ag+bh cg+dh eg+fh ai+bj ci+dj ei+fj ak+bl ck+dl ek+fl

[0161] and used in subsequent column-major computations, which are the correct untransposed matrices:

[0162] ag+bh ai+bj ak+bl

[0163] cg+dh ci+dj ck+dl

[0164] eg+fh ei+fj ek+fl

[0165] III. Exemplary Usage

[0166] Figure 16 An example of the use of the matrix (tiles) is illustrated. In this example, matrix C 1601 includes two tiles, matrix A 1603 includes one tile, and matrix B 1605 includes two tiles. This diagram illustrates an example of the inner loop of the algorithm for computing the matrix multiplication. In this example, two result tiles from matrix C 1601, tmmO and tmmi, are used to accumulate the intermediate results. When one tile from matrix B 1603 (tmm2) is multiplied by two tiles from matrix B 1605, this tile is reused 2 times. Pointers are used to load new A tiles and two new B tiles from the direction indicated by the arrows. An outer loop not shown adjusts the pointers for the C tiles.

[0167] Exemplary code as illustrated includes the use of tile configuration instructions and is executed to configure the tile usage, load the tiles, loops for processing the tiles, store the tiles to memory, and release the tile usage.

[0168] Figure 17 An embodiment of the use of the matrix (tiles) is illustrated. At 1701, the tile usage is configured. For example, a TILECONFIG instruction is executed to configure the tile usage, including setting the number of rows and columns for each tile. Typically, at least one matrix (tile) is loaded from memory at 1703. At 1705, the at least one matrix (tile) operation is performed using the matrix (tile). At 1707, the at least one matrix (tile) is stored out to memory, and at 1709, a context switch can occur.

[0169] IV. Exemplary Configuration

[0170] A. Tile Configuration Hardware Support

[0171] As discussed above, tile usage typically needs to be configured before use. For example, it can not be necessary to use all of the rows and columns. Not configuring these rows and columns not only saves power in some embodiments, but the configuration can be used to determine if an operation will generate an error. For example, a matrix multiplication of the form (NxM)*(L*N) will typically not work if M and L are not the same.

[0172] Before using a matrix of tiles, in some embodiments, the tiles will be configured. For example, how many rows and how many columns per tile, which tiles will be used, and so on. The TILECONFIG instruction is a modification to the computer itself, as it provides support for configuring the computer to use a matrix accelerator (as part of the processor core, or as an external device). Specifically, execution of the TILECONFIG instruction causes a configuration to be retrieved from memory and applied to the matrix (tile) settings within the matrix accelerator.

[0173] i. Tile Usage Configuration

[0174] Figure 18 Figure illustrates support for configuration of the usage of tiles, according to an embodiment. Memory 1801 contains a description 1803 of the matrix (tiles) that will be supported.

[0175] The execution circuitry 1811 of the processor / core 1805 stores aspects of the tile description 1803 into a tile configuration 1817. The tile configuration 1817 details what tiles are configured for the palette (number of rows and columns in each tile) and a flag that the matrix support is in use. Specifically, the instruction execution resources 1811 are configured to use the tiles as specified by the tile configuration 1817. The instruction execution resources can also include machine specific registers or configuration registers for indicating tile usage. Additional values are also set, such as the in-use value and the start value. The tile configuration 1817 stores the tile usage and configuration information with one or more registers 1819.

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

[0177] Byte 1 stores the value that will be stored in the "startRow" register 1903, and byte 2 stores the value that will be stored in the "startP" register 1905. To support resuming the instruction after these events, the instruction stores information in these registers. To support resuming the instruction after an interrupt event such as those detailed above, the instruction stores information in these registers. The startRow value indicates the row that should be used for resumption. The startP value indicates the location within the row for the store operation when used, and in some embodiments, the startP value indicates the lower half of the row (in the lower tile of the pair) or the upper half of the row (in the upper tile of the pair). In general, this location in the row (column) is not needed.

[0178] Successfully executing a matrix (tile) instruction will set both startRow and startP to zero, TILECONFIG and STTILECFG are exceptions.

[0179] At any point in time where a matrix (tile) that was interrupted is not resumed, it is the responsibility of the software to zero the startRow and startP values. For example, an unmasked floating point exception handler can decide to complete the operation in software and change the program counter value to another instruction, typically the next instruction. In this case, before resuming the program, the software exception handler must zero the startRow and startP values in the exception presented to the software exception handler by the operating system. The operating system will then use the resume instruction to reload those values.

[0180] Byte 3 stores the indication of the pair of tiles (1b per tile) 1907.

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

[0182] Finally, the configuration in memory is typically ended with an end of description such as all zeros for several consecutive bytes.

[0183] ii. Exemplary Tile and Tile Configuration Storage

[0184] Figures 20(A)-20(D)An example of multiple registers 1819 is illustrated. FIG. 20(A) illustrates multiple registers 1819. As shown, each tile (TMM0 2001...TMMN 2003) has separate registers, with each register storing the row size 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 the tiles are configured for use.

[0185] FIG. 20(B) illustrates multiple registers 1819. As shown, each tile has separate registers for its rows and its 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 the tiles are configured for use.

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

[0187] FIG. 20(D) illustrates multiple registers 1819. As shown, a single register stores tile configurations (rows and columns for each 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 the tiles are configured for use.

[0188] Other combinations are contemplated, such as combining the start registers into a single register in which the start registers are shown separately, and so on.

[0189] B. Tile Load Pairs

[0190] Public matrix operations such as loading a tile from a set of registers stored in a tile stored in memory. An example of a particular use is loading matrix elements in a row and column of a source matrix (tile) to corresponding element locations of a destination matrix of the same size. Detailed herein is a TILELOADQPAIR instruction and embodiments of its execution. The TILELOADQPAIR instruction is an improvement to the computer itself as it provides support for loading data within a matrix (tile) with a single instruction. Specifically, execution of the TILELOADQPAIR instruction causes elements of a left tile and a right tile (or even tile and odd tile) of a source matrix (tile) to be loaded to corresponding element locations of a left tile and a right tile (or even tile and odd tile) of a destination matrix (tile). The size of the data elements to be loaded can vary depending on the instruction and tile support. Exemplary sizes include, but are not limited to: 16 bits, 32 bits, 64 bits, 128 bits, 256 bits, etc. However, the TILELOADQPAIR instruction operates on quadword elements. In some embodiments, elements of rows of the destination matrix (tile) that do not have a corresponding column in the source matrix (tile) are zeroed.

[0191] I. Exemplary Execution

[0192] Figure 21 An exemplary execution of the TILELOADQPAIR instruction is illustrated. The TILELOADQPAIR instruction format includes fields for an opcode, a source tile identifier "tsrc," and a destination tile identifier "tdest." Each of the identified source and destination tiles has K rows and N columns, and the PAIR parameter is set to TRUE. The identified source and destination tiles have quadword elements of 4 bytes, as indicated by the "Q" in the opcode. As shown, the decoded TILELOADQPAIR instruction 2102 is received by the execution circuit 2108, which in some embodiments, loads each element of the left tile and the right tile of the identified destination matrix from corresponding element locations of the left tile and the right tile of the identified source matrix using the grid of FMAs 2110.

[0193] In some embodiments, the execution operates on one row of the identified destination matrix at a time, starting with the first row. In some embodiments, the execution operates on one block of C bytes of the row being operated on at a time. The number of bytes C in the block can vary anywhere between 1 byte and the full row of bytes. In some embodiments, the execution circuit 2108 periodically saves state after each load operation (of either or both the row operation and the block operation) so that the execution circuit 2108 can resume execution after an error interrupt that occurs during execution, and continue execution from where the execution stopped. 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 current destination tile element being loaded.

[0194] As detailed earlier, the left source matrix (tile), the right source matrix (tile), the left destination matrix (tile), and the right destination matrix (tile) can be loaded in a set of registers, locations in memory, or other storage accessible to the execution circuit. However, as shown, the identified left tile 2104 and right tile 2106 of the source matrix (tile) are loaded in the application memory 2112, and the left tile 2114 and right tile 2116 of the identified destination matrix (tile) are loaded in a set of registers.

[0195] As shown, the instruction 2102 includes a TILELOADQPAIR opcode, a destination tile identifier “tdest,” and a source tile identifier “tsrc.” The identified source matrix (tile) and destination matrix (tile) include left and right tiles (or even and odd tiles), each tile having k = 8 rows, N = 16 columns, and having a four-byte element size. The identified left source matrix (tile) and right source matrix (tile) together use 1 kB of storage (2 sides x 8 rows x 16 columns x 4B elements).

[0196] In some embodiments, the matrix (tiles) are configured to use only a subset of the possible rows and columns. For example, the matrix (tiles) can have up to 16 rows and 16 columns for use, but only 4 rows and 4 columns of each matrix (tile) are used. The configuration of each matrix (tile) is typically done by executing a configuration instruction prior to the matrix (tile) being used. In this example, there are N columns and K rows possible.

[0197] II. Exemplary Instruction Format(s)

[0198] An embodiment of the format of the TILELOADQPAIR instruction is TILELOADQPAIR tdest, tsr. In some embodiments, TILELOADQPAIR is an opcode mnemonic for the instruction, where Q indicates that the data element size is four bytes. In some embodiments, the tdest field is an R / M value (such as, Figures 25A-25B(2546), the tsrc field is Figures 25A-25B REG 2544, and the data element size is Figures 25A-25B It was found in 2564.

[0199] In some embodiments, the encoding of instructions includes proportional-indexed-base (SIB) type memory addressing operands that indirectly identify multiple indexed destination locations in memory (e.g., Figures 25A-25B (Field 2550). In one embodiment, an SIB memory operand may include encoding that identifies a base address register. The contents of the base address register may represent a base address in memory from which the address of a specific destination location in memory can be computed. For example, the base address may be the address of a first location in a block of potential destination locations for extended vector instructions. In one embodiment, an SIB memory operand may include encoding that identifies an index register. Each element of the index register may specify an index or offset value that can be used to compute the address of the corresponding destination address within a block of potential destination addresses using the base address. In one embodiment, an SIB memory operand may include encoding that specifies a scaling factor to be used for each index value when computed to the corresponding destination address. For example, if a scaling factor value of 4 is encoded in the SIB memory operand, each index value obtained from an element of the index register is multiplied by 4 and then added to the base address to compute the destination address.

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

[0201] III. Execution of (multiple) exemplary methods

[0202] Figure 22 An embodiment of a processor executing a TILELOADQPAIR instruction is illustrated. At 2201, an instruction is fetched. For example, a TILELOADQPAIR instruction having fields for an opcode, a source identifier, and a destination identifier are fetched, the source and destination identifiers identifying a source matrix (tile) and a destination matrix (tile) each having a PAIR parameter equal to TRUE. In some embodiments, the instruction is fetched by fetch circuitry from an instruction cache. The opcode of the TILELOADQPAIR instruction indicates to load corresponding packed data element locations of a left matrix (tile) and a right matrix (tile) of the identified source matrix (tile) into packed quadword data element locations of a left matrix (tile) and a right matrix (tile) of the identified destination matrix (tile). The opcode of the TILELOADQPAIR instruction includes a "Q" to specify a size of each of the tile elements as a quadword.

[0203] At 2203, the fetched instruction is decoded. For example, the fetched TILELOADQPAIR instruction is decoded by decoding circuitry such as detailed herein.

[0204] At 2205, execution of the decoded instruction is scheduled (as needed), which is an optional step (as indicated by the dashed border therearound), in that this step can occur at different times, or not at all.

[0205] At 2207, the decoded TILELOADQPAIR instruction is executed by execution circuitry (hardware) such as detailed herein. For the TILELOADQPAIR instruction, the execution will cause the execution circuitry to load each element of a left tile and a right tile of the identified destination matrix from corresponding element locations of a left tile and a right tile of the identified source matrix, where the execution operates on one row of the identified destination matrix at a time, starting with the first row.

[0206] In some embodiments, at 2209, the instruction is committed or retired, which is an optional step (as indicated by the dashed border therearound), in that this step can occur at different times, or not at all.

[0207] Figure 23 A more detailed description of the execution of a TILELOADQPAIR instruction is illustrated. Typically, this is performed by execution circuitry such as detailed above.

[0208] At 2302, a determination is made as to whether all of the following conditions are true: 1) is there at least one configured tile? 2) do the identified source and destination tiles have the VALID parameter set to TRUE? and 3) do the identified source and destination tiles have the PAIR parameter set to TRUE? When any of these conditions is not true, an error is generated at 2304.

[0209] When all of the conditions tested at 2302 are true, the execution circuit loops at 2306 from the first row, on each row M of the left and right tiles of the identified destination tile. At 2308, for each row, the execution circuit loads each element of the row from the corresponding row of the identified source tile. At 2310, the execution circuit increments M and determines whether any rows remain, and if so, continues at 2306 to operate on the next row. But when the determination at 2310 indicates that no rows remain, the process ends.

[0210] IV. Exemplary Pseudo Code

[0211] Figure 24A is exemplary pseudo code describing an embodiment of a processor executing a TILELOADQPAIR instruction. As shown in the pseudo code 2400, the TILELOADQPAIR instruction includes an opcode, TILELOADQPAIR, a destination tile identifier "tdest," and a source tile identifier "tsib" which is a SIB-type memory operand used to identify the destination tile in memory. If either tdest or tsib has a VALID and / or PAIR parameter not set to TRUE, an error is generated. The letter "Q" included in the opcode indicates that the source and destination tiles have elements of quadword size. As shown, if any of three error checks fail, the pseudo code 2400 first causes the execution circuit to generate an error. Subsequently, the pseudo code causes the processor to loop on each row of the identified destination tile after initializing a memory start address, a stride value, and a number of bytes. At each row, the processor writes a byte row from the start memory address to the identified destination tile.

[0212] Figure 24Bis exemplary pseudocode describing an embodiment of a helper function used by a processor executing a TILELOADQPAIR instruction. Pseudocode 2450 defines a "write_row_and_zero(treg, r, data, nbytes)" function. Pseudocode 2452 defines a "zero_upper_rows(treg, r)" function. Pseudocode 2454 defines a "zero_tileconfig_start()" function.

[0213] Figure 24A and Figure 24B The pseudocode in

[0214] Further Examples

[0215] Example 1 provides a processor comprising: a decode circuit to decode a load matrix pair instruction, the load matrix pair instruction having fields for an opcode, a source identifier, and a destination identifier, the source and destination identifiers to identify a source matrix and a destination matrix, respectively, each matrix having a PAIR parameter equal to true; and an execution circuit to execute the decoded load matrix pair instruction to load each element of a left tile and a right tile of the identified destination matrix from corresponding element locations of a left tile and a right tile of the identified source matrix, respectively, the execution operating on one row of the identified destination matrix at a time, starting with a first row.

[0216] Example 2 includes the exemplary processor of Example 1, wherein the execution circuit is further to generate an error upon determining that one of: a number of configured tiles is equal to zero; a PAIR parameter of at least one of the identified source matrix and the destination matrix is not set to true; and a VALID parameter of at least one of the identified source matrix and the destination matrix is not set to true.

[0217] Example 3 includes the exemplary processor of Example 1, wherein the execution circuit is further to save state after operating on each row of the identified destination, the execution circuit further to: continue executing the decoded load matrix pair instruction from where the execution left off prior to an error when the execution is interrupted by the error; wherein the saved state comprises a row pointer.

[0218] Example 4 includes the exemplary processor of Example 1, wherein the execution circuit is further to operate on one byte block of each row of the identified destination matrix at a time, the execution circuit further to save state after operating on each block, the execution circuit further to: continue executing the decoded load matrix pair instruction from where the execution stopped prior to an error when the execution is interrupted by the error; wherein the saved state comprises one or more of a row pointer, a block pointer, an element pointer, and a byte pointer.

[0219] Example 5 includes the entity of the example processor of any of examples 1-4, wherein the identified left source matrix and the right source matrix are each a set of registers for representing a matrix.

[0220] Example 6 includes the entity of the example processor of any of examples 1-4, wherein the identified left source matrix and the right source matrix are each a plurality of memory locations for representing a matrix.

[0221] Example 7 includes the entity of the example processor of any of examples 1-4, wherein the identified left destination matrix and the right destination matrix are each a set of registers for representing a matrix.

[0222] Example 8 includes the entity of the example processor of any of examples 1-4, wherein the identified left destination matrix and the right destination matrix are each a plurality of memory locations for representing a matrix.

[0223] Example 9 includes the entity of the example processor of any of examples 1-4, wherein the operation code further includes an element size identifier for specifying an element size of each data element of the identified left source matrix, the right source matrix, the left destination matrix, and the right destination matrix, wherein the element size is one of 16 bits, 32 bits, 64 bits, 128 bits, and 256 bits.

[0224] Example 10 includes the entity of the example processor of any of examples 1-4, wherein the execution circuitry is further to zero any data elements in any remaining configured rows and columns of the identified left destination matrix and the right destination matrix.

[0225] Example 11 provides a method comprising: decoding, by a decode circuitry, a load pair of matrices instruction having fields for an operation code, a source identifier, and a destination identifier for identifying a source matrix and a destination matrix, respectively, each matrix having a PAIR parameter equal to true; and executing, by an execution circuitry, the decoded load pair of matrices instruction to load each element of a left tile and a right tile of the identified destination matrix from corresponding element locations of a left tile and a right tile of the identified source matrix, respectively, wherein the executing operates on one row of the identified destination matrix at a time starting from a first row.

[0226] Example 12 includes the entity of the example method of example 11, further comprising generating, by the execution circuitry, an error upon determining at least one of: a number of configured tiles is equal to zero; a PAIR parameter of at least one of the identified source matrix and the destination matrix is not set to true; and a VALID parameter of at least one of the identified source matrix and the destination matrix is not set to true.

[0227] Example 13 includes the entity of the example method of example 11, further comprising saving state by the execution circuit after operating on each row of the identified destination; and upon execution being interrupted by an error, resuming execution of the decoded load matrix pair instruction from where the execution stopped prior to the error; wherein the saved state includes at least a row pointer.

[0228] Example 14 includes the entity of the example method of example 11, further comprising operating by the execution circuit on one block of bytes of each row of the identified destination matrix at a time; saving state after operating on each block; and upon execution being interrupted by an error, resuming execution of the decoded load matrix pair instruction from where the execution stopped prior to the error; wherein the saved state includes one or more of a row pointer, a block pointer, an element pointer, and a byte pointer.

[0229] Example 15 includes the entity of the example method of any of examples 11-14, wherein the identified left source matrix and the right source matrix are each a set of registers for representing a matrix.

[0230] Example 16 includes the entity of the example method of any of examples 11-14, wherein the identified left source matrix and the right source matrix are each a plurality of memory locations for representing a matrix.

[0231] Example 17 includes the entity of the example method of any of examples 11-14, wherein the identified left destination matrix and the right destination matrix are each a set of registers for representing a matrix.

[0232] Example 18 includes the entity of the example method of any of examples 11-14, wherein the identified left destination matrix and the right destination matrix are each a plurality of memory locations for representing a matrix.

[0233] Example 19 includes the entity of the example method of any of examples 11-14, wherein the opcode further includes an element size identifier for specifying an element size of each data element of the identified left source matrix, the right source matrix, the left destination matrix, and the right destination matrix, wherein the element size is one of 16 bits, 32 bits, 64 bits, 128 bits, and 256 bits.

[0234] Example 20 includes the entity of the example method of any of examples 11-14, further comprising zeroing by the execution circuit any data elements in any remaining configured rows and columns of the identified left destination matrix and the right destination matrix.

[0235] Example 21 provides a system comprising: a processor and an accelerator coupled to the processor, the accelerator comprising: means for decoding a load matrix pair instruction, the load matrix pair instruction having fields for an opcode, a source identifier, and a destination identifier, the source and destination identifiers to identify a source matrix and a destination matrix, respectively, each matrix having a PAIR parameter equal to true; and means for executing the decoded load matrix pair instruction to load each element of a left and right tile of the identified destination matrix from corresponding element locations of a left and right tile, respectively, of the identified source matrix, wherein the executing operates on one row of the identified destination matrix at a time, starting with a first row.

[0236] Example 22 includes the tangible system of Example 21, wherein the means for executing is further to generate an error upon determining at least one of: the number of configured tiles is equal to zero; the PAIR parameter of at least one of the identified source and destination matrices is not set to true; and the VALID parameter of at least one of the identified source and destination matrices is not set to true.

[0237] Example 23 includes the tangible system of Example 21, wherein the means for executing is further to save state after operating on each row of the identified destination, the execution circuit further to: continue executing the decoded load matrix pair instruction from where the execution stopped prior to the error when the execution is interrupted by an error; wherein the saved state comprises a row pointer.

[0238] Example 24 includes the tangible system of Example 21, wherein the means for executing is further to operate on one byte block of each row of the identified destination matrix at a time, the means for executing is further to save state after operating on each block, the execution circuit further to: continue executing the decoded load matrix pair instruction from where the execution stopped prior to the error when the execution is interrupted by an error; wherein the saved state comprises one or more of a row pointer, a block pointer, an element pointer, and a byte pointer.

[0239] Example 25 includes the tangible system of any of Examples 21-24, wherein the identified left and right source matrices are each a set of registers to represent a matrix.

[0240] Example 26 includes the tangible system of any of Examples 21-24, wherein the identified left and right source matrices are each a plurality of memory locations to represent a matrix.

[0241] Example 27 includes the tangible system of any of Examples 21-24, wherein the identified left and right destination matrices are each a set of registers to represent a matrix.

[0242] Example 28 includes the entity of the example system of any of examples 21-24, wherein the identified left destination matrix and the identified right destination matrix are each a plurality of memory locations for representing a matrix.

[0243] Example 29 includes the entity of the example system of any of examples 21-24, wherein the operation code further includes an element size identifier for specifying an element size of each data element of the identified left source matrix, the identified right source matrix, the identified left destination matrix, and the identified right destination matrix, wherein the element size is one of 16 bits, 32 bits, 64 bits, 128 bits, and 256 bits.

[0244] Example 30 includes the entity of the example system of any of examples 21-24, wherein the means for performing is further for zeroing any data elements in any remaining configured rows and columns of the identified left destination matrix and the identified right destination matrix.

[0245] Example 31 provides a non-transitory machine readable medium storing a load pair of matrices instruction that causes a processor to execute the instruction by: decoding the load pair of matrices instruction having fields for an operation code, a source identifier, and a destination identifier for identifying a source matrix and a destination matrix, respectively, each matrix having a PAIR parameter equal to true; and executing the decoded load pair of matrices instruction to load each element of a left tile and a right tile of the identified destination matrix from corresponding element locations of a left tile and a right tile of the identified source matrix, respectively, wherein the executing operates on one row of the identified destination matrix at a time, starting with a first row.

[0246] Example 32 includes the entity of the example non-transitory machine readable medium of example 31, wherein the processor is further for executing by: generating an error by the execution circuit when at least one of: a number of configured tiles is equal to zero; a PAIR parameter of at least one of the identified source matrix and the identified destination matrix is not set to true; and a VALID parameter of at least one of the identified source matrix and the identified destination matrix is not set to true.

[0247] Example 33 includes the entity of the example non-transitory machine readable medium of example 31, wherein the execution circuit is further for executing by: saving state by the execution circuit after operating on each row of the identified destination; and when execution is interrupted by an error, continuing execution of the decoded load pair of matrices instruction from where the execution stopped prior to the error; wherein the saved state includes at least a row pointer.

[0248] Example 34 includes the entity of Example 31 exemplary non-transitory machine-readable medium, wherein the processor is further to execute by the execution circuitry by operating on one block of bytes of each row of the identified destination matrix at a time; saving state after operating on each block; and when execution is interrupted by an error, resuming execution of the decoded load matrix pair instruction from where the execution stopped prior to the error; wherein the saved state includes one or more of a row pointer, a block pointer, an element pointer, and a byte pointer.

[0249] Example 35 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the identified left source matrix and the right source matrix are each a set of registers to represent a matrix.

[0250] Example 36 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the identified left source matrix and the right source matrix are each a plurality of memory locations to represent a matrix.

[0251] Example 37 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the identified left destination matrix and the right destination matrix are each a set of registers to represent a matrix.

[0252] Example 38 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the identified left destination matrix and the right destination matrix are each a plurality of memory locations to represent a matrix.

[0253] Example 39 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the opcode further includes an element size identifier to specify an element size of each data element of the identified left source matrix, the right source matrix, the left destination matrix, and the right destination matrix, wherein the element size is one of 16 bits, 32 bits, 64 bits, 128 bits, and 256 bits.

[0254] Example 40 includes the entity of any of Examples 31-34 exemplary non-transitory machine-readable medium, wherein the processor is further to execute by the execution circuitry by zeroing any data elements in any remaining configured rows and columns of the identified left destination matrix and the right destination matrix.

[0255] V. DETAILED EXAMPLE SYSTEM, PROCESSOR, AND EMULATION

[0256] Examples of hardware, software, etc. to perform the instructions described above are detailed herein. For example, the content described below details aspects of instruction execution, including various pipeline stages such as fetch, decode, schedule, execute, retire, etc.

[0257] Instruction Set

[0258] An instruction set can include one or more instruction formats. A given instruction format can define various fields (e.g., number of bits, location of bits) to specify, among other things, the operation to be performed (e.g., opcode) and the operand(s) on which that operation is to be performed and / or other data field(s) (e.g., mask). Some instruction formats are further broken down by definition of instruction templates (or subformats). For example, instruction templates of a given instruction format can be defined to have different subsets of the fields of that instruction format (including fields often in the same order, but with different bit locations for at least some fields because fewer fields are included), and / or to have given fields interpreted differently. Thus, each instruction of an ISA is expressed using a given instruction format (and, if defined, in a given one of the instruction templates of that instruction format) and includes fields to specify the operation and operands. For example, an exemplary ADD instruction has a particular opcode and instruction format that includes an opcode field to specify that opcode and operand fields to select the operands (source 1 / destination and source 2); and an occurrence of that ADD instruction in an instruction stream will have the particular contents in the operand fields that select the particular operands. The Advanced Vector Extensions (AVX) (AVX1 and AVX2) and the set of SIMD extensions utilizing the Vector Extensions (VEX) coding scheme (see, e.g., Intel® 64 and IA-32 Architectures Software Developers Manual; and see Intel® Advanced Vector Extensions Programming Reference, October 2014) have been introduced and / or released.

[0259] Exemplary Instruction Formats

[0260] Embodiments of the instruction(s) described herein can be embodied in different formats. In addition, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the instruction(s) can execute on such systems, architectures, and pipelines, but are not limited to those described in detail.

[0261] General Vector Friendly Instruction Format

[0262] A vector friendly instruction format is an instruction format that is amenable to vector instructions (e.g., there are specific fields dedicated to vector operations). Although embodiments are described in which both vector and scalar operations are supported by the vector friendly instruction format, alternative embodiments use only vector operations by the vector friendly instruction format.

[0263] Figures 25A-25B ​​is a block diagram illustrating a generic vector friendly instruction format and its instruction templates according to an embodiment of the application. Figure 25A is a block diagram illustrating a generic vector friendly instruction format and its class A instruction templates according to an embodiment of the application; while Figure 25B is a block diagram illustrating a generic vector friendly instruction format and its class B instruction templates according to an embodiment of the application. Specifically, class A and class B instruction templates are defined for the generic vector friendly instruction format 2500, both of which include instruction templates for no memory access 2505 and instruction templates for memory access 2520. The term "generic" in the context of the vector friendly instruction format refers to an instruction format that is not tied to any specific instruction set.

[0264] While embodiments of the application will be described in which the vector friendly instruction format supports the following cases: 64 byte vector operand length (or size) with 32-bit (4 byte) or 64-bit (8 byte) data element width (or size) (and, as a result, 64 byte vectors are composed of 16 double word size elements, or, alternatively, 8 quad word size elements); 64 byte vector operand length (or size) with 16-bit (2 byte) or 8-bit (1 byte) data element width (or size); 32 byte vector operand length (or size) with 32-bit (4 byte), 64-bit (8 byte), 16-bit (2 byte) or 8-bit (1 byte) data element width (or size); and 16 byte vector operand length (or size) with 32-bit (4 byte), 64-bit (8 byte), 16-bit (2 byte), or 8-bit (1 byte) data element width (or size); alternative embodiments can support larger, smaller and / or different vector operand sizes (e.g., 256 byte vector operands) with larger, smaller or different data element widths (e.g., 128-bit (16 byte) data element widths).

[0265] Figure 25A The class A instruction templates in include: 1) within the no memory access 2505 instruction templates, instruction templates for no memory access full swizzle control type operations 2510 and no memory access data transform type operations 2515; and 2) within the memory access 2520 instruction templates, instruction templates for memory access temporal 2525 and memory access non-temporal 2530. Figure 25B The class B instruction templates in include: 1) within the no memory access 2505 instruction templates, instruction templates for no memory access write mask control partial swizzle control type operations 2512 and no memory access write mask control vsize (vector size) type operations 2517; and 2) within the memory access 2520 instruction templates, instruction templates for memory access write mask control 2527.

[0266] The generic vector friendly instruction format 2500 includes the following fields listed in the order shown below in Figures 25A-25B

[0267] Format field 2540 - the particular value in this field (instruction format identifier value) uniquely identifies the vector friendly instruction format, and thereby the instruction appears in the instruction stream in the vector friendly instruction format. As such, this field is not needed for instruction sets that only have the generic vector friendly instruction format, in this sense the field is optional.

[0268] Base operation field 2542 - its content distinguishes different base operations.

[0269] Register index fields 2544 - their content specifies the location of source or destination operands in registers or in memory, directly or through address generation. These fields include a sufficient number of bits to select N registers out of a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) register file. Although in one embodiment N can be up to three source registers and one destination register, alternative embodiments can support more or fewer source registers and destination registers (e.g., up to two source registers, one of which is also used as a destination register; up to three source registers, one of which is also used as a destination register; up to two source registers and one destination register).

[0270] Modifier field 2546 - its content distinguishes instructions in the generic vector instruction format that specify memory access from those that do not; i.e., distinguishes between no memory access 2505 and memory access 2520 instruction templates. Memory access operations read and / or write to the memory hierarchy (in some cases using values in registers to specify the source and / or destination addresses), while non-memory access operations do not (e.g., sources and / or destinations are registers). Although in one embodiment this field also selects between three different ways to perform memory address computation, alternative embodiments can support more, fewer, or different ways to perform memory address computation.

[0271] ​Extended operation field 2550 - its content distinguishes which of various different operations, in addition to the base operation, are to be performed. This field is context-dependent. In one embodiment of the application, this field is divided into a class field 2568, an alpha field 2552, and a beta field 2554. Extended operation field 2550 allows a number of groups of common operations to be performed in a single instruction, rather than 2, 3, or 4 instructions.

[0272] Scale field 2560 - its content allows scaling of the content of the index field used for memory address generation (e.g., for 2 比例 index + base address generation).

[0273] Displacement field 2562A - its content is used as part of memory address generation (e.g., for 2 比例 index + base + displacement address generation).

[0274] Displacement factor field 2562B (note that collocation of displacement field 2562A directly over displacement factor field 2562B indicates use of one or the other) - its content is used as part of address generation; it specifies a displacement factor that scales a size (N) of a memory access, where N is the number of bytes in the memory access (e.g., for 2 比例 index + base + scaled displacement address generation). Redundant low-order bits are ignored, and thus the content of the displacement factor field is multiplied by the total size of the memory operand (N) to generate the final displacement to be used in the calculation of the effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 2574 (described later in this document) and the data manipulation field 2554C. Displacement field 2562A and displacement factor field 2562B are optional in the sense that they are not used for the no memory access 2505 instruction template and / or different embodiments can implement only one of these two or neither of these two.

[0275] Data element width field 2564 - its content distinguishes which of a number of data element widths are to be used (in some embodiments for all instructions; in other embodiments for only some instructions). This field is not needed if only one data element width is supported and / or the data element width is supported using some aspect of the opcode, in which case this field is optional.

[0276] Write mask field 2570 - its content controls on a per data element position basis whether the data element position in the destination vector operand reflects the result of the base operation and the augmentation operation or not. The class A instruction templates support merge-write masking, while the class B instruction templates support both merge-write masking and zeroing-write masking. When merging, the vector mask allows any set of elements in the destination to be protected from update during the execution of any operation (specified by the base operation and the augmentation operation); in another embodiment, the old value of each element of the destination where the corresponding mask bit has a zero is preserved. Conversely, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the base operation and the augmentation operation); in one embodiment, the elements of the destination are set to zero when the corresponding mask bit has a zero value. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span from the first to the last element being modified); however, the elements being modified need not necessarily be contiguous. Thus, the write mask field 2570 allows partial vector operations, including loads, stores, arithmetic, logic, etc. While embodiments of the present application are described in which the content of the write mask field 2570 selects one of a plurality of write mask registers containing the write mask to be used (and thus, the content of the write mask field 2570 indirectly identifies the masking to be performed), alternative embodiments alternatively or additionally allow the content of the mask write field 2570 to directly specify the masking to be performed.

[0277] Immediate field 2572 - its content allows the specification of an immediate number. This field is optional in the sense that it is not present in generic vector friendly format implementations that do not support immediate numbers and is not present in instructions that do not use an immediate number.

[0278] Class field 2568 - its content distinguishes between different classes of instructions. Referring to Figures 25A-25B , the content of this field selects between class A instructions and class B instructions. In Figures 25A-25B , a rounded square is used to indicate that a particular value is present in the field (e.g., class A 2568A and class B 2568B for the class field 2568 in Figures 25A-25B , respectively).

[0279] Class A instruction templates

[0280] In the case of the non-memory access 2505 instruction templates of class A, the alpha field 2552 is interpreted as its content distinguishes which one of the different augmentation operation types is to be performed (e.g., the round type operation 2510 and data transform type operation 2515 without memory access instruction templates specify round 2552A.1 and data transform 2552A.2, respectively, as the RS field 2552A) while the beta field 2554 distinguishes which one of the operations of the specified type is to be performed. In the non-memory access 2505 instruction templates, the scale field 2560, the displacement field 2562A, and the displacement factor field 2562B do not exist.

[0281] Non-memory access instruction templates - full round control type operations

[0282] In the non-memory access full round control type operation 2510 instruction templates, the beta field 2554 is interpreted as its content(s) provide a static round control field 2554A of the round. While in the described embodiment of the invention the round control field 2554A includes a suppress all floating point exceptions (SAE) field 2556 and a round operation control field 2558, alternative embodiments can support both concepts, can encode both concepts as the same field, or have only one or the other of these concepts / fields (e.g., can have only the round operation control field 2558).

[0283] SAE field 2556 - its content distinguishes whether exception event reporting is disabled; when the content of the SAE field 2556 indicates that suppression is enabled, the given instruction does not report any kind of floating point exception flags and does not invoke any floating point exception handlers.

[0284] Round operation control field 2558 - its content distinguishes which one of a set of rounding operations is to be performed (e.g., round up, round down, round towards zero, and round towards nearest). As such, the round operation control field 2558 allows the rounding mode to be changed on a per-instruction basis. In one embodiment of the invention in which the processor includes a control register for specifying the rounding mode, the content of the round operation control field 2550 overrides that register value.

[0285] Non-memory access instruction templates - data transform type operations

[0286] In the non-memory access data transform type operation 2515 instruction templates, the beta field 2554 is interpreted as a data transform field 2554B whose content distinguishes which one of a number of data transforms is to be performed (e.g., no data transform, permute, broadcast).

[0287] In the case of the instruction templates for class A memory access 2520, the alpha field 2552 is interpreted as an eviction hint field 2552B, the contents of which distinguish which of the eviction hints to use (in Figure 25A In the case of the instruction templates for memory access temporal 2525 and memory access non-temporal 2530, the beta field 2554 is interpreted as a data manipulation field 2554C, the contents of which distinguish which of a number of data manipulation operations (also called primitives) to perform (e.g., no manipulation, broadcast, upcast of source, and downcast of destination). The instruction templates for memory access 2520 include a scale field 2560, and optionally include a displacement field 2562A or a displacement factor field 2562B.

[0288] Vector memory instructions use translation support to perform vector loads from memory and vector stores to memory. Like ordinary vector instructions, vector memory instructions transfer data from / to memory in a data-element-wise fashion, where the elements actually transferred are dictated by the contents of a vector mask selected as a write mask.

[0289] Instruction templates for memory access - temporal

[0290] Temporal data is data that can be reused quickly enough to benefit from caching in a cache. However, this is a hint, and different processors can implement it in different ways, including completely ignoring the hint.

[0291] Instruction templates for memory access - non-temporal

[0292] Non-temporal data is data that is unlikely to be reused quickly enough to benefit from caching in a level 1 cache and should be given eviction priority. However, this is a hint, and different processors can implement it in different ways, including completely ignoring the hint.

[0293] Class B instruction templates

[0294] In the case of the class B instruction templates, the alpha field 2552 is interpreted as a write mask control (Z) field 2552C, the contents of which distinguish whether the write mask operation controlled by the write mask field 2570 should be merge or zero.

[0295] In the case of class B non-memory access 2505 instruction templates, part of the beta field 2554 is interpreted as an RL field 2557A, whose content distinguishes which of the different extended operation types are to be performed (e.g., round 2557A.1 and vector length (VSIZE) 2557A.2 are specified for the write mask control partial- round control type operation 2512 and the write mask control VSIZE type operation 2517 instruction templates, respectively), while the rest of the beta field 2554 distinguishes which of the operations of the specified type are to be performed. In the non-memory access 2505 instruction templates, the scale field 2560, the displacement field 2562A, and the displacement factor field 2562B are not present.

[0296] In the write mask control partial round control type operation 2510 instruction templates, the rest of the beta field 2554 is interpreted as a round operation field 2559A, and exception event reporting is disabled (the given instruction does not report any kind of floating-point exception flags and does not invoke any floating-point exception handlers).

[0297] The round operation control field 2559A - like the round operation control field 2558 - has a content that distinguishes which of a set of round operations are to be performed (e.g., round up, round down, round to zero, and round to nearest). As such, the round operation control field 2559A allows the round mode to be changed on a per-instruction basis. In one embodiment of the application in which the processor includes a control register for specifying the round mode, the content of the round operation control field 2550 overrides that register value.

[0298] In the write mask control VSIZE type operation 2517 instruction templates, the rest of the beta field 2554 is interpreted as a vector length field 2559B, whose content distinguishes which of a plurality of data vector lengths are to be performed (e.g., 128 bytes, 256 bytes, or 512 bytes).

[0299] In the case of class B memory access 2520 instruction templates, part of the beta field 2554 is interpreted as a broadcast field 2557B, whose content distinguishes whether a broadcast type data manipulation operation is to be performed, while the rest of the beta field 2554 is interpreted as a vector length field 2559B. The memory access 2520 instruction templates include the scale field 2560, and optionally include the displacement field 2562A or the displacement factor field 2562B.

[0300] For the generic vector friendly instruction format 2500, the full opcode field 2574 is shown to include the format field 2540, the base operation field 2542, and the data element width field 2564. Although one embodiment is shown in which the full opcode field 2574 includes all of these fields, in embodiments that do not support all of these fields, the full opcode field 2574 includes fewer than all of these fields. The full opcode field 2574 provides the operation code (opcode).

[0301] The extension operation field 2550, the data element width field 2564, and the writemask field 2570 allow these features to be specified on a per-instruction basis with the generic vector friendly instruction format.

[0302] The combination of the writemask field and the data element width field create various types of instructions, as these instructions allow the mask to be applied based on different data element widths.

[0303] The various instruction templates that occur within class A and class B are beneficial in different scenarios. In some embodiments of the invention, different processors or different cores within a processor can support only class A, only class B, or can support both classes. For example, a high-performance general-purpose out-of-order core intended for general-purpose computing can support only class B, a core intended primarily for graphics and / or scientific (throughput) computing can support only class A, and a core intended for both general-purpose computing and graphics and / or scientific (throughput) computing can support both class A and class B (of course, a core that has some mixture of templates and instructions from both classes, but not all templates and instructions from both classes, is within the scope of the invention). Likewise, a single processor can include 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 core in the graphics core intended primarily for graphics and / or scientific computing can support only class A, while one or more of the general-purpose cores can be a high-performance general-purpose core with out-of-order execution and register renaming intended for general-purpose computing that supports only class B. Another processor without separate graphics cores can include one or more general-purpose in-order or out-of-order cores that support both class A and class B. Of course, features from one class can also be implemented in the other class in different embodiments of the invention. Programs written in a high-level language will be compiled into various different executable forms, including: 1) a form with only the instructions of the class(es) supported by the target processor for execution; or 2) a form with alternative routines written using different combinations of instructions of all classes, and control flow code that selects the routines to execute based on the instructions supported by the processor currently executing the code.

[0304] Exemplary specific vector friendly instruction format

[0305] Figure 26A is a block diagram illustrating an exemplary specific vector friendly instruction format in accordance with embodiments of the present application. Figure 26A The specific vector friendly instruction format 2600 is shown to specify the location, size, interpretation and order of fields, and values for some of those fields, in a sense making the specific vector friendly instruction format 800 specific. The specific vector friendly instruction format 2600 can be used to extend the x86 instruction set, and as such some of the fields are similar or identical to those used in the existing x86 instruction set and extensions thereof (e.g., AVX). The format remains consistent with the prefix encoding field, real opcode byte field, MOD R / M field, SIB field, displacement field, and immediate fields of the existing x86 instruction set with extensions. The fields from Figure 25 are shown, from Figure 26A The fields from Figure 26 are shown, from

[0306] It should be appreciated that while embodiments of the application are described with reference to the specific vector friendly instruction format 2600 in the context of the general vector friendly instruction format 2500 for illustrative purposes, the application is not limited to the specific vector friendly instruction format 2600 except where so claimed. For example, the general vector friendly instruction format 2500 contemplates various possible sizes of various fields, while the specific vector friendly instruction format 2600 is shown with particular sizes for the fields. As a specific example, while the data element width field 2564 is shown as a one bit field in the specific vector friendly instruction format 2600, the application is not so limited (that is, the general vector friendly instruction format 2500 contemplates other sizes for the data element width field 2564).

[0307] The general vector friendly instruction format 2500 includes the fields listed below in the order shown in Figure 26A

[0308] EVEX prefix (bytes 0-3) 2602 - encoded in four bytes.

[0309] Format field 2540 (EVEX byte 0, bits [7:0]) - the first byte (EVEX byte 0) is the format field 2540 and it contains Ox62 (the only value used in one embodiment of the application to distinguish vector friendly instruction format).

[0310] The second-fourth bytes (EVEX bytes 1-3) include a number of bit fields that provide specific capabilities.

[0311] ​REX field 2605 (EVEX Byte 1, bits [7-5]) - comprised of EVEX.R bit field (EVEX Byte 1, bit [7] - R), EVEX.X bit field (EVEX Byte 1, bit [6] - X), and (255 7BEX Byte 1, bit [5] - B). EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields, and are encoded in ones' complement form, with ZMMO encoded as 111 IB, ZMM15 encoded as 0000B. Other fields of the instruction encode the lower three bits of the register indexes as is known in the art (rrr, xxx, and bbb), such that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.

[0312] 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') that is used to encode either the upper 16 or lower 16 of the extended 32 register set. In one embodiment of the invention, this bit is stored in bit inverted format, along with others as indicated below, to (in the well-known x86 32-bit mode) distinguish from the BOUND instruction, whose real opcode byte is 62, but does not accept in the MOD R / M field (described below) the value 11 in the MOD field; alternative embodiments of the invention do not store this bit, and others as 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 other RRR from other fields.

[0313] Opcode map field 2615 (EVEX Byte 1, bits [3:0] - mmmm) - its content encodes the implied leading opcode byte (0F, 0F 38, or 0F 3).

[0314] Data element width field 2564 (EVEX Byte 2, bit [7] - W) - 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.

[0315] 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 (l-complement) form, and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand, specified in 1 -complement form for certain vector shifts; or 3) EVEX.vvvv does not encode any operand, the field is reserved and should contain 1111b. Thus, the EVEX.vvvv field 2620 encodes the 4 lower-order bits of the first source register specifier, stored in inverted (l-complement) form. Depending on the instruction, an additional different EVEX bit field is used to extend the specifier size to 32 registers.

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

[0317] Prefix encoding field 2625 (EVEX Byte 2, bits [1 :0]-pp) - provides additional bits for the base operation field. This has the benefit of compressing the SIMD prefix (EVEX prefix needs only 2 bits, instead of a byte to express the SIMD prefix), in addition to providing support for legacy SSE instructions in EVEX prefix format. In one embodiment, to support legacy SSE instructions using the SIMD prefixes in both legacy format and in EVEX prefix format (66H, F2H, F3H), these legacy SIMD prefixes are encoded into the SIMD prefix encoding field; and are expanded into the legacy SIMD prefixes before being provided to the PLA of the decoder at runtime (thus, without modification, the PLA can execute both the legacy format of these legacy instructions and the EVEX format of these legacy instructions). While newer instructions can use the contents of the EVEX prefix encoding field directly as an opcode extension, particular embodiments expand in a similar manner for consistency, but allow the different meanings designated by these legacy SIMD prefixes. Alternative embodiments can redesign the PLA to support 2-bit SIMD prefix encoding, and thus do not require expansion.

[0318] Alpha field 2552 (EVEX Byte 3, bit [7] - EH, also called EVEX.EH, EVEX.rs, EVEX.RL, EVEX.write mask control, and EVEX.N; also shown as a) - as previously described, this field is context specific.

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

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

[0321] Write mask field 2570 (EVEX byte 3, bit [2:0] - kkk) - Its content specifies the register index in the write mask register, as previously described. In one embodiment of the application, the special behavior of no write mask for the specific instruction is implied by the specific value EVEX.kkk = 000 (this can be implemented in a variety of ways, including using a hardwired write mask to all targets or hardware that bypasses the masking hardware).

[0322] Real opcode field 2630 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0323] MOD R / M field 2640 (byte 5) includes MOD field 2642, Reg field 2644, and R / M field 2646. As previously described, the content of MOD field 2642 distinguishes between memory access operations and non-memory access operations. The role of Reg field 2644 can be summarized into two scenarios: encoding a destination register operand or a source register operand; or be considered as opcode extension and not used to encode any instruction operand. The role of R / M field 2646 can include the following: encoding an instruction operand that references a memory address; or encoding a destination register operand or a source register operand.

[0324] Scale, index, base (SIB) byte (byte 6) - As previously described, the content of scale field 2550 is used for memory address generation. SIB.xxx 2654 and SIB.bbb 2656 - The content of these fields has been previously mentioned with respect to register indexes Xxxx and Bbbb.

[0325] Displacement field 2562A (bytes 7-10) - When MOD field 2642 contains 10, bytes 7-10 are the displacement field 2562A, and it works just like the traditional 32-bit displacement (disp32), and works in byte granularity.

[0326] Displacement factor field 2562B (byte 7) - When MOD field 2642 contains 01, byte 7 is the displacement factor field 2562B. The location of this field is the same as the location of the traditional x86 instruction set 8-bit displacement (disp8) that works in byte granularity. Since disp8 is sign-extended, it can only address between -128 and 127 byte offsets; in terms of 64-byte cache lines, disp8 uses 8 bits that can be set to only four really useful values -128, -64, 0, and 64; since a larger range is often needed, disp32 is used; however, disp32 requires 4 bytes. In contrast to disp8 and disp32, the displacement factor field 2562B is a reinterpretation of disp8; when the displacement factor field 2562B is used, the actual displacement is determined by multiplying the contents of the displacement factor field by the size of the memory operand access (N). This type of displacement is referred to as disp8*N. This reduces the average instruction length (a single byte is used for the displacement, but with a much larger range). Such compressed displacements are based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and thus the redundant low-order bits of the address offset do not need to be encoded. In other words, the displacement factor field 2562B replaces the traditional x86 instruction set 8-bit displacement. As such, the displacement factor field 2562B is encoded in the same way as the x86 instruction set 8-bit displacement (thus, there are no changes in the ModRM / SIB encoding rules), the only difference being that disp8 is overloaded to disp8*N. In other words, there are no changes in the encoding rules or encoding length, but only in the interpretation of the displacement value by the hardware (which needs to scale the displacement by the size of the memory operand to obtain a byte-wise address offset). The immediate field 2572 operates as previously described.

[0327] Full opcode field

[0328] Figure 26B is a block diagram illustrating the fields of the specific vector friendly instruction format 2600 that make up the full opcode field 2574 according to embodiments of the application. 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 map field 2615, and the real opcode field 2630.

[0329] Register index field

[0330] Figure 26C is a block diagram illustrating the fields of the special-purpose vector friendly instruction format 2600 that make up 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 / M.r / m field 2646, the VVVV field 2620, the xxx field 2654, and the bbb field 2656.

[0331] extended operation field

[0332] Figure 26D is a block diagram illustrating the fields of the special-purpose vector friendly instruction format 2600 that make up the extended operation field 2550 according to one embodiment of the invention. When the class (U) field 2568 contains 0, it signifies EVEX.U0 (class A 2568A); when it contains 1, it signifies EVEX.U1 (class B 2568B). When U=0 and the MOD field 2642 contains 11 (signifying no memory access operation), the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the rs field 2552A. When the rs field 2552A contains 1 (round 2552A.1), the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the round control field 2554A. The round control field 2554A includes a one bit SAE field 2556 and a two bit round operation field 2558. When the rs field 2552A contains 0 (data transform 2552A.2), the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a three bit data transform field 2554B. When U=0 and the MOD field 2642 contains 00, 01, or 10 (signifying memory access operations), the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the eviction hint (EH) field 2552B and the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a three bit data mani

[0333] When U=1, the alpha field 2552 (EVEX byte 3, bit [7] - EH) is interpreted as the write mask control (Z) field 2552C. When U=1 and the MOD field 2642 contains 11 (signifying no memory access operation), a portion of the beta field 2554 (EVEX byte 3, bit [4] - S0) is interpreted as the RL field 2557A; when it contains 1 (round 2557A.1), the rest of the beta field 2554 (EVEX byte 3, bits [6-5] - SS) is interpreted as the round control field 2554A. When U=1 and the MOD field 2642 contains 00, 01, or 10 (signifying memory access operations), the beta field 2554 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the data mani 2-1) is interpreted as the round operation field 2559A, while the rest of the beta field 2554 (EVEX Byte 3, bits [6-5] - SS) is interpreted as the vector length prefix field 2559B (EVEX Byte 3, bits [6-5] - L 2-1 ) is interpreted as the vector length field 2559B (EVEX Byte 3, bits [6-5] - L 1-0 ) is interpreted as the round operation field 2559A, while the rest of the beta field 2554 (EVEX Byte 3, bits [6-5] - SS) is interpreted as the vector length prefix field 2559B (EVEX Byte 3, bits [6-5] - L 1-0 ) and the broadcast field 2557B (EVEX Byte 3, bit [4] - B).

[0334] Exemplary Register Architecture

[0335] Figure 27 is a block diagram of a register architecture 2700 according to one embodiment of the application. In the illustrated embodiment, there are 32 512-bit wide vector registers 2710; these registers are referenced as zmm0 through zmm31. The lower order 256 bits of the lower 16 zmm registers overlay on the registers ymm0-16. The lower order 128 bits of the lower 16 zmm registers (the lower order 128 bits of the ymm registers) overlay on the registers xmm0-15. The specific vector friendly instruction format 2600 operates on these overlaid register files as illustrated in the following table.

[0336]

[0337] 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 preceding length; and the instruction templates without the vector length field 2559B operate at 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 as well as packed or scalar integer data. Scalar operations are operations performed on the lowest order data element position in the zmm / ymm / xmm registers; depending on the embodiment, the higher order data element positions are either left the same as before the instruction or zeroed.

[0338] Write mask registers 2715 - in the illustrated embodiment, there are eight write mask registers (kO through k7), each of which is 64 bits in size. In alternative embodiments, the write mask registers 2715 are 16 bits in size. As previously described, in one embodiment of the invention, vector mask register kO cannot be used as a write mask; when the encoding normally indicating kO is used as a write mask, it selects the hardwired write mask 0xFFFF, effectively disabling write masking for that instruction.

[0339] General purpose registers 2725 - in the illustrated embodiment, there are sixteen 64-bit general purpose registers, which are used with existing x86 addressing modes to address memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0340] Scalar floating point stack register file (x87 stack) 2745, with the MMX packed integer flat register file 2750 overlaid on top of it - in the illustrated embodiment, the x87 stack is an eight-element stack used for performing scalar floating point operations using the x87 instruction set extensions on 32 / 64 / 80-bit floating point data; while the MMX registers are used for performing operations on 64-bit packed integer data, as well as holding operands for some operations performed between MMX and XMM registers.

[0341] Alternative embodiments of the invention can use wider or narrower registers. In addition, alternative embodiments of the invention can use more, fewer, or different register files and registers.

[0342] Example core architecture, processor, and computer architecture

[0343] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores can include: 1) general-purpose in-order cores, 2) general-purpose out-of-order cores, 3) special-purpose cores, e.g., graphics, physics, and / or scientific (throughput) computing cores. Implementations of different processors can include: 1) CPUs with one or more general-purpose in-order cores, 2) CPUs with one or more general-purpose out-of-order cores, 3) CPUs with one or more special-purpose cores, e.g., graphics, physics, and / or scientific (throughput) cores, 4) CPUs with one or more in-order cores, one or more out-of-order cores, and / or one or more special-purpose cores, and 5) CPUs with arrangements of multiple cores of similar or different types. Such different processors can have different microarchitectures and / or architectures.

[0344] Example Core Architecture

[0345] In-Order and Out-of-Order Core Block Diagrams

[0346] Figure 28A is a block diagram illustrating an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, according to embodiments of the application. Figure 28B is a block diagram illustrating exemplary in-order architecture core and exemplary register renaming, out-of-order issue / execution architecture cores to be included in a processor according to embodiments of the application. Figures 28A-28B The solid lined boxes in illustrate a typical in-order pipeline and in-order core, while the dashed lined boxes represent an optional in-order core that is not included in the in-order pipeline. Broken line boxes represent optional modules that, when present, are located between the in-order pipeline and the out-of-order pipeline. The solid lined blocks outside the in-order pipeline illustrate an optional in-order core and an optional out-of-order core.

[0347] In Figure 28A In, processor pipeline 2800 includes fetch stage 2802, length decode stage 2804, decode stage 2806, allocation stage 2808, renaming stage 2810, scheduling (also referred to as dispatch or issue) stage 2812, register read / memory read stage 2814, execution stage 2816, writeback / memory write stage 2818, exception handling stage 2822, and commit stage 2824.

[0348] Figure 28BA processor core 2890 is shown including a front end unit 2830 coupled to an execution engine unit 2850, and both are coupled to a memory unit 2870. The core 2890 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 2890 can be a special-purpose core, such as, for example, a network or communication core, compression engine, co-processor core, general-purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0349] 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 one or more micro-operations, microcode entries, microinstructions, other instructions, or other control signals from the decoded instructions as output. The decode unit 2840 can be implemented with one or more logic, logic arrays, arrays of logic formed using one or more semi-conductor fabrication technologies, and the like. Examples of suitable mechanisms that can be used include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), and the like. In one embodiment, the core 2890 includes a microcode ROM or other medium for storing microcode for certain macroinstructions (e.g., in the decode unit 2840 or otherwise within the front end unit 2830). The decode unit 2840 is coupled to a rename / allocator unit 2852 in the execution engine unit 2850.

[0350] The execution engine unit 2850 includes a rename / allocator unit 2852 coupled to a retirement unit 2854 and to a set of one or more scheduler units 2856. The scheduler unit(s) 2856 represents any number of different schedulers, including a reservation station, a central instruction window, etc. The scheduler unit(s) 2856 is coupled to the physical register file(s) unit 2858. Each physical register file unit 2858 represents one or more physical register files, where different physical register file stores different types of data (e.g., scalar integer, scalar floating point, packed data (e.g., SIMD) integer, packed data (e.g., SIMD) floating point). 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 can provide architectural vector, mask, and scalar registers for the one or more instruction

[0351] The set of memory access units 2864 are coupled to a memory unit 2870 including a data TLB unit 2872 coupled to a data cache unit 2874 coupled to a level 2 (L2) cache unit 2876. In one example embodiment, the memory access units 2864 can include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 2872 in the memory unit 2870. The instruction cache unit 2834 is also coupled to the level 2 (L2) cache unit 2876 in the memory unit 2870. The L2 cache unit 2876 is coupled to one or more other levels of cache, and ultimately to main memory.

[0352] As an example, an exemplary register renaming, out-of-order issue / execution core can implement the pipeline 2800 as follows: 1) the instruction fetch 2838 performs fetch and length decode stages 2802 and 2804; 2) the decode unit 2840 performs a decode stage 2806; 3) the rename / allocator unit 2852 performs a allocate / renaming stage 2808 and a scheduling stage 2810; 4) the scheduler unit 2856 performs a schedule stage 2812; 5) the register

[0353] The core 2890 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set; and / or the ARM instruction set (optionally with additional extensions such as the NEON extension, which includes support for SIMD

[0354] It should be understood that a core can support multithreading (execution of two or more parallel sets of instructions or threads), and can do so in any variety of ways including time-sliced multithreaded, simultaneous multithreaded (where a single physical core provides logical cores each of which is multithreaded with the physical core simultaneously multithreading threads of each), or a combination thereof (for example, time-sliced fetch and decode with simultaneous multithreading thereafter). Simultaneous multithreading in hyperthreading technology.

[0355] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in in-order architectures. Although the illustrated processor includes separate instruction and data cache units 2834 / 2874 and a shared L2 cache unit 2876, alternative embodiments can have a single internal cache for both instructions and data, such as for example, a unified cache or a hierarchy of caches. In some embodiments, a system can include a combination of internal caches and external caches outside of a core and / or processor. Alternatively, all caches can be external to a core and / or processor.

[0356] A specific example in-order core architecture

[0357] Figures 29A-29B Figure illustrates a block diagram of a more specific example in-order core architecture that will be one of several logical blocks (including other cores of the same or different type) in a chip. The logical block communicates with some fixed function logic, other logical blocks, and an external memory I / O interface through a high-bandwidth interconnect network (for example, a ring network) depending on the application.

[0358] Figure 29A is a block diagram of a single processor core according to an embodiment of the application and its connection to an on-die interconnect network 2902 and a local subset of its level 2 (L2) cache 2904. In one embodiment, the instruction decoder 2900 supports the x86 instruction set with the SSE2 instruction set extension. The L1 cache 2906 allows for low latency access to cached memory as it enters the scalar and vector units. Although in one embodiment (for simplicity of design), the scalar unit 2908 and vector unit 2910 use separate register sets (scalar registers 2912 and vector registers 2914, respectively), and data transferred between these registers is written to memory and subsequently read back from the level 1 (L1) cache 2906, alternative embodiments of the application can use a different approach (for example, using a single register set or including a communication path that allows data to be transferred between the two register files without being written to and read back from memory).

[0359] The local subset 2904 of L2 cache is a portion of a global L2 cache that is partitioned into multiple separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset 2904 of L2 cache. 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 subset. Data written by a processor core is stored in that processor core's own L2 cache subset 2904 and is flushed from other subsets if necessary. A ring network ensures coherency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 cache, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0360] Figure 29B is a block diagram of a portion of a processor core in Figure 29A according to embodiments of the application. Figure 29B The L1 data cache 2906A portion includes L1 cache 2904, and more detail regarding vector units 2910 and vector registers 2914. In particular, the vector units 2910 are 16-wide vector processing units (VPUs) (see 16-wide ALU 2928) that execute one or more integer, single precision floating point, and double precision floating point instructions. The VPUs utilize a hybrid unit 2920 to support a hybrid of register inputs, number format conversions with number format conversion units 2922A-B, and replication of memory inputs with a replication unit 2924. Write mask registers 2926 allow the resulting vector writes to be asserted.

[0361] Figure 30 is a block diagram of a processor 3000 that can have more than one core, that can have an integrated memory controller, and that can have an integrated graphics device, in accordance with a number of embodiments of the application. Figure 30 The solid line block diagram of 3000 illustrates a processor 3000 with a single core 3002A, a system agent 3010, a set of one or more bus controller units 3016, and optional additional elements, while the dashed line block diagram illustrates an alternative processor 3000 with a set of multiple cores 3002A-N, a system agent unit 3010 that can include one or more integrated memory controller units 3014, and a set of one or more special purpose logic devices 3008.

[0362] Thus, different implementations of the processor 3000 can include: 1) a CPU with the special purpose logic 3008 being integrated graphics and / or scientific (throughput) logic (which can include one or more cores), and the cores 3002A-N being 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 with the cores 3002A-N being a large number of special purpose cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor with the cores 3002A-N being a large number of general purpose in-order cores. As such, the processor 3000 can be a general-purpose processor, coprocessor or a special-purpose processor, such as, for example, a network or communication processor (NCP), compression engine, graphics processor, GPGPU (General Purpose Graphics Processing Unit), a high-throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, and / or the like. The processor can be implemented on one or more chips. The processor 3000 can be a part of one or more

[0363] The memory hierarchy includes one or more cache levels within the cores, a set or one or more shared cache units 3006, and external memories (not shown) coupled to the set of integrated memory controller units 3014. The set of shared cache units 3006 can include one or more intermediate level caches, a last level cache (LLC), and / or a combination of the two, such as an L2 and L3 cache, an L2 and L4 cache, an L3 and L4 cache, etc. While in one embodiment a ring-based interconnect unit 3012 interconnects the integrated graphics logic 3008 (of which integrated graphics logic 3008 is an example, and which is also referred to herein as special-purpose logic), the set of shared cache units 3006, and the system agent unit 3010 / integrated memory controller(s) unit 3014, alternative embodiments can use any of the known techniques for interconnecting such units. In one embodiment, coherency is maintained between the one or more cache units 3006 and the cores 3002-A-N.

[0364] In some embodiments, one or more of the cores 3002A-N are capable of multi-threading. The system agent 3010 includes those components that coordinate and operate the cores 3002A-N. The system agent unit 3010 can include for example a power control unit (PCU) and a display unit. The PCU can be or include the logic and components needed for adjusting the power state of the cores 3002A-N, as well as the integrated graphics logic 3008, and can include a built-in microcontroller that controls the power state of these components. The display unit is an on-board graphics display that drives one or more externally connected displays.

[0365] The cores 3002A-N can be homogeneous or heterogeneous in terms of architectural instruction sets; that is, two or more of the cores 3002A-N can be capable of executing the same instruction set, while others can be capable of only executing a subset of that instruction set or a different instruction set.

[0366] Exemplary Computer Architecture

[0367] Figures 31-34 is a block diagram of an exemplary computer architecture. Other system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and / or other execution logic as disclosed herein are generally suitable.

[0368] Referring now to Figure 31 , a block diagram of a system 3100 is shown in accordance with one embodiment of the present application. The system 3100 can include one or more processors 3110, 3115, which are coupled to a controller hub 3120. In one embodiment the controller hub 3120 includes a graphics memory controller hub (GMCH) 3190 and an input / output hub (IOH) 3150 (which can be on separate chips) ; the GMCH 3190 includes memory and graphics controllers; the memory 3140 and a co-processor 3145 are coupled to the GMCH 3190; the IOH 3150 is coupled to the GMCH 3190 and I / O devices 3160. Alternatively, one or both of the memory and graphics controllers are integrated within the processor (as described herein), the memory 3140 and the co-processor 3145 are coupled directly to the processor 3110, and the controller hub 3120 is on the same chip as the IOH 3150.

[0369] The optional nature of additional processors 3115 is denoted in Figure 31 by a dashed lined. Each processor 3110, 3115 can include one or more of the processing cores described herein and can be some version of the processor 3000.

[0370] Memory 3140 can be, for example, a dynamic random access memory (DRAM) such as a synchronous DRAM (SDRAM), a PCRAM, or a combination of these. For at least one embodiment, controller hub 3120 communicates with processor(s) 3110, 3115 via a bus, such as a frontside bus (FSB), point-to-point interface such as QuickPath Interconnect (QPI), or similar communication link 3195.

[0371] In one embodiment, coprocessor 3145 is a special-purpose processor, such as, for example, a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, a GPGPU, embedded processor, etc. In one embodiment, controller hub 3120 can include an integrated graphics accelerator.

[0372] There can be a variety of differences between the physical resources 3110, 3115 in terms of a spectrum of metrics, including architectural, microarchitectural, thermal, power consumption characteristics, and the like.

[0373] In one embodiment, processor 3110 executes instructions to perform general- purpose processing. Embedded within these instructions can be coprocessor instructions. The processor 3110 recognizes these coprocessor instructions as being of a type that should be executed by an attached coprocessor 3145. Accordingly, the processor 3110 issues these coprocessor instructions (or control signals representing the coprocessor instructions) on a coprocessor bus or other interconnect to the coprocessor 3145. Coprocessor(s) 3145 accept and execute the received coprocessor instructions.

[0374] Referring now to the drawing figures in which is shown a block diagram of a more Figure 32 specific first exemplary system 3200 in accordance with an embodiment of the present application. As shown Figure 32 The multiprocessor system 3200 is a point-to-point interconnect system, as shown, and includes a first processor 3270 and a second processor 3280 coupled via a point-to-point interconnect 3250. Each of the processors 3270 and 3280 can be some version of the processor 3000. In one embodiment of the application, processors 3270 and 3280 are processors 3110 and 3115, respectively, while coprocessor 3238 is coprocessor 3145. In another embodiment, processors 3270 and 3280 are processors 3110, coprocessor 3145, respectively.

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

[0376] Processors 3270, 3280 can each exchange information with a chipset 3290 via individual P-P interfaces 3252, 3254 using point to point (P-P) interface circuits 3276, 3294, 3286, 3298. Chipset 3290 can optionally exchange information with a co-processor 3238 via a high-performance interface 3292. In one embodiment, co-processor 3238 is a special-purpose processor, such as for example a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, a GPGPU, embedded processor, etc.

[0377] A shared cache (not shown) can be included in either processor, or outside the two processors but connected via P-P interconnects, such that each processor's local cache information can be stored in the shared cache if the processors are placed in a low power mode.

[0378] Chipset 3290 can be coupled to a first bus 3216 via an interface 3296. In one embodiment, first bus 3216 can be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I / O interconnect bus, although the scope of the application is not so limited.

[0379] As Figure 32As shown, various I / O devices 3214 can be coupled to the first bus 3216 along with a bus bridge 3218, which as coupling the first bus 3216 to a second bus 3220. In one embodiment, one or more additional processors 3215, such as coprocessors, high-speed MIC processors, GPGPU, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processors can be coupled to the first bus 3216. In one embodiment, the second bus 3220 can be a low pin count (LPC) bus. Various devices can be coupled to the second bus 3220, including, in one embodiment, a keyboard / mouse 3222, communication devices 3227 and a storage unit 3228, such as a disk drive or other mass storage device which can include instructions / codes and data 3230. Further, an audio I / O 3224 can be coupled to the second bus 3220. Note that other architectures are possible. For example, instead of Figure 32 a point-to-point architecture, a system can implement a multi-drop bus or other such architecture.

[0380] Referring now to Figure 33 , there is shown a block diagram of a more specific second exemplary system 3300 in accordance with an embodiment of the present application. Figure 32 and Figure 33 like elements in Figure 33 are numbered alike, and certain aspects of the Figure 32 are omitted in Figure 33 to avoid obscuring other aspects of the

[0381] Figure 33 The processors 3270, 3280 can include integrated memory and I / O control logic ("CL") 3272 and 3282, respectively. Thus, the CL 3272, 3282 includes integrated memory controller units and include I / O control logic. Figure 33 As illustrated, not only is memory 3232, 3234 coupled to the CL 3272, 3282, but also I / O devices 3314 are coupled to the control logic 3272, 3282. Traditional I / O devices 3315 are coupled to the chipset 3290.

[0382] Referring now to Figure 34 , shown is a block diagram of a SoC 3400 in accordance with an embodiment of the present application. In Figure 30 like parts are numbered alike, and certain aspects of the Figure 34In this embodiment, multiple interconnect units 3402 are coupled to: an application processor 3410, which includes a set of one or more cores 3002A-N and multiple shared cache units 3006, the set of one or more cores 3002A-N including cache units 3004A-N; a system proxy unit 3010; multiple bus controller units 3016; multiple integrated memory controller units 3014; a set of one or more coprocessors 3420, which may include integrated graphics logic, an image 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 multiple coprocessors 3420 include dedicated processors, such as, for example, network or communication processors, compression engines, GPGPUs, high-throughput MIC processors, embedded processors, etc.

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

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

[0385] The program code can be implemented using a high-level procedural programming language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used if needed. In fact, the mechanisms described herein are not limited to any particular programming language. In any case, the language can be a compiled language or an interpreted language.

[0386] One or more aspects of at least one embodiment may be implemented by representational instructions stored on a machine-readable medium, representing various logics in a processor, which, when read by a machine, cause the machine to manufacture logic for performing the techniques described herein. Such representations, referred to as “IP cores,” may be stored on tangible machine-readable media and may be supplied to various customers or production facilities for loading into the manufacturing machines that actually manufacture the logic or processor.

[0387] Such machine -readable storage media can include, without limitation, non- transitory, tangible arrangements made of machine or device- readable material for

[0388] Accordingly, embodiments of the application also include non-transitory, tangible machine -readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuitry, apparatuses, processors, and / or systems described herein. Such embodiments can also be referred to as program products.

[0389] emulation (including binary translation, code morphing, etc.)

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

[0391] Figure 35 is a block diagram of translating binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction translator in accordance with embodiments of the application. In the illustrated embodiment, the instruction translator is a software instruction translator, but the instruction translator can alternatively be implemented in software, firmware, hardware, or various combinations thereof. Figure 35It is shown that a program in a high-level language 3502 can be compiled using an x86 compiler 3504 to generate x86 binary code 3506 that can be natively executed by a processor 3516 having at least one x86 instruction set core. A processor 3516 having at least one x86 instruction set core represents any processor that can perform substantially the same functions as an Intel processor with at least one x86 instruction set core by compatibly executing or otherwise processing Figure 35 It is shown that a program in a high-level language 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 3514 that does not have at least one x86 instruction set core (e.g., a processor with cores that execute the MIPS instruction set of MIPS Technologies of Sunnyvale, CA and / or that execute the ARM instruction set of ARM Holdings of Sunnyvale, CA). An instruction translator 3512 is used to translate the x86 binary code 3506 into code that can be natively executed by the processor 3514 without the x86 instruction set core. This translated code will not be the same as the alternative instruction set binary code 3510 because an instruction translator 3512 capable of such is difficult to make; however, the translated code will accomplish the general operation and be made up of instructions from the alternative instruction set. In this manner, the instruction translator 3512 represents software, firmware, hardware, or combinations thereof that allow a processor or other electronic device without an x86 instruction set processor or core to execute the x86 binary code 3506.

Claims

1. A chip comprising: a plurality of memory controllers; a level two (L2) cache memory coupled to the plurality of memory controllers; a processor coupled to the plurality of memory controllers and to the L2 cache memory, the processor having a plurality of cores including a core to perform an operation corresponding to an instruction, the instruction identifying a first two-dimensional source tile in a memory and a second two-dimensional source tile in the memory, the core to perform the operation including to: determine that an indicator indicates that a pair of matrices are to be loaded; and in response to determining that the indicator indicates that the pair of matrices are to be loaded, load elements from element positions of each row of the first two-dimensional source tile into corresponding element positions of a first two-dimensional destination tile and load elements from element positions of each row of the second two-dimensional source tile into corresponding element positions of a second two-dimensional destination tile; an interconnect coupled to the processor; and a bus controller coupled to the processor. the core to load each element of the first two-dimensional source tile into the first two-dimensional destination tile and to load each element of the second two-dimensional source tile into the second two-dimensional destination tile. the first two-dimensional source tile and the second two-dimensional source tile are adjacent to each other in the memory.

2. The chip of claim 1, wherein, the first two-dimensional destination tile and the second two-dimensional destination tile each include a plurality of registers of the processor.

3. The chip of claim 1, wherein, the first two-dimensional source tile and the second two-dimensional source tile each have eight rows.

4. The chip of claim 1, wherein, the instruction has a field to specify a size of elements of the first two-dimensional source tile.

5. The chip of claim 1, wherein, the elements of the first two-dimensional source tile are 16-bit elements.

6. The chip of claim 1, wherein, the plurality of cores include graphics cores.

7. The chip of claim 1, wherein, the plurality of cores are heterogeneous.

8. The chip of claim 1, wherein, the plurality of cores are heterogeneous graphics cores.

9. The chip of claim 1, wherein, 11. The chip of claim 1, further comprising an instruction translator to translate the instruction into one or more instructions of a different instruction set that is executable by the core.

10. The chip of claim 1, wherein, 12. A method performed by a chip, the method comprising: accessing a memory with a plurality of memory controllers of the chip; storing data in a level two (L2) cache memory of the chip; processing data with a plurality of cores of a processor of the chip; performing an operation corresponding to an instruction with a core of the plurality of cores, the instruction identifying a first two-dimensional source tile in the memory and a second two-dimensional source tile in the memory, wherein the operation includes: determining that an indicator indicates that a pair of matrices are to be loaded; and in response to determining that the indicator indicates that the pair of matrices are to be loaded, loading elements from element positions of each row of the first two-dimensional source tile into corresponding element positions of a first two-dimensional destination tile and loading elements from element positions of each row of the second two-dimensional source tile into corresponding element positions of a second two-dimensional destination tile; communicating data from the processor to an interconnect of the chip; and accessing a bus with a bus controller of the chip. processing the data with the plurality of cores includes processing the data with a plurality of heterogeneous graphics cores. ​ 13. The method of claim 12, wherein, ​ 14. The method of claim 12, wherein, Loading the elements from the element locations of each row of the first two-dimensional source tile into corresponding element locations of the first two-dimensional destination tile includes loading the elements from the element locations of each of eight rows of the first two-dimensional source tile into corresponding element locations of the first two-dimensional destination tile.

15. The method of claim 12, wherein, The elements from the element locations of each row of the first two-dimensional source tile are loaded into corresponding element locations of the first two-dimensional destination tile stored in a plurality of registers of the processor.

16. The method of claim 15, wherein, Loading the elements from the element locations of each row of the first two-dimensional source tile into corresponding element locations of the first two-dimensional destination tile includes loading each element from each element location of each row of the first two-dimensional source tile into a corresponding element location of the first two-dimensional destination tile.

17. The method of claim 15, further comprising: The instructions are converted into one or more instructions of a different instruction set executable by the core.

18. A machine-readable medium storing instructions which, when executed, cause a computing device to perform any of the methods of claims 13-17.

19. A processing system comprising means for performing any of the methods of claims 13-17.

Images