System and method for executing instructions to convert into 16-bit floating point format

Abstract

The disclosure relates to systems and methods for executing instructions to convert into a 16-bit floating point format. In one embodiment, a processor includes fetch circuitry to fetch an instruction having a field to specify positions of an opcode and a first source vector including N single precision elements and a target vector including at least N 16-bit floating point elements, the opcode instructs execution circuitry to convert each element of the first source vector into a 16-bit floating point format and store each converted element into a corresponding position of the target vector, the conversion including truncation and rounding if necessary; the decoding circuit is used for decoding the instruction; and execution circuitry to respond to the instruction in accordance with the opcode.

Description

Technical Field

[0001] The field of this invention relates generally to computer processor architecture, and more specifically to systems and methods for executing instructions to be converted into a 16-bit floating-point format. Background Technology

[0002] An instruction set, or instruction set architecture (ISA), is a part of computer architecture related to programming. It can include primitive data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input / output (I / O). An instruction set includes one or more instruction formats. A given instruction format defines various fields (number of bits, bit positions) to specify the operation to be performed and the operand(s) on which to perform that operation, etc. A given instruction is expressed using a given instruction format and specifies the operation and operand. An instruction stream is a specific sequence of instructions, where each instruction in the sequence is an instruction appearing in a certain instruction format.

[0003] Scientific, financial, automated vectorization general, RMS (recognition, mining, and synthesis) / vision and multimedia applications (e.g., 2D / 3D graphics, image processing, video compression / decompression, speech recognition algorithms, and audio manipulation) often require performing the same operation on a large number of data items (a concept known as "data parallelism"). Single Instruction Multiple Data (SIMD) refers to a class of instructions that enable a processor to perform the same operation on multiple data items. SIMD technology is particularly well-suited for processors that can logically divide bits in registers into fixed-size data elements, each representing a separate value. For example, bits in a 512-bit register can be specified as source operands to be operated on as sixteen separate 32-bit single-precision floating-point data elements. As another example, bits in a 256-bit register can be specified as source operands to be operated on as sixteen separate 16-bit floating-point compact data elements, eight separate 32-bit compact data elements (double-word-sized data elements), or thirty-two separate 8-bit data elements (byte (B)-sized data elements). This type of data is called a packed data type or vector data type, and the objects operated on by this data type are called packed data operands or vector operands. In other words, a packed data item or vector refers to a sequence of packed data elements; and a packed data operand or vector operand is the source or target operand of a SIMD instruction (also known as a packed data instruction or vector instruction).

[0004] As an example, a class of SIMD instructions specifies a single vector operation to be performed vertically on two source vector operands to generate a target vector operand with the same size, the same number of data elements, and in the same data element order. The data elements in the source vector operands are called source data elements, and the data elements in the target vector operands are called target or result data elements. These source vector operands have the same size and contain data elements of the same width, thus containing the same number of data elements. Source data elements at the same bit position in the two source vector operands form pairs of data elements (also called corresponding data elements; that is, data elements at position 0 of each source operand correspond, data elements at position 1 of each source operand correspond, and so on). The operation specified by the SIMD instruction is performed on each of these pairs of source data elements to generate a matching number of result data elements, so that each pair of source data elements has a corresponding result data element. Because the operations are vertical and because the result vector operands are of the same size, have the same number of data elements, and are stored in the same order as the source vector operands, the result data elements are located in the same bit position in the result vector operands, just like their corresponding source data elements in the source vector operands. Besides this exemplary type of SIMD instruction, various other types of SIMD instructions exist.

[0005] For some applications that handle single-precision vectors, switching to 16-bit floating-point vector format also yields almost equivalent performance. Summary of the Invention

[0006] According to a first aspect of this disclosure, a processor is provided, comprising: an extraction circuit for extracting an instruction having a field specifying an opcode and the positions of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing an execution circuit to convert each element of the first source vector to a 16-bit floating-point format and store each converted element in a corresponding position in the target vector, the conversion including, where necessary, truncation and rounding; a decoding circuit for decoding the instruction; and an execution circuit for responding to the instruction according to the opcode.

[0007] According to a second aspect of this disclosure, a system is provided, including a processor and a memory, the processor comprising: an extraction circuit for extracting instructions having a field specifying an opcode and the positions of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing an execution circuit to convert each element of the first source vector to a 16-bit floating-point format and store each converted element in a corresponding position in the target vector, the conversion including truncation and rounding where necessary; a decoding circuit for decoding the instructions; and an execution circuit for responding to the instructions according to the opcode.

[0008] According to a third aspect of this disclosure, a method executed by a processor is provided, the method comprising: extracting instructions using extraction circuitry, the instructions having a field specifying an opcode and the positions of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing execution circuitry to convert each element of the first source vector to a 16-bit floating-point format and store each converted element in a corresponding position in the target vector, the conversion including, where necessary, truncation and rounding; decoding the instructions using decoding circuitry; and responding to the instructions using execution circuitry based on the opcode.

[0009] According to a fourth aspect of this disclosure, a machine-readable medium is provided, the machine-readable medium including code that, when executed, causes a machine to perform the method described according to a third aspect of this disclosure. Attached Figure Description

[0010] Figure 1 This is a block diagram illustrating a processing component for executing format conversion (or) instructions according to an embodiment;

[0011] Figure 2A This is a block diagram illustrating the execution of the format conversion () instruction according to an embodiment;

[0012] Figure 2B This is a block diagram illustrating the execution of the format conversion () instruction according to an embodiment;

[0013] Figure 2C This is a block diagram illustrating the execution of the format conversion () instruction according to an embodiment;

[0014] Figure 2D This is a block diagram illustrating the execution of the 2 input format conversion () instruction according to an embodiment;

[0015] Figure 3AThis is pseudocode illustrating an exemplary execution of the format conversion () instruction according to one embodiment;

[0016] Figure 3B The following is pseudocode illustrating an exemplary execution of the 2 Input Format Conversion() instruction according to an embodiment;

[0017] Figure 3C The figure illustrates an embodiment for use Figure 3A and 3B The pseudocode of the helper function;

[0018] Figure 4A This is a flowchart illustrating the process of a processor responding to a format conversion () instruction according to an embodiment;

[0019] Figure 4B This is a flowchart illustrating the process of a processor responding to an input format conversion () instruction according to an embodiment;

[0020] Figure 5A This is a block diagram illustrating the format of the format conversion (VCVTNEPS2BF16) instruction according to an embodiment;

[0021] Figure 5B This is a block diagram illustrating the format of the 2-input format conversion (VCVTNE2PS2BF16) instruction according to an embodiment;

[0022] Figures 6A-6B This is a block diagram illustrating a general vector-friendly instruction format and its instruction template according to some embodiments of the present invention;

[0023] Figure 6A This is a block diagram illustrating a general vector-friendly instruction format and its category A instruction template according to some embodiments of the present invention;

[0024] Figure 6B This is a block diagram illustrating a general vector-friendly instruction format and its category B instruction template according to some embodiments of the present invention;

[0025] Figure 7A This is a block diagram illustrating an exemplary specific vector-friendly instruction format according to some embodiments of the present invention;

[0026] Figure 7B This is a block diagram illustrating, according to one embodiment, the fields of a specific vector-friendly instruction format that constitute a complete opcode field;

[0027] Figure 7C This is a block diagram illustrating, according to one embodiment, the fields that constitute a specific vector-friendly instruction format for a register index field;

[0028] Figure 7DThis is a block diagram illustrating, according to one embodiment, the fields that constitute a specific vector-friendly instruction format for an enhanced operation field;

[0029] Figure 8 This is a block diagram of a register architecture according to one embodiment;

[0030] Figure 9A This is a block diagram illustrating both an exemplary ordered pipe and an exemplary register renaming, unordered issue / execution pipe, based on some embodiments;

[0031] Figure 9B These are block diagrams illustrating, based on some embodiments, both an exemplary embodiment of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core.

[0032] Figures 10A-10B The diagram illustrates a more specific exemplary ordered core architecture, which will be one of several logical blocks in the chip (including other cores of the same type and / or different types);

[0033] Figure 10A It is a block diagram of a single processor core and its connection to the on-chip interconnect network and its local subset to the Level 2 (L2) cache, according to some embodiments;

[0034] Figure 10B According to some embodiments Figure 10A An extended view of a portion of the processor core;

[0035] Figure 11 It is a block diagram of a processor according to some embodiments, which may have more than one core, may have an integrated memory controller and may have an integrated graphics.

[0036] Figures 12-15 It is a block diagram of an exemplary computer architecture;

[0037] Figure 12 A block diagram of the system is shown according to some embodiments;

[0038] Figure 13 This is a block diagram of a first, more specific, exemplary system according to some embodiments;

[0039] Figure 14 This is a block diagram of a second, more specific, exemplary system according to some embodiments;

[0040] Figure 15 This is a block diagram of a system-on-a-chip (SoC) according to some embodiments; and

[0041] Figure 16This is a block diagram comparing some embodiments with the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set. Detailed Implementation

[0042] Numerous specific details are set forth in the following description. However, it should be understood that some embodiments can be implemented without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0043] The use of phrases such as "an embodiment," "an example embodiment," or "an exemplary embodiment" in the specification indicates that the described embodiment may include a feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a feature, structure, or characteristic is described with respect to an embodiment, it is assumed that implementing that feature, structure, or characteristic with respect to other embodiments (if explicitly described) is within the knowledge of those skilled in the art.

[0044] As mentioned above, applications processing vectors with single-precision sources achieve almost equivalent performance when using 16-bit floating-point format vectors instead. This document discloses, and is illustrated with figures, vector compaction data format conversion instructions (VCVTNEPS2BF16 and VCVTNE2PS2BF16) for implementing format conversion of one or two source vectors. The VCVTNEPS2BF16 mnemonic indicates: “VCVT” = Vector Convert, “NE” = Round to the nearest even number (…). N earest E ven), “PS” = compressed single-precision source, “2” = to, and “BF16” = BF loat16. The two-input version of this instruction extracts two source vectors, each with N single-precision elements, and generates a target vector with 2 x N 16-bit floating-point elements. The two-input version allows for a balanced solution where an N-element source vector is transformed into an N-element target vector. Using this balanced solution, all operands, whether source or target, can be stored in the same type of vector register, whether it is a 128-bit, 256-bit, or 512-bit vector register. (At least refer to...) Figure 8 The diagram illustrates and describes an exemplary processor register file.

[0045] Compared to algorithms that use single precision for both source and target elements, the publicly available format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instructions are expected to achieve comparable quality, but with reduced memory usage and memory bandwidth requirements, which will help improve performance and power efficiency, especially in machine learning scenarios.

[0046] Related floating-point formats

[0047] The 16-bit floating-point formats used in the disclosed embodiments include bfloat16 (defined by Google Inc. of Mountain View, California), which is sometimes referred to herein as "bf16" or "BF16"; and binary16 (issued by the Institute of Electrical and Electronics Engineers as IEEE 754-2008), which is sometimes referred to herein as "half-precision" or "fp16". The 32-bit floating-point formats used in the disclosed embodiments include binary32 (also issued as part of IEEE 754-2008), which is sometimes referred to herein as "single-precision" or "fp32".

[0048] Table 1 lists some relevant characteristics and distinctions between the related data formats. As shown in the table, all three formats include a sign bit. binary32, binary16, and bfloat16 have exponent widths of 8, 5, and 8 bits, respectively, and significant digit (sometimes referred to as "mantissa" or "fraction") bits, respectively. One advantage of bfloat16 over fp16 is that we can truncate fp32 numbers and have significant bfloat16 numbers.

[0049] Table 1

[0050] Format Bit symbol index Significant numbers Binary32 32 1 8-bit 24-bit Binary16 16 1 5 people 11th Bfloat16 16 1 8-bit 8-bit

[0051] Processors implementing the publicly available format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instructions will include extraction circuitry to extract the instructions, which have fields specifying the opcode and the locations of the first source, second source (for the 2-input version), and target vector. At least refer to Figures 5A-5B6A-6B and 7A-7D further illustrate and describe the format of the format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instructions. The specified source and destination vectors can reside in vector registers or memory. The opcode instructs the execution circuitry to convert each element of the specified source vector into a 16-bit floating-point number, including truncation and rounding (if necessary), and to store each converted element in the corresponding location of the specified destination vector. This processor will also include: decoding circuitry for decoding the extracted instructions; and execution circuitry for responding to the instructions according to the opcode. (At least refer to...) Figures 1-2D , Figures 9A-9B and Figures 10A-10B The execution circuitry is further described and illustrated below.

[0052] Figure 1 This is a block diagram illustrating a processing component for executing format conversion (or) instructions according to some embodiments. As shown, the computing system 100 includes a storage device 101 for storing one or more format conversion instructions 103 to be executed. In some embodiments, the computing system 100 is a SIMD processor for simultaneously processing multiple elements of a compressed data vector.

[0053] In operation, one or more format conversion instructions 103 are retrieved from storage device 101 by extraction circuitry 105. The one or more format conversion instructions 103 have fields (not shown here) specifying an opcode and the location of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements. The opcode instructs execution circuitry to convert each element of the specified source vector to 16-bit floating-point format, including truncation and rounding (if necessary), and to store each converted element in the corresponding location of the specified target vector. (At least refer to...) Figures 5A-5B Further illustrations and descriptions of the format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instruction formats for 6A-6B and 7A-7D are provided.

[0054] The extracted format conversion instruction 107 is decoded by the decoding circuit 109, which decodes the extracted format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instruction 107 into one or more operations. In some embodiments, this decoding includes generating multiple micro-operations to be executed by an execution circuit (e.g., execution circuit 117). The decoding circuit 109 also decodes instruction suffixes and prefixes (if used).

[0055] The execution circuitry 117, which has access to the register file and memory 115, responds to instruction 111 according to the opcode, and is referred to at least hereinafter by reference. Figure 2A-2D3A-3C, 4A-4B, 9A-9B and 10A-10B will be used to further describe and illustrate it.

[0056] In some embodiments, register renaming, register allocation, and / or scheduling circuitry 113 provides functionality for one or more of the following: 1) renaming logical operand values ​​to physical operand values ​​(e.g., register alias tables in some embodiments), 2) assigning status bits and flags to decoded instructions, and 3) scheduling decoded format conversion (VCVTNEPS2BF16 or VCVTNE2PS2BF16) instructions 111 for execution on execution circuitry 117 outside the instruction pool (e.g., using a reserved station in some embodiments).

[0057] In some embodiments, write-back circuit 119 writes back the result of the executed instructions. Write-back circuit 119 and register renaming / scheduling circuit 113 are optional, as indicated by their dashed borders, because they may occur at different times or not at all.

[0058] Figure 2A This is a block diagram illustrating the execution of a format conversion () instruction according to an embodiment. As shown, a computing device 200 (e.g., a processor) receives, extracts, and decodes (the extraction and decoding circuitry is not shown here, but at least referenced) Figure 1 and Figures 9A-9B (Illustration and description) Format conversion instruction 201. Format conversion instruction 201 includes fields to specify the position of opcode 202 (VCVTNEPS2BF16), a first source vector 206 comprising N single-precision elements, and a target vector 204 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements.

[0059] Here, N equals 4, and the specified first source 212 and target 218 vectors both have four elements. However, the source and target vectors are not balanced because they have different widths. The software can issue an unbalanced format conversion instruction 201 by assigning vectors of different sizes to the source and target vectors, for example, by assigning a 256-bit ymm vector as the source and a 128-bit xmm vector as the target. Figure 2B-2D The illustration depicts a scenario where balance is achieved by assigning vectors of the same type to both the source and the target. (At least refer to...) Figure 8 To further illustrate and describe an exemplary processor register file.

[0060] In some embodiments, the format conversion instruction 201 further includes a mask {k} 208 and a zeroing control {z} 210. (At least refer to...) Figure 5A , 6A-6B and 7A-7D further illustrate and describe the format of the format conversion instruction 201 with the opcode VCVTNEPS2BF16. A designated first source vector 212, an execution circuit 214, and a designated target vector 218 are also shown, wherein the execution circuit 214 includes conversion circuits 216A-D.

[0061] In operation, computing device 200 (e.g., processor) uses fetch and decode circuitry (not shown) to fetch and decode instruction 201. Instruction 201 has fields specifying opcode 202 and the positions of first source 206 and target 204 vectors. The opcode instructs the computing device (e.g., processor) to convert each element of the specified first source vector 212 into a 16-bit floating-point format (e.g., bfloat16). Converter circuitry 216A-D includes truncation and rounding (if necessary) and stores each converted element in the corresponding position of the specified target vector 218. (See at least the reference...) Figure 5A , 6A As further illustrated and described in -6B and 7A-7D, instruction 201 may specify different vector lengths in other embodiments, such as 128 bits, 512 bits, or 1024 bits. Execution circuitry 214 responds to the instruction here according to opcode 202.

[0062] Figure 2B This is a block diagram illustrating the execution of a format conversion () instruction according to an embodiment. As shown, a computing device 220 (e.g., a processor) receives, extracts, and decodes (the extraction and decoding circuitry is not shown here, but at least referenced) Figure 1 and Figures 9A-9B (To be illustrated and described) Format conversion instruction 221, which includes fields to specify the positions of opcode 222 (VCVTNEPS2BF16), a first source vector 226 comprising N single-precision elements, and a target vector 224 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements.

[0063] Here, balancing is achieved by assigning registers of the same type as the designated first source 232 and target 238. However, the designated target vector 238, with a width half that of the designated first source vector 232, has twice as many entries. In operation, the transformed entries are written to the first four target entries, and zeros are written to the remaining four entries.

[0064] In some embodiments, the format conversion instruction 221 further includes a mask {k} 228 and a zeroing control {z} 230. (At least refer to...) Figure 5A , 6A-6B and 7A-7D further illustrate and describe the format of the format conversion instruction 221 with the opcode VCVTNEPS2BF16. A specified first source vector 232, execution circuitry 234, and a specified destination vector 238 are also shown, wherein execution circuitry 214 includes conversion circuitry 236A-D.

[0065] In operation, computing device 220 (e.g., processor) uses fetch and decode circuitry (not shown) to fetch and decode instruction 221. Instruction 221 has fields specifying opcode 222 (i.e., VCVTNEPS2BF16) and the positions of the first source vector 226 and the target vector 224. The opcode instructs computing device 220 (e.g., processor) to use converters 236A-D in execution circuitry 234 to convert each element of the specified first source vector 232 into a 16-bit floating-point format (e.g., bfloat16). Converter circuitry 236A-D includes truncation and rounding (if necessary) and stores each converted element in the corresponding position of the specified target vector 218. Here, the corresponding target vector position includes the first four elements, with zeros written to the remaining four elements. (See at least the reference...) Figure 5A , 6A As further illustrated and described in -6B and 7A-7D, instruction 221 may specify different vector lengths in other embodiments, such as 128 bits, 512 bits, or 1024 bits. Execution circuitry 234 responds to the instruction here according to opcode 202.

[0066] Figure 2C This is a block diagram illustrating the execution of a format conversion () instruction according to an embodiment. As shown, a computing device 240 (e.g., a processor) receives, extracts, and decodes (the extraction and decoding circuitry is not shown here, but at least referenced) Figure 1 and Figures 9A-9B (To be illustrated and described) Format conversion instruction 241, which includes fields to specify the positions of opcode 242 (VCVTNEPS2BF16), a first source vector 246 comprising N single-precision elements, and a target vector 244 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements.

[0067] Here, balancing is achieved by assigning registers of the same type as the specified first source vector 252 and target vector 258. However, the specified target vector 258, with a width half that of the specified first source vector 252, has twice as many entries. In operation, the transformed entries are written to the first four target entries, and zeros are written to the remaining four entries. Zeroing is performed at... Figure 2C This is not shown, but will be done implicitly in this embodiment.

[0068] Implicit zeroing is the default treatment for masked elements in some embodiments. In other embodiments, the architecture-specific register (MSR) is software-programmed to control whether zeroing or masking is applied to the masked element. In still other embodiments, the zeroing behavior is specified by format conversion instructions.

[0069] In some embodiments, the format conversion instruction 241 further includes a mask {k} 248 and a zeroing control {z} 250. (At least refer to...) Figure 5A , 6A -6B and 7A-7D further illustrate and describe the format of the format conversion instruction 241 with the opcode VCVTNEPS2BF16.

[0070] The diagram also shows a designated first source vector 252, an execution circuit 254, and a designated target vector 258, wherein the execution circuit 214 includes conversion circuits 256A-D.

[0071] In operation, computing device 240 (e.g., a processor) uses fetch and decode circuitry (not shown) to fetch and decode instruction 241. Instruction 241 has fields specifying opcode 242 (i.e., VCVTNEPS2BF16) and the positions of a first source vector 246 and a target vector 244. The opcode instructs computing device 240 (e.g., a processor) to use converters 256A-D in execution circuitry 254 to convert each element of the specified first source vector 252 into a 16-bit floating-point format (e.g., bfloat16). Converter circuitry 256A-D includes truncation and rounding (if necessary) and stores each converted element in the corresponding position of the specified target vector 258. Here, the corresponding target vector position includes the first four elements, with zeros implicitly written to the remaining four elements. Implicit zeroing is the default treatment for masked elements in some embodiments. In other embodiments, a structured model-specific register (MSR) is software-programmed to control whether zeroing or masking is applied to the masked elements. In other embodiments, the zeroing behavior is specified by a format conversion instruction.

[0072] As at least refer to Figure 5A , 6A As further illustrated and described in -6B and 7A-7D, instruction 241 may specify different vector lengths in other embodiments, such as 128 bits, 512 bits, or 1024 bits. Execution circuitry 254 responds to the instruction here according to opcode 242.

[0073] Figure 2DThis is a block diagram illustrating the execution of a format conversion (VCVTNE2PS2BF16) instruction according to an embodiment. As shown, a computing device 260 (e.g., a processor) receives, extracts, and decodes (the extraction and decoding circuitry is not shown here, but at least referenced) Figure 1 and Figures 9A-9B (To be illustrated and described) Format conversion instruction 261 includes fields specifying opcode 262 (VCVTNE2PS2BF16), first and second source vectors 266 and 268 comprising N single-precision elements, and the location of a target vector 264 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements. Here, N equals 4, and the specified target vector 264 comprises 8 elements.

[0074] Here, the width of the target vector is half that of the source vector, but balance is achieved by assigning two source vectors whose elements are transformed and written to the target. In operation, the transformed entries from the designated first source 272A are written to the first four entries of the designated target 278, and the transformed entries from the designated second source 272B are written to the last four entries of the designated target 278.

[0075] In some embodiments, the format conversion instruction 261 further includes a mask {k} 268 and a zeroing control {z} 270. (At least refer to...) Figure 5A , 6A -6B and 7A-7D further illustrate and describe the format of the format conversion instruction 261 with the opcode VCVTNEPS2BF16.

[0076] The specified first and second source vectors 272A-B, execution circuit 274, and specified target vector 278 are also shown, wherein the execution circuit 274 includes conversion circuits 276A-H.

[0077] In operation, computing device 260 (e.g., processor) uses fetch and decode circuitry (not shown) to fetch and decode instruction 261. Instruction 261 has fields specifying opcode 262 (i.e., VCVTNE2PS2BF16) and the positions of first and second source vectors 266 and 268 and target vector 264. The opcode instructs computing device 260 (e.g., processor) to use converters 276A-H in execution circuitry 274 to convert each element of the specified first and second source vectors 272A-B into a 16-bit floating-point format (e.g., bfloat16). Converter circuitry 276A-H includes truncation and rounding (if necessary) and stores each converted element in the corresponding position of the specified target vector 278. Here, the first four elements of the specified target 278 correspond to the specified first source 272A, and the last four elements of the specified target 278 correspond to the specified second source 272B. (See at least the reference...) Figure 5A , 6A As further illustrated and described in -6B and 7A-7D, instruction 261 may specify different vector lengths in other embodiments, such as 128 bits, 512 bits, or 1024 bits. Execution circuitry 274 responds to the instruction here according to opcode 262.

[0078] Figure 3A This is pseudocode illustrating exemplary execution of a format conversion (VCVTNEPS2BF16) instruction according to one embodiment. As shown, the format conversion instruction 301 has fields specifying the positions of the opcode 302 (VCVTNEPS2BF16) and the first source 306 (src) and destination 304 (dest) vectors, which can be any of 128 bits, 256 bits, and 512 bits, depending on a constant VL instantiated in the code and representing the "vector length". In some embodiments, instruction 301 also has fields specifying a mask 308 and a zeroing control 310. Pseudocode 315 also illustrates the use of a write mask to control whether each destination element is masked, and masked elements are zeroed or merged (as at least referenced). Figure 5A , 6A -6B and 7A-7D further illustrate and describe that, in some embodiments, the format conversion instructions include fields to specify a mask and control whether to zero out or merge. (At least refer to...) Figure 2A-2C 4A and 9A-9B further illustrate and describe the execution of the format conversion instruction 301.

[0079] Figure 3BThis is pseudocode illustrating exemplary execution of a 2-input format conversion () instruction according to one embodiment. As shown, the format conversion instruction 321 has fields to specify the opcode 322 (VCVTNE2PS2BF16) and the positions of the first source 326 (src1), the second source 328 (src2), and the destination 324 (dest) vectors. The destination vector can be any of 128 bits, 256 bits, and 512 bits depending on the constant VL. Here, the source vector positions can be in memory or in a register. In some embodiments, the format conversion instruction 321 has fields to specify a write mask {k} 330 and a zeroing control {z} 331. Pseudocode 335 also shows the use of a write mask to control whether each destination element is masked, and the masked elements are zeroed or merged (as at least referenced). Figure 5A , 6A -6B and 7A-7D further illustrate and describe that, in some embodiments, the format conversion instructions include fields to specify a mask and control whether to zero out or merge. (At least refer to...) Figure 2D , 4B The execution of the format conversion instruction 321 is further illustrated and described in 9A-9B.

[0080] Figure 3C The figure illustrates an embodiment for use Figures 3A-3B The pseudocode for the helper function is shown below. Here, pseudocode 354 defines the helper function `convert_fp32_to_bfloat16()`, which converts binary32 format to bfloat16 format.

[0081] Pseudocode 340 illustrates that the disclosed embodiment advantageously performs rounding of the normal number and takes into account rounding bias, unlike a simple conversion that only truncates the lower sixteen bits of a binary32 number. The code shows that this format conversion instruction has improved rounding behavior compared to mere truncation. The rounding behavior of the disclosed embodiment facilitates more accurate calculations compared to conversions performed by truncation. In some embodiments, the execution circuitry follows rounding behavior according to rounding rules promulgated as IEEE 754, such as indicating rounding to the nearest even number ("NE"). In some embodiments, rounding behavior is specified by instructions, for example, by including the suffix "NE" in the opcode to indicate rounding to the nearest even number. In other embodiments, rounding behavior adopts a default behavior like "NE". In still other embodiments, rounding behavior is controlled by a software-configured architecture-specific register (MSR).

[0082] Pseudocode 340 also illustrates the disclosed embodiment performing truncation when necessary, such as performing truncation if the input to the function is not a number (nan).

[0083] At least refer to Figure 2A-2D3A-3B, 4A-4B, and 9A-9B further illustrate and describe the execution of the format conversion instructions.

[0084] Figure 4A This is a flowchart illustrating the process of a processor responding to a format conversion instruction according to one embodiment. The format conversion instruction 401 includes fields specifying the opcode 402 (VCVTNEPS2BF16) and the positions of a first source vector 406 comprising N single-precision elements and a target vector 404 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements.

[0085] As shown in the figure, the processor responds to the decoded format conversion instruction via execution flow 400. At 421, the processor uses extraction circuitry to extract the instruction, which has fields specifying an opcode (e.g., VCVTNEPS2BF16) and the location of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements (e.g., bfloat16 or binary16). The opcode instructs execution circuitry to convert each element of the specified source vector to 16-bit floating-point, including truncation and rounding (if necessary), and to store each converted element in the corresponding location of the specified target vector. At 423, the processor uses decoding circuitry to decode the extracted instruction. In some embodiments, the processor schedules execution of the decoded instruction at 425. At 427, the processor uses execution circuitry to respond to the instruction according to the opcode. In some embodiments, the processor submits the result of the executed instruction at 429. Operations 425 and 429 are optional, as indicated by their dashed borders, because they may occur at different times or not at all.

[0086] Figure 4B This is a flowchart illustrating the process of a processor responding to an input format conversion () instruction according to one embodiment. The format conversion instruction 451 includes fields specifying the opcode 452 (VCVTNE2PS2BF16) and the positions of first and second source vectors 456 and 462, each comprising N single-precision elements, and a target vector 454 comprising at least N 16-bit floating-point (e.g., bfloat16 or binary16) elements.

[0087] Note that this invention is not intended to be limited to any particular mnemonic for opcodes. Here, VCVTNEPS2BF16 is chosen as a mnemonic with letters representing various instruction characteristics. For example, "VCVT" is chosen as an indicator vector conversion ( V ector C on V er TFor example, "NE" is chosen to indicate that the rounding mode specified by IEEE 754 (here, nearest even) is selected. "2PS" indicates 2 compact single. "2" indicates "to". Finally, "BF16" indicates bfloat16.

[0088] As shown in the figure, the processor responds to the decoded format conversion instruction via execution flow 450. At 471, the processor uses extraction circuitry to extract the instruction, which has fields specifying an opcode (e.g., VCVTNE2PS2BF16) and the location of first and second source vectors comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements (e.g., bfloat16 or binary16). The opcode instructs execution circuitry to convert each element of the specified first and second source vectors into 16-bit floating-point values, including truncation and rounding (if necessary), and to store each converted element in the corresponding location of the specified target vector. At 473, the processor uses decoding circuitry to decode the extracted instruction. In some embodiments, the processor schedules execution of the decoded instruction at 475. At 477, the processor uses execution circuitry to respond to the instruction according to the opcode. In some embodiments, the processor submits the result of the executed instruction at 479. Operations 475 and 479 are optional, as indicated by their dashed borders, because they may occur at different times or not at all.

[0089] Figure 5A This is a block diagram illustrating the format of a format conversion (VCVTNEPS2BF16) instruction according to one embodiment. As shown, the format conversion instruction 500 includes fields for specifying the opcode 502 (VCVTNEPS2BF16) and the locations of the target 504 and the first source 506 vector. The source and target vectors may each be located in a register or in memory.

[0090] Opcode 502 is indicated by including an asterisk, which means that various optional fields can be added as prefixes or suffixes to the opcode. That is, the format conversion instruction 500 also includes optional parameters to affect the instruction behavior, including a mask {k} 508, a zeroing control {z} 510, an element format 514, a vector size (N) 516, and a rounding mode 518. One or more of the instruction modifiers 508, 510, 514, 516, and 518 can be specified using prefixes or suffixes of opcode 502.

[0091] In some embodiments, one or more of optional instruction modifiers 508, 510, 514, 516, and 518 are encoded in an immediate field (not shown) optionally included with instruction 500. In some embodiments, one or more of optional instruction modifiers 508, 510, 514, 516, and 518 are specified via a configuration register, such as a model-specific register (MSR) included in an instruction set architecture.

[0092] At least refer to Figure 5B , 6A -6B and 7A-7D further illustrate and describe the format of the format conversion instruction 500.

[0093] Figure 5B This is a block diagram illustrating the format of a 2-input format conversion (VCVTNE2PS2BF16) instruction according to one embodiment. As shown, the format conversion instruction 550 includes fields for specifying the opcode 552 (VCVTNE2PS2BF16) and the positions of the target 554, the first source 556, and the second source 552 vector. The source and target vectors may each be located in a register or in memory.

[0094] Opcode 552 is indicated by including an asterisk, which means that various optional fields can be added as prefixes or suffixes to the opcode. That is, format conversion instruction 550 also includes optional parameters to affect instruction behavior, including mask {k} 558, zeroing control {z} 560, element format 564, vector size (N) 566, and rounding mode 568. One or more of instruction modifiers 558, 560, 564, and 566 can be specified using prefixes or suffixes of opcode 552.

[0095] In some embodiments, one or more of optional instruction modifiers 558, 560, 564, 566, and 568 are encoded in an immediate field (not shown) optionally included with instruction 550. In some embodiments, one or more of optional instruction modifiers 558, 560, 564, 566, and 568 are specified via configuration registers, such as model-specific registers (MSRs) included in the instruction set architecture.

[0096] At least refer to Figure 5A , 6A -6B and 7A-7D further illustrate and describe the format of the format conversion instruction 550.

[0097] Instruction set

[0098] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of bits) to specify the operation to be performed (e.g., the opcode) and the operand(s) on which the operation is performed, and / or other data fields(e.g., a mask), etc. Some instruction formats are further decomposed through the definition of instruction templates (or subformats). For example, an instruction template for a given instruction format may be defined as having different subsets of the fields of that instruction format (the included fields are usually in the same order, but at least some may have different bit positions because fewer fields are included) and / or be defined to interpret the given fields differently. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, by a given instruction template of that instruction format) and includes fields for specifying the operation and operand. For example, a demonstrative ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / target and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field for selecting a specific operand. A set of SIMD extensions known as Advanced Vector Extension (AVX) (AVX1 and AVX2) and using the Vector Extension (VEX) encoding scheme have been published and / or released (e.g., see...). Software Developer's Manual for IA-64 and IA-32 Architectures, September 2014; and see also Advanced Vector Extension Programming Reference, October 2014.

[0099] Exemplary instruction format

[0100] Implementations of the instructions(s) described herein may be implemented in various formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Implementations of the instructions(s) may be executed on such systems, architectures, and pipelines, but are not limited to those detailed herein.

[0101] General Vector-Friendly Instruction Format

[0102] A vector-friendly instruction format is an instruction format suitable for vector instructions (e.g., having certain fields specific to vector operations). While an embodiment in which both vector and scalar operations are supported through a vector-friendly instruction format has been described, alternative embodiments use only the vector-friendly instruction format for vector operations.

[0103] Figures 6A-6B This is a block diagram illustrating a general vector-friendly instruction format and its instruction template according to some embodiments of the present invention. Figure 6A This is a block diagram illustrating a general vector-friendly instruction format and its category A instruction template according to some embodiments of the present invention; while Figure 6B This is a block diagram illustrating a general vector-friendly instruction format and its category B instruction template according to some embodiments of the present invention. Specifically, for the general vector-friendly instruction format 600, category A and category B instruction templates are defined, both of which include a no-memory-access 605 instruction template and a memory-access 620 instruction template. In the context of the vector-friendly instruction format, the term "general" means that the instruction format is not bound to any particular instruction set.

[0104] While embodiments of the invention described herein will support the following items in their vector-friendly instruction formats: 64-byte vector operand length (or size) with a 32-bit (4-byte) or 64-bit (8-byte) data element width (or size) (therefore, a 64-byte vector consists of 16 double-word elements or 8 quad-word elements); 64-byte vector operand length (or size) with a 16-bit (2-byte) or 8-bit (1-byte) data element width (or size); 32-byte vector operand length (or size) with a 32-bit (4-byte), 6 4-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); however, alternative embodiments may support more, fewer, and / or different vector operand sizes (e.g., 256-byte vector operands) with more, fewer, or different data element widths (e.g., 128-bit (16-byte) data element widths).

[0105] Figure 6A The Category A instruction templates include: 1) within the No Memory Access 605 instruction template, showing the No Memory Access, Full Rounding Control Operation 610 instruction template and the No Memory Access, Data Transformation Operation 615 instruction template; and 2) within the Memory Access 620 instruction template, showing the Memory Access, Transient 625 instruction template and the Memory Access, Non-Transient 630 instruction template. Figure 6B The category B instruction templates include: 1) within the no memory access 605 instruction template, an instruction template for no memory access, write mask control, partial rounding control type operation 612 and an instruction template for no memory access, write mask control, vsize type operation 617 are shown; and 2) within the memory access 620 instruction template, an instruction template for memory access, write mask control 627 is shown.

[0106] General Vector-Friendly Instruction Format 600 includes by Figures 6A-6BThe following fields are listed below in the order shown.

[0107] Format field 640 – A specific value in this field (instruction format identifier value) uniquely identifies the vector-friendly instruction format, thereby identifying the occurrence of instructions adopting the vector-friendly instruction format in the instruction stream. Thus, this field is optional, as it is not required for instruction sets that only have a general vector-friendly instruction format.

[0108] Basic Operations Field 642 – Its content distinguishes different basic operations.

[0109] Register index field 644 – its contents directly or by address generate the location of the specified source and target operands, whether they are in registers or memory. These include a sufficient number of bits to select N registers from a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) register file. While in one embodiment N can be up to three source and one target registers, alternative embodiments may support more or fewer source and target registers (e.g., up to two sources, where one of these sources also acts as a target; up to three sources, where one of these sources also acts as a target; up to two sources and one target).

[0110] Modifier field 646 – its content distinguishes between instructions in the general vector instruction format that specify memory access and those that do not; that is, it distinguishes between the no-memory-access instruction template 605 and the memory-access instruction template 620. 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 read and / or write to the memory hierarchy (e.g., the source and destination are registers). Although in one embodiment this field also selects between three different ways to perform memory address calculation, alternative embodiments may support more, fewer, or different ways to perform memory address calculation.

[0111] Enhanced Operation Field 650 – Its content distinguishes which of several different operations need to be performed in addition to the basic operation. This field is context-dependent. In some embodiments, this field is divided into Category Field 668, Alpha Field 652, and Beta Field 654. Enhanced Operation Field 650 allows for the execution of a common group of operations in a single instruction instead of two, three, or four instructions.

[0112] The scaling field 660 – its content allows scaling the contents of the index field for memory address generation (e.g., for applications using 2). 缩放比例 *Address generation of index + radix.

[0113] Displacement field 662A – its contents are used as part of memory address generation (e.g., for memory addresses using 2). 缩放比例 *Address generation using index + radix + offset.

[0114] The displacement factor field 662B (note that placing displacement field 662A directly above displacement factor field 662B indicates that one or the other is being used) – its contents are used as part of the address generation; it specifies the displacement factor scaled by the size (N) of the memory access – where N is the number of bytes in the memory access (e.g., for a memory access using 2...). 缩放比例 *Address generation of the index + radix + scaling displacement. Redundant low-order bits are ignored, and therefore, the contents of the displacement factor field are multiplied by the total size (N) of the memory operand to generate the final displacement to be used to calculate the effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 674 (described later herein) and the data manipulation field 654C. The displacement field 662A and the displacement factor field 662B are optional because they are not used in the No Memory Access 605 instruction template, and / or different embodiments may implement only one of them or neither.

[0115] The data element width field 664 – its content distinguishes which of several data element widths is used (in some embodiments, it is used for all instructions; in other embodiments, it is used for only some instructions). This field is optional because it is not needed if only one data element width is supported and / or if some aspect of the opcode is used to support the data element width.

[0116] The write mask field 670 – whose content controls, based on the position of each data element, whether that position in the target vector operation object reflects the result of the basic and enhanced operations. Category A instruction templates support merge-write masking, while Category B instruction templates support both merge-write masking and zero-write masking. When merging, the vector mask allows any set of elements in the target to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in another embodiment, the old value of each element with a corresponding mask bit of 0 is preserved. In contrast, the zero-vector mask allows any set of elements in the target to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in one embodiment, elements in the target are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the performed operation (i.e., the span of the modified elements, from first to last); however, the modified elements do not necessarily have to be contiguous. Thus, the write mask field 670 allows for some vector operations, including load, store, arithmetic, logical, etc. Although an embodiment of the invention has been described in which the content of the write mask field 670 selects one of several write mask registers containing the write mask to be used (thereby the content of the write mask field 670 indirectly identifying the mask to be performed), alternative embodiments are provided as alternatives or additions that allow the content of the mask write field 670 to directly specify the mask to be performed.

[0117] The immediate field 672 – its content allows for the specification of immediate. This field is optional because it does not exist in implementations of generic vector-friendly formats that do not support immediate, and it does not exist in instructions that do not use immediate.

[0118] Category field 668 – Its content distinguishes different categories of instructions. (Reference) Figures 6A-6B This field allows you to choose between Category A and Category B instructions. Figures 6A-6B In Chinese, rounded rectangles are used to indicate that a specific value exists in a field (e.g., ...). Figures 6A-6B The categories 668 and 668A are used respectively for category A and category B in the category field 668.

[0119] Instruction template for category A

[0120] In the case of the non-memory access instruction template 605 of category A, the alpha field 652 is interpreted as the RS field 652A, the content of which distinguishes which of the different enhanced operation types should be executed (for example, the instruction templates for non-memory access rounding operation 610 and non-memory access data transformation operation 615 specify rounding 652A.1 and data transformation 652A.2, respectively), while the beta field 654 distinguishes which of the specified type of operation should be executed. In the non-memory access instruction template 605, the scaling field 660, the displacement field 662A, and the displacement scaling field 662B are absent.

[0121] No memory access instruction template - Fully round-control operation

[0122] In the instruction template of the No Memory Access Full Rounding Control Operation 610, the beta field 654 is interpreted as the rounding control field 654A, the contents of which provide static rounding. While the rounding control field 654A in the embodiments described in this invention includes a suppress all floating-point exception (SAE) field 656 and a rounding operation control field 658, alternative embodiments may support encoding these concepts into the same field or may have only one or the other of these concepts / fields (e.g., only the rounding operation control field 658).

[0123] SAE field 656 – its content distinguishes whether exception event reporting is disabled; when the content of SAE field 656 indicates that suppression is enabled, the given instruction does not report any kind of floating-point exception flag and does not trigger any floating-point exception handler.

[0124] The rounding operation control field 658 – its contents distinguish which of a set of rounding operations to perform (e.g., round up, round down, round to zero, and round to nearest). Thus, the rounding operation control field 658 allows the rounding mode to be changed based on each instruction. In some embodiments where the processor includes a control register for specifying the rounding mode, the contents of the rounding operation control field 650 exceed that register value.

[0125] No memory access instruction template - data transformation operation

[0126] In the instruction template 615 for a no-memory-access data transformation operation, the beta field 654 is interpreted as the data transformation field 654B, the contents of which distinguish which of several data transformations is to be performed (e.g., no data transformation, swizzle, broadcast).

[0127] In the case of the memory access 620 instruction template of category A, the alpha field 652 is interpreted as the eviction hint field 652B, the content of which distinguishes which eviction hint to use (in... Figure 6A In the memory access transient instruction template 625 and the memory access non-transient instruction template 630, transient 652B.1 and non-transient 652B.2 are specified respectively, while the beta field 654 is interpreted as the data manipulation field 654C, the contents of which distinguish which of several data manipulation operations (also called primitives) should be performed (e.g., no manipulation; broadcast; source upcast; and destination downcast). The memory access instruction template 620 includes a scaling field 660 and optionally includes a displacement field 662A or a displacement factor field 662B.

[0128] Vector memory instructions perform vector loading from and vector storing to memory, with translation support. Like regular vector instructions, vector memory instructions transfer data to / from memory element by element, where the actual elements transferred are specified by the contents of a vector mask selected as the write mask.

[0129] Memory access instruction template - transient

[0130] Transient data is data that is likely to be reused quickly enough to benefit from caching. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely.

[0131] Memory access instruction template - non-transient

[0132] Non-transient data is data that is unlikely to be fast enough to benefit from being cached in the L1 cache and should be given eviction priority. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely.

[0133] Category B instruction template

[0134] In the case of instruction template of category B, alpha field 652 is interpreted as write mask control (Z) field 652C, the content of which distinguishes whether the write mask controlled by write mask field 670 should be merged or zeroed.

[0135] In the case of the non-memory access instruction template 605 (Category B), a portion of the beta field 654 is interpreted as the RL field 657A, the content of which distinguishes which of the different enhanced operation types should be executed (e.g., for the no-memory access, write mask control, partial rounding control type operation 612 instruction template and the no-memory access, write mask control, VSIZE type operation 617 instruction template, rounding 657A.1 and vector length (VSIZE) 57A.2 are specified respectively), while the remainder of the beta field 654 distinguishes which of the specified type of operation should be executed. In the no-memory access instruction template 605, the scaling field 660, the displacement field 662A, and the displacement scaling field 662B are absent.

[0136] In the instruction template of No Memory Access, Write Mask Control, Partial Rounding Control Operation 610, the remainder of the beta field 654 is interpreted as the rounding operation field 659A and exception reporting is disabled (the given instruction does not report any kind of floating-point exception flag and does not trigger any floating-point exception handler).

[0137] Rounding operation control field 659A – Like rounding operation control field 658, its contents distinguish which of a set of rounding operations to perform (e.g., round up, round down, round to zero, and round to nearest). Thus, rounding operation control field 659A allows the rounding mode to be changed on a per-instruction basis. In some embodiments where the processor includes a control register for specifying the rounding mode, the contents of rounding operation control field 650 exceed that register value.

[0138] In the instruction template 617 for No Memory Access, Write Mask Control, VSIZE type operation, the remainder of the beta field 654 is interpreted as the vector length field 659B, the contents of which distinguish which of several data vector lengths to be executed (e.g., 128, 256, or 512 bytes).

[0139] In the case of the memory access 620 instruction template of category B, a portion of the beta field 654 is interpreted as a broadcast field 657B, the content of which distinguishes whether a broadcast data manipulation is to be performed, while the remainder of the beta field 654 is interpreted as a vector length field 659B. The memory access 620 instruction template includes a scaling field 660 and optionally includes a displacement field 662A or a displacement factor field 662B.

[0140] For the general vector-friendly instruction format 600, the complete opcode field 674 is shown as including the format field 640, the basic operation field 642, and the data element width field 664. While one embodiment is shown in which the complete opcode field 674 includes all of these fields, embodiments that do not support all of them may include only some of these fields. The complete opcode field 674 provides the operation code (opcode).

[0141] The enhanced operation field 650, data element width field 664, and write mask field 670 allow these features to be specified on a per-instruction basis in a generic vector-friendly instruction format.

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

[0143] The various instruction templates found within categories A and B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only category A, only category B, or both categories. For example, a high-performance general-purpose out-of-order core intended for general-purpose computing may support only category B, a core intended primarily for graphics and / or scientific (throughput) computing may support only category A, and a core intended for both may support both (of course, a core having some mixture of templates and instructions from both categories, but not all templates and instructions from both categories, is within the scope of the invention). Additionally, a single processor may include multiple cores, all supporting the same category or different cores supporting different categories. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores intended primarily for graphics and / or scientific computing may support only category A, while one or more of the general-purpose cores may be high-performance general-purpose cores intended for general-purpose computing with out-of-order execution and register renaming that support only category B. Another processor without a separate graphics core may include one or more general-purpose ordered or out-of-order cores supporting both category A and category B. Of course, in different embodiments of the invention, features from one category may also be implemented in another category. Programs written in high-level languages ​​will be placed (e.g., compiled just-in-time or statically) in a variety of different executable forms, including: 1) a form having only instructions from one or more categories supported by the target processor for execution; or 2) a form having alternative routines written using different combinations of instructions from all categories and control flow code that selects the routine to be executed based on instructions supported by the processor currently executing the code.

[0144] Exemplary Vector-Friendly Instruction Format

[0145] Figure 7A This is a block diagram illustrating an exemplary vector-friendly instruction format according to some embodiments of the present invention. Figure 7A The diagram illustrates a specific vector-friendly instruction format 700 in the sense that it specifies the position, size, interpretation, and order of fields, as well as the values ​​of some of these fields. This specific vector-friendly instruction format 700 can be used to extend x86 instruction sets so that some of the fields are similar to or identical to those used in existing x86 instruction sets and their extensions (e.g., AVX). This format is consistent with the prefix-encoded fields, real opcode byte fields, MOD R / M fields, SIB fields, shift fields, and instantaneous fields of existing x86 instruction sets with extensions. The diagram illustrates... Figure 7A The fields that are mapped to the fields from Figure 6.

[0146] It should be understood that although embodiments of the invention are described with reference to a specific vector-friendly instruction format 700 within the context of a general vector-friendly instruction format 600 for illustrative purposes, the invention is not limited to the specific vector-friendly instruction format 700 unless otherwise stated. For example, the general vector-friendly instruction format 600 envisions a variety of possible sizes for various fields, while the specific vector-friendly instruction format 700 is shown as a field with a specific size. As a specific example, although the data element width field 664 is shown as a one-bit field in the specific vector-friendly instruction format 700, the invention is not limited thereto (that is, the general vector-friendly instruction format 600 envisions other sizes for the data element width field 664).

[0147] General Vector-Friendly Instruction Format 600 includes by Figure 7A The following fields are listed below in the order shown.

[0148] The EVEX prefix (bytes 0-3) 702 – is encoded as a four-byte form.

[0149] Format field 640 (EVEX byte 0, bits [7:0]) - The first byte (EVEX byte 0) is format field 640 and it contains 0x62 (a unique value used in some embodiments to distinguish vector-friendly instruction formats).

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

[0151] The REX field 705 (EVEX byte 1, bits [7-5]) consists of the EVEX.R bit field (EVEX byte 1, bits [7]-R), the EVEX.X bit field (EVEX byte 1, bits [6]-X), and the 657BEX byte 1, bits [5]-B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using one's complement form, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of the instruction encode the lower three bits of the register index as is known in the art, so that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.

[0152] REX'710A – This is the first part of the REX' field 710 and is the EVEX.R' bit field (EVEX byte 1, bit [4]-R') used for encoding the high 16 or low 16 of the extended 32 register set. In some embodiments, this bit, along with the other bits shown below, is stored in bit-inverted format to distinguish it from the BOUND instruction (in the known x86 32-bit mode), whose actual opcode byte is 62, but does not accept the value 11 in the MOD field in the MOD R / M field (described below); alternative embodiments of the invention do not store this bit and the other bits indicated below in inverted format. The value 1 is used for encoding the low 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and other RRR from other fields.

[0153] Opcode mapping field 715 (EVEX byte 1, bits [3:0] – mmmm) – its contents encode the implied dominant opcode type (0F, 0F 38, or 0F 3).

[0154] The data element width field 664 (EVEX byte 2, bit [7] – W) is represented by the symbol EVEX.W. EVEX.W is used to define the granularity (size) of the data type (32-bit data element or 64-bit data element).

[0155] The function of EVEX.vvvv 720 (EVEX byte 2, bits [6:3] -vvvv) -EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand specified in inverted (ones' complement) form, and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand specified in ones' complement form for certain vector shifts; or 3) EVEX.vvvv does not encode any operands, this field is reserved and should contain 1111b. Thus, the EVEX.vvvv field 720 encodes the four lower-order bits of the first source register specifier stored in inverted (ones' complement) form. Depending on the instruction, an additional different EVEX bit field is used to extend the specifier size to 32 registers.

[0156] EVEX.U 668 Category field (EVEX byte 2, bit [2]-U) – If EVEX.U = 0, it indicates category A or EVEX.U0; if EVEX.U = 1, it indicates category B or EVEX.U1.

[0157] The prefix encoding field 725 (EVEX byte 2, bits [1:0]-pp) – provides additional bits for the basic operation field. Besides supporting conventional SSE instructions in the EVEX prefix format, this also has the benefit of compressing the SIMD prefix (the EVEX prefix requires only 2 bits instead of one byte to represent the SIMD prefix). In one embodiment, to support both conventional and EVEX prefix formats using SIMD prefixes (66H, F2H, F3H), these conventional SIMD prefixes are encoded into the SIMD prefix encoding field; and are expanded to the conventional SIMD prefix at runtime before being provided to the encoder's PLA (thus the PLA can execute both conventional and EVEX formats of these conventional instructions without modification). While newer instructions can directly use the contents of the EVEX prefix encoding field as opcode expansion, some embodiments expand in a similar manner for consistency, but allow these conventional SIMD prefixes to specify different meanings. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encoding, thus eliminating the need for expansion.

[0158] Alpha field 652 (EVEX byte 3, bit [7] – EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl and EVEX.N; also illustrated with α) – As previously stated, this field is context-dependent.

[0159] Beta field 654 (EVEX byte 3, bits [6:4] – SSS; also known as EVEX.s 2-0EVEX.r 2-0 ,EVEX.rr1,EVEX.LL0,EVEX.LLB; also illustrated with βββ) – as mentioned before, this field is context-dependent.

[0160] REX'710B – This is the remainder of REX' field 710 and is the EVEX.V' bit field (EVEX byte 3, bit [3]-V') that can be used for encoding the high 16 or low 16 of the extended 32 register set. This bit is stored in bit-inverted format. The value 1 is used for encoding the low 16 registers. In other words, V'VVVV is formed by combining EVEX.V' and EVEX.vvvv.

[0161] Write mask field 670 (EVEX byte 3, bits [2:0]-kkk) - its contents specify the index of the register in the write mask register as described above. In some embodiments, the specific value EVEX.kkk = 000 has a special behavior that implies that the write mask is not used for a particular instruction (this can be achieved in a variety of ways, including using a write mask that is hardwired to all one or hardware that bypasses the masking hardware).

[0162] The actual opcode field 730 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0163] The MOD R / M field 740 (byte 5) includes the MOD field 742, the Reg field 744, and the R / M field 746. As previously mentioned, the content of the MOD field 742 distinguishes between memory access and non-memory access operations. The function of the Reg field 744 can be summarized in two cases: encoding the destination register operand or the source register operand, or being treated as an opcode extension and not used to encode any instruction operand. The function of the R / M field 746 can include: encoding an instruction operand that references a memory address, or encoding the destination register operand or the source register operand.

[0164] Scaling, Index, Base (Scale, Index, Base, SIB) bytes (byte 6) – As previously mentioned, the contents of scaling field 650 are used for memory address generation. SIB.xxx 754 and SIB.bbb 756 – The contents of these fields have previously been referenced for register indices Xxxx and Bbbb.

[0165] Displacement field 662A (bytes 7-10) - When MOD field 742 contains 10, bytes 7-10 are displacement field 662A, and it works in the same way as the traditional 32-bit displacement (disp32) and operates at the byte granularity.

[0166] Displacement Factor Field 662B (Byte 7) - When MOD field 742 contains 0s and 1s, Byte 7 is the displacement factor field 662B. This field is positioned the same as the traditional x86 instruction set 8-bit displacement (disp8), operating at the byte level. Because disp8 is sign-extended, it can only be addressed between byte offsets of -128 and 127 bytes; for a 64-byte cache line, disp8 uses 8 bits, which can be set to only four truly useful values: -128, -64, 0, and 64; since a larger range is often required, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, the displacement factor field 662B is a reinterpretation of disp8; when using the displacement factor field 662B, the actual displacement is determined by multiplying the contents of the displacement factor field by the size (N) of the memory operand access. This type of displacement is called disp8*N. This reduces the average instruction length (a single byte is used for displacement, but with a much larger range). This compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and therefore, redundant low-order bits of the address offset do not need to be encoded. In other words, the displacement factor field 662B replaces the traditional x86 instruction set 8-bit displacement. Thus, the displacement factor field 662B is encoded in the same way as the x86 instruction set 8-bit displacement (therefore, there is no change in the ModRM / SIB encoding rules), with the only exception that disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules or encoding length, only in the hardware's interpretation of the displacement value (the hardware needs to scale the displacement according to the size of the memory operand to obtain the byte address offset). Immediately, field 672 operates as described above.

[0167] Full opcode field

[0168] Figure 7B This is a block diagram illustrating, according to some embodiments, the fields constituting a specific vector-friendly instruction format 700 for a complete opcode field 674. Specifically, the complete opcode field 674 includes a format field 640, a basic opcode field 642, and a data element width (W) field 664. The basic opcode field 642 includes a prefix encoding field 725, an opcode mapping field 715, and a real opcode field 730.

[0169] Register index field

[0170] Figure 7CThis is a block diagram illustrating, according to some embodiments, the fields constituting a specific vector-friendly instruction format 700 of register index field 644. Specifically, register index field 644 includes REX field 705, REX' field 710, MODR / M.reg field 744, MODR / Mr / m field 746, VVVV field 720, xxx field 754, and bbb field 756.

[0171] Enhance operation fields

[0172] Figure 7D This is a block diagram illustrating, according to some embodiments, the fields constituting a specific vector-friendly instruction format 700 for the enhanced operation field 650. When the category (U) field 668 contains 0, it represents EVEX.U0 (category A 668A); when it contains 1, it represents EVEX.U1 (category B 668B). When U = 0 and the MOD field 742 contains 11 (indicating no memory access operation), the alpha field 652 (EVEX byte 3, bits [7] – EH) is interpreted as the rs field 652A. When the rs field 652A contains 1 (rounding 652A.1), the beta field 654 (EVEX byte 3, bits [6:4] – SSS) is interpreted as the rounding control field 654A. The rounding control field 654A includes a one-bit SAE field 656 and a two-bit rounding operation field 658. When the rs field 652A contains 0 (data transformation 652A.2), the beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data transformation field 654B. When U = 0 and the MOD field 742 contains 00, 01, or 10 (indicating a memory access operation), the alpha field 652 (EVEX byte 3, bits [7]-EH) is interpreted as an eviction hint (EH) field 652B and the beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data manipulation field 654C.

[0173] When U = 1, the alpha field 652 (EVEX byte 3, bit [7] – EH) is interpreted as the write mask control (Z) field 652C. When U = 1 and the MOD field 742 contains 11 (indicating no memory access operation), a portion of the beta field 654 (EVEX byte 3, bit [4] – S0) is interpreted as the RL field 657A; when it contains 1 (rounded to 675A.1), the remainder of the beta field 654 (EVEX byte 3, bit [6-5] – S0) is interpreted as the RL field 657A. 2-1 The remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, while when RL field 657A contains 0 (VSIZE657.A2), the remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, and when RL field 657A contains 0 (VSIZE657.A2), the remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, while when RL field 657A contains 0 (VSIZE657.A2), the remainder of beta field 654 (EVEX byte 3, bit [6-5]-S) is interpreted as a rounding operation field 659A, and when RL field 657A contains 2-1) is interpreted as the vector length field 659B (EVEX byte 3, bits [6-5]-L) 1-0 When U=1 and MOD field 742 contains 00, 01, or 10 (indicating a memory access operation), beta field 654 (EVEX byte 3, bits [6:4]-SSS) is interpreted as vector length field 659B (EVEX byte 3, bits [6-5]-L). 1-0 ) and broadcast field 657B (EVEX byte 3, bit [4]-B).

[0174] Exemplary Register Architecture

[0175] Figure 8 This is a block diagram of a register architecture 800 according to some embodiments. In the illustrated embodiment, there are 32 512-bit wide vector registers 810; these registers are referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers are overwritten on registers ymm0-16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) are overwritten on registers xmm0-15. A specific vector-friendly instruction format 700 operates on these overwritten register files as shown in the following table.

[0176]

[0177] In other words, the vector length field 659B selects between a maximum length and one or more other shorter lengths, each of which is half the length of the previous one; and no instruction template with vector length field 659B operates on the maximum vector length. Additionally, in one embodiment, the category B instruction template of a particular vector-friendly instruction format 700 operates on compressed or scalar single / double-precision floating-point data and compressed or scalar integer data. Scalar operations are performed at the lowest-order data element location in the zmm / ymm / xmm registers; higher-order data element locations are either kept the same as before the instruction or zeroed out, depending on the embodiment.

[0178] Write mask register 815 – In the illustrated embodiment, there are eight write mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, write mask register 815 is 16 bits in size. As previously mentioned, in some embodiments, vector mask register k0 can be used as the write mask; when the encoding that would normally indicate k0 is used for the write mask, it selects the hardwired write mask 0xffff, effectively disabling write masking for that instruction.

[0179] General Purpose Registers 825 – In the illustrated embodiment, there are sixteen 64-bit general purpose registers that, along with the existing x86 addressing modes, are used to address memory operation objects. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0180] The scalar floating-point stack register file (x87 stack) 845, on which the MMX compact integer flat register file 850 is aliased – in the illustrated embodiment, the x87 stack is an octet stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using the x87 instruction set extension; while the MMX register is used to perform operations on 64-bit compact integer data, and to hold the operation objects for some operations performed between the MMX and XMM registers.

[0181] Alternative embodiments may use wider or narrower registers. Furthermore, alternative embodiments may use more, fewer, or different register files and registers.

[0182] Exemplary core architecture, processor, and computer architecture

[0183] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, such core implementations may include: 1) general-purpose ordered cores intended for general-purpose computing; 2) high-performance general-purpose unordered cores intended for general-purpose computing; and 3) dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) CPUs comprising one or more general-purpose ordered cores intended for general-purpose computing and / or one or more general-purpose unordered cores intended for general-purpose computing; and 2) coprocessors comprising one or more dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Such different processors lead to different computer system architectures, which may include: 1) coprocessors on a separate chip from the CPU; 2) coprocessors in the same package as the CPU, on a separate die; 3) coprocessors on the same die as the CPU (in this case, such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or dedicated cores); and 4) systems-on-a-chip that may include the described CPU (sometimes referred to as application cores or application processors), the aforementioned coprocessors, and additional functionality on the same die. An exemplary core architecture is described next, followed by a description of exemplary processors and computer architectures.

[0184] Exemplary core architecture

[0185] Ordered and disordered core diagrams

[0186] Figure 9A The diagram illustrates, according to some embodiments of the present invention, both exemplary ordered pipes and exemplary register renaming, and unordered issue / execution pipes. Figure 9B The diagram illustrates, according to some embodiments of the invention, both an exemplary embodiment of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core. Figures 9A-9B The solid boxes in the diagram illustrate ordered pipelines and ordered kernels, while the optional dashed boxes illustrate register renaming, out-of-order issue / execute pipelines, and kernels. Given that ordered aspects are a subset of out-of-order aspects, the out-of-order aspects will be described.

[0187] exist Figure 9A In the processor pipeline 900, there are fetch stage 902, length decoding stage 904, decoding stage 906, allocation stage 908, renaming stage 910, scheduling (also known as dispatch or issue) stage 912, register read / memory read stage 914, execution stage 916, write back / memory write stage 918, exception handling stage 922 and commit stage 924.

[0188] Figure 9B The processor core 990 is shown to include a front-end unit 930 coupled to an execution engine unit 950, and both are coupled to a memory unit 970. The core 990 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Alternatively, the core 990 can be a dedicated core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and so on.

[0189] Front-end unit 930 includes branch prediction unit 932 coupled to instruction cache unit 934, instruction cache unit 934 coupled to translation lookaside buffer (TLB) 936, instruction TLB 936 coupled to instruction fetch unit 938, and instruction fetch unit 938 coupled to decoding unit 940. Decoding unit 940 (or decoder) decodes instructions and generates one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as outputs. These micro-operations, microcode entry points, microinstructions, other instructions, or other control signals are decoded from, or otherwise reflect, the original instructions, or are derived from the original instructions. Decoding unit 940 can be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), and so on. In one embodiment, core 990 includes a microcode ROM or other medium that stores microcode for certain macro instructions (e.g., in decoding unit 940 or otherwise within front-end unit 930). Decoding unit 940 is coupled to rename / allocator unit 952 in execution engine unit 950.

[0190] The execution engine unit 950 includes a rename / allocator unit 952 coupled to a retirement unit 954 and a set of one or more scheduler units 956. The scheduler units 956 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler units 956 are coupled to one or more physical register file units 958. Each of the physical register file units 958 represents one or more physical register files, which store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer as the address of the next instruction to be executed), etc. In one embodiment, the physical register file unit 958 includes vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. One or more physical register file units 958 overlap with retirement units 954 to illustrate various ways that can be used to implement register renaming and out-of-order execution (e.g., using one or more reorder buffers and one or more retirement register files; using one or more future files, one or more history buffers and one or more retirement register files; using register maps and register pools; etc.). Retirement units 954 and one or more physical register file units 958 are coupled to one or more execution clusters 960. The execution clusters 960 include a set of one or more execution units 962 and a set of one or more memory access units 964. Execution units 962 can perform various operations (e.g., shift, addition, subtraction, multiplication) on various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include several execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. One or more scheduler units 956, one or more physical register file units 958, and one or more execution clusters 960 are shown as potentially multiple, because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each having its own scheduler unit, physical register file unit, and / or execution cluster – and in the case of separate memory access pipelines, some embodiments are implemented where only the execution cluster of this pipeline has one or more memory access units 964). It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be issued / executed out of order, while the rest are ordered.

[0191] A set of memory access units 964 is coupled to a memory unit 970, which includes a data TLB unit 972. The TLB unit 972 is coupled to a data cache unit 974, and the data cache unit 974 is coupled to a Level 2 (L2) cache unit 976. In one exemplary embodiment, the memory access unit 964 may include a load unit, a memory address unit, and a memory data unit, each of which is coupled to the data TLB unit 972 in the memory unit 970. An instruction cache unit 934 is further coupled to the Level 2 (L2) cache unit 976 in the memory unit 970. The L2 cache unit 976 is coupled to one or more other levels of cache and ultimately to main memory.

[0192] As an example, the exemplary register renaming, out-of-order issue / execution core architecture can implement the pipeline 900 as follows: 1) Instruction fetch 938 performs fetch and length decoding stages 902 and 904; 2) Decoding unit 940 performs decoding stage 906; 3) Rename / allocator unit 952 performs allocation stage 908 and rename stage 910; 4) (one or more) scheduler unit 956 performs scheduling stage 912; 5) (one or more) physical register file unit 958 and memory unit 970 perform register read / memory read stage 914; execution cluster 960 performs execution stage 916; 6) memory unit 970 and (one or more) physical register file unit 958 perform write-back / memory write stage 918; 7) Various units may be involved in exception handling stage 922; and 8) retirement unit 954 and (one or more) physical register file unit 958 perform commit stage 924.

[0193] Core 990 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California; the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California (with optional additional extensions, such as NEON)), including one or more of the instructions described herein. In one embodiment, Core 990 includes logic to support compact data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using compact data.

[0194] It should be understood that the core can support multithreaded processing (two or more parallel sets of operations or threads), and can support multithreaded processing in a variety of ways, including time-sliced ​​multithreaded processing, simultaneous multithreaded processing (where a single physical core provides a logical core for each thread performing simultaneous multithreaded processing on that physical core), or a combination thereof (e.g., time-sliced ​​extraction and decoding, followed by simultaneous multithreaded processing, such as...). (as in Hyperthreading technology).

[0195] Although register renaming is described in an out-of-order execution context, it should be understood that register renaming can be used in ordered architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units 934 / 974 and a shared L2 cache unit 976, alternative embodiments may have a single internal cache for both instructions and data, such as a Level 1 (L1) internal cache, or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be located outside the core and / or processor.

[0196] Specific exemplary ordered core architecture

[0197] Figures 10A-10B The diagram illustrates a more specific exemplary ordered core architecture, which will be one of several logic blocks (including other cores of the same and / or different types) in the chip. The logic blocks communicate with certain fixed-function logic, memory I / O interfaces, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network), depending on the application.

[0198] Figure 10A This is a block diagram of a single processor core and its connection to an on-chip interconnect network 1002 and a local subset 1004 of a Level 2 (L2) cache, according to some embodiments of the invention. In one embodiment, the instruction decoder 1000 supports the x86 instruction set with a compact data instruction set extension. The L1 cache 1006 allows low-latency access to cache memory in scalar and vector units. Although in one embodiment (for design simplification), scalar units 1008 and vector units 1010 use separate sets of registers (scalar register 1012 and vector register 1014, respectively) and data transferred between them is written to memory and then read back from the Level 1 (L1) cache 1006, alternative embodiments of the invention may use different schemes (e.g., using a single set of registers or including a communication path that allows data to be transferred between two register files without being written and read back).

[0199] The local subset 1004 of the L2 cache is part of the global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset 1004 of the L2 cache. Data read by a processor core is stored in its L2 cache subset 1004 and is quickly accessible, in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1004 and can be flushed from other subsets as needed. The ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches, and other logical blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0200] Figure 10B According to some embodiments of the present invention Figure 10A An expanded view of a portion of the processor core. Figure 10B This includes the L1 data cache 1006A portion of L1 cache 1004, and further details regarding vector unit 1010 and vector register 1014. Specifically, vector unit 1010 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1028) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports register input allocation using allocation unit 1020, numerical conversion using value conversion units 1022A-B, and copying of memory input using copy unit 1024. Write mask register 1026 allows assertion result vector writing.

[0201] Figure 11 This is a block diagram of a processor 1100 that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to some embodiments of the present invention. Figure 11 The solid box in the figure illustrates a processor 1100 having a single core 1102A, a system agent 1110, and a group of one or more bus controller units 1116, while the optional addition of the dashed box illustrates an alternative processor 1100 having multiple cores 1102A-N, a group of one or more integrated memory control units 1114 among the system agent units 1110, and dedicated logic 1108.

[0202] Therefore, different implementations of processor 1100 may include: 1) a CPU in which dedicated logic 1108 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and cores 1102A-N are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose unordered cores, or a combination of both); 2) a coprocessor in which cores 1102A-N are a large number of dedicated cores primarily intended for graphics and / or scientific (throughput); and 3) a coprocessor in which cores 1102A-N are a large number of general-purpose ordered cores. Thus, processor 1100 may be a general-purpose processor, coprocessor, or dedicated processor, such as a network or communication processor, compression engine, graphics processor, GPGPU (General-Purpose Graphics Processing Unit), high-throughput many-integrated-core (MIC) coprocessor (including 30 or more cores), embedded processor, etc. The processor may be implemented on one or more chips. Processor 1100 may be part of one or more substrates and / or implemented on one or more substrates using any of several process technologies, such as BiCMOS, CMOS, or NMOS.

[0203] The memory hierarchy may include one or more levels of cache within the core, a set or one or more shared cache units 1106, and external memory (not shown) coupled to the set of integrated memory controller units 1114. The set of shared cache units 1106 may include one or more intermediate level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (4), or other levels of cache, the last level cache (LLC), and / or combinations thereof. While in one embodiment, ring-based interconnect units 1112 interconnect integrated graphics logic 1108 (which is an example of dedicated logic and is also referred to herein as dedicated logic), the set of shared cache units 1106, and system proxy units 1110 / (one or more) integrated memory controller units 1114, alternative embodiments may use any number of known techniques to interconnect such units. In one embodiment, consistency is maintained between one or more cache units 1106 and cores 1102A-N.

[0204] In some embodiments, one or more of the cores 1102A-N are capable of multithreaded processing. System agent 1110 includes those components that coordinate and operate the cores 1102A-N. System agent unit 1110 may include, for example, a power control unit (PCU) and a display unit. The PCU may be, or may include, the logic and components required to regulate the power state of the cores 1102A-N and the integrated graphics logic 1108. The display unit is used to drive one or more externally connected displays.

[0205] The core 1102A-N can be homogeneous or heterogeneous in terms of its architecture instruction set; that is, two or more cores of the 1102A-N may be able to execute the same instruction set, while others may be able to execute a subset of that instruction set or a different instruction set.

[0206] Exemplary computer architecture

[0207] Figures 12-15 This is a block diagram of an exemplary computer architecture. Other system designs and configurations known in the art for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In summary, many kinds of systems or electronic devices capable of incorporating the processors and / or other execution logic disclosed herein are generally suitable.

[0208] Now for reference Figure 12The diagram illustrates a block diagram of a system 1200 according to an embodiment of the present invention. System 1200 includes one or more processors 1210, 1215 coupled to a controller hub 1220. In one embodiment, controller hub 1220 includes a graphics memory controller hub (GMCH) 1290 and an input / output hub (IOH) 1250 (which may be on separate chips); GMCH 1290 includes memory and a graphics processor coupled to memory 1240 and coprocessor 1245; IOH 1250 couples input / output (I / O) devices 1260 to GMCH 1290. Alternatively, one or both of the memory and graphics controller are integrated within the processor (as described herein), memory 1240 and coprocessor 1245 are directly coupled to processor 1210, and controller hub 1220 and IOH 1250 are on a single chip.

[0209] The option of an additional processor 1215 is available. Figure 12 The text is represented by dashed lines. Each processor 1210, 1215 may include one or more of the processing cores described herein and may be a version of processor 1100.

[0210] The memory 1240 may be, for example, dynamic random-access memory (DRAM), phase-change memory (PCM), or a combination of both. In at least one embodiment, the controller center 1220 communicates with one or more of 1210, 1215 via a multi-point branch bus (e.g., frontside bus, FSB), a point-to-point interface (e.g., QuickPath Interconnect, QPI), or a similar connection 1295.

[0211] In one embodiment, the coprocessor 1245 is a dedicated processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, etc. In one embodiment, the controller center 1220 may include an integrated graphics accelerator.

[0212] Between physical resources 1210 and 1215, there can be various differences in the range of value metrics, including architectural characteristics, microarchitectural characteristics, thermal characteristics, power consumption characteristics, and so on.

[0213] In one embodiment, processor 1210 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 1210 identifies these coprocessor instructions as types that should be executed by an attached coprocessor 1245. Therefore, processor 1210 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1245 on a coprocessor bus or other interconnect. One or more coprocessors 1245 receive and execute the received coprocessor instructions.

[0214] Now for reference Figure 13 A block diagram of a first more specific exemplary system 1300 according to an embodiment of the present invention is shown. Figure 13 As shown, the multiprocessor system 1300 is a point-to-point interconnect system and includes a first processor 1370 and a second processor 1380 coupled via a point-to-point interconnect 1350. Each of processors 1370 and 1380 may be a version of processor 1100. In some embodiments, processors 1370 and 1380 are processors 1210 and 1215, respectively, and coprocessor 1338 is coprocessor 1245. In another embodiment, processors 1370 and 1380 are processor 1210 and coprocessor 1245, respectively.

[0215] Processors 1370 and 1380 are shown to include integrated memory controller (IMC) units 1372 and 1382, respectively. Processor 1370 also includes point-to-point (PP) interfaces 1376 and 1378 as part of its bus controller unit; similarly, the second processor 1380 includes PP interfaces 1386 and 1388. Processors 1370 and 1380 can exchange information via point-to-point (PP) interface 1350 using PP interface circuits 1378 and 1388. Figure 13 As shown, IMC 1372 and 1382 couple the processor to their respective memories, namely memory 1332 and memory 1334, which may be part of the main memory locally attached to the respective processor.

[0216] Processors 1370 and 1380 can each exchange information with chipset 1390 via individual PP interfaces 1352 and 1354 using point-to-point interface circuits 1376, 1394, 1386, and 1398, respectively. Chipset 1390 can optionally exchange information with coprocessor 1338 via high-performance interface 1392. In one embodiment, coprocessor 1338 is a dedicated processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, etc.

[0217] A shared cache (not shown) may be included in either processor or in two processors but connected to the processors via a PP interconnect, such that local cache information of either or both processors may be stored in the shared cache when the processors are in a low-power mode.

[0218] Chipset 1390 may be coupled to first bus 1316 via interface 1396. In one embodiment, first bus 1316 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a Fast PCI bus or another third-generation I / O interconnect bus, although the scope of the invention is not limited thereto.

[0219] like Figure 13 As shown, various I / O devices 1314 may be coupled to a first bus 1316, and a bus bridge 1318 couples the first bus 1316 to a second bus 1320. In one embodiment, one or more additional processors 1315, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or digital signal processing (DSP) unit), a field-programmable gate array, or any other processor, are coupled to the first bus 1316. In one embodiment, the second bus 1320 may be a low pin count (LPC) bus. Various devices may be coupled to the second bus 1320, such as a keyboard and / or mouse 1322, a communication device 1327, and a storage unit 1328, such as a disk drive or other mass storage device, which in one embodiment may include instruction / code and data 1330. Additionally, audio I / O 1324 may be coupled to the second bus 1320. Note that other architectures are possible. For example, instead of Figure 13 The system can implement a point-to-point architecture, or a multi-point branch bus or other such architectures.

[0220] Now for reference Figure 14 A block diagram of a second, more specific exemplary system 1400 according to an embodiment of the present invention is shown. Figure 13 and Figure 14 Similar elements in the text have similar labels, and Figure 13 Some aspects were from Figure 14 Omitted to avoid ambiguity Figure 14 Other aspects.

[0221] Figure 14The diagram shows that processors 1370 and 1380 may include integrated memory and I / O control logic (“CL”) 1472 and 1482, respectively. Thus, CL 1472 and 1482 include an integrated memory controller unit and I / O control logic. Figure 14 The diagram shows that not only are the memories 1332 and 1334 coupled to CLs 1472 and 1482, but the I / O device 1414 is also coupled to the control logic 1472 and 1482. The conventional I / O device 1415 is coupled to the chipset 1390.

[0222] Now for reference Figure 15 A block diagram of a SoC 1500 according to an embodiment of the present invention is shown. Figure 11 Similar elements in the text have similar labels. Additionally, dashed boxes are an optional feature on more advanced SoCs. Figure 15 In this embodiment, one or more interconnect units 1502 are coupled to: an application processor 1510, which includes a set of one or more cores 1102A-N and one or more shared cache units 1106, wherein cores 1102A-N include cache units 1104A-N; a system proxy unit 1110; one or more bus controller units 1116; one or more integrated memory controller units 1114; a set of one or more coprocessors 1520, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 1530; a direct memory access (DMA) unit 1532; and a display unit 1540 for coupling to one or more external displays. In one embodiment, one or more coprocessors 1520 include a dedicated processor, such as a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, etc.

[0223] Embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the invention can be implemented as computer programs or program code that execute on a programmable system comprising 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.

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

[0225] The program code can be implemented using a high-level procedural or object-oriented programming language to communicate with the processing system. If desired, the program code can also be implemented using assembly or machine language. In fact, the mechanisms described in this article are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0226] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, causes the machine-manufacturing logic to perform the techniques described herein. Such a representation, referred to as an "IP core," can be stored on a tangible machine-readable medium and provided to various customer or manufacturing facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

[0227] Such machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles made or formed by a machine or device, including storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks, semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EEPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM), magnetic cards or optical cards, or any other type of medium suitable for storing electronic instructions.

[0228] Therefore, embodiments of the present invention also include a non-transitory tangible machine-readable medium containing instructions or design data, such as a Hardware Description Language (HDL), that defines the features of the structures, circuits, devices, processors, and / or systems described herein. Such embodiments may also be referred to as program products.

[0229] Simulation (including binary conversion, code transformation, etc.)

[0230] In some cases, instruction translators can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can transform (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), morphing, emulation, or otherwise translate instructions into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on the processor, off-processor, or partially on-processor and partially off-processor.

[0231] Figure 16This is a block diagram comparing some embodiments of the present invention with the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter can be implemented using software, firmware, hardware, or various combinations thereof. Figure 16 A program of high-level language 1602 is shown to be compiled using x86 compiler 1604 to generate x86 binary code 1606, which can be natively executed by a processor having at least one x86 instruction set core 1616. A processor having at least one x86 instruction set core 1616 means any processor that can perform substantially the same function as an Intel processor having at least one x86 instruction set core by compatiblely executing or otherwise processing (1) a substantial portion of the instruction set of an Intel x86 instruction set core or (2) a version of object code for an application or other software running on an Intel processor having at least one x86 instruction set core, in order to achieve substantially the same result as an Intel processor having at least one x86 instruction set core. x86 compiler 1604 means a compiler operable to generate x86 binary code 1606 (e.g., object code), which can be executed on a processor 1616 having at least one x86 instruction set core, with or without additional linking processing. Similarly, Figure 16 A program in high-level language 1602 is shown to be compiled using a replacement instruction set compiler 1608 to generate replacement instruction set binary code 1610, which can be natively executed by a processor 1614 without at least one x86 instruction set core (e.g., a processor with a core executing the MIPS instruction set of MIPS Technologies, Inc., .C., and / or the ARM instruction set of ARM Holdings, Inc., .C., .C., .C., .Instruction converter 1612 is used to translate x86 binary code 1606 into code that can be natively executed by a processor 1614 without an x86 instruction set core. This translated code is unlikely to be identical to replacement instruction set binary code 1610, as an instruction converter capable of doing so would be difficult to manufacture; however, the translated code will implement general operations and consist of instructions from the replacement instruction set. Thus, instruction converter 1612 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without an x86 instruction set processor or core to execute x86 binary code 1606 through emulation, simulation, or any other process.

[0232] Further examples

[0233] Example 1 describes an exemplary processor comprising: extraction circuitry for extracting instructions having a specified opcode and a field indicating the location of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing execution circuitry to convert each element of the specified source vector into a 16-bit floating-point format and store each converted element in a corresponding location in the specified target vector, the conversion including, where necessary, truncation and rounding; decoding circuitry for decoding the extracted instructions; and execution circuitry for responding to the instructions according to the opcode.

[0234] Example 2 includes the essence of the exemplary processor as described in Example 1, wherein: the instructions further specify the location of a second source vector comprising N single-precision elements; the specified target vector comprises 2 by N 16-bit floating-point elements, the first half of which corresponds to the first source vector and the second source vector, respectively; and the opcode instructs the processor to convert each element of the specified first and second source vectors into 16-bit floating-point format and to store each converted element in the corresponding location of the specified target vector, the conversion including truncation and rounding where necessary.

[0235] Example 3 includes the substance of an exemplary processor as described in Example 1, wherein the location of each specified source vector and target vector is in a register or in memory.

[0236] Example 4 includes the substance of the exemplary processor as described in Example 1, wherein the 16-bit floating-point format includes a sign bit, an 8-bit exponent, and a mantissa, the mantissa including 7 explicit bits and an eighth implicit bit.

[0237] Example 5 includes the substance of an exemplary processor as described in Example 1, wherein N is specified by the instructions and has a value of one of 4, 8, 16, and 32.

[0238] Example 6 includes the substance of the exemplary processor as described in Example 1, wherein when the execution circuit performs rounding, it performs it according to the nearest even rounding rule.

[0239] Example 7 includes the substance of an exemplary processor as described in Example 1, wherein the 16-bit floating-point format is bfloat16 or binary16.

[0240] Example 8 includes the substance of an exemplary processor as described in Example 1, wherein the execution circuitry generates all N elements of a specified target in parallel.

[0241] Example 9 describes an exemplary method executed by a processor, the method comprising: extracting an instruction using extraction circuitry, the instruction having a specified opcode and a field indicating the location of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing execution circuitry to convert each element of the specified source vector into a 16-bit floating-point format and store each converted element in a corresponding location in the specified target vector, the conversion including truncation and rounding where necessary; decoding the extracted instruction using decoding circuitry; and responding to the instruction using execution circuitry based on the opcode.

[0242] Example 10 includes the essence of the exemplary method as described in Example 9, wherein: the instruction further specifies the location of a second source vector comprising N single-precision elements; the specified target vector comprises 2 by N 16-bit floating-point elements, the first half of which corresponds to the first source vector and the second source vector, respectively; and the opcode instructs the execution circuit to convert each element of the specified first and second source vectors into a 16-bit floating-point format and to store each converted element in the corresponding location of the specified target vector, the conversion including truncation and rounding where necessary.

[0243] Example 11 includes the substance of the exemplary method as described in Example 9, wherein the positions of each specified source vector and target vector are in a register or in memory.

[0244] Example 12 includes the substance of the exemplary method as described in Example 9, wherein the 16-bit floating-point format includes a sign bit, an 8-bit exponent, and a mantissa, the mantissa including 7 explicit bits and an eighth implicit bit.

[0245] Example 13 includes the substance of the exemplary method as described in Example 9, wherein N is specified by the instructions and has a value of one of 4, 8, 16, and 32.

[0246] Example 14 includes the substance of the exemplary method as described in Example 9, wherein when the execution circuit performs rounding, it performs it according to the rounding to the nearest even number rule promulgated as IEEE 754.

[0247] Example 15 includes the substance of the exemplary method as described in Example 9, wherein the 16-bit floating-point format is bfloat16 or binary16.

[0248] Example 16 includes the substance of the exemplary method as described in Example 9, wherein the execution circuitry generates all N elements of a specified target in parallel.

[0249] Example 17 describes an exemplary non-transitory machine-readable medium containing instructions that, when executed by a processor, cause the processor to respond by: retrieving the instructions using extraction circuitry, the instructions having a specified opcode and a field indicating the location of a first source vector comprising N single-precision elements and a target vector comprising at least N 16-bit floating-point elements, the opcode instructing execution circuitry to convert each element of the specified source vector into 16-bit floating-point format and store each converted element in a corresponding location in the specified target vector, the conversion including truncation and rounding where necessary; decoding the retrieved instructions using decoding circuitry; and responding to the instructions using execution circuitry based on the opcode.

[0250] Example 18 includes the substance of an exemplary non-transitory machine-readable medium as described in Example 17, wherein: the instructions further specify the location of a second source vector comprising N single-precision elements; the specified target vector comprises 2 by N 16-bit floating-point elements, the first half of which corresponds to the first source vector and the second source vector, respectively; and the opcode instructs the execution circuit to convert each element of the specified first and second source vectors into a 16-bit floating-point format and to store each converted element in the corresponding location of the specified target vector, the conversion including truncation and rounding where necessary.

[0251] Example 19 includes the substance of an exemplary non-transitory machine-readable medium as described in Example 17, wherein the location of each specified source vector and destination vector is in a register or in memory.

[0252] Example 20 includes the substance of an exemplary non-transitory machine-readable medium as described in Example 17, wherein when the execution circuitry performs rounding, it does so according to the nearest even rounding rule.

Claims

1. A processor comprising: Extraction circuitry is used to extract format conversion instructions; A decoding circuit is used to decode the format conversion instruction, which has fields to specify the opcode, the position of the first source vector, the position of the second source vector, and the position of the target vector. The first source vector has a first plurality of 32-bit single-precision floating-point data elements, and the second source vector has a second plurality of 32-bit single-precision floating-point data elements. as well as An execution circuit coupled to the decoding circuit, the execution circuit being used to perform operations corresponding to the format conversion instructions, including: The first plurality of 32-bit single-precision floating-point data elements are converted into the first plurality of 16-bit floating-point data elements, and the second plurality of 32-bit single-precision floating-point data elements are converted into the second plurality of 16-bit floating-point data elements. The first plurality of 16-bit floating-point data elements and the second plurality of 16-bit floating-point data elements have a format, which includes a sign bit, an 8-bit exponent, seven explicit mantissa bits, and one implicit mantissa bit. as well as The first plurality of 16-bit floating-point data elements are stored in the corresponding positions in the first half of the target vector, and the second plurality of 16-bit floating-point data elements are stored in the corresponding positions in the second half of the target vector.

2. The processor of claim 1, wherein converting the first plurality of 32-bit single-precision floating-point data elements into the first plurality of 16-bit floating-point data elements and converting the second plurality of 32-bit single-precision floating-point data elements into the second plurality of 16-bit floating-point data elements comprises performing rounding and truncation.

3. The processor according to claim 1, wherein the format is bfloat16 format.

4. The processor of claim 1 further includes a control register for specifying a rounding mode.

5. The processor of claim 4, wherein the execution circuitry uses a rounding mode that rounds to the nearest even number to convert at least one of the first plurality of 32-bit single-precision floating-point data elements to at least one of the first plurality of 16-bit floating-point data elements.

6. The processor of claim 4, wherein the execution circuit uses the rounding mode controlled by the control register to convert at least one of the first plurality of 32-bit single-precision floating-point data elements into at least one of the first plurality of 16-bit floating-point data elements.

7. The processor according to any one of claims 1 to 6, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 128-bit vector registers.

8. The processor according to any one of claims 1 to 6, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 256-bit vector registers.

9. The processor according to any one of claims 1 to 6, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 512-bit vector registers.

10. The processor according to any one of claims 1 to 6, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 1024-bit vector registers.

11. The processor according to any one of claims 1 to 6, wherein the format conversion instruction allows the first source vector to be either at least 128 bits or 512 bits.

12. The processor according to any one of claims 1 to 6, wherein the processor is a Reduced Instruction Set Computing (RISC) core.

13. A calculation method, comprising: Extract format conversion instructions; Decode the format conversion instruction, which has fields to specify the opcode, the position of the first source vector, the position of the second source vector, and the position of the target vector. The first source vector has a first plurality of 32-bit single-precision floating-point data elements, and the second source vector has a second plurality of 32-bit single-precision floating-point data elements. as well as Performing the operations corresponding to the format conversion instructions includes: The first plurality of 32-bit single-precision floating-point data elements are converted into the first plurality of 16-bit floating-point data elements, and the second plurality of 32-bit single-precision floating-point data elements are converted into the second plurality of 16-bit floating-point data elements. The first plurality of 16-bit floating-point data elements and the second plurality of 16-bit floating-point data elements have a format, which includes a sign bit, an 8-bit exponent, seven explicit mantissa bits, and one implicit mantissa bit. as well as The first plurality of 16-bit floating-point data elements are stored in the corresponding positions in the first half of the target vector, and the second plurality of 16-bit floating-point data elements are stored in the corresponding positions in the second half of the target vector.

14. The method of claim 13, wherein converting the first plurality of 32-bit single-precision floating-point data elements to the first plurality of 16-bit floating-point data elements and converting the second plurality of 32-bit single-precision floating-point data elements to the second plurality of 16-bit floating-point data elements includes performing rounding and truncation.

15. The method of claim 13, wherein the format is bfloat16 format.

16. The method of claim 13, further comprising storing the rounding mode in a control register.

17. The method of claim 16, wherein converting at least one of the first plurality of 32-bit single-precision floating-point data elements to at least one of the first plurality of 16-bit floating-point data elements comprises employing a rounding mode that rounds to the nearest even number.

18. The method of claim 16, wherein converting at least one of the first plurality of 32-bit single-precision floating-point data elements to at least one of the first plurality of 16-bit floating-point data elements comprises employing the rounding mode stored in the control register.

19. The method according to any one of claims 13 to 18, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 128-bit vector registers.

20. The method according to any one of claims 13 to 18, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 256-bit vector registers.

21. The method according to any one of claims 13 to 18, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 512-bit vector registers.

22. The method according to any one of claims 13 to 18, wherein the position of the first source vector, the position of the second source vector, and the position of the target vector are 1024-bit vector registers.

23. The method according to any one of claims 13 to 18, wherein the format conversion instruction allows the first source vector to be either at least 128 bits or 512 bits.

24. A computing system comprising: The processor according to any one of claims 1 to 12; and System memory coupled to the processor.

25. One or more computer-readable media, the computer-readable medium comprising instructions that, in response to being executed by one or more processors, cause the one or more processors to perform the method of any one of claims 13 to 23.

26. A computing device comprising means for performing the method of any one of claims 13 to 23.

27. A computer program product comprising instructions that, in response to being executed on a computing device, cause the computing device to perform the method of any one of claims 13 to 23.

28. A memory system comprising One or more cache units within the core; One or more shared cache units coupled to one or more cache units within the core; An integrated memory controller unit coupled to at least one external memory; as well as A ring-based interconnect unit configured to interconnect the one or more cache units, the one or more shared cache units, and the integrated memory controller unit within the core; One or more shared cache units include one or more intermediate-level caches and the last-level cache; Consistency is maintained between one or more cache units and the core.

Images