TW202405646A - Bfloat16 arithmetic instructions - Google Patents

Abstract

Techniques for performing arithmetic operations on BF16 values are described. An exemplary instruction includes fields for an opcode, an identification of a location of a first packed data source operand, an identification of a location of a second packed data source operand, and an identification of location of a packed data destination operand, wherein the opcode is to indicate an arithmetic operation execution circuitry is to perform, for each data element position of the identified packed data source operands, the arithmetic operation on BF16 data elements in that data element position in BF16 format and store a result of each arithmetic operation into a corresponding data element position of the identified packed data destination operand.

Description

16-bit brain floating point (BFLOAT16) arithmetic instructions

The present invention relates to 16-bit brain floating point arithmetic instructions.

In recent years, fused multiply-add (FMA) units with lower precision multiplication and higher precision accumulation have proven useful in machine learning/artificial intelligence applications, most notably in training deep neural networks, because Its extreme computing intensity. Compared to classic IEEE-754 32-bit (FP32) and 64-bit (FP64) arithmetic, this reduced-precision arithmetic is naturally accelerated disproportionately to its shortened width.

According to an embodiment of the present invention, a device is specifically proposed, which includes: a decoding circuit system for decoding an instance of a single instruction, which includes an operation code and a first packet data. a field identifying a position of the source operand, an identification of a position of the second wrapper data source operand, and a field identifying a position of the wrapper data destination operand, where the opcode is used to Instructs an arithmetic operation execution circuitry to perform the arithmetic operation on the BF16 data element in BF16 format at each data element position of the identified wrapping data source operand, and to A result of an arithmetic operation is stored in a corresponding data element location of the identified packet data destination operand; and the execution circuitry is used to execute the decoded instruction according to the opcode.

This disclosure relates to methods, devices, systems, and non-transitory computer-readable storage media for performing arithmetic operations on BF16 data elements. BF16 has attracted much attention due to its ability to perform well in machine learning algorithms, especially in deep learning training. FP32 format 101 has a sign bit (S), an 8-bit exponent, and a 23-bit fraction (a 24-bit mantissa using an implicit bit). FP16 format 103 has a sign bit (S), a 5-bit exponent, and a 10-bit fraction. BF16 format 105 has a sign bit (S), an 8-bit exponent, and a 7-bit fraction.

Compared to the IEEE 754 standardized 16-bit (FP16) variant, BF16 does not compromise range when compared to FP32. FP32 numbers have an 8-bit exponent and a 24-bit mantissa (including an implicit one). BF16 strips 16 bits from the 24-bit FP32 mantissa to produce a 16-bit floating point data type. In comparison, FP16 roughly halve the FP32 mantissa to 10 explicit bits and reduce the exponent to 5 bits to match the 16-bit data type envelope.

Although BF16 provides less accuracy than FP16, it is generally better suited to support deep learning tasks. Due to the limited range of FP16, its range is not sufficient for deep learning training out of the box. BF16 does not suffer from this problem, and this limited accuracy can actually help generalize learned weights in neural network training tasks. In other words, lower accuracy can be thought of as providing a built-in regularization property.

Detailed herein are embodiments and support for instructions that natively operate on BF16 source data elements by performing one of addition, subtraction, multiplication, division, or reciprocal calculations. In some embodiments, instructions are defined such that their execution treats denormal input or output as zero, supports any rounding mode, and/or reports or suppresses floating point value flags. No upconversion, etc. is required to operate these instructions. However, although accurate arithmetic operations (such as addition, division, multiplication, subtraction) may be performed, the final results to be stored may be rounded.

Figure 1 illustrates an exemplary execution of an instruction that performs an arithmetic operation on source BF16 data elements. Although this illustration is in a small-first format, the principles discussed here operate in a large-first format. The arithmetic operation on the source BF16 data element instruction (shown here with the example opcode mnemonic V{ARITH}NEPBF16, where the arithmetic operation to be performed is annotated with {ARITH}, such as ADD, SUB, DIV, or MUL ) includes one or more fields that define the opcode used for the instruction, one or more fields that reference or indicate the source of the enveloping data (e.g., a register or memory location), and/or One or more fields that reference or indicate the destination of packet data (e.g., a register or memory location). In some embodiments, the command also includes one or more fields to reference or indicate a write mask or predicate register, which is used to store write mask or predicate values as described later.

In this example, envelope data sources 101 and 103 include 8 envelope data elements, and each envelope data element is in BF16 format. Encapsulated data sources 101 and 103 may be a register or a memory location. In some embodiments, when the second source 103 is a memory location, the number of bytes at the specified address corresponding to the length of the selected vector register size is loaded from memory, or the number of bytes at the specified address is loaded from memory. Load a scalar value at the specified address and broadcast to all entries in the vector register (eg, using broadcast circuitry 111). In some embodiments, two of these variations cause a temporary load to the vector registers, and the operation then proceeds as if operating on 3 vector registers. An embodiment may select different microarchitectures for handling fused memory operators.

Encapsulated data sources 101 and 103 (or scratchpad variants) are fed into execution circuitry 109 to be manipulated. Specifically, the execution circuitry 109 performs corresponding per-data element position addition (e.g., using the addition circuitry 114), multiplication (e.g., using the multiplication circuitry 116), and subtraction (e.g., using the multiplication circuitry 116) according to the {ARITH} instruction of the operation code. using subtraction circuitry 115) or division (eg, using division circuitry 117).

In some embodiments, this implementation uses a round-to-nearest (even) rounding mode. In some embodiments, the output denormal value is always cleared to zero, and the input denormal value is always treated as zero.

Wrap data destination 131 is written to store the resulting arithmetic operation in a wrap data element corresponding to, for example, wrap data source 101. In some embodiments, when the instruction requires the use of predicates or write masks, a write mask (or predicate) register 131 specifies how to use write mask circuitry 121 to store and/or zero out the resulting Arithmetic operation value.

Figure 2 illustrates one embodiment of a method for performing an arithmetic operation on a BF16 data element instruction by a processor. For example, a processor core as shown in Figure 13(B), a pipeline as described in detail below, etc. perform this method.

At step 201, an instruction is fetched, the instruction having an identification for an operation code, an identification of a location of a first packaging data source operand, and an identification of a location of a second packaging data source operand. and a field identifying one of the locations of the packet data destination operands, wherein the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed on each data of the identified packet data source operands element position, perform the arithmetic operation on the bf16 data element at the data element position, and store a result of each arithmetic operation in a corresponding data element position of the identified wrapping data destination operand.

An example of a format for performing arithmetic operations on BF16 data element instructions is V{ARITH}NEPBF16 DST{k}, SRC. In some embodiments, V{ARITH}NEPBF16 is the opcode mnemonic of the instruction. DST is the field used to encapsulate the data destination register operand. The SRC is one or more fields for a source, such as an envelope data register and/or memory. The source and destination operands may be presented in one or more sizes, such as 128 bits, 256 bits, 512 bits, etc. When using write masks or predicates, use {k}.

In some embodiments, at step 203, the fetched instructions of a first ISA are translated into one or more instructions of a second, different ISA. Second, when one or more instructions of different ISAs are executed, they will provide the same result as if the fetched instruction had been executed. It should be noted that translation can be performed by hardware, software, or a combination thereof.

At step 205, the instruction (or the translated instruction or instructions) is decoded. This decoding may result in the generation of one or more micro-operations to be performed.

At step 207, the data value associated with the source operand of the decoded instruction is retrieved. For example, when a source operand is stored in memory, data from the indicated memory location is retrieved.

At step 209, the decoded instructions are executed by execution circuitry (hardware) such as those detailed herein. The execution circuitry is to perform the arithmetic operation on the bf16 data element at the data element position for each data element position of the identified wrapping data source operands, and store one result of each arithmetic operation into a corresponding data element position of the identified packet data destination operand.

In some embodiments, at step 211, the instruction is committed or retired.

Figures 3-6 illustrate exemplary embodiments of virtual code representing the execution and format of the V{ARITH}NEPBF16 instruction. It should be noted that EVEX.b is mapped to b of the first code 1601(C). Annotations for DAZ, FTZ, RNE, and SAE refer to support for the following operations: clear to zero (FTZ), denormalize to zero (DAZ), suppress all exceptions (SAE), and round to even (RNE). enter.

Figure 7 illustrates an exemplary execution of an instruction to calculate the reciprocal of one of the BF16 data elements. Although this illustration is in a small-first format, the principles discussed here operate in a large-first format. The instruction for the reciprocal of the BF16 data element (shown here with the example opcode mnemonic VRCPNEPBF16) includes one or more fields to define the opcode, reference, or directive to wrap the data source (e.g., temporary one or more fields that reference or indicate the destination of the packet data (e.g., a register or memory location). In some embodiments, the command also includes one or more fields to reference or indicate a write mask or predicate register, which is used to store write mask or predicate values as described later.

An example of a format for calculating the approximate reciprocal of a BF16 data element instruction is VRCPNEPBF16 DST{k}, SRC. In some embodiments, VRCPNEPBF16 is the opcode mnemonic for this instruction. DST is the field used to encapsulate the data destination register operand. The SRC is one or more fields for a source, such as an envelope data register and/or memory. The source and destination operands may be presented in one or more sizes, such as 128 bits, 256 bits, 512 bits, etc. When using write masks or predicates, use {k}.

In this example, the envelope data source 701 includes 8 envelope data elements, and each envelope data element is in BF16 format. Encapsulated data source 701 may be a register or a memory location.

Encapsulated data source 701 is fed into execution circuitry 709 to be manipulated. Specifically, execution circuitry 709 performs a calculation that approximates the reciprocal for each of the packet data elements. In some embodiments, this execution of the instruction uses a round-to-nearest (even) rounding mode. In some embodiments, the output denormal value is always cleared to zero, and the input denormal value is always treated as zero.

The wrapper data destination 731 is written to store the resulting BF16 format approximate reciprocal in the wrapper data element corresponding to, for example, the wrapper data source 701. In some embodiments, when the instruction requires the use of predicates or write masks, a write mask (or predicate) register 731 specifies how to use write mask circuitry 721 to store and/or zero the resulting BF16 is the approximate reciprocal.

Figure 8 illustrates one embodiment of a method performed by a processor for computing an approximate reciprocal of a BF16 data element instruction. For example, a processor core as shown in Figure 13(B), a pipeline as described in detail below, etc. perform this method.

At step 801, an instruction is fetched that has fields for an operation code, an identification of a position of a wrapper data source operand, and an identification of a position of a wrapper data destination operand, The operation code is used to instruct the execution circuit system to perform an approximate reciprocal operation on a bf16 data element at the data element position for each data element position of the identified packet data source operand, The approximate reciprocal is stored in a corresponding data element location of the identified packet data destination operand.

In some embodiments, at step 803, the fetched instructions of a first ISA are translated into one or more instructions of a second, different ISA. Second, when one or more instructions of different ISAs are executed, they will provide the same result as if the fetched instruction had been executed. It should be noted that translation can be performed by hardware, software, or a combination thereof.

At step 805, the instruction (or the translated instruction or instructions) is decoded. This decoding may result in the generation of one or more micro-operations to be performed.

At step 807, the data value associated with the source operand of the decoded instruction is retrieved. For example, when a source operand is stored in memory, data from the indicated memory location is retrieved.

At step 809, the decoded instructions are executed by execution circuitry (hardware) such as those detailed herein. The execution circuitry is to perform an approximate reciprocal operation on a bf16 data element at the data element position for each data element position of the identified packet data source operand, and store the approximate reciprocal in in a corresponding data element position of the identified packet data destination operand.

In some embodiments, at step 811, the instruction is committed or retired.

Figure 9 illustrates an exemplary embodiment of virtual code representing the execution and format of a VRCPNEPBF16 instruction. It should be noted that EVEX.b is mapped to b of the first code 1601(C). Annotations for DAZ, FTZ, RNE, and SAE refer to support for the following operations: clear to zero (FTZ), denormalize to zero (DAZ), suppress all exceptions (SAE), and round to even (RNE). enter.

Figure 10 illustrates an embodiment of hardware to process an instruction such as the V{ARITH}NEPBF16 and/or VRCPNEPBF16 instruction. As illustrated, memory 1003 stores a V{ARITH}NEPBF16 and/or VRCPNEPBF16 instruction 1001 to be executed.

Instruction 1001 is received by decoding circuitry 1005. For example, decode circuitry 1005 receives this instruction from the fetch logic/circuitry. The command includes fields for an opcode, first and second sources, and a destination. In some embodiments, the source and destination are registers, while in other embodiments, one or more are memory locations. In some embodiments, the opcode specifies which arithmetic operation is to be performed.

More detailed embodiments of at least one instruction format will be described in detail later. Decoding circuitry 1005 decodes the instruction into one or more operations. In some embodiments, this decoding includes generating a plurality of micro-operations to be performed by execution circuitry, such as execution circuitry 1009. The decoding circuitry 1005 also decodes the instruction first code.

In some embodiments, register renaming, register allocation, and/or scheduling circuitry 1007 provides functionality for one or more of the following: 1) renaming logical operand values into physical operand values ( For example, in some embodiments, a register alias table), 2) allocates status bits and flags to the decoded instruction, and 3) schedules the process from an instruction pool for execution on the execution circuitry. Decode the instruction (eg, using a reservation station in some embodiments).

Registers (register folders) and/or memory 1008 store data as operands that will be subject to instructions operating on circuitry 1009 . Example register types include packed data registers, general purpose registers, and floating point registers.

Execution circuitry 1009 executes the decoded instruction. Exemplary detailed implementation circuitry is shown in Figures 1, 13, etc.

In some embodiments, retirement/writeback circuitry 1011 architecturally commits the result 1008 and retires the instruction. Exemplary Computer Architecture

Exemplary computer architectures, command formats, etc. that support the disclosed commands are described in detail below. Other systems known in the industry for design and assembly of laptops, desktops, and 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, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally speaking, a wide variety of systems or electronic devices that can incorporate a processor and/or other execution logic as disclosed herein are generally suitable.

Figure 11 illustrates an embodiment of an exemplary system. The multi-processor system 1100 is a point-to-point interconnect system and includes a plurality of processors, including a first processor 1170 and a second processor 1180 , coupled through a point-to-point interconnect 1150 . In some embodiments, first processor 1170 and second processor 1180 are homogeneous. In some embodiments, the first processor 1170 and the second processor 1180 are heterogeneous.

Processors 1170 and 1180 are shown including integrated memory controller (IMC) unit circuitry 1172 and 1182, respectively. Processor 1170 also includes point-to-point (P-P) interfaces 1176 and 1178 as part of its interconnecting controller unit; similarly, second processor 1180 includes P-P interfaces 1186 and 1188 . Processors 1170, 1180 may exchange information via point-to-point (P-P) interconnect 1150 using P-P interface circuits 1178, 1188. IMCs 1172 and 1182 couple the processors 1170, 1180 to individual memories, namely memory 1132 and memory 1134, which may be portions of main memory that are regionally attached to the individual processors.

Processors 1170, 1180 may each exchange information with a chipset 1190 via respective P-P interconnects 1152, 1154 using point-to-point interface circuits 1176, 1194, 1186, 1198. Chipset 1190 may optionally exchange information with co-processor 1138 via a high performance interface 1192. In some embodiments, co-processor 1138 is a special purpose processor, such as, for example, a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like. By.

A shared cache (not shown) may be included in processors 1170, 1180 or external to both processors and connected to the processors via a P-P interconnect so that when the processors are in low While in power mode, either or both of the processor's local cache information may be stored in the shared cache.

Chipset 1190 may be coupled to a first interconnect 1116 via an interface 1196 . In some embodiments, the first interconnect 1116 may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I/O interconnect. In some embodiments, one of the interconnects is coupled to a power control unit (PCU) 1117, which may include circuitry, software, and/or firmware to perform operations related to processors 1170, 1180, and/or or power management operations of co-processor 1138. PCU 1117 provides control information to a voltage regulator to cause the voltage regulator to generate an appropriately regulated voltage. PCU 1117 also provides control information to control the generated operating voltage. In various embodiments, PCU 1117 may include various power management logic units (circuitry) to perform hardware-based power management. Such power management may be fully processor-controlled (e.g., controlled by various processor hardware and may be triggered by workload and/or power, thermal, or other processor constraints) and/or the power management may be responsive to external source (such as a platform or power management source or system software).

PCU 1117 is illustrated as existing as separate logic from processor 1170 and/or processor 1180 . In other cases, PCU 1117 may execute on a given one or more of the cores (not shown) of processor 1170 or 1180. In some cases, the PCU 1117 may be implemented as a microcontroller (dedicated or general purpose) or other control logic configured to execute its own dedicated power management code, sometimes referred to as P-code. In yet other embodiments, the power management operations to be performed by PCU 1117 may be performed external to the processor, such as as a separate power management integrated circuit (PMIC) or another component external to the processor. However, in other embodiments, the power management operations to be performed by PCU 1117 may be performed within the BIOS or other system software.

Various I/O devices 1114 may be coupled to the first interconnect 1116 and in conjunction with a (bus) bridge 1118 that couples the first interconnect 1116 to the second interconnect. Connected parts 1120. In some embodiments, one or more additional processors 1115, such as co-processors, high throughput MIC processors, GPGPUs, accelerators (such as, for example, graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays (FPGA) or any other processor is coupled to the first interconnect 1116 . In some embodiments, the second interconnect 1120 may be a low pin count (LPC) interconnect. Various devices may be coupled to second interconnect 1120 , including, for example, keyboard and/or mouse 1122 , communication device 1127 , and storage unit circuitry 1128 . In some embodiments, storage unit circuitry 1128 is a disk drive or other mass storage device that may include instructions/code and data 1130 . Additionally, audio I/O 1124 may be coupled to second interconnect 1120 . It should be noted that other architectures than the point-to-point architecture described above are possible. For example, instead of a point-to-point architecture, a system such as multiprocessor system 1100 may implement a multipoint interconnect or other such architecture. Exemplary Core Architectures, Processors, and Computer Architectures

Processor cores may be implemented in different ways for different purposes and may be located in different processors. For example, implementations of such cores may include: 1) general-purpose in-order cores intended for general-purpose computing; 2) high-performance general-purpose out-of-order cores intended for general-purpose computing; 3) primarily intended for graphics and/or or special-purpose cores for scientific (processing) operations. Implementations of different processors may include: 1) a CPU including one or more general-purpose in-order cores intended for general-purpose operations and/or one or more general-purpose out-of-order cores intended for general-purpose operations; and 2 ) A co-processor that includes one or more special-purpose cores intended primarily for graphics and/or scientific (throughput). These different processors result in different computer system architectures, which may include: 1) co-processors on a separate die from the CPU; 2) co-processors on a separate die in the same package as the CPU; 3) A co-processor on the same die as the CPU (in which case this co-processor is sometimes referred to as dedicated logic, such as integrated graphics and/or scientific (throughput) logic, or as a dedicated core ); and 4) a system-on-chip, which may include the co-processor and additional functionality described above on the same die as the CPU (sometimes referred to as an application core or application processor) as described sex. Next, an exemplary core architecture is described, followed by a description of exemplary processor and computer architectures.

Figure 12 illustrates a block diagram of an embodiment of a processor 1200 that may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid box illustrates the processor 1200 with a single core 1202(A), system agent 1210, and a set of one or more interconnected controller unit circuits 1216, while the addition of optional dashed boxes illustrates having multiple cores 1202(A)-(N), a set of one or more integrated memory controller unit circuitry 1214 and special purpose logic 1208 in system agent unit circuitry 1210, and a set of one or more interconnect controllers Replacement processor 1200 for unit circuitry 1216 . It should be noted that the processor 1200 may be one of the processors 1170 or 1180 of FIG. 11 or the co-processors 1138 or 1115.

Accordingly, different implementations of processor 1200 may include: 1) a CPU with special purpose logic that is integrated graphics and/or scientific (throughput) logic (which may include one or more cores, not shown) 1208, and cores 1202(A)-(N) that are one or more general-purpose cores (e.g., a general-purpose in-order core, a general-purpose out-of-order core, or a combination of both); 2) a co-processor having Cores 1202(A)-(N) that are large numbers of special purpose cores intended primarily for graphics and/or science (throughput); and 3) a co-processor with cores 1202(A) that are large numbers of general purpose in-order cores -(N). Therefore, the processor 1200 may be a general-purpose processor, a co-processor, or a special-purpose processor, such as a network or communications processor, a compression engine, a graphics processor, a GPGPU (general-purpose graphics processing unit circuitry), A high throughput multi-integrated core (MIC) co-processor (comprising 30 or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. Processor 1200 may be part of and/or may be implemented on one or more substrates using any of several process technologies, such as, for example, BiCMOS, CMOS or NMOS.

A memory hierarchy includes one or more cache memory unit circuitry 1204(A)-(N) within cores 1202(A)-(N), a set of one or more shared cache memory units circuitry 1206, and external memory (not shown) coupled to the set of integrated memory controller unit circuitry 1214. The set of one or more shared cache unit circuits 1206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or such as a The last level cache (LLC), other levels of cache, and/or combinations thereof. Although in some embodiments, ring-based interconnect network circuitry 1212 interconnects special purpose logic 1208 (eg, integrated graphics logic), the set of shared cache unit circuitry 1206 and system agent unit circuitry 1210 , alternative embodiments use any number of well-known techniques for interconnecting such units. In some embodiments, coherence is maintained between shared cache memory cell circuitry 1206 and one or more of cores 1202(A)-(N).

In some embodiments, one or more of cores 1202(A)-(N) are capable of multi-threading. System agent unit circuitry 1210 includes those components of coordination and operations cores 1202(A)-(N). System agent unit circuitry 1210 may include, for example, power control unit (PCU) circuitry and/or display unit circuitry (not shown). The PCU may be or may include the logic and components required to regulate the power state of cores 1202(A)-(N) and/or special purpose logic 1208 (eg, integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

Cores 1202(A)-(N) may be homogeneous or heterogeneous with respect to architectural instruction sets; that is, two or more of cores 1202(A)-(N) may be capable of executing the same instruction set while others The core may be able to execute only a subset of that instruction set or a different instruction set. Exemplary core architecture ordered and unordered core block diagrams

13(A) is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to an embodiment of the present invention. 13(B) illustrates an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor in accordance with embodiments of the present invention. block diagram. The solid boxes in Figures 13(A)-(B) illustrate in-order pipelines and in-order cores, while the addition of optional dashed boxes illustrates register renaming, out-of-order issue/execution pipelines and cores. Considering ordered aspects as a subset of disordered aspects, disordered aspects will be explained.

In Figure 13(A), a processor pipeline 1300 includes a fetch stage 1302, an optional length decode stage 1304, a decode stage 1306, an optional allocation stage 1308, an optional rename stage 1310, a scheduler (also called a dispatch or release) stage 1312, an optional register read/memory read stage 1314, an execution stage 1316, a writeback/memory write stage 1318, an optional exception handling Level 1322 and an optional submission level 1324. One or more operations may be performed in each of these processor pipeline stages. For example, during fetch stage 1302, one or more instructions are fetched from instruction memory. During decode stage 1306, the one or more fetched instructions may be decoded using the address of the transfer register port. (eg, a load storage unit (LSU) address) may be generated, and branch transfers (eg, an immediate offset or a linked register (LR)) may be performed. In one embodiment, decode stage 1306 and register read/memory read stage 1314 may be combined into one pipeline stage. In one embodiment, during execution level 1316, decoded instructions may be executed, LSU addresses/data pipelined to the Advanced Microcontroller Bus (AHB) interface may be executed, and multiplication and addition operations may be performed. be performed, arithmetic operations with branching results may be performed, etc.

For example, an exemplary register renaming, out-of-order issue/execution core architecture may execute pipeline 1300 as follows: 1) instruction fetch 1338 performs fetch and length decode stages 1302 and 1304; 2) decode unit circuitry 1340 performs decode stage 1306; 3) Rename/distributor unit circuitry 1352 performs allocation level 1308 and rename level 1310; 4) Scheduler unit circuitry 1356 performs scheduling level 1312; 5) Physical register clip unit circuitry 1358 and The memory unit circuit 1370 performs the register read/memory read stage 1314; the execution cluster 1360 performs the execution stage 1316; 6) the memory unit circuit 1370 and the physical register unit circuit 1358 perform writeback/ Memory write stage 1318; 7) Various units (unit circuitry) may be involved in exception handling stage 1322; and 8) Retirement unit circuitry 1354 and physical register clip unit circuitry 1358 execute commit stage 1324.

13(B) shows a processor core 1390 that includes front-end unit circuitry 1330 coupled to an execution engine unit circuitry 1350, and both are coupled to a memory unit circuitry 1370. Core 1390 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, core 1390 may be a special purpose core, such as, for example, a networking or communications core, a compression engine, a co-processor core, a general-purpose graphics processing unit (GPGPU) core, a graphics core, or the like.

Front-end unit circuitry 1330 may include branch prediction unit circuitry 1332 coupled to instruction cache unit circuitry 1334, which is coupled to an instruction translation lookaside buffer (TLB) 1336, Instruction translation lookaside buffer 1336 is coupled to instruction fetch unit circuitry 1338 , which is coupled to decode unit circuitry 1340 . In one embodiment, instruction cache unit circuitry 1334 is included in memory unit circuitry 1370 rather than in front-end unit circuitry 1330 . Decode unit circuitry 1340 (or decoder) may decode instructions and generate as output one or more microoperations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from the original instruction, or Otherwise reflect or derive from the original instructions. Decoding unit circuitry 1340 may further include address generation unit circuitry (AGU, not shown). In one embodiment, the AGU uses the transferred register port to generate the LSU address, and may further perform branch transfer (eg, immediate offset branch transfer, LR register branch transfer, etc.). Decoding unit circuitry 1340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memory (ROM), etc. In one embodiment, core 1390 includes a microcode ROM (not shown) that stores microcode for specific microinstructions (eg, in decode unit circuitry 1340 or otherwise within front-end unit circuitry 1330 ) or Other media. In one embodiment, decode unit circuitry 1340 includes a micro-op to hold/cache decoded operations, micro-tags, or micro-ops generated during decode or other stages of processor pipeline 1300 . ) or arithmetic cache (not shown). Decode unit circuitry 1340 may be coupled to rename/distributor unit circuitry 1352 in execution engine unit circuitry 1350 .

Execution engine circuitry 1350 includes rename/distributor unit circuitry 1352 coupled to retirement unit circuitry 1354 and a set of one or more scheduler circuits 1356 . Scheduler circuitry 1356 represents any number of different schedulers, including reservation stations, central command windows, etc. In some embodiments, scheduler circuitry 1356 may include arithmetic logic unit (ALU) scheduler/scheduling circuitry, ALU queues, arithmetic generation unit (AGU) scheduler/scheduling circuitry, AGU queues Column etc. Scheduler circuitry 1356 is coupled to physical register clip circuitry 1358 . Each of the physical register folder circuitry 1358 represents one or more physical register folders, where different physical register folders store one or more different data types, such as scalar integers, scalar floating point , packed integer, packed floating point, vector integer, vector floating point, status (for example, an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register clip unit circuitry 1358 includes vector register unit circuitry, write mask register unit circuitry, and scalar register unit circuitry. These register units provide architectural vector registers, vector mask registers, general purpose registers, etc. Physical register clip unit circuitry 1358 is overlaid by retirement unit circuitry 1354 (also referred to as an exit queue or a retirement queue) to illustrate the various ways in which register renaming and out-of-order execution may be performed. (For example, using reorder buffers (ROB) and retirement register folders; using future files, history buffers, and retirement register folders; using register images and register pools; etc.). Retirement unit circuitry 1354 and physical register folder circuitry 1358 are coupled to execution cluster 1360 . Execution cluster 1360 includes a set of one or more execution unit circuits 1362 and a set of one or more memory access circuits 1364 . Execution unit circuitry 1362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) and on various types of data (e.g., scalar floating point, packed integers, packed Sealed floating point, vector integer, vector floating point) implementation. While some embodiments may include several execution units or execution unit circuitry dedicated to a particular function or set of functions, other embodiments may include only one execution unit circuitry or multiple execution units/execution unit circuits that all perform all functions. system. Scheduler circuitry 1356, physical register unit circuitry 1358, and execution clusters 1360 are shown as possibly being plural, as some embodiments generate separate pipelines for certain types of data/operations (e.g., each A scalar integer pipeline, scalar floating point/wrapped integer/wrapped floating point/vectored integer/vectored floating point pipeline with its own scheduler circuitry, physical register clip unit circuitry, and/or execution clusters, and /or memory access pipeline - and in the case of a single memory access pipeline, some embodiments may be implemented in which only the execution cluster of this pipeline has memory access unit circuitry 1364). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order release/execution and the remainder in-order.

In some embodiments, execution engine unit circuitry 1350 may implement a load storage unit (LSU) address/data pipeline to an advanced microcontroller bus (AHB) interface (not shown), and implement address phase and Write back, data phase loading, saving and branching.

The set of memory access circuitry 1364 is coupled to memory unit circuitry 1370. Memory unit circuitry 1370 includes data TLB unit circuitry 1372 coupled to data cache circuitry 1374. Data cache circuitry 1372. Bank circuitry 1374 is coupled to level 2 (L2) cache circuitry 1376 . In an exemplary embodiment, memory access unit circuitry 1364 may include load unit circuitry, storage address unit circuitry, and storage data unit circuitry, each of which is coupled to the memory unit circuitry. Data TLB circuit system 1372 in 1370. Instruction cache circuitry 1334 is further coupled to level 2 (L2) cache memory cell circuitry 1376 in memory cell circuitry 1370 . In one embodiment, instruction cache 1334 and data cache 1374 are combined into a single instruction and data cache (not shown) in L2 cache unit circuitry 1376, Level 3 ( L3) cache memory unit circuit system (not shown), and/or main memory. L2 cache cell circuitry 1376 is coupled to one or more other levels of cache and ultimately to main memory.

Core 1390 may support one or more instruction sets including the instructions described herein (e.g., the x86 instruction set (with some extensions that have been added in newer versions); the MIPS instruction set; the ARM instruction set (with any extensions such as NEON). Select additional extensions)). In one embodiment, core 1390 includes logic to support packed data instruction set extensions (eg, AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data. Exemplary Execution Unit Circuitry

Figure 14 illustrates an embodiment of execution unit circuitry, such as execution unit circuitry 1362 of Figure 13(B). As illustrated, execution unit circuits 1362 may include one or more ALU circuits 1401, vector/SIMD unit circuits 1403, load/store unit circuits 1405, and/or branch/jump unit circuits 1407. ALU circuit 1401 performs integer arithmetic and/or Boolean operations. Vector/SIMD unit circuit 1403 performs vector/SIMD operations on packet data (such as SIMD/vector registers). The load/store unit circuit 1405 executes load and store instructions to load data from the memory into the register or store data from the register into the memory. Load/store unit circuit 1405 may also generate addresses. The branch/jump unit circuit 1407 causes a branch or jump to a memory address depending on the instruction. Floating point unit (FPU) circuit 1409 performs floating point arithmetic. The width of execution unit circuitry 1362 varies depending on the embodiment and can range from 16 bits to 1,024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit) . Example register architecture

Figure 15 is a block diagram of a register architecture 1500 according to some embodiments. As illustrated, there are vector/SIMD registers 1510 varying in width from 128 bits to 1,024 bits. In some embodiments, the vector/SIMD register 1510 is physically 512 bits, and depending on the mapping, only some of the lower bits are used. For example, in some embodiments, the vector/SIMD register 1510 is a ZMM register, which is 512 bits: the lower 256 bits are used for the YMM register, and the lower 128 bits The element system is used for XMM registers. Thus, there is an overlay of registers. In some embodiments, the vector length field selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element positions in the ZMM/YMM/XMM registers; depending on the embodiment, the higher-order data element positions remain the same as they were before the instruction or are reset to zero.

In some embodiments, the register architecture 1500 includes a write mask/predicate register 1515. For example, in some embodiments, there are 8 write mask/predicate registers (sometimes referred to as k0 through k7) that are each 16-bit, 32-bit, 64-bit, or 128-bit in size. ). Writing the mask/predicate register 1515 may allow merging (e.g., allowing any set of elements in the destination to be protected from updates during the execution of any operation) and/or zeroing (e.g., zeroing the vector mask allowing the destination Any set of elements in is zeroed out during the execution of any operation). In some embodiments, each data element position in a given write mask/predicate register 1515 corresponds to a data element position at the destination. In other embodiments, write mask/predicate register 1515 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 per 64-bit vector element). Enabled bits).

The register architecture 1500 includes a plurality of general registers 1525 . These registers can be 16-bit, 32-bit, 64-bit, etc., and can be used for scalar operations. In some embodiments, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

In some embodiments, register architecture 1500 includes scalar floating point registers 1545 for performing scalar floating point operations on 32/64/80-bit floating point data using x87 instruction set extensions or as MMX The registers are used to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between the MMX and XMM registers.

One or more flag registers 1540 (eg, EFLAGS, RFLAGS, etc.) store status and control information used for arithmetic, comparison, and system operations. For example, one or more flag registers 1540 may store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some embodiments, one or more flag registers 1540 are referred to as program status and control registers.

Sector register 1520 contains sector points used to access memory. In some embodiments, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

Machine Specific Register (MSR) 1535 controls and reports processor performance. Most of the MSR 1535 handles system-related functions and is not accessible by applications. Machine check register 1560 consists of control, status, and error reporting MSRs that are used to detect and report hardware errors.

One or more instruction pointer registers 1530 store instruction pointer values. Control registers 1555 (eg, CRO-CR4) determine the operating mode of the processor (eg, processors 1170, 1180, 1138, 1115, and/or 1200) and the characteristics of the currently executing task. Debug register 1550 controls and allows monitoring of processor or core debug operations.

Memory management register 1565 specifies the location of data structures used in protected mode memory management. These registers may include GDTR, IDRT, task register and LDTR register.

Alternative embodiments of the invention may use wider or narrower registers. Additionally, alternative embodiments of the invention may use more, fewer, or different register folders and registers. Instruction Set

An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) that specify, among other things, the operation to be performed (e.g., opcode) and the operands on which this operation is to be performed, and /or other data fields (e.g., masks). Some command formats are further broken down through the definition of command templates (or subformats). For example, a command template for a given command format may be defined to have different subsets of the command format's fields (the fields are generally included in the same order, but at least some have different bit positions because fewer fields are included) bit) and/or are defined to have different interpretations of a given field. Thus, each instruction of the ISA is expressed using a given instruction format (and, where defined, as given in the instruction template for that instruction format), and includes fields for specifying operations and operands. . For example, an exemplary ADD instruction has a specific opcode and instruction format that includes opcode fields to specify its opcode and operands to select operands (source1/destination and source2) field; and occurrences of this ADD instruction in the instruction stream will have the specific content of selecting a particular operand in the Operand field. Example command format

Embodiments of the instructions described herein may be embodied in different formats. Additionally, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the instructions may be executed on such systems, architectures, and pipelines, but are not limited to those specified.

Figure 16 illustrates an embodiment of an instruction format. As illustrated, a command may include multiple components including, but not limited to, fields for one or more of the following: one or more headers 1601, an opcode 1603, addressing information 1605 (e.g., temporary register identifier, memory addressing information, etc.), an offset value 1607 and/or an immediate 1609. It should be noted that some instructions utilize some or all of the format's fields, while other instructions may use only the fields of opcode 1603. In some embodiments, the order illustrated is the order in which the fields will be encoded, however, it should be understood that in other embodiments, the fields may be encoded in a different order, combined, etc.

The first code field 1601 will modify the command when used. In some embodiments, one or more headers are used to repeat a sequence of instructions (e.g., 0xF0, 0xF2, 0xF3, etc.) to provide sector overlays (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65 , 0x2E, 0x3E, etc.) to perform a bus lock operation and/or change the operand (e.g., 0x66) and address size (e.g., 0x67). Some instructions require a mandatory first code (for example, 0x66, 0xF2, 0xF3, etc.). Some of these headers may be considered "legacy" headers. Other headers (one or more examples detailed herein) indicate and/or provide further capabilities, such as specifying specific registers. These other first codes generally continue from the "old" first codes.

Opcode field 1603 is used to define, at least in part, the operation to be performed after decoding of the instruction. In some embodiments, the length of a primary opcode encoded in opcode field 1603 is 1, 2, or 3 bytes. In other embodiments, the primary opcodes may be of different lengths. The additional 3-bit opcode field is sometimes encoded in another field.

Addressing field 1605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Figure 17 illustrates an embodiment of an addressing field 1605. In this illustration, an optional ModR/M byte 1702 and an optional Scale, Index, Base (SIB) byte 1704 are shown. ModR/M bytes 1702 and SIB bytes 1704 are used to encode up to two operands of the instruction, each of which is a direct register or valid memory address. It should be noted that each of these fields is optional since not all instructions include one or more of these fields. MOD R/M byte 1702 includes a MOD field 1742, a register field 1744, and an R/M field 1746.

The contents of MOD field 1742 differentiate between memory access and non-memory access modes. In some embodiments, register direct addressing mode is utilized when MOD field 1742 has the value b11, and register indirect addressing is used otherwise.

Register field 1744 may encode a destination register operand or a source register operand, or may encode an opcode extension that is not used to encode any instruction operand. The contents of register index field 1744 specify, directly or through address generation, the location of the source or destination operand (either in a register or in memory). In some embodiments, register field 1744 is supplemented with additional bits from the header code (eg, header code 1601) to allow larger addressing.

R/M field 1746 may be used to encode an instruction operand that refers to a memory address, or may be used to encode a destination register operand or a source register operand. It should be noted that in some embodiments, the R/M field 1746 may be combined with the MOD field 1742 to specify an addressing mode.

The SIB byte 1704 includes a size field 1752, an index field 1754, and a base address field 1756 for use in address generation. Scale field 1752 indicates the scale factor. Index field 1754 specifies the index register to use. In some embodiments, index field 1754 is supplemented with additional bits from the header code (eg, header code 1601) to allow for larger addressing. Base address field 1756 specifies the base address register to be used. In some embodiments, base address field 1756 is supplemented with additional bits from the header code (eg, header code 1601) to allow for larger addressing. In effect, the contents of scale field 1752 allow scaling of the contents of index field 1754 for memory address generation (eg, for address generation using 2 ^scale *index+base).

Some addressing forms use an offset value to generate a memory address. For example, memory addresses can be generated based on 2 ^scale *index+base+displacement, index*scale+displacement, r/m+displacement, instruction pointer (RIP/EIP)+displacement, register+displacement, etc. . The displacement can be 1 byte, 2 bytes, 4 bytes, etc. In some embodiments, the displacement field 1607 provides this value. Additionally, in some embodiments, the displacement factor usage is encoded in the MOD field of addressing field 1605, which indicates a compressed displacement scheme that is used by combining disp8 with vector length-based, b-bit The displacement value is calculated by multiplying the value and the scale factor N determined by the size of the input element of the command. The displacement value is stored in displacement field 1607.

In some embodiments, the immediate field 1609 specifies the immediate for the instruction. Immediately can be encoded into a 1-byte value, a 2-byte value, a 4-byte value, etc.

Figure 18 illustrates an embodiment of a first header 1601(A). In some embodiments, the first header 1601(A) is an embodiment of a REX header. Instructions using this header can specify general-purpose registers, 64-bit packed data registers (for example, single instruction multiple data (SIMD) registers or vector registers), and/or control registers and error register (for example, CR8-CR15 and DR8-DR15).

Instructions using first header 1601(A) may use 3-bit fields to specify up to three registers depending on the format: 1) Register fields 1744 and R using Mod R/M byte 1702 /M field 1746; 2) use the Mod R/M byte 1702 and the SIB byte 1704, which includes the use of the register field 1744 and the base address field 1756 and the index field 1754; or 3) use a Register field for the opcode.

In the first code 1601(A), bit positions 7:4 are set to 0100. Bit position 3(W) can be used to determine operand size, but not only operand width. In this way, when W=0, the operand size is determined by the code section descriptor (CS.D), and when W=1, the operand size is 64 bits.

It should be noted that the addition of another bit allows 16 (2 ⁴ ) registers to be addressed, whereas MOD R/M register field 1744 and MOD R/MR/M field 1746 alone can each address only 8 a temporary register.

In first header 1601(A), bit position 2(R) may be an extension of MOD R/M register field 1744, and may be used to encode a general purpose register, a ModR/M register field 1744 is modified when a 64-bit packet data register (e.g., SSE register) or a control or debug register is used. When the Mod R/M byte 1702 specifies other registers or defines extended opcodes, R is ignored.

Bit position 1 (X) The X bit modifies SIB byte index field 1754.

Bit location B (B) B may modify the base address in Mod R/M R/M field 1746 or SIB byte base address field 1756; or it may be modified to access a general purpose register (e.g., general purpose The opcode register field of register 1525).

19(A)-(D) illustrate an embodiment of how to use the R, X and B fields of the first header 1601(A). Figure 19(A) illustrates R and B from first header 1601(A) used to extend MOD R/M bytes 1702 when SIB bytes 1704 are not used for memory addressing. Register field 1744 and R/M field 1746. Figure 19(B) illustrates R and B from the first header 1601(A), which are used to extend MOD R/ when the SIB byte 1704 is not used (register to register addressing). Register field 1744 and R/M field 1746 of M byte 1702. Figure 19(C) illustrates R, The register field 1744, the index field 1754 and the base address field 1756. Figure 19(D) illustrates B from first header 1601(A) used to extend the register field of MOD R/M bytes 1702 when the register is encoded in opcode 1603 Bit 1744.

20(A)-(B) illustrate an embodiment of the second first code 1601(B). In some embodiments, the second first code 1601(B) is an embodiment of a VEX first code. The second header 1601(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector/SIMD registers 1510) to be longer than 64 bits (e.g., 128 bits and 256 bits). bits). Use of the second code 1601(B) provides three-operand (or more) syntax. For example, the previous two operand instructions perform an operation such as A = A + B, which overwrites a source operand. The use of the second code 1601(B) enables the operands to perform non-destructive operations such as A = B + C.

In some embodiments, the second first code 1601(B) is in two forms—a two-byte form and a three-byte form. The two-byte second code 1601(B) is mainly used for 128-bit, scalar and some 256-bit instructions; the three-byte second code 1601(B) provides the first code 1601(A ) and a compact replacement for 3-byte opcode instructions.

FIG. 20(A) illustrates an embodiment of the two-byte form of the second first code 1601(B). In one example, format field 2001 (byte 0 2003) contains the value C5H. In one example, byte 1 2005 includes the "R" value in bit [7]. This value is the complement of the same value of the first code 1601(A). Bit[2] is used to specify the length (L) of the vector (where the value 0 is a scalar or 128-bit vector and the value 1 is a 256-bit vector). Bits[1:0] provide opcode extensions equivalent to some old prefixes (for example, 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). Bits[6:3] shown as vvvv can be used to: 1) encode the first source register operand, which is specified in inverted (1's complement) form and for sources with 2 or more The instruction for the operand is valid; 2) encodes the destination register operand, which is specified in 1's complement form for the specific vector shift; or 3) does not encode any operand, the field is reserved and Should contain a specific value such as 1111b.

Instructions using this first code can use Mod R/M R/M field 1746 to encode the instruction operand that refers to the memory address, or to encode the destination register operand or the source register operand.

Instructions using this first code can use Mod R/M register field 1744 to encode the destination register operand or the source register operand. It is considered an opcode extension and is not used for any instructions. Operands are encoded.

For instruction syntax that supports four operands vvvv, Mod R/M R/M field 1746 and Mod R/M register field 1744 encode three of the four operands. Bits [7:4] of immediate 1609 are then used to encode the third source register operand.

FIG. 20(B) illustrates an embodiment of the three-tuple form of the second header code 1601(B). In one example, format field 2011 (byte 0 2013) contains the value C4H. Byte 1 2015 includes "R", "X" and "B" in bits [7:5], which is the complement of the same value of the first prefix 1601(A). Bits[4:0] of Byte 1 2015 (shown as mmmmm) contain the content used to encode one or more implicit preamble opcode bytes as needed. For example, 00001 implies a 0FH preamble opcode, 00010 implies a 0F38H preamble opcode, 00011 implies a 0F3AH preamble opcode, etc.

Bit [7] of Byte 2 2017 is used similar to W of the first header 1601(A), including to help determine the operand size that can be generalized. Bit[2] is used to specify the length (L) of the vector (where the value 0 is a scalar or 128-bit vector and the value 1 is a 256-bit vector). Bits[1:0] provide opcode extensions equivalent to some old prefixes (for example, 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). Bits[6:3] shown as vvvv can be used to: 1) encode the first source register operand, which is specified in inverted (1's complement) form and for sources with 2 or more The instruction for the operand is valid; 2) encodes the destination register operand, which is specified in 1's complement form for the specific vector shift; or 3) does not encode any operand, the field is reserved and Should contain a specific value such as 1111b.

Instructions using this first code can use Mod R/M R/M field 1746 to encode the instruction operand that refers to the memory address, or to encode the destination register operand or the source register operand.

Instructions using this first code can use Mod R/M register field 1744 to encode the destination register operand or the source register operand. It is considered an opcode extension and is not used for any instructions. Operands are encoded.

For instruction syntax that supports four operands vvvv, Mod R/M R/M field 1746 and Mod R/M register field 1744 encode three of the four operands. Bits [7:4] of immediate 1609 are then used to encode the third source register operand.

Figure 21 illustrates an embodiment of a third header 1601(C). In some embodiments, the first header 1601(A) is an example of an EVEX header. The third first code 1601(C) is the four-byte first code.

The third header 1601(C) can encode 32 vector registers in 64-bit mode (eg, 128-bit, 256-bit, and 512-bit registers). In some embodiments, this header is utilized using write mask/compute mask instructions (see discussion of registers in previous figures, such as Figure 15) or predicates. Arithmetic mask registers allow conditional processing or selection control. Arithmetic mask instructions whose source/destination operands are the arithmetic mask registers and which treat the contents of the arithmetic mask register as a single value are encoded using the second header 1601(B).

The third header 1601(C) can encode functionality specific to the instruction class (e.g., a wrapped instruction with load+operate semantics can support embedded broadcast functionality, a float with rounding semantics Point instructions can support static rounding functionality, floating point instructions with non-rounding arithmetic meaning can support "suppress all exceptions" functionality, etc.).

The first tuple of the third header code 1601(C) is a format field 2111, and the format field 2111 has a value of 62H in one example. Subsequent bytes are referred to as payload bytes 2115-2119 and collectively form a 24-bit value P[23:0], which provides specific ability.

In some embodiments, P[1:0] of payload bytes 2119 are the same as the lower two mmmmmm bits. In some embodiments, P[3:2] is retained. Bit P[4] (R') allows access to the upper 16 vector register set when combined with P[7] and the ModR/M register field 1744. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] consists of R, Bit 1744 and ModR/M R/M field 1746 when combined allow access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensions equivalent to some old prefixes (for example, 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). In some embodiments, P[10] is a fixed value of 1. P[14:11] shown as vvvv can be used to: 1) encode the first source register operand, which is specified in inverted (1's complement) form and for operations with 2 or more sources instruction is valid; 2) encode the destination register operand, which is specified in 1's complement form for the specific vector shift; or 3) do not encode any operand, this field is reserved and should Contains a specific value such as 1111b.

P[15] is similar to W of the first code 1601(A) and the second code 1611(B), and can be used as an operation code extension bit or an operand size increase.

P[18:16] specifies the index of the register in the operation mask (write mask) register (eg, write mask/predicate register 1515). In one embodiment of the present invention, the specific value aaa = 000 has the special behavior of implying that no arithmetic mask is used for a particular instruction (this can be implemented in a variety of ways, including using an arithmetic mask hardwired to the owner or a wraparound Hardware over masking hardware). When combined, a vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (specified by the base operation and the augmentation operation); in other embodiments, when the corresponding mask When a bit has a value of 0, the old value of each element of the destination is retained. In contrast, when zeroed, a vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the base operation and the augmentation operation); in one embodiment, when the corresponding mask When the mask bit has a value of 0, one of the destination elements is set to 0. This subset of functionality is the ability to control the length of the vector for the operation being performed (i.e., the span of elements is modified from the first to the last); however, the elements being modified need not be consecutive . Therefore, the operation mask field allows some vector operations, including loading, storage, arithmetic, logic, etc. Although it is stated that the contents of the computation mask field select one of several computation mask registers containing the computation mask to be used (and therefore the contents of the computation mask field indirectly identify the mask to be applied ) embodiment of the invention, but alternative or different embodiments allow the contents of the mask write field to directly specify the mask to be applied.

P[19] can be combined with P[14:11] to encode the second source vector register using a non-destructive source syntax, which can use P[19] to access the upper 16 vector registers device. P[20] encodes multiple functionality that varies among different classes of instructions and can affect the meaning of the vector length/rounding control specifier field (P[22:21]). P[23] indicates support for merge-write masks (e.g., when set to 0) or support for zeroing and merge-write masks (e.g., when set to 1).

An exemplary embodiment of the encoding of the register in the instruction using the third header code 1601(C) is detailed in the table below. 4 3 [2:0] scratchpad type Commonly used scratchpad R' R ModR/M register GPR, vector source or destination VVVV V' vvvv GPR, vector Secondary source or destination RM X B ModR/MR/M GPR, vector first source or destination Base address 0 B ModR/MR/M GPR memory addressing index 0 X SIB.index GPR memory addressing VIDX V' X SIB.index vector VSIB memory addressing Table 1 : 32-registers supported in 64-bit mode [2:0] scratchpad type Commonly used scratchpad ModR/M register GPR, vector source or destination VVVV vvvv GPR, vector Secondary source or destination RM ModR/MR/M GPR, vector first source or destination Base address ModR/MR/M GPR memory addressing index SIB.index GPR memory addressing VIDX SIB.index vector VSIB memory addressing Table 2 : Encoding register specifiers in 32-bit mode [2:0] scratchpad type Commonly used scratchpad ModR/M register k0-k7 Source VVVV vvvv k0-k7 secondary source RM ModR/MR/M k0-7 first source {k1] aaa k0 ¹ -k7 Operate mask Table 3 : Operation mask register specifier encoding

Programming code may be applied to input commands to perform the functions described herein and to generate output information. In a known manner, the output information may be applied to one or more output devices. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor .

Programming code may be executed in a high-level programming or object-oriented programming language to communicate with the processing system. If necessary, the program code can also be implemented in assembly language or machine language. In fact, the mechanisms described in this article are not limited in scope to any particular programming language. In any case, the language may be a compiled language or an interpreted language.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the invention may be implemented on a computer including at least one processor, a storage system (including dependent and non-volatile memory and/or storage devices), at least one input device, and at least one output device. A computer program or code that executes on a planning system.

One or more aspects of at least one embodiment may be implemented by representative instructions representing various logic within a processor stored on a machine-readable medium that, when read by a machine, cause the Machines construct the logic used to perform the techniques described in this article. These representations, known as "IP cores," may be stored on tangible machine-readable media and supplied to various consumer or manufacturing facilities for loading into the building machines that actually constitute the logic or processor.

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

Accordingly, embodiments of the present invention may also include non-transitory tangible machine-readable media, such as a hardware description language (HDL), containing instructions or containing design data that defines the structures, circuits, devices, processes described herein device and/or system characteristics. These embodiments may also be referred to as program products. Imitation ( including binary translation, code programming, etc.)

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

22 illustrates a block diagram comparing the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present invention. In the illustrated embodiment, the command converter is a software command converter, but alternatively, the command converter may be implemented in software, firmware, hardware, or various combinations thereof. Figure 22 shows that a first ISA compiler 2204 can be used to compile a program in a high-level language 2202 to produce a first ISA binary code 2206 that can be natively executed by a processor 2216 having at least one first instruction set core. A processor 2216 having at least a first ISA instruction set core may achieve substantially the same results as a processor having at least a first ISA instruction set core by consistently executing or otherwise processing the following: Any processor that performs substantially the same functions as an Intel® processor having at least one first ISA instruction set core: (1) a substantial portion of the instruction set of the first ISA instruction set core, or (2) with the goal of An object code version of an application or other software running on an Intel processor with at least one first ISA instruction set core. The first ISA compiler 2204 represents a compiler operable to generate a first ISA binary 2206 (e.g., object code) that may be generated with or without additional chaining processing. Executed on a processor 2216 having at least one first ISA instruction set core. Similarly, Figure 22 shows that an alternative instruction set compiler 2208 can be used to compile a program in a high-level language 2202 to produce alternative instruction set binaries 2210 that can be natively used by a processor that does not have the first ISA instruction set core. 2214 executed. The instruction converter 2212 is used to convert the first ISA binary code 2206 into program code that can be natively executed by the processor 2214 that does not have the first ISA instruction set core. It is unlikely that the converted code will be identical to the alternative instruction set binary code 2210 because an instruction set converter capable of doing so is difficult to make; however, the converted code will perform the normal operation and be generated from consists of instructions from an alternative instruction set. Therefore, the instruction converter 2212 represents software, firmware, or other electronic devices that allow a processor or other electronic device that does not have the first ISA instruction set processor or core to execute the first ISA binary code 2206 through emulation, emulation, or any other process. Hardware or combination thereof.

References to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the illustrated embodiment may include a particular feature, structure, or characteristic, but that each embodiment may not necessarily include the particular feature , structure or characteristics. Furthermore, these phrases are not necessarily referring to the same embodiment. Additionally, when a particular feature, structure, or characteristic is described in connection with one embodiment, it is intended that changes to such feature, structure, or characteristic be made in connection with other embodiments, whether explicitly stated or not. Within the knowledge of those skilled in the art.

Furthermore, in the various embodiments described above, unless expressly stated otherwise, disjunctive language such as the phrase "at least one of A, B, or C" is intended to be understood to mean A, B, or C, or Any combination of them (for example, A, B and/or C). As such, disjunctive language is not intended and should not be understood to imply that a given embodiment requires the presence of each of at least one of A, at least one of B, or at least one of C.

Examples of utilizing BF16 data elements include, but are not limited to: 1. A device containing: Decoding circuitry for decoding an instance of a single instruction that includes an identification of a location for an opcode, a first packet data source operand, and a second packet data source. A field identifying a position of an operand and a position of a packet data destination operand, where the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed on the identified packets. For each data element position of the data source operand, perform the arithmetic operation on the BF16 data element in BF16 format at that data element position, and store one result of each arithmetic operation into the identified wrapper data destination operation in the position of a corresponding data element of the element; and The execution circuit system is used to execute the decoded instruction according to the operation code. 2. The device of example 1, wherein the field used for the identification of the first source operand is used to identify a vector register. 3. The device of Example 1, wherein the field used for the identification of the first source operand is used to identify a memory location. 4. The device of Example 1, wherein the arithmetic operation is addition. 5. The device of Example 1, wherein the arithmetic operation is multiplication. 6. As in the device of example 1, the arithmetic operation is division. 7. The device of Example 1, wherein the arithmetic operation is subtraction. 8. A system comprising: Memory for storing an instance of a single instruction; Decoding circuitry for decoding the instance of the single instruction to include an identification of a location for an opcode, a first packet data source operand, a second packet data source A field identifying a position of an operand and a position of a packet data destination operand, where the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed on the identified packets. For each data element position of the data source operand, perform the arithmetic operation on the BF16 data element in BF16 format at that data element position, and store one result of each arithmetic operation into the identified wrapper data destination operation in the position of a corresponding data element of the element; and The execution circuit system is used to execute the decoded instruction according to the operation code. 9. The system of Example 8, wherein the field used for the identification of the first source operand is used to identify a vector register. 10. The system of example 8, wherein the field for the identification of the first source operand is used to identify a memory location. 11. As in the system of Example 8, the arithmetic operation is addition. 12. As in the system of Example 8, the arithmetic operation is multiplication. 13. As in the system of Example 8, the arithmetic operation is division. 14. As in the system of Example 8, the arithmetic operation is subtraction. 15. A method comprising: An example of decoding a single instruction to include an identification of a location for an opcode, a first packet data source operand, and one of a location for a second packet data source operand. A field identifying the location of an envelope data destination operand, where the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed for each of the identified envelope data source operands. data element positions, perform the arithmetic operation on the BF16 data element in BF16 format at the data element position, and store one result of each arithmetic operation in a corresponding data element position of the identified envelope data destination operand middle; and The decoded instruction is executed according to the opcode. 16. The method of Example 15, wherein the arithmetic operation is addition. 17. The method of Example 15, wherein the arithmetic operation is multiplication. 18. The method of Example 15, wherein the arithmetic operation is division. 19. The method of Example 15, wherein the arithmetic operation is subtraction. 20. As in Example 15, it further includes: Translating the single instruction into one or more instructions of a different instruction set architecture, wherein executing the decoded instruction according to the opcode includes executing the one or more instructions of the different instruction set architecture. 21. A device comprising: Decoding circuitry for decoding an instance of a single instruction that includes an identification of a location for an opcode, a wrapper data source operand, and a wrapper data destination operand. A field identifying one of the positions, where the opcode is used to instruct the execution circuitry to, for each identified data element position of the envelope data source operand, perform a bf16 data element at that data element position. Perform an operation on an approximate reciprocal and store the approximate reciprocal in a corresponding data element location of the identified packet data destination operand; and The execution circuit system is used to execute the decoded instruction according to the operation code. 22. The device of example 21, wherein the field used for the identification of the first source operand is used to identify a vector register. 23. The device of example 21, wherein the field for the identification of the first source operand is used to identify a memory location. 24. A system comprising: Memory for storing an instance of a single instruction; Decoding circuitry for decoding the instance of the single instruction to include an identification of a location for an opcode, a wrapper data source operand, and a wrapper data destination operand. A field identifying one of the positions, where the opcode is used to instruct the execution circuitry to, for each identified data element position of the envelope data source operand, perform a bf16 data element at that data element position. Perform an operation on an approximate reciprocal and store the approximate reciprocal in a corresponding data element location of the identified packet data destination operand; and The execution circuit system is used to execute the decoded instruction according to the operation code. 25. The system of Example 24, wherein the field used for the identification of the first source operand is used to identify a vector register. 26. The system of example 24, wherein the field for the identification of the first source operand is used to identify a memory location. 27. A method comprising: An example of decoding a single instruction to include fields for an opcode, an identification of a location of a wrapper data source operand, and an identification of a location of a wrapper data destination operand. , where the operation code is used to instruct the execution circuit system to perform an approximate reciprocal operation on a bf16 data element at the data element position for each data element position of the identified packet data source operand. , and store the approximate reciprocal in a corresponding data element location of the identified packet data destination operand; and The decoded instruction is executed according to the opcode. 28. As in Example 27, it further includes: Translating the single instruction into one or more instructions of a different instruction set architecture, wherein executing the decoded instruction according to the opcode includes executing the one or more instructions of the different instruction set architecture.

The specification and drawings should therefore be regarded as illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

101: Encapsulated data source, FP32 format 103: Encapsulated data source, FP16 format, second source 105:BF16 format 109,709,1009:Execution circuit system 111:Broadcast circuit system 114:Adder circuit system 115:Subtraction circuit system 116: Multiplication circuit system 117: Division circuit system 121,721:Write mask circuit system 131: Write mask (or predicate) register, encapsulate data destination 701: Encapsulated data source 731: Write the destination of the packet data and write the mask (or predicate) register 1001:(VRCPNEPBF16) command 1003:Storage 1005: Decoding circuit system 1007: Scheduling circuit system 1008: Register (register folder) and/or memory, result 1011: Retirement/writeback circuit system 1100:Multiprocessor system 1114:I/O device 1115,1138: (total) processors 1116: First interconnection 1117:Power control unit (PCU) 1118: Interconnect (Bus) Bridge 1120: Second interconnection piece 1122:Keyboard and/or mouse 1124: Audio I/O 1127:Communication device 1128: Storage unit circuit system 1130: Program code and data 1132,1134: memory 1150: Point-to-point (P-P) interconnects 1152,1154:P-P interconnect 1170: (First) Processor 1172,1182: Integrated memory controller (IMC) unit circuit system 1176: Point-to-point interface circuit, point-to-point (P-P) interface 1178:P-P interface circuit, point-to-point (P-P) interface 1180: (Second) Processor 1186: Point-to-point interface circuit, P-P interface 1188: P-P interface circuit, P-P interface 1190:Chipset 1192:High performance interface 1194,1198: Point-to-point interface circuit 1196:Interface 1200,2214,2216:processor 1202(A),1202(N):Core 1204(A),1204(N): Cache memory unit circuit system 1206: Shared cache memory unit circuit system 1208:Specific purpose logic 1210: System agent (unit circuit system) 1212: Ring-based interconnection network circuit system 1214: Integrated memory controller unit circuit system 1216: Interconnected Controller Unit Circuit System 1300: (Processor) Pipeline 1302: Extraction level 1304: Length decoding level 1306: Decoding level 1308: Distribution level 1310: Rename level 1312:Scheduling level 1314: Temporary register read/memory read level 1316:Executive level 1318: Write back/memory write level 1322:Exception level 1324: Submit level 1330: Front-end unit circuit system 1332: Branch prediction unit circuit system 1334: Instruction cache (unit circuit system) 1336: Instruction Translation Lookaside Buffer (TLB) 1338: Instruction fetch (unit circuit system) 1340: Decoding unit circuit system 1350: Engine (unit) circuit system 1352: Rename/distributor unit circuit system 1354: Retirement unit circuit system 1356: Scheduler (unit) circuit system 1358: Physical register clip (unit) circuit system 1360: Execution cluster 1362: Execution unit circuit (system) 1364: Memory access (unit) circuit system 1370: Memory unit circuit system 1372: Data TLB (unit) circuit system 1374: Data cache (circuit system) 1376: Level 2 (L2) cache memory (unit) circuit system 1390: (processor) core 1401:ALU circuit 1403: Vector/SIMD unit circuit 1405: Load/store unit circuit 1407: Branch/jump unit circuit 1409: Floating point unit (FPU) circuit 1500: scratchpad architecture 1510: Vector/SIMD register 1515: Write mask/predicate register 1520: Section register 1525: General register 1530: Instruction indicator register 1535: Machine Specific Register (MSR) 1540: Flag register 1545: Scalar floating point register 1550: Debug register 1555: Control register 1560: Machine check scratchpad 1565: Memory management register 1601(A): first digit 1601(B),1611: The second digit 1601(C): (third) first code 1601: First code (field) 1603:Operation code (field) 1605:Addressing information 1607: Displacement field, displacement value 1609: Immediately (field) 1702: MOD R/M byte, Mod R/M byte, ModR/M byte 1704: Base address (SIB) byte 1742:MOD field 1744: Register (index) field, MOD R/M register field, Mod R/M byte, ModR/M register field 1746:(Mod R/M )R/M field, (MOD R/M )R/M field, (ModR/M )R/M field 1752: Standard field 1754: (SIB byte) index field 1756: (SIB byte) base address field 2001,2011,2111:Format field 2003, 2013: Byte 0 2005, 2015: Byte 1 201,203,205,207,209,211,801,803,805,807,809,811: Steps 2017: Byte 2 2115, 2217, 2119: payload bytes 2202:High-level languages 2204: The first ISA compiler 2206: First ISA binary code 2208: Alternative instruction set compiler 2210: Alternative instruction set binary code 2212:Instruction converter

Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:

Figure 1 illustrates an exemplary execution of an instruction that performs an arithmetic operation on source BF16 data elements.

Figure 2 illustrates one embodiment of a method for performing an arithmetic operation on a BF16 data element instruction by a processor.

Figures 3-6 illustrate exemplary embodiments of virtual code representing the execution and format of the V{ARITH}NEPBF16 instruction.

Figure 7 illustrates an exemplary execution of an instruction to calculate the reciprocal of one of the BF16 data elements.

Figure 8 illustrates one embodiment of a method performed by a processor for computing an approximate reciprocal of a BF16 data element instruction.

Figure 9 illustrates an exemplary embodiment of virtual code representing the execution and format of a VRCPNEPBF16 instruction.

Figure 10 illustrates an embodiment of hardware to process an instruction such as the V{ARITH}NEPBF16 and/or VRCPNEPBF16 instruction.

Figure 11 illustrates an embodiment of an exemplary system.

Figure 12 illustrates a block diagram of an embodiment of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics.

13(A) is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to an embodiment of the present invention.

13(B) illustrates an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor in accordance with embodiments of the present invention. or block diagram.

Figure 14 illustrates an embodiment of execution unit circuitry, such as that of Figure 13(B).

Figure 15 is a block diagram of a register architecture according to some embodiments.

Figure 16 illustrates an embodiment of an instruction format.

Figure 17 illustrates an embodiment of an address field.

Figure 18 illustrates an embodiment of a first header.

19(A)-(D) illustrate an embodiment of how to use the R, X and B fields of the first header 1601(A).

20(A)-(B) illustrate an embodiment of a second first code.

Figure 21 illustrates an embodiment of a third header.

22 illustrates a block diagram comparing the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present invention.

101: Encapsulation data source, FP32 format

103: Encapsulated data source, FP16 format, second source

109: Execution circuit system

111:Broadcast circuit system

113: Arithmetic circuit systems

114:Adder circuit system

115:Subtraction circuit system

116: Multiplication circuit system

117: Division circuit system

121:Write mask circuit system

131: Write the mask (or predicate) register to encapsulate the data destination

Claims (21)

A device containing: A decoding component for decoding an instance of a single instruction that includes an identification of a location for an operation code, a first wrapped data source operand, and a second wrapped data source operation. A field identifying a position of a packet data destination operand and an identification field of a position of a packet data destination operand, where the opcode is used to indicate that an arithmetic operation execution unit is to be targeted at the identified source of packet data. For each data element position of an operand, perform the arithmetic operation on the BF16 data element in BF16 format at that data element position, and store one result of each arithmetic operation into the identified destination operand of the wrapped data. in the position of a corresponding data element; and The execution component is used to execute the decoded instruction according to the operation code. The device of claim 1, wherein the field used for the identification of the first source operand is used to identify a vector register. The device of claim 1, wherein the field used for the identification of the first source operand is used to identify a memory location. Such as the device of claim 1, wherein the arithmetic operation is addition. Such as the device of claim 1, wherein the arithmetic operation is multiplication. Such as the device of claim 1, wherein the arithmetic operation is division. Such as the device of claim 1, wherein the arithmetic operation is subtraction. A system that includes: Memory for storing an instance of a single instruction; Decoding circuitry for decoding the instance of the single instruction to include an identification of a location for an opcode, a first packet data source operand, a second packet data source A field identifying a position of an operand and a position of a packet data destination operand, where the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed on the identified packets. For each data element position of the data source operand, perform the arithmetic operation on the BF16 data element in BF16 format at that data element position, and store one result of each arithmetic operation into the identified wrapper data destination operation in the position of a corresponding data element of the element; and The execution circuit system is used to execute the decoded instruction according to the operation code. The system of claim 8, wherein the field used for the identification of the first source operand is used to identify a vector register. The system of claim 8, wherein the field for the identification of the first source operand is used to identify a memory location. The system of claim 8, wherein the arithmetic operation is addition. The system of claim 8, wherein the arithmetic operation is multiplication. Such as the system of claim 8, wherein the arithmetic operation is division. The system of claim 8, wherein the arithmetic operation is subtraction. A method that contains: An example of decoding a single instruction to include an identification of a location for an opcode, a first packet data source operand, and one of a location for a second packet data source operand. A field identifying the location of an envelope data destination operand, where the opcode is used to indicate that an arithmetic operation execution circuitry is to be performed for each of the identified envelope data source operands. data element positions, perform the arithmetic operation on the BF16 data element in BF16 format at the data element position, and store one result of each arithmetic operation in a corresponding data element position of the identified envelope data destination operand middle; and The decoded instruction is executed according to the opcode. The method of claim 15, wherein the arithmetic operation is addition. The method of claim 15, wherein the arithmetic operation is multiplication. The method of claim 15, wherein the arithmetic operation is division. The method of claim 15, wherein the arithmetic operation is subtraction. For example, the method of any one of claim items 15 to 19 further includes: Translating the single instruction into one or more instructions of a different instruction set architecture, wherein executing the decoded instruction according to the opcode includes executing the one or more instructions of the different instruction set architecture. A computer program comprising instructions which, when executed by a computer, cause the computer to perform the method as claimed in any of the preceding claims 15 to 20.