CN104011670B - The instruction of one of two scalar constants is stored for writing the content of mask based on vector in general register - Google Patents

Abstract

According to an embodiment, take out the expression of instruction.The form of this instruction specifies its sole source operand writing mask register from single vector, and single general register is appointed as its destination.Additionally, the form of this instruction includes that the first field and the second field, this single vector of the content choice of this first field write mask register, and this single general register of the content choice of this second field.This source operand is to include the mask of writing that a multiple bit vector writes mask element, and a plurality of bit vector writes mask element corresponding to the different long numeric data element position in framework vector registor.The method also includes: occur in response to the single performing described single instruction, store data in described single general register so that based on bit vectors multiple in source operand, the content of described single general register writes whether mask element is that full 0 represents the first or second scalar constant.

Description

instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector write mask

technical field

Embodiments of the invention relate to the field of processors; more specifically, to instructions for setting scalar values in general purpose registers based on writemask contents.

Background technique

An instruction set, or instruction set architecture (ISA), is the part of a computer's architecture that involves programming, and can include native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (ISA) /O). It should be noted that in this context the term instruction generally refers to macro-instructions - i.e. given to a processor (or instruction converter which translates, transforms, morphs (eg using static binary translation, dynamic binary translation including dynamic compilation) , emulation, or otherwise convert an instruction into one or more instructions to be processed by the processor) for execution—rather than microinstructions or micro-ops—these are the processor's decoders to decode macroinstructions the result of.

An instruction set architecture is distinct from a microarchitecture, which is the internal design of the processor that implements the ISA. Processors with different microarchitectures can share a common instruction set. For example, Intel Pentium4 processors, Intel Core processors, and processors from Advanced Micro Devices, Inc. of Sunnyvale CA implement nearly identical versions of the x86 instruction set (with some extensions added to newer versions), However, has a different internal design. For example, the same register architecture of an ISA can be implemented in different ways in different microarchitectures using known techniques, including dedicated physical registers, using register renaming mechanisms such as using register alias table RAT, reorder buffer ROB, and retired register banks; one or more dynamically allocated physical registers using multiple maps and register pools), etc. Unless otherwise stated, the phrases "register architecture", "register bank", and registers refer to what is visible to the software/programmer and to the way instructions specify registers. Where specificity is required, the adjective "logically, architecturally, or software-visible" will be used to denote a register/bank within a register architecture, while a different adjective will be used to designate a register within a given microarchitecture (e.g., physical registers, reorder buffers, retirement registers, register pools).

An instruction set includes one or more instruction formats. A given instruction format defines various fields (number of bits, position of bits) to specify, among other things, the operation to be performed (operand) and the operands on which it will be operated. Thus, each instruction of the ISA is expressed using a given instruction format, and includes fields for specifying operations and operands. For example, an exemplary ADD instruction has a dedicated opcode and an instruction format that includes an opcode field that specifies the opcode and an operand field that selects operands (source 1/destination and source 2), and the ADD instruction in the instruction stream Occurrences of will have private content in the operand field that selects the private operand.

General in science, finance, automatic vectorization, RMS (recognition, mining, and synthesis)/visual and multimedia applications (e.g., 2D/3D graphics, image processing, video compression/decompression, speech recognition algorithms, and audio manipulation) often The need to perform the same operation on a large number of data items (known as "data parallelism"). Single Instruction Multiple Data (SIMD) refers to a type of instruction that causes a processor to perform the same operation on multiple data items. SIMD techniques are particularly well-suited for processors that can logically partition the bits in a register into a number of fixed-size data elements, each of which represents a separate value. For example, bits in a 256-bit register can be specified as four individual 64-bit packed data elements (quadword (Q) sized data elements), eight individual 32-bit packed data elements (double word (D ) sized data elements), sixteen individual 16-bit packed data elements (word (W) sized data elements), or thirty-two individual 8-bit data elements (byte (B) sized data elements) The source operand to be operated on. Data of this type are called packed data types or vector data types, and operands of this data type are called packed data operands or vector operands. In other words, a packed data item or vector refers to a sequence of packed data elements; and a packed data operand or vector operand is a source or destination operand of a SIMD instruction (also called a packed data instruction or vector instruction) .

As an example, one type of SIMD instruction specifies a single vector operation to be performed on two source vector operands in a longitudinal fashion to utilize the same number of data elements, in the same data element order, to produce a destination vector operand of the same size (Also known as the result vector operand). The data elements in the source vector operand are called source data elements, and the data elements in the destination vector operand are called destination or result data elements. These source vector operands are the same size and contain data elements of the same width, and as such, they contain the same number of data elements. The source data elements in the same bit positions in the two source vector operands form data element pairs (also called corresponding data elements; that is, the data elements in data element position 0 of each source operand correspond, each corresponding to the data element in data element position 1 of the source operand, etc.). The operations specified by the SIMD instruction are performed on each of the pairs of source data elements separately to generate a matching number of result data elements such that each pair of source data elements has a corresponding result data element. Since the operation is vertical and because the result vector operand is the same size, has the same number of data elements, and the result data elements are stored in the same data element order as the source vector operand, the result data element bits in the result vector operand The positions are the same as their corresponding pairs of source data elements in the source vector operands. In addition to this exemplary type of SIMD instruction, there are various other types of SIMD instructions (e.g., those with only one or more than two source vector operands; those that operate in a lateral fashion; those that generate result vectors of different sizes) number, have different size data elements, and/or have different data element order). It should be understood that the term "destination vector operand" (or destination operand) is defined as the immediate result of performing the operation specified by the instruction, including storing the destination operand in a location (register or instruction) so that it can be accessed as a source operand by another instruction (by another instruction specifying that same location).

such as those with instruction sets including x86, MMX ^™ , Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE4.1, and SSE4.2 instructions SIMD technology, such as the technology used by Core ^TM processors, achieves dramatic improvements in application performance. (Core ^TM and MMX ^TM are registered trademarks or trademarks of Intel Corporation, Santa Clara, California.). An additional set of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) which in turn uses the VEX encoding scheme has been released or published (for example, see 64 and IA-32 Architectures Software Developers Manual, October 2011; see Advanced Vector Extensions Programming Reference (Advanced Vector Extensions Programming Reference), June 2011).

Description of drawings

The present invention is best understood by referring to the following description and accompanying drawings, which illustrate embodiments of the invention. In the attached picture:

1 is a block diagram illustrating the operation of an exemplary instruction for storing one of two scalar constants in a general-purpose register based on a vector write mask, according to some embodiments of the invention;

Figure 2A is a block diagram illustrating an example of a specific "set GRP if mask is 0" instruction according to one embodiment of the present invention;

2B is a block diagram illustrating an example of a specific "set GRP if mask is not 0" instruction according to one embodiment of the present invention;

3 is a flowchart for processing each occurrence of an instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector writemask, according to some embodiments of the invention;

4 is a flow diagram of the occurrence of an instruction for executing an instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector writemask, according to some embodiments of the invention;

5 is a block diagram of a specific machine for handling the presence of an instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector writemask, according to some embodiments of the invention;

Figure 6A is a table illustrating the dependence of one-bit vector writemask elements on vector size and data element size, according to one embodiment of the present invention;

FIG. 6B is a diagram illustrating the use of a vector writemask register 640 and bit positions as a writemask as a function of vector size and data element size according to one embodiment of the invention;

7A is a block diagram illustrating an exemplary operation 760 of merging using a writemask from a 64-bit vector writemask register K1, where the vector size is 512 bits and the data element size is 32 bits, according to some embodiments of the invention. bit;

7B is a block diagram illustrating an exemplary operation 766 of zeroing using a write mask from the 64-bit write mask register K1, where the vector size is 512 bits and the data element size is 32 bits;

FIG. 8A shows pseudo-code for a "set GPR if mask is 0" instruction (KSETZB GPR _Y , K _X ) for using an 8-bit sized source operand 134, according to some embodiments of the invention;

Figure 8B shows pseudo-code for a "set GPR if mask is 0" instruction (KSETZW GPR _Y , K _X ) for using a 16-bit sized source operand 134, according to some embodiments of the invention;

Figure 8C shows pseudo-code for a "set GPR if mask is 0" instruction (KSETZD GPR _Y , K _X ) for using a 32-bit sized source operand 134, according to some embodiments of the invention;

Figure 8D shows pseudo-code for a "set GPR if mask is 0" instruction (KSETZQ GPR _Y , K _X ) for using a 64-bit sized source operand 134, according to some embodiments of the invention;

FIG. 9A shows pseudo-code for a “set GPR if mask is not 0” instruction (KSETNZB GPR _Y , K _X ) for using an 8-bit sized source operand 134, according to some embodiments of the invention;

Figure 9B shows pseudocode for a "set GPR if mask is not 0" instruction (KSETNZW GPR _Y , K _X ) for using a source operand 134 of 16-bit size, according to some embodiments of the present invention;

Figure 9C shows pseudo-code for a "set GPR if mask is not 0" instruction (KSETNZD GPR _Y , K _X ) for using a 32-bit sized source operand 134, according to some embodiments of the invention;

Figure 9D shows pseudo-code for a "set GPR if mask is not 0" instruction (KSETNZQ GPR _Y , K _X ) for using a 64-bit sized source operand 134, according to some embodiments of the invention;

Figure 10A shows an exemplary code sequence written in AVX1/AVX2 instructions to pass parameters to a function;

Figure 10B shows an exemplary code sequence for passing parameters to a function written with the KSETZW instruction according to one embodiment of the present invention;

Figure 11A shows an exemplary code sequence written in AVX1/AVX2 instructions using pointers and indirect function calls;

Figure 11B shows an exemplary code sequence using pointers and indirect function calls written with the KSETZW instruction according to one embodiment of the present invention;

Figure 12A provides a representation of the VEX C4 encoding;

Figure 12B shows which fields from Figure 12A make up the full opcode field 1274 and the base opcode field 1242;

FIG. 12C shows which fields from FIG. 12A constitute register index field 1244;

13A is a block diagram illustrating a general vector friendly instruction format and its class A instruction templates according to an embodiment of the present invention;

13B is a block diagram illustrating a generic vector-friendly instruction format and its Class B instruction templates according to an embodiment of the present invention;

14A is a block diagram illustrating an exemplary specific vector friendly instruction format according to an embodiment of the present invention;

FIG. 14B is a block diagram illustrating the fields of the specific vector friendly instruction format 1400 that make up the full opcode field 1374 according to an embodiment of the invention;

FIG. 14C is a block diagram illustrating the fields in the specific vector friendly instruction format 1400 that make up the register index field 1344 according to one embodiment of the invention;

Figure 14D is a block diagram showing the fields with the specific vector friendly instruction format 1400 that make up the extended operation field 1350 according to one embodiment of the present invention;

Figure 15 is a block diagram of a register architecture 1500 according to one embodiment of the invention;

16A 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 invention;

16B is a block diagram illustrating 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 according to an embodiment of the present invention;

FIG. 17A is a block diagram of a single processor core with its connection to an on-die interconnect network 1702 and its local subset 1704 of Level 2 (L2) cache, according to various embodiments of the invention;

Figure 17B is an expanded view of a portion of the processor core in Figure 17A in accordance with various embodiments of the invention;

18 is a block diagram of a processor 1800 that may have more than one core, may have an integrated memory controller, and may have an integrated graphics device, according to an embodiment of the invention;

Figure 19 is a block diagram of a system 1900 according to an embodiment of the invention;

Figure 20 is a block diagram of a first more specific exemplary system 2000 according to an embodiment of the present invention;

Figure 21 is a block diagram of a second more specific exemplary system 2100 according to an embodiment of the present invention;

FIG. 22 is a block diagram of a SoC 2200 according to an embodiment of the invention; and

23 is a block diagram comparing binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction translator, according to an embodiment of the present invention.

detailed description

In the following description, numerous specific details such as logic implementation, opcodes, manner of specifying operands, resource division/sharing/duplication implementation, types and interrelationships of system components, and logic division/integration selection are set forth, To provide a more thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those skilled in the art, with the included description, will be able to implement the appropriate function without undue experimentation.

It should also be understood that references such as "one embodiment," "an embodiment" or "one or more embodiments" mean that a particular feature may be included in the practice of the embodiments of the invention, but that each embodiment may This particular feature need not be included. Similarly, it should be understood that various features are sometimes grouped together in a single embodiment, figure, or description thereof in order to streamline the disclosure and to facilitate understanding of the various innovative aspects. Furthermore, when a particular feature, structure or characteristic is described with reference to one embodiment, it is considered within the purview of those skilled in the art that such feature, structure or characteristic can be implemented with other embodiments whether or not explicitly described. This method of disclosure, however, is not to be interpreted as reflecting an intention that more features than are recited in the claims are required. Rather, as the following claims reflect, each inventive aspect may have less than all features of a single disclosed embodiment. Thus, the claims following the specification are hereby expressly incorporated into this specification, with each claim standing on its own as a separate embodiment of this invention.

In the following description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact. "Connected" is used to indicate the establishment of communication between two or more elements that are coupled to each other.

The operations of the flowcharts will be described with reference to the exemplary embodiments of the block diagrams. It should be understood, however, that the operations of the flowcharts may be performed by embodiments of the invention that differ from those discussed with reference to the block diagrams, and that embodiments discussed with reference to the block diagrams may perform operations different than those discussed with reference to the flowcharts operate.

To facilitate understanding, dashed lines are used in the figures to indicate the optional nature of certain items (e.g., features not supported by a given implementation of the invention; features supported by a given implementation but used in some cases but not in others features not used below).

overview

Figure 1 is a block diagram illustrating the operation of an exemplary instruction for storing one of two scalar constants in a general purpose register based on a vector write mask, according to some embodiments of the present invention. FIG. 1 shows architectural vector write mask register 110 , architectural vector register 120 , and architectural general purpose register 130 .

Vector registers 120, individually designated _VRZ , where z can be a value from 0 to U, are used to store vector operands. The instruction set architecture includes at least some SIMD instructions that specify vector operations and have at least some SIMD instructions that select source registers and/or destination registers from these vector registers 120 (an exemplary SIMD instruction may specify that the contents of one or more of the vector registers 120 are to be A vector operation is performed, the result of which is stored in one of the vector registers 120). Different embodiments of the present invention may have different size vector registers and support more/less/different size data elements. The size of a multi-bit data element specified by a SIMD instruction (eg, byte, word, doubleword, quadword) determines the bit positioning of a "data element position" within a vector register, and the size of a vector operand determines the number of data elements. In other words, depending on the size of the data elements in the destination operand and the size of the destination operand (total number of bits in the destination operand) (or in other words, depending on the size of the destination operand and the number of data elements in the destination operand number), the bit location of the multi-bit data element position within the resulting vector operand is changed (for example, if the destination of the resulting vector operand is a vector register, the multi-bit data element within the destination vector register The bit alignment of the position changes). For example, the bit positions of multi-bit data elements differ between vector operations that operate on 32-bit data elements (data element position 0 occupies bit positions 31:0, data element position 1 occupies bit positions 63:32, and so on) and vector operations that operate on 64-bit The vector operations that operate on data elements (data element position 0 occupies bit positions 63:0, data element position 1 occupies bit positions 127:64, and so on) differ between vector operations. This is described in more detail in this paper.

Vector writemask registers 110 are individually designated as Kx, where _x can range from 0 to T, and vector writemask registers 110 are used to store a writemask, wherein the writemask includes a plurality of one-bit vector writemasks code elements, the vector writemask elements corresponding to different multi-bit data element positions within the destination vector operand. At least a portion of the SIMD instructions described above include a field for selecting a write mask from the vector write mask register 110, and the one-bit write mask element of the selected write mask controls which of the destination vector operands The data element positions reflect the results of operations on this vector. Because the bit alignment of the multi-bit data elements of the destination operand is changed in embodiments that support vector operations operating on data elements of different sizes as described above (e.g., the bit alignment of the multi-bit data elements in the are different between vector operations that operate on data elements and vector operations that operate on 64-bit data elements), so these embodiments can support a different relationship between the one-bit writemask element and the bit positioning within the destination operand ( Also known as correspondence or mapping); thus, as the bit positioning changes with the destination operand, the mapping of the bit vector writemask elements also changes.

Individually designated as GPR _Y , where Y can range from 0 to V, general purpose registers 130 are used to store operands for logical operations, arithmetic operations, address calculations, and memory pointers. The instruction set architecture includes scalar instructions that specify scalar operations to be performed on the contents of registers within general purpose registers 130 . The difference between general purpose registers 130 and vector registers 120 may vary between different embodiments of the invention (e.g., vector registers differ in total number relative to general purpose registers; vector registers differ in size compared to general purpose registers; vector registers may be An example of this is described in more detail later in this article.

Although the number of registers in each of vector writemask register 110, vector register 120, and general purpose register 130 is specified as T, U, and V, respectively, one or more of these register banks may have the same number of register. In one embodiment, the value of a given vector writemask register can be set in various ways, including as a direct result of a vector compare instruction, transferred from a GPR, or as a direct result of a logical operation between two masks to calculate.

In this figure, encircled letters are used to indicate the order of reading the items shown to facilitate understanding and, in some cases, to indicate the relationship between those items. At circled A there is an instruction 100 having a format comprising a first field 102 and a second field 104, the content of the first field 102 selecting the source register _KX and the content of the second field selecting the destination register GPR _Y. The instruction 100 belongs to the instruction set architecture, and each "occurrence" of the instruction 100 within the instruction stream will include values in the first field 102 and the second field 104, which select the architectural vector writemask register 110 and the architectural general A specific register in register 130.

The circled B represents selecting K _X from the vector write mask register 110 as the source vector write mask register. FIG. 1 alone shows a specific example of the contents 132 of the selected source vector writemask register, where the vector writemask register is a 64-bit register and where exemplary bit positions 0:15, 31, and 63 are shown. value.

Similarly, a circled C shows that GPR _Y within the general purpose register 130 is selected as the destination general purpose register.

At dashed circle D, source operand 134 is selected from the contents of source vector write mask register _KX . Dot-dash lines with dash marks at different bit positions of the source vector writemask register (specifically, the dash marks are between bit positions 7:8, 15:16, and 31:32) It is shown that the size of source operand 134 is optional in some embodiments of the invention. Different embodiments that allow selection of source operands 134 of different sizes may control this selection in various ways (eg, using different opcodes, using a value from one of the general purpose registers). Of course, alternative embodiments of the present invention may support different sizes of vector writemask registers and/or different/more/less select sizes of source operands 134 . Furthermore, some embodiments of the present invention may only support source operands that include the entire contents of the selected vector writemask register (source operand 134 is always the same size as the selected vector writemask register).

At the circled E, the source operand 134 is operated on to produce a scalar constant (this scalar constant is called the destination operand or result). Encircled E includes a first block 140 in which it is determined whether all bit vector writemask elements of the source operand are zeros. If so, a first scalar constant (eg, 1) is output (block 142); otherwise, a second scalar constant (eg, 0) is output (block 142).

At the circled F, the result (which is either the first scalar constant or the second scalar constant) is written back to the general purpose register GPR _Y . Because this is a scalar result and it is being written back to a general-purpose register, in some embodiments, based on whether the multiple one-bit writemask elements in the source operand are all zeros, the entire contents of the multi-bit general-purpose register will be Indicates the first scalar constant (eg 00...1) or the second scalar constant (eg 00...0).

As described in more detail below, instruction 100 may be implemented such that the two scalar constants are Boolean 1 and 0. As such, a Boolean value is stored in the selected GPR based on whether all bits of the vector's writemask are all zeros (in other words, the bits of the selected GPR will collectively represent a 1 or 0). In this Boolean case, instruction 100 is referred to as a "set GPR if mask is P" instruction, where K may or may not be zero. As such, Boolean values are generated based on the control flow information inherent in the vector writemask in the ISA. By placing the boolean value (eg, the carry flag) in the GPR instead of the control flow register, decisions based on the boolean value can be data flow based rather than control flow based. Specifically, control-flow-based decisions rely on instructions that change the flow of execution (eg, jumps, branches, etc.), while data-flow decisions choose between data based on the Boolean value. For example, the set GPR instruction if the mask is P is useful for parameters passed in functions (see Figure 11A-B), and for efficient pointer generation and indirect function calls for fast conditional execution of different code segments (see Figure 12A-B).

Although FIG. 1 shows a single instruction 100 that will store one of two scalar constants in a general-purpose register based on the contents of the vector writemask, it should be understood that the instruction set architecture may include multiple such designations like Instructions that operate but have different criteria (e.g., choose a different source operand size, choose between different scalar constants, store the opposite scalar constant when all bit vector writemask elements are 0), as described later in this document of. Although in some embodiments of the invention instruction 100 is shown specifying a source operand from a single vector writemask register in vector writemask register 110 as its only source operand and a single general purpose register 130 registers as its destination, however other embodiments of the invention may include additional sources (e.g., data for memory access calculations), different types of destinations (e.g., memory locations instead of registers), and/or additional A source operand and a destination (eg, an instruction that also stores the result in a condition code flag, an instruction that causes a separate operation to be performed on an additional source operand, the result of which is stored in the additional destination).

Exemplary "set GPR if mask is 0" and "set GPR if mask is not 0" instructions

FIG. 2A is a block diagram showing an example of a specific "set GPR if mask is 0" instruction according to one embodiment of the present invention, and FIG. 2B is a block diagram showing an example of a specific "if mask Block diagram of an example of the set GPR if code is not 0" instruction. Both FIGS. 2A and 2B show the source vector writemask register K _X contents 132 . Also, both figures show source operand 134A, which is bits 15:0 of bits 63:0 in source vector _writemask register KX, rather than all bits in source vector _writemask register KX. bit. Additionally, both figures include determining that all bit vector writemask elements of the writemask in the source operand 134A are all zeros. In FIG. 2A, if all bits in source operand 134A are all zeros, control passes to block 212 where GPR _Y is made equal to the scalar constant 1; otherwise, control passes to block 214 where GPR _Y Equal to the scalar constant 0. Turning to block 210 of FIG. 2B, if all bits of source operand 134A are all zeros, then control passes to block 216 where GPR _Y is made equal to the scalar constant 0; otherwise, control passes to block 218 where GPR Y is made equal to the scalar constant 0; _Y is equal to the scalar constant 1.

In some embodiments of the invention, the "set GPR if mask is 0" instruction type is called KSETZ{B,W,D,Q}GPR _Y , K _X (where { } indicates the optional source operand 134 size), and the "set GPR if mask is not 0" instruction type is called KSETNZ{B,W,D,Q}GPR _Y ,K _X .

Exemplary Streams and Processor Cores

3 is a flowchart for processing each occurrence of an instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector writemask, according to some embodiments of the invention. At block 301, a representation of such instructions is fetched. The format of this instruction designates a source operand from a single vector writemask register as its only source operand and a single general purpose register as its destination. The format of the instruction includes a first field whose contents select the single vector writemask register from a plurality of architectural vector writemask registers; and the format of the instruction includes a second field whose contents The single general purpose register is selected from a plurality of architectural general purpose registers. The source operand is a writemask comprising a plurality of one-bit vector writemask elements corresponding to different multi-bit data element locations within the architectural vector register. From block 300 , control passes to block 302 .

At block 302, in response to executing a single occurrence of the single instruction from block 301, data is stored in the single general-purpose register such that its contents represent the first One or two scalar constants. See FIGS. 2A and 2B for examples of scalar constants that may be selected and which scalar constant is selected based on whether the plurality of bit vector writemask elements are all zeros.

4 is a flow diagram of the occurrence of an instruction for executing an instruction to store one of two scalar constants in a general-purpose register based on the contents of a vector writemask, according to some embodiments of the invention. As shown in block 401, a logical OR operation is performed on the multiple bit vector writemask elements of the source operand occurrences of one such instruction. To support different source operand sizes, a set of OR trees connected by multiplexers can be used (the least significant bits making up the smallest size source operand are the input to the first OR tree, and the output of this first OR tree is the OR gate The other input of this OR gate is the output of the multiplexer, the input of this multiplexer is 0 and the output of the second OR tree, the input of the second OR tree is the lower dimension of the next dimension that constitutes the source operand One most significant bit, the multiplexer is controlled by a signal indicating whether the smallest or larger sized source operand is being used, which may be scaled to include additional sized source operands). From block 401 , control passes to block 402 . At block 402, the first or second scalar constant is multiplexed based on a control signal formed from a result of the logical OR operation and an indication of which of a plurality of types the instruction is. For example, one such type is the "set GPR if vector writemask is 0" type from Figure 2A, and another such type is "set GPR if vector writemask is not 0" from Figure 2B Types of. As a further example, if the "set GPR if vector writemask is 0" and "set GPR if vector writemask is not 0" types are represented by "type signals" of logic 1 and 0, respectively, then this type signal The control signal can be "exclusively ORed" with the result of a logical OR of the source operands (also known as "XOR" or logical exclusive OR operation); the control signal is provided to a multiplexer that selects between these two scalar constants device. In this embodiment, the two scalar constants are hardwired to 1 and 0; whereas in such an embodiment, a control signal of logic 1 selects the hardwired scalar constant 1, while a control signal of logic 0 selects the hardwired scalar constant 1. Scalar constant 0 for the wire.

Although specific discrete logic is described with reference to FIG. 4, it should be understood that different embodiments may use different logic (eg, logic value assignments to different types of instructions may be flipped and multiplexer inputs may be flipped).

Figure 5 is a block diagram of a specific machine for handling the presence of an instruction to store one of two scalar constants in a general purpose register based on the contents of a vector write mask, according to some embodiments of the invention. FIG. 5 repeats instruction 100, vector writemask register 110, vector register 120, general register 130, and circled B-C from FIG. 5 also shows processing core 500, which includes optional instruction fetch unit 510, hardware decode unit 515, and execution engine unit 520, as well as vector write mask register 110, vector register 120, and general purpose register 130. .

At circled A in FIG. 5 , a representation of instruction 100 (or a different type of instruction that stores one of two scalar constants in a general-purpose register based on the contents of the vector writemask) is provided to hardware decode unit 515 ( Optionally as a result of instruction fetch unit 510 fetching instruction 100). For the decoding unit 515, various known decoding units can be used. For example, the decode unit may decode each macroinstruction into a single wide microinstruction. As another example, the decode unit may decode some macroinstructions as a single wide microinstruction, but other macroinstructions as multiple wide microinstructions. As another example particularly suited to out-of-order processor pipelines, the decode unit may decode each macro-instruction into one or more micro-ops, each of which may be issued and executed out-of-order. Also, the decoding unit may be implemented by one or more decoders, and each decoder may be implemented as a Programmable Logic Array (PLA), as known in the art. As an example, a given decode unit may: 1) have steering logic to direct different macroinstructions to different decoders; 2) a first decoder that can decode a subset of that instruction set (but less than the second, third , and fourth decoders decode more) and generate two micro-ops each time; 3) second, third, and fourth decoders can each only decode a subset of the full instruction set, and generate only one micro-op; 4) the micro-sequencer ROM, which can decode only a subset of the full instruction set and generate four micro-ops at a time; and 5) the multiplexing logic fed by the decoder and the micro-sequencer ROM, which determines the output of which is provided to the uop queue. Other embodiments of the decode unit may have more or fewer decoders that decode more or fewer instructions and subsets of instructions. For example, one embodiment may have second, third, and fourth decoders that may each generate two uops at a time; and may include 8 uops at a time Microsequencer ROM.

At circled D, the architectural vector writemask register that provides that source operand is accessed (this could be through a dedicated physical register, a renamed physical register, a bypass path (if the content was just generated), etc.), and the The source operands are provided to the execution engine unit 520, which executes the occurrence of the instruction 100 in the instruction stream at the circled E. Specifically, in response to each occurrence, execution engine unit 520 will determine whether the multiple bit vector writemask elements of the source operand for that occurrence are all zeros, and cause data to be stored in the selected single A general purpose register such that its content represents either the first or the second scalar constant based on the determination. Execution engine unit 520 may be implemented in various ways, including the logic described above with reference to FIG. 4 .

At the circled F, the result (which is either the first scalar constant or the second scalar constant) is written back into the architectural general purpose register GPR _Y (which may be written to a dedicated physical register, a renamed physical register, etc.). Since this is a scalar result and it is being written back to a general purpose register, the contents of this general purpose register will represent either the first scalar constant or the second scalar constant based on whether the multiple one-bit writemask elements in the source operand are all zeros .

Exemplary Correspondence and Vector Write Masking Operations

Figure 6A is a table illustrating the dependence of one-bit vector writemask elements on vector size and data element size, according to one embodiment of the present invention. Vector sizes of 128-bit, 256-bit, and 512-bit are shown, but other widths are possible. Considers data element sizes of 8-bit byte (B), 16-bit word (W), 32-bit doubleword (D) or single-precision floating point, and 64-bit quadword (Q) or double-precision floating point, but other Width is also possible. As shown, when the vector size is 128 bits, 16 bits can be used for the mask when the data element size of the vector is 8 bits, and 8 bits can be used for the mask when the data element size of the vector is 16 bits, 4 bits can be used for the mask when the data element size of the vector is 32 bits, and 2 bits can be used for the mask when the data element size of the vector is 64 bits. When the vector size is 256 bits, 32 bits can be used for the mask when the packed data element width is 8 bits, and 16 bits can be used for the mask when the data element size of the vector is 16 bits. 8 bits can be used for the mask when the size is 32 bits, and 4 bits can be used for the mask when the data element size of the vector is 64 bits. As shown, when the vector size is 512 bits, 64 bits can be used for the mask when the data element size of the vector is 8 bits, and 32 bits can be used for the mask when the data element size of the vector is 16 bits, 16 bits can be used for the mask when the data element size of the vector is 32 bits, and 8 bits can be used for the mask when the data element size of the vector is 64 bits.

Figure 6B is a diagram illustrating the use of vector writemask register 640 and bit positions as a writemask depending on vector size and data element size according to one embodiment of the invention. In Figure 6B, the vector writemask register is 64 bits wide, but this is not required. Depending on the combination of vector size and data element size, either all 64 bits, or only a subset of 64 bits, can be used as a write mask. In general, when using a single per-element mask control bit, the number of bits used for masking in the vector writemask register is equal to the vector size in bits divided by the vector data element size in bits.

Several illustrative examples are shown for 512-bit vectors. That is, when the vector size is 512 bits and the vector's data element size is 64 bits, then only the lowest 8 bits of the register are used as a write mask. When the vector size is 512 bits and the vector's data element size is 32 bits, then only the lowest 16 bits of this register are used as a write mask. When the vector size is 512 bits and the vector's data element size is 16 bits, then only the lowest 32 bits of this register are used as a write mask. When the vector size is 512 bits and the vector's data element size is 8 bits, then all 64 bits of this register are used as the write mask. Although in the illustrated embodiment the lowest order subset or portion of the register is used for the mask, alternative embodiments may use some other set of bits (eg, the highest order subset). Also, although FIG. 6 only envisions a 512-bit vector size, the same principles apply to other vector sizes such as, for example, 256-bit and 128-bit.

7A is a block diagram illustrating an exemplary operation 760 of merging using a writemask from a 64-bit vector writemask register K1, where the vector size is 512 bits and the data element size is 32 bits, according to some embodiments of the invention. bit. 7A shows source A operand 705 ; source B operand 710 ; the contents of vector writemask register K1 715 (where the lower 16 bits include a mix of 1s and 0s); and destination operand 720 . Furthermore, an exemplary correspondence 700 is shown in FIG. 7A. Specifically, because the bit alignment of multi-bit data elements of the destination vector operand as described above changes between embodiments that support vector operations operating on data elements of different sizes (e.g., Bit positioning is different between vector operations that operate on 32-bit data elements and vector operations that operate on 64-bit data elements), so these embodiments can support a one-bit writemask element with a bit within the destination operand A different relationship of alignment (also known as correspondence or mapping); thus, as the bit alignment changes with the destination operand, the mapping of the bit vector writemask elements also changes. So, while correspondence 700 has only the lower 16-bit positions in vector writemask register K1 corresponding to data elements (and thus the lower 16 vector writemask element positions) (K1[0] corresponds to data element position 0 occupying bits 31:0; K1[1] corresponds to data element position 1 occupying bits 63:32; and so on), however this correspondence changes if the size of the data element is changed (e.g., If the data element is 16 bits, then K1[0] corresponds to data element position 0 occupying bits 15:0, K1[1] corresponds to data element position 1 occupying bits 32:16, and so on).

For each data element position in destination vector operand 720, it contains either the content of that data element position in source operand 710 or the The result of the operation (shown as plus).

7B is a block diagram illustrating an exemplary zero operation 766 using a write mask from the 64-bit write mask register K1, where the vector size is 512 bits and the data The element size is 32 bits. FIG. 7B includes the same items as FIG. 7A except that destination operand 720 is replaced by destination operand 764 . For each data element position in the destination vector operand 764, it contains either a 0 or the result of the operation (shown as an addition), depending on whether the corresponding bit position in the vector writemask register K1 is 0 or 1, respectively.

Exemplary "set GPR if mask is P" instruction

Figures 8A-D and Figures 9A-D illustrate the "set GPR if mask is 0" and "if mask is not Then set the pseudocode of the GPR" type instruction. FIG. 8A shows pseudocode for a "set GPR if mask is 0" instruction (KSETZB GPR _Y , K _X ) using an 8-bit sized source operand 134, according to some embodiments of the invention. FIG. 8B shows pseudocode for a "set GPR if mask is 0" instruction (KSETZW GPR _Y , K _X ) using a 16-bit sized source operand 134, according to some embodiments of the invention. FIG. 8C shows pseudocode for a "set GPR if mask is 0" instruction (KSETZD GPR _Y , K _X ) using a source operand 134 of size 32 bits, according to some embodiments of the invention. FIG. 8D shows pseudocode for a "set GPR if mask is 0" instruction (KSETZQ GPR _Y , K _X ) for using a 64-bit sized source operand 134, according to some embodiments of the invention. Figure 9A shows pseudo-code for a "set GPR if mask is not 0" instruction (KSETNZB GPR _Y , K _X ) using an 8-bit sized source operand 134, according to some embodiments of the invention. FIG. 9B shows pseudocode for a "set GPR if mask is not zero" instruction (KSETNZW GPR _Y , K _X ) using a source operand 134 of size 16 bits, according to some embodiments of the invention. FIG. 9C shows pseudocode for a "set GPR if mask is not zero" instruction (KSETNZD GPR _Y , K _X ) using a source operand 134 of size 32 bits, according to some embodiments of the invention. FIG. 9D shows pseudocode for a "set GPR if mask is not zero" instruction (KSETNZQ GPR _Y , K _X ) for using a 64-bit sized source operand 134, according to some embodiments of the invention.

Exemplary code sequence using the "set GPR if mask is P" instruction

As mentioned earlier, by placing a boolean value (eg, the carry flag) in a GPR instead of a control flow register, decisions based on that boolean value can be data flow based rather than control flow based. Specifically, control-flow-based decisions rely on instructions that change the flow of execution (eg, jumps, branches, etc.), while data-flow decisions choose between data based on the Boolean value. For example, the set GPR instruction if the mask is P is useful for parameters passed in functions (see Figure 10A-B), and for efficient pointer generation and indirect function calls for fast conditional execution of different code segments of (see Figure 11A-B). Specifically, Figures 10A and 11A show pseudo-assembly code sequences written with AVX1/AVX2 instructions (see 64 and IA-32 Architectures Software Developer's Handbook, October 2011; see also Advanced Vector Extensions Programming Reference, June 2011).

Figure 10A shows an exemplary code sequence written in AVX1/AVX2 instructions to pass parameters to a function. The sequence includes two function calls to a function called "foo". The first call to foo passes A, B, and 1 as arguments, while the second call passes A, B, and 0. The sequence uses control flow instructions to choose between these two function calls. Specifically, the code sequence begins with VMOVAPS, which moves aligned packed single-precision floating-point data elements from A (which can be a ymm register or a 256-bit memory location) to ymm1. Next, VCMPPS uses bits 4:0 of imm8 as a comparison predicate (where bits 4:0 define the type of comparison and bits 5:7 are reserved; and in Figure 10A indicate less than (LT))) to The packed single precision floating point value in B (which can be a ymm register or a 256-bit memory location) is compared with ymm1. Next, VPTEST sets the 0 flag (ZF) and the carry flag (CF) (which are the condition code flags in the EFLAGS register) according to the bitwise logical AND and logical ANDN (ANDNOT, NAND) of the source (if in the bitwise AND The ZF flag is set if all bits are all 0 in the result of bitwise ANDN; the CF flag is set if all bits are all 0 in the result of bitwise ANDN). Next, if ZF is equal to 0, JZ jumps to the destination "Output". This conditional branch (JZ instruction) can result in a mis-asserted branch and thus affect performance. If no jump is performed, the function calls foo(A,B,1) and jmp end are processed. If a jump is made, the function calls foo(A,B,0) and End: (end:) are processed.

Figure 10B shows an exemplary code sequence written with the KSETZW instruction to pass parameters to a function, according to one embodiment of the present invention. This sequence includes only one function call to foo and no JZ instruction, but achieves the same result as at the sequence of Figure 10A. Specifically, this code sequence begins with the same VMOVAPS instruction. Next, a new type of VCMPPS instruction is used. This new type of VCMPPS instruction passes B (which can be a ymm register or a float32 vector memory location ) is compared with ymm1 and the result (a quadword writemask of all 1s (comparison true) or all 0s (comparison false)) is placed back into K1. Next, if the least significant word of K1 is all zeros; then KSETZW sets rax(GPR) to the scalar constant 1; otherwise, zeros rax. Next, a single function call to foo is performed, passing A, B, and rax as arguments. Thus, setting rax to a scalar constant 1 or a scalar constant 0 allows rax to be used to pass 1 or 0 to foo with a single function call. Thus, the sequence in Figure 10B achieves the same result as Figure 10A, but does so with data flow decisions rather than control flow decisions; and thus Figure 10B avoids conditional branches (JZ instructions) and reduces code size .

Figure 11A shows an exemplary code sequence written in AVX1/AVX2 instructions using pointers and indirect function calls. The sequence in Figure 11A is the same as in Figure 10A, except that foo(A,B,1) is replaced by LEA rbx,foo and (*rbx)(A[],B[],C[]); while foo(A, B,0) is replaced by LEA rbx,foo+8 and (*rbx)(A[],B[],C[]+size), where the capital letters in front of "[]" (such as A[]) represent points to pointer to the array. The LEA instruction loads the effective address into rbx(GPR); the first and second occurrences of LEA load the effective addresses of foo and foo+8 into rbx, respectively. This causes the two instructions following the occurrence of the LEA instruction to make an indirect function call to foo or foo+8 using a pointer (see (*rbx)); and the two function calls differ by passing the arguments C[] or C[ ]+size; where "size" is a value in memory or a constant (via #define). Also, this conditional branch (JZ instruction) can result in a mis-asserted branch and thus affect performance.

Figure 1 IB shows an exemplary code sequence written with the KSETZW instruction using pointers and indirect function calls according to one embodiment of the present invention. Similar to FIG. 10B, the sequence in FIG. 11B includes only one function call and no JZ instruction, but achieves the same result as the sequence of FIG. 11A. The sequence in Figure 11B is the same as in Figure 10B, except that foo(A,B,rax) has been replaced by LEA rbx,foo+rax*8; IMULrax,size(size) and (*rbx)(A[],B[] , C[]+rax) instead. The presence of the LEA instruction loads into rbx the effective address of foo+rax*8, where rax is a scalar constant 0 or 1 depending on the result of the KSETZW instruction; 8 (computed foo+1*8) effective address to load rbx. The IMUL instruction multiplies two signed integers; the presence of the IMUL instruction multiplies the contents of rax by size (size) and stores the result in rax; so rax=rax*size; in other words, make rax equal to 0*size or 1*size. As a result, (*rbx)(A[],B[],C[]+rax) makes an indirect function call to foo or foo+8 and passes C[] or C[]+8 respectively as arguments. So setting rax and rbx to scalar constant 0 or scalar constant 1 allows rax and rbx to generate different effective addresses and different parameter values with a single function call. Thus, the sequence in FIG. 11B achieves the same result as FIG. 11A , but through data flow decisions instead of control flow decisions; and thus FIG. 11B avoids conditional branches (JZ instructions) and reduces code size.

Exemplary Instruction Encoding

Embodiments of the instructions described herein may be embodied in different formats. Additionally, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instructions may execute on these systems, architectures, and pipelines, but are not limited to the systems, architectures, and pipelines detailed.

VEX code

As an example, the VEX C4 encoding will be described, and one example of how the various "set GPR if mask is P" instructions can be encoded into the encoding will be described.

Figure 12A provides a representation of the VEX C4 encoding. This code includes the following fields (see Advanced Vector Extensions Programming Reference, June 2011):

VEX prefix (bytes 0-2) 1202 - encoded in three bytes.

Format field 1240 (VEX byte 0, bits [7:0]) - The first byte (VEX byte 0) is the format field 1240 and this format field 1240 contains an explicit C4 byte value (used to distinguish the C4 instruction format unique value).

The second-third bytes (VEX bytes 1-2) include a number of bit fields providing specific capabilities. in particular:

The REX field 1205 (VEX byte 1, bits [7-5]) is composed of the VEX.R bit field (VEX byte 1, bits [7]–R), the VEX.X bit field (VEX byte 1, bits [6] ]–X) and the VEX.B bit field (VEX byte 1, bits [5]–B). The other fields of these instructions encode the lower three bits of the register index (rrr, xxx, and bbb) as known in the art, whereby Rrrr, Xxxx, and Bbbb can be increased by adding VEX.R, VEX.X, and VEX.B to form.

Opcode Map Field 1215 (VEX byte 1, bits [4:0] - mmmmm) - its content encodes the implicit leading opcode bytes.

VEX.W (VEX byte 2, bits [7] - W) - is represented by the notation VEX.W and provides different functions depending on the instruction.

VEX.vvvv1220 (VEX byte 2, bits [6:3]-vvvv) - The role of VEX.vvvv can include the following: 1) The VEX.vvvv pair specifies the first source register operation in the form of inversion (1's complement) and valid for instructions with two or more source operands; 2) VEX.vvvv encodes a destination register operand specified in 1's complement for a specific vector displacement; or 3) VEX .vvvv does not encode any operands, this field is reserved, and should contain 1111b.

VEX.L1268 size field (VEX byte 2, bits [2]-L) - if VEX.L = 0, it indicates a 128-bit vector; if VEX.L = 1, it indicates a 256-bit vector.

Prefix encoding field 1225 (VEX byte 2, bits [1:0]-pp) - provides additional bits for the base operation field.

Real opcode field 1230 (byte 3)

This is also known as the opcode byte. Part of the opcode is specified in this field.

MOD R/M field 1240 (byte 4)

Modifier field 1246 (MODR/M.MOD, bits [7-6] - MOD field 1242).

MODR/M.reg field 1244, bits [5-3] - the role of the ModR/M.reg field can be summarized into two cases: ModR/M.reg is to the destination register operand or the source register operand (in Rfff rrr) for encoding; or ModR/M.reg is considered an opcode extension and is not used to encode any instruction operands.

MODR/M.r/m field 1246, bits [2-0] - The role of the ModR/M.r/m field may include the following: ModR/M.r/m encodes an instruction operand that references a memory address; or ModR/M.r/m pairs Destination register operand or source register operand to encode.

Scale, Index, Base (SIB) byte (byte 5)

Scale Field 1260 (SIB.SS, bits [7-6] - The content of the Scale Field 1260 is used for memory address generation.

SIB.xxx1254 (bits[5-3]) and SIB.bbb1256 (bits[2-0]) - The contents of these fields have been referenced previously for register indices Xxxx and Bbbb.

Offset byte (byte 6 or bytes 6-9)

Immediate 1272 (IMM8) (starts at byte 7 or 10)

FIG. 12B shows which fields from FIG. 12A make up the full opcode field 1274 and the base opcode field 1242 . Figure 12C shows which fields from Figure 12A constitute the register index field.

example code

KSETZ{B,W,D,Q}GPR _Y ,K _X and KSETNZ{B,W,D,Q}GPR _Y ,K _X

Format Field 1240 = C4

VEX.R and MODR/M.reg field 1244 (Rrrr) - identifies GPR _Y

VEX.X and VEX.B – ignored

Opcode Mapping Field 1215 = 0F

VEX.W=x (ignored; alternatively select size of GPR _Y - 0 for EAX and 1 for RAX).

VEX.vvvv1220 – ignored

VEX.L=0

Prefix code field 1225 = 00

Real opcode field 1230 - indicates set on 0 or set on 1; indicates B, W, D, Q

_MODR /Mr/m field 1246 - Indicates Kx. In other words, a bit that was historically used for an instruction that accesses a different register, is used herein to access the architectural vector writemask register.

SIB – ignored (if present)

Offset field 1262 – ignored (if present)

immediate value (IMM8) – ignored if present

Generic Vector Friendly Instruction Format

A vector friendly instruction format is an instruction format suitable for vector instructions (eg, there are specific fields dedicated to vector operations). Although an embodiment is described in which both vector and scalar operations are supported through a vector friendly instruction format, alternative embodiments use only vector operations through a vector friendly instruction format.

13A-13B are block diagrams illustrating a generic vector friendly instruction format and its instruction templates according to an embodiment of the present invention. 13A is a block diagram illustrating a general vector friendly instruction format and a class A instruction template thereof according to an embodiment of the present invention; and FIG. 13B is a block diagram illustrating a general vector friendly instruction format and a class B instruction template thereof according to an embodiment of the present invention block diagram. Specifically, class A and class B instruction templates are defined for the general vector friendly instruction format 1300 , both of which include no memory access 1305 instruction templates and memory access 1320 instruction templates. The term generic in the context of a vector friendly instruction format refers to an instruction format that is not bound to any specialized instruction set.

Although will be described where the vector-friendly instruction format supports the following: 64-byte vector operand length (or size) with 32-bit (4-byte) or 64-bit (8-byte) data element width (or size) (and thus, 64-byte vector consisting of 16 dword-sized elements or alternatively 8 dword-sized elements), 64-byte vector operand length (or size) with 16 bits (2 bytes) or 8 bits (1 byte) Data element width (or size), 32-byte vector operand length (or size) and 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-word section) data element width (or size), and 16-byte vector operand length (or size) with 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1 byte) data element width (or size) of the present invention, but alternative embodiments may support larger, smaller, and/or different vector operand sizes (e.g., 256 byte vector operands) with a larger, smaller, or different data element width (for example, a 128-bit (16-byte) data element width).

The class A instruction templates in FIG. 13A include: 1) In the instruction templates without memory access 1305, the instruction templates showing all rounding (round) control type operations 1310 without memory access, and the data transformation type without memory access The instruction template of operation 1315; and 2) within the instruction template of memory access 1320, the instruction template of time-sensitive 1325 of memory access and the instruction template of non-time-sensitive 1330 of memory access are shown. The class B instruction templates in FIG. 13B include: 1) In the instruction templates of no memory access 1305, the instruction templates of the partial rounding control type operation 1312 showing the write mask control of no memory access and the write mask of no memory access and 2) within the instruction templates for memory access 1320, the instruction template for writemask control 1327 for memory access is shown.

The generic vector friendly instruction format 1300 includes the following fields listed below in the order shown in Figures 13A-13B.

Format field 1340 - A specific value in this field (instruction format identifier value) uniquely identifies the vector friendly instruction format, and thereby identifies that the instruction appears in the vector friendly instruction format in the instruction stream. Thus, this field is optional in the sense that an instruction set that only has a generic vector friendly instruction format is not required.

Base Operations field 1342 - its content distinguishes between different base operations.

Register Index Field 1344 - its content specifies the location of the source or destination operand in a register or in memory either directly or through address generation. These fields include a sufficient number of bits to select N registers from a bank of PxQ (eg, 32x512, 16x128, 32x1024, 64x1024) registers. Although in one embodiment N can be as high as three source and one destination registers, alternative embodiments can support more or fewer source and destination registers (for example, up to two sources can be supported, where the A source also acts as a destination, supporting up to three sources, where one of these sources also acts as a destination, supporting up to two sources and a destination).

Modifier field 1346 - its content distinguishes instructions that appear in the general vector instruction format that specify memory access from instructions that appear in the general vector instruction format that do not specify memory access; Access 1320 among instruction templates. Memory access operations read and/or write to the memory level (in some cases using values in registers to specify source and/or destination addresses), while non-memory access operations do not (e.g., source and/or destination ground is a register). Although in one embodiment this field also selects between three different ways to perform memory address calculations, alternative embodiments may support more, fewer or different ways to perform memory address calculations.

Extended Operation Field 1350 - its content distinguishes which of a variety of different operations to perform in addition to the base operation. This field is context specific. In one embodiment of the invention, this field is divided into a class field 1368 , an alpha field 1352 , and a beta field 1354 . Extended operations field 1350 allows multiple sets of common operations to be performed in a single instruction instead of 2, 3 or 4 instructions.

Scale field 1360 - its content allows scaling of the content of the index field for memory address generation (eg, for address generation using 2 ^scale *index+base).

Displacement field 1362A - its content is used as part of memory address generation (eg, for address generation using 2 ^scale *index+base+displacement).

Displacement Factor Field 1362B (note that the concatenation of Displacement Field 1362A directly on Displacement Factor Field 1362B indicates the use of one or the other) - whose content is used as part of address generation, which specifies displacement scaled by the size (N) of the memory access factor, where N is the number of bytes in the memory access (e.g. for address generation using a displacement of 2 ^scale *index+base+scale). Redundant low-order bits are ignored, and thus the contents of the displacement factor field are multiplied by the total memory operand size to generate the final displacement used in computing the effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 1374 (described later herein) and the data manipulation field 1354C. They are optional in the sense that displacement field 1362A and displacement factor field 1362B may not be used for the instruction template of no memory access 1305 and/or different embodiments may implement only one or neither of the two.

Data Element Width Field 1364 - its content distinguishes which of a number of data element widths is used (in some embodiments for all instructions, in other embodiments only for some instructions). This field is optional in the sense that it is not required if only one data element width is supported and/or some aspect of the opcode is used to support data element widths.

Writemask field 1370 - its content controls on a per data element position basis whether the data element position in the destination vector operand reflects the results of base and augment operations. Class A instruction templates support coalescing-writemasking, while class B instruction templates support both coalescing and zeroing writemasking. When combined, a vector mask allows to protect any set of elements in the destination from being updated during the execution of any operation (specified by the base and augmentation operations), in another embodiment, maintaining the one in which the corresponding mask bit has 0 The old value of each element of the destination. Conversely, 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 and augmentation operations). In one embodiment, the elements of the destination are in the corresponding mask bits Has a value of 0 and is set to 0. A subset of this functionality is the ability to control the vector length of the operations performed (i.e., the span from the first to the last element to be modified), however, it is not necessary that the modified elements be contiguous. Thus, the writemask field 1370 allows partial vector operations, including loads, stores, arithmetic, logic, and the like. Although described in which the content of writemask field 1370 selects one of a number of writemask registers that contains the writemask to use (and thus indirectly identifies which one to perform mask), but alternate embodiments instead or in addition allow the contents of the mask write field 1370 to directly specify the mask to be performed.

Immediate field 1372 - its content allows specification of an immediate. It is optional in the sense that it is not present in implementations that do not support the general vector friendly format for immediates and is not present in instructions that do not use immediates.

Class field 1368 - its content distinguishes between different classes of instructions. Referring to Figures 13A-B, the content of this field selects between Type A and Type B instructions. In Figures 13A-B, rounded squares are used to indicate that a dedicated value exists in the field (eg, Class A 1368A and Class B 1368B for class field 1368, respectively, in Figures 13A-B).

Type A instruction template

In the case of an instruction template for a class A non-memory access 1305, the alpha field 1352 is interpreted as its content to distinguish which of the different types of augmented operations are to be performed (e.g., a round-type operation 1310 for a no-memory access and a no-memory The instruction template of the accessed data transformation type operation 1315 specifies the RS field 1352A of rounding 1352A.1 and data transformation 1352A.2) respectively, while the beta field 1354 distinguishes which of the specified types of operations is to be performed. In the no memory access 1305 instruction template, the scale field 1360, displacement field 1362A, and displacement scale field 1362B do not exist.

Instruction templates with no memory access - all round-controlled operations

In the instruction template for all round-control-type operations without memory access 1310, the beta field 1354 is interpreted as a round-control field 1354A whose content provides static rounding. Although in the described embodiment of the invention the rounding control field 1354A includes the suppress all floating point exceptions (SAE) field 1356 and the rounding operation control field 1358, alternative embodiments may support, and may encode, both of these concepts as The same fields or only one or the other of these concepts/fields (eg, there may be only the rounding operation control field 1358).

SAE field 1356 - its content distinguishes whether exception event reporting is disabled; when the content of SAE field 1356 indicates suppression is enabled, the given instruction does not report any kind of floating point exception flag and does not raise any floating point exception handler.

Rounding operation control field 1358 - its content distinguishes which of a set of rounding operations is performed (eg, round up, round down, round towards zero, and round to nearest). Thus, the rounding operation control field 1358 allows the rounding mode to be changed on a per instruction basis. In one embodiment of the invention where the processor includes a control register for specifying the rounding mode, the content of the rounding operation control field 1350 takes precedence over the register value.

Instruction templates without memory access - data transformation type operations

In the instruction template for a data transformation type operation 1315 with no memory access, the β field 1354 is interpreted as a data transformation field 1354B whose content distinguishes which of a number of data transformations to perform (e.g., no data transformation, mixing, broadcasting) .

In the case of an instruction template for a class A memory access 1320, the alpha field 1352 is interpreted as an eviction hint field 1352B whose content distinguishes which of the eviction hints to use (in FIG. The instruction template of the memory access non-timeliness 1330 specifies timeliness 1352B.1 and non-timeliness 1352B.2), respectively, and the β field 1354 is interpreted as a data manipulation field 1354C, whose content distinguishes that a large number of data manipulation operations (also called which of the primitives (eg, no manipulation, broadcast, source upcast, and destination downcast). The instruction template for memory access 1320 includes scale field 1360, and optionally displacement field 1362A or displacement scale field 1362B.

Vector memory instructions use conversion support to perform vector loads from memory and store vectors to memory. Like regular vector instructions, vector memory instructions transfer data to and from memory in a data-element fashion, where the actual elements transferred are specified by the contents of the vector mask selected as the write mask.

Instruction Templates for Memory Access - Timing

Time-sensitive data is data that is likely to be reused soon enough to benefit from caching. However, this is a hint and different processors may implement it differently, including ignoring the hint entirely.

Instruction templates for memory accesses - not time sensitive

Non-time-sensitive data is data that is unlikely to be reused quickly enough to benefit from caching in the first level cache and should be given priority for eviction. However, this is a hint and different processors may implement it differently, including ignoring the hint entirely.

Type B instruction template

In the case of a Type B instruction template, the alpha field 1352 is interpreted as a writemask control (Z) field 1352C, the content of which distinguishes whether the writemask controlled by the writemask field 1370 should be coalesced or zeroed.

In the case of an instruction template for class B non-memory access 1305, part of the β field 1354 is interpreted as the RL field 1357A, whose content distinguishes which of the different types of extended operations to perform (e.g., write masking for no memory access The instruction template of the code control section rounding control type operation 1312 and the instruction template of the write mask control VSIZE type operation 1317 without memory access specify rounding 1357A.1 and vector size (VSIZE) 1357A.2), respectively, while the β field 1354 The remainder of the distinguishes which of the specified types of operations is to be performed. In the no memory access 1305 instruction template, the scale field 1360, displacement field 1362A, and displacement scale field 1362B do not exist.

In instruction templates for writemask-controlled partial rounding-controlled operations with no memory access 1310, the remainder of the beta field 1354 is interpreted as the rounding operation field 1359A, and exception reporting is disabled (given instruction does not report any kind of floating-point exception flags and does not raise any floating-point exception handlers).

Rounding operation control field 1359A - as rounding operation control field 1358 only, its content distinguishes which of a set of rounding operations to perform (e.g., round up, round down, round toward zero, and round to nearest ). Thus, the rounding operation control field 1359A allows the rounding mode to be changed on a per instruction basis. In one embodiment of the invention where the processor includes a control register for specifying the rounding mode, the content of the rounding operation control field 1350 takes precedence over the register value.

In the instruction template for the writemask control VSIZE type operation 1317 with no memory access, the remainder of the β field 1354 is interpreted as a vector length field 1359B whose content distinguishes which of a number of data vector lengths to execute (e.g., 128 words section, 256 bytes, or 512 bytes).

In the case of the instruction template for class B memory access 1320, a portion of the β field 1354 is interpreted as a broadcast field 1357B whose content distinguishes whether a broadcast-type data manipulation operation is to be performed, while the rest of the β field 1354 is interpreted as a vector length field 1359B. The instruction template for memory access 1320 includes scale field 1360, and optionally displacement field 1362A or displacement scale field 1362B.

For the generic vector friendly instruction format 1300 , a full opcode field 1374 is shown, including a format field 1340 , a base operation field 1342 , and a data element width field 1364 . Although an embodiment is shown in which the full opcode field 1374 includes all of these fields, the full opcode field 1374 includes less than all of these fields in embodiments that do not support all of these fields. Full opcode field 1374 provides the operation code (opcode).

Extended operation field 1350, data element width field 1364, and writemask field 1370 allow these features to be specified on a per-instruction basis in a generic vector friendly instruction format.

The combination of the write mask field and the data element width field creates various types of instructions that allow the mask to be applied based on different data element widths.

The various instruction templates found within Class A and Class B are beneficial in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only class A, only class B, or may support both classes. For example, a high-performance general-purpose out-of-order core expected for general-purpose computing might only support class B, a core expected primarily for graphics and/or scientific (throughput) computing might only support class A, and a core expected for both The cores of ® may support both (of course, cores with some mix of templates and instructions from both classes, but not all templates and instructions from both classes are within the purview of this invention). Likewise, a single processor may include multiple cores, all supporting the same class or where different cores support different classes. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores expected to be primarily used for graphics and/or scientific computing may only support class A, while one or more of the general-purpose cores may It is a high-performance general-purpose core that supports class B out-of-order execution and register renaming for general-purpose computing. Another processor without a separate graphics core may include one or more general-purpose in-order or out-of-order cores that support both class A and class B. Of course, features from one class may also be implemented in other classes in different embodiments of the invention. A program written in a high-level language can be imported (e.g., time-only or statistically compiled) into a variety of different executable forms, including: 1) a form with only the classes of instructions supported by the target processor for execution; or 2) To have replacement routines written using different combinations of instructions of all classes and in the form of control flow code that selects these routines to execute based on the instructions supported by the processor that is currently executing the code.

Exemplary Specific Vector Friendly Instruction Format

Figure 14 is a block diagram illustrating an exemplary specific vector friendly instruction format according to an embodiment of the present invention. Figure 14 shows a specific vector friendly instruction format 1400 that is specific in the sense that it specifies the location, size, interpretation, and order of the fields, and the values of some of those fields. The specific vector friendly instruction format 1400 can be used to extend the x86 instruction set, and thus some fields are similar or identical to those used in the existing x86 instruction set and its extensions (eg, AVX). The format remains consistent with the prefix encoding field, real opcode byte field, MOD R/M field, SIB field, displacement field, and immediate field of the existing x86 instruction set with extensions. The fields from FIG. 14 to which the fields from FIG. 13 map are shown.

It should be understood that although embodiments of the invention have been described with reference to the specific vector friendly instruction format 1400 in the context of the general vector friendly instruction format 1300 for purposes of illustration, the invention is not limited to the specific vector friendly instruction format 1400, the stated except places. For example, the general vector friendly instruction format 1300 contemplates various possible sizes of various fields, while the specific vector friendly instruction format 1400 is shown with fields of specific sizes. As a specific example, although the data element width field 1364 is shown as a one-bit field in the specific vector friendly instruction format 1400, the invention is not so limited (i.e., the general vector friendly instruction format 1300 contemplates other sizes for the data element width field 1364) .

The generic vector friendly instruction format 1300 includes the following fields listed below in the order shown in Figure 14A.

EVEX prefix (bytes 0-3) 1402 - Encoded in four bytes.

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

The second-fourth bytes (EVEX bytes 1-3) include a number of bit fields providing specific capabilities.

REX field 1405 (EVEX byte 1, bits [7-5]) - composed of the EVEX.R bit field (EVEX byte 1, bits [7]–R), the EVEX.X bit field (EVEX byte 1, bits [7] 6]–X) and (1357BEX byte 1, bit[5]–B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using 1's complement form, ie ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of these instructions encode the lower three bits of the register index (rrr, xxx, and bbb) as known in the art, whereby Rrrr, Xxxx, and Bbbb can be changed by adding EVEX.R, EVEX.X and EVEX.B to form.

REX' field 1310 - This is the first part of the REX' field 1310 and is the EVEX.R' bitfield (EVEX byte 1, bits [4]–R'). In one embodiment of the invention, this bit is stored in bit-reversed format along with the other bits indicated below to distinguish (in the known x86 32-bit mode) from the BOUND instruction whose opcode byte is 62, But the value 11 in the MOD field is not accepted in the MOD R/M field (described below); alternate embodiments of the invention do not store this indicated bit, along with other indicated bits, in inverted format. A value of 1 is used to encode the lower 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and other RRRs from other fields.

Opcode Mapping Field 1415 (EVEX byte 1, bits [3:0] - mmmm) - its content encodes the implicit leading opcode byte (OF, 0F38, or 0F3).

Data Element Width Field 1364 (EVEX byte 2, bits [7] - W) - denoted by the notation EVEX.W. EVEX.W is used to define the granularity (size) of a data type (32-bit data element or 64-bit data element).

EVEX.vvvv1420 (EVEX byte 2, bits [6:3]-vvvv) - The role of EVEX.vvvv may include the following: 1) EVEX.vvvv pairs the first source register specified in inverted (1's complement) form Operands are encoded and valid for instructions with two or more source operands; 2) EVEX.vvvv encodes a destination register operand specified in 1's complement for a specific vector displacement; or 3) EVEX .vvvv does not encode any operands, this field is reserved, and should contain 1111b. Thus, the EVEX.vvvv field 1420 encodes the 4 low order bits of the first source register specifier stored in inverted (1's complement) form. According to this instruction, an additional distinct EVEX bit field is used to extend the specifier size to 32 registers.

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

Prefix encoding field 1425 (EVEX byte 2, bits [1:0]-pp) - Provides additional bits for the base operation field. In addition to providing support for legacy SSE instructions in EVEX prefix format, this also has the benefit of compressing SIMD prefixes (EVEX prefixes require only 2 bits instead of bytes to express SIMD prefixes). In one embodiment, to support legacy SSE instructions using SIMD prefixes (66H, F2H, F3H) in legacy format and in EVEX prefixed format, these legacy SIMD prefixes are encoded into the SIMD prefix encoding field; The PLA to the decoder was previously extended to a legacy SIMD prefix (so the PLA can execute these legacy instructions in both legacy and EVEX formats without modification). While newer instructions may extend the contents of the EVEX prefix encoding field directly as an opcode, for consistency certain embodiments extend in a similar fashion, but allow different meanings to be specified by these legacy SIMD prefixes. An alternate embodiment could redesign the PLA to support 2-bit SIMD prefix encoding, and thus not require extensions.

Alpha field 1352 (EVEX byte 3, bit [7] - EH, also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.writemask control, and EVEX.N; also shown with alpha) - As stated previously, this field is context specific.

Beta field 1354 (EVEX byte 3, bits [6:4] - SSS, also known as EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; also shown as having βββ) - As stated previously, this field is content specific.

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

Writemask field 1370 (EVEX byte 3, bits [2:0]-kkk) - its content specifies the register index in the writemask register, as previously described. In one embodiment of the invention, a dedicated value of EVEX.kkk=000 has an implicit no write mask for a particular instruction (this can be done in various ways, including using a write mask hardwired to all or bypassing the mask special behavior of the hardware) implementation of the code hardware.

The real opcode field 1430 (byte 4) is also referred to as the opcode byte. Part of the opcode is specified in this field.

MOD R/M field 1440 (byte 5 ) includes MOD field 1442 , Reg field 1444 , and R/M field 1446 . As previously described, the contents of the MOD field 1442 distinguish between memory access and non-memory access operations. The role of the Reg field 1444 can be reduced to two cases: to encode either a destination register operand or a source register operand; or to be treated as an opcode extension and not used to encode any instruction operands. The role of the R/M field 1446 may include the following: encoding an instruction operand that references a memory address; or encoding a destination register operand or a source register operand.

Scale Index Base (SIB) Byte (Byte 6) - As previously described, the contents of the scale field 1350 are used for memory address generation. SIB.xxx1454 and SIB.bbb1456 - The contents of these fields have been previously referenced for register indices Xxxx and Bbbb.

Displacement field 1362A (bytes 7-10) - When the MOD field 1442 contains 10, bytes 7-10 is the displacement field 1362A, and it works like a traditional 32-bit displacement (disp32), and at byte granularity.

Displacement Factor Field 1362B (Byte 7) - When the MOD field 1442 contains 01, Byte 7 is the Displacement Factor field 1362B. The location of this field is the same as that of the legacy x86 instruction set 8-bit displacement ( disp8 ), which works at byte granularity. Since disp8 is sign-extended, it can only be addressed between -128 and 127 byte offsets, and in terms of a 64-byte cache line, disp8 usage can be set to only four useful values 8 bits for -128, -64, 0, and 64; since a larger range is often needed, disp32 is used; however, disp32 requires 4 bytes. In contrast to disp8 and disp32, the displacement factor field 1362B is a reinterpretation of disp8; when the displacement factor field 1362B is used, the actual displacement is determined by multiplying the contents of the displacement factor field by the size (N) of the memory operand access. This type of displacement is called disp8*N. This reduces the average instruction length (single byte for bit shifts but with a much larger range). This compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and thus the redundant low-order bits of the address offset need not be encoded. In other words, the displacement factor field 1362B replaces the traditional x86 instruction set 8-bit displacement. Thus, the displacement factor field 1362B is encoded in the same way as an x86 instruction set 8-bit displacement (so no change in the ModRM/SIB encoding rules), with the only difference that disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules, or only the encoded length, in the interpretation of the displacement value by the hardware (which requires the displacement to scale the size of the memory operand to obtain the byte-wise address offset).

The immediate field 1372 operates as previously described.

full opcode field

Figure 14B is a block diagram illustrating the fields of the specific vector friendly instruction format 1400 that make up the full opcode field 1374, according to an embodiment of the invention. Specifically, full opcode field 1374 includes format field 1340 , base operation field 1342 , and data element width (W) field 1364 . The base operation field 1342 includes a prefix encoding field 1425 , an opcode mapping field 1415 , and a real opcode field 1430 .

register index field

Figure 14C is a block diagram illustrating the fields of the specific vector friendly instruction format 1400 that make up the register index field 1344 according to one embodiment of the invention. Specifically, the register index field 1344 includes a REX field 1405, a REX' field 1410, a MODR/M.reg field 1444, a MODR/M.r/m field 1446, a VVVV field 1420, a xxx field 1454, and a bbb field 1456.

Extended Action Field

Figure 14D is a block diagram illustrating the fields of the specific vector friendly instruction format 1400 that make up the extended operation field 1350 according to one embodiment of the present invention. When the class (U) field 1368 contains 0, it expresses EVEX.U0 (A class 1368A); when it contains 1, it expresses EVEX.U1 (B class 1368B). When U=0 and MOD field 1442 contains 11 (expressing no memory access operation), alpha field 1352 (EVEX byte 3, bits [7] - EH) is interpreted as rs field 1352A. When the rs field 1352A contains 1 (round 1352A.1), the beta field 1354 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the round control field 1354A. Rounding control field 1354A includes a one-bit SAE field 1356 and a two-bit rounding operation field 1358 . When the rs field 1352A contains 0 (data transform 1352A.2), the beta field 1354 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the three-bit data transform field 1354B. When U=0 and the MOD field 1442 contains 00, 01, or 10 (expressing a memory access operation), the alpha field 1352 (EVEX byte 3, bits [7] - EH) is interpreted as the eviction hint (EH) field 1352B and the beta Field 1354 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a three-bit data manipulation field 1354C.

When U=1, alpha field 1352 (EVEX byte 3, bits [7] - EH) is interpreted as writemask control (Z) field 1352C. When U=1 and MOD field 1442 contains 11 (expressing no memory access operation), part of β field 1354 (EVEX byte 3, bits [4] - S0) is interpreted as RL field 1357A; 1357A.1), the remainder of the β field 1354 (EVEX byte 3, bits [6-5]–S2-1) is interpreted as the rounding operation field 1359A, while the RL field 1357A contains 0 (VSIZE1357.A2 ), the rest of the β field 1354 (EVEX byte 3, bits [6-5]-S2-1) is interpreted as the vector length field 1359B (EVEX byte 3, bits [6-5]-L1-0) . When U=1 and the MOD field 1442 contains 00, 01, or 10 (expressing a memory access operation), the β field 1354 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the vector length field 1359B (EVEX word section 3, bits[6-5]–L1-0) and broadcast field 1357B (EVEX byte 3, bits[4]–B).

Exemplary Register Architecture

Figure 15 is a block diagram of a register architecture 1500 according to one embodiment of the invention. In the illustrated embodiment, there are thirty-two 512-bit wide vector registers 1510; these registers are referenced as zmm0 through zmm31. The lower order 256 bits of the lower 16zmm registers are overlaid on registers ymm0-16. The lower order 128 bits of the lower 16zmm registers (the lower order 128 bits of the ymm registers) are overlaid on registers xmm0-15. The specific vector friendly instruction format 1400 operates on these overlaid register banks, as shown in the table below.

In other words, vector length field 1359B selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the previous length, and there is no instruction template pair for vector length field 1359B Maximum vector length operation. Furthermore, in one embodiment, the class B instruction templates of the specific vector friendly instruction format 1400 operate on packed or scalar single/double precision floating point data as well as packed or scalar integer data. Scalar operations are operations performed on the lowest order data element positions in a zmm/ymm/xmm register; according to this embodiment, higher order data element positions remain the same as before the instruction or are zeroed.

Write Mask Registers 1515 - In the embodiment shown, there are 8 write mask registers (k0 to k7), each 64 bits in size. In an alternate embodiment, the writemask register 1515 is 16 bits in size. As previously stated, in one embodiment of the invention, the vector mask register k0 cannot be used as a writemask; it selects the hardwired writemask when an encoding that would normally indicate k0 is used as a writemask 0xFFFF, effectively disabling the write mask for that instruction.

General Purpose Registers 1525 - In the illustrated embodiment, there are sixteen 64-bit general purpose registers that are used with existing x86 addressing modes to address memory operands. These registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

Scalar floating point stack register set (x87 stack) 1545 over which is aliased the MMX packed integer flat register set 1550 - in the embodiment shown, the x87 stack is used to use the x87 instruction set extensions for 32 An eight-element stack that performs scalar floating-point operations on 64/80-bit floating-point data; while MMX registers are used to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between MMX and XMM registers.

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

Exemplary core architecture, processor and computer architecture

Processor cores can be implemented in different processors in different ways for different purposes. 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 scientific (throughput) dedicated cores for computing. Implementations of different processors may include: a CPU including one or more general-purpose in-order cores intended for general-purpose computing and/or one or more general-purpose out-of-order cores intended for general-purpose computing; Coprocessor with one or more dedicated cores for graphics and/or science (throughput). Such different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) A coprocessor on the same die as the CPU (in which case such a coprocessor 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 that may include the described CPU (sometimes called an application core or application processor), the coprocessors described above, and additional functionality on the same die. An exemplary core architecture is described next, followed by an exemplary processor and computer architecture.

Exemplary Core Architecture

Ordered and Disordered Core Block Diagrams

16A 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. 16B is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register-renaming, out-of-order issue/execution architecture core included in a processor according to an embodiment of the invention. The solid line boxes in Figures 16A-16B illustrate in-order pipelines and in-order cores, while the optional additions in dashed boxes illustrate register renaming, out-of-order issue/execution pipelines and cores. Given that an ordered aspect is a subset of an unordered aspect, an unordered aspect will be described.

In FIG. 16A, processor pipeline 1600 includes fetch stage 1602, length decode stage 1604, decode stage 1606, allocate stage 1608, rename stage 1610, dispatch (also called dispatch or issue) stage 1612, register read/memory read Fetch stage 1614 , execute stage 1616 , writeback/memory write stage 1618 , exception handling stage 1622 and commit stage 1624 .

FIG. 16B shows processor core 1690 including front end unit 1630 coupled to execution engine unit 1650 , and both execution engine unit and front end unit are coupled to memory unit 1670 . Core 1690 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 alternate core type. As yet another option, core 1690 may be a special purpose core such as, for example, a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processor unit (GPGPU) core, or a graphics core, among others.

Front end unit 1630 includes branch prediction unit 1632 coupled to instruction cache unit 1634, which is coupled to instruction translation lookaside buffer (TLB) 1636, which is coupled to instruction fetch unit 1638 , the instruction fetch unit 1638 is coupled to the decode unit 1640 . Decode unit 1640 (or decoder) may decode an instruction and generate one or more micro-operations, microcode entry points, microinstructions decoded from, or otherwise reflecting, or derived from, the original instruction. , other instructions, or other control signals as output. The decoding unit 1640 may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), and the like. In one embodiment, core 1690 includes a microcode ROM or other medium that stores microcode for certain macroinstructions (eg, in decode unit 1640 or otherwise within front end unit 1630 ). Decode unit 1640 is coupled to rename/allocator unit 1652 in execution engine unit 1650 .

Execution engine unit 1650 includes a rename/allocator unit 1652 coupled to a retirement unit 1654 and a set of one or more scheduler units 1656 . Scheduler unit 1656 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. Scheduler unit 1656 is coupled to physical register file unit 1658 . Each physical register file unit 1658 represents one or more physical register files, where different physical register files store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer , vector floating point, state (eg, an instruction pointer that is the address of the next instruction to execute), etc. In one embodiment, the physical register file unit 1658 includes a vector register unit, a write mask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file unit 1658 is overlaid by the retirement unit 1654 to illustrate the various ways that register renaming and out-of-order execution can be implemented (e.g., using reorder buffers and retiring register files; using future files, history buffers, and Retire register sets; use register maps and register pools, etc.). Retirement unit 1654 and physical register file unit 1658 are coupled to execution cluster 1660 . Execution cluster 1660 includes a set of one or more execution units 1662 and a set of one or more memory access units 1664 . The execution unit 1662 may perform various operations (e.g., shift, add, subtract, multiply), as well as perform . While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. The scheduler unit 1656, the physical register file unit 1658, and the execution cluster 1660 are shown as potentially multiple, as some embodiments provide for certain types of data/operations (e.g., scalar integer pipeline, scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipelines, and/or memory access pipelines each with its own scheduler unit, physical register unit, and/or execution cluster - and in the case of separate memory access pipelines, implementing Only execution clusters of this pipeline (certain embodiments with memory access unit 1664) create separate pipelines. It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the remaining pipelines may be in-order issue/execution.

Set of memory access units 1664 are coupled to memory unit 1670 including data TLB unit 1672 coupled to data cache unit 1674 coupled to level two (L2) cache unit 1676 . In one exemplary embodiment, the memory access unit 1664 may include a load unit, a store address unit and a store data unit, each of which is coupled to the data TLB unit 1672 in the memory unit 1670 . Instruction cache unit 1634 is also coupled to level two (L2) cache unit 1676 in memory unit 1670 . The L2 cache unit 1676 is coupled to one or more other levels of cache and ultimately to main memory.

As an example, an exemplary register renaming, out-of-order issue/execution core architecture may implement pipeline 1600 as follows: 1) instruction fetch 1638 performs fetch and length decode stages 1602 and 1604; 2) decode unit 1640 performs decode stage 1606; 3) Rename/allocator unit 1652 performs allocation stage 1608 and rename stage 1610; 4) scheduler unit 1656 performs dispatch stage 1612; 5) physical register file unit 1658 and memory unit 1670 performs register read/memory read stage 1614; Execution cluster 1660 executes execution stage 1616; 6) memory unit 1670 and physical register file unit 1658 executes writeback/memory write stage 1618; 7) units may involve exception handling stage 1622; and 8) retirement unit 1654 and physical register Group unit 1658 executes commit stage 1624 .

Core 1690 may support one or more instruction sets (e.g., x86 instruction set (with some extensions added with newer versions); MIPS instruction set from MIPS Technologies, Inc., Sunnyvale, Calif.; ARM Holdings of Sunnyvale's ARM instruction set (with optional additional extensions such as NEON), which includes the instructions described in this article. In one embodiment, core 1690 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2, and/or some form of the previously described general vector-friendly instruction format (U=0 and/or U=1), This allows many operations used by multimedia applications to be performed using packed data.

It should be understood that a core can support multithreading (a collection of two or more operations or threads executing in parallel), and that this multithreading can be accomplished in a variety of ways, including time-division multithreading, synchronous Multithreading (where a single physical core provides a logical core for each of the threads that the physical core is synchronously multithreading), or a combination thereof (e.g., time-division fetch and decode and thereafter such as with Hyper-threading technology to synchronize multi-threading).

Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in in-order architectures. Although the illustrated embodiment of the processor also includes separate instruction and data cache units 1634/1674 and a shared L2 cache unit 1676, alternative embodiments may have a single internal cache for both instructions and data, such as Examples include Level 1 (L1) internal caches or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches external to the cores and/or processors. Alternatively, all cache memory may be external to the core and/or processor.

Concrete Exemplary Ordered Core Architecture

17A-B show block diagrams of more specific exemplary in-order core architectures, which may be one of several logical blocks (including other cores of the same type and/or different types) in a chip. Depending on the application, these logic blocks communicate with certain fixed function logic, memory I/O interfaces, and other necessary I/O logic through a high-bandwidth interconnect network (eg, a ring network).

Figure 17A is a block diagram of a single processor core along with its connection to an on-die interconnect network 1702 and its local subset 1704 of Level 2 (L2) cache according to various embodiments of the invention. In one embodiment, instruction decoder 1700 supports the x86 instruction set with packed data instruction set extensions. L1 cache 1706 allows low latency access to cache memory in scalar and vector units. Although in one embodiment (to simplify the design), scalar unit 1708 and vector unit 1710 use separate sets of registers (scalar registers 1712 and vector registers 1714, respectively), and data transferred between these registers is written to memory and then read back from Level 1 (L1) cache 1706, but alternative embodiments of the invention could use a different approach (such as using a single set of registers or including allowing data to be transferred between these two register sets without being written to and readback communication paths).

Local subset of L2 cache 1704 is a portion of the global L2 cache that is divided into separate local subsets, ie, one local subset per processor core. Each processor core has a direct access path to its own local subset of L2 cache 1704. Data read by a processor core is stored in its L2 cache subset 1704 and can be accessed quickly in parallel with other processor cores accessing their own local L2 cache subset. Data written by a processor core is stored in its subset's L2 cache subset 1704 and flushed from other subsets if necessary. The ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

Figure 17B is an expanded view of a portion of the processor core in Figure 17A, according to various embodiments of the invention. FIG. 17B includes a portion of L1 data cache 1706A as L1 cache 1704 , and more details about vector unit 1710 and vector register 1714 . Specifically, vector unit 1710 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1728 ) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports mixing of register inputs through mixing unit 1720 , value conversion through value conversion units 1722A-B , and replication of memory inputs through replication unit 1724 . Write mask register 1726 allows predicated resulting vector writes.

Processor with integrated memory controller and graphics

18 is a block diagram of a processor 1800 that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to an embodiment of the invention. 18 shows a processor 1800 with a single core 1802A, a system agent 1810, a set of one or more bus controller units 1816, while the optional additional dashed boxes show alternative processing 1800 having multiple cores 1802A-N, a set of one or more integrated memory controller units 1814 in a system agent unit 1810 and dedicated logic 1808.

Thus, different implementations of processor 1800 may include: 1) a CPU, where application-specific logic 1808 is integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and cores 1802A-N are one or Multiple general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, a combination of both); 2) coprocessors, where cores 1802A-N are primarily intended for graphics and/or scientific (throughput ) a large number of special-purpose cores; and 3) coprocessors, wherein cores 1802A-N are a large number of general-purpose in-order cores. Thus, processor 1800 may be a general-purpose processor, a co-processor, or a special-purpose processor, such as, for example, a network or communications processor, a compression engine, a graphics processor, a GPGPU (general-purpose graphics processing unit), a high-throughput integrated many-core ( MIC) coprocessor (including 30 or more cores), or embedded processor, etc. The processor may be implemented on one or more chips. Processor 1800 may be part of and/or may be implemented on one or more substrates using any of a number of processing technologies such as, for example, BiCMOS, CMOS, or NMOS.

The memory hierarchy includes one or more levels of cache within each core, a set of one or more shared cache units 1806 , and external memory (not shown) coupled to a set of integrated memory controller units 1814 . The set of shared cache units 1806 may include one or more intermediate level caches, such as level two (L2), level three (L3), level four (L4) or other levels of cache, last level cache (LLC) ), and/or combinations thereof. Although in one embodiment a ring-based interconnect unit 1812 interconnects the integrated graphics logic 1808, the set of shared cache units 1806, and the system agent unit 1810/integrated memory controller unit 1814, alternative embodiments may use any number of known techniques to interconnect these units. In one embodiment, coherency is maintained between one or more cache units 1806 and cores 1802-A-N.

In some embodiments, one or more of cores 1802A-N are capable of multithreading. System agent 1810 includes those components that coordinate and operate cores 1802A-N. The system agent unit 1810 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or include the logic and components needed to adjust the power states of cores 1802A-N and integrated graphics logic 1808 . The display unit is used to drive one or more externally connected displays.

The cores 1802A-N may be homogeneous or heterogeneous in terms of architectural instruction sets; that is, two or more of the cores 1802A-N may be capable of executing the same set of instructions while other cores may be capable of executing the same set of instructions. Only a subset or a different set of instructions.

Exemplary Computer Architecture

19-22 are block diagrams of exemplary computer architectures. Known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network equipment, network backbones, switches, embedded processors, digital signal processors (DSPs), graphics devices, Other system designs and configurations for video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a number of systems and electronic devices capable of incorporating the processors and/or other execution logic disclosed herein are generally suitable.

Referring now to FIG. 19 , shown is a block diagram of a system 1900 in accordance with an embodiment of the present invention. System 1900 may include one or more processors 1910, 1915 coupled to a controller hub 1920. In one embodiment, controller hub 1920 includes graphics memory controller hub (GMCH) 1990 and input/output hub (IOH) 1950 (which may be on separate chips); GMCH 1990 includes memory 1940 and coprocessor 1945 coupled to memory and graphics controller; IOH 1950 couples input/output (I/O) devices 1960 to GMCH 1990. Alternatively, one or both of the memory and the graphics controller are integrated within the processor (as described herein), the memory 1940 and coprocessor 1945 are directly coupled to the processor 1910, and the IOH 1950 is in a single chip. Controller Hub 1920.

The optional nature of additional processors 1915 is indicated in Figure 19 with dashed lines. Each processor 1910 , 1915 may include one or more of the processing cores described herein, and may be some version of processor 1800 .

Memory 1940 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of both. For at least one embodiment, the controller hub 1920 is connected 1995 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a quickpath interconnect (QPI), or the like. Communicates with processors 1910,1915.

In one embodiment, coprocessor 1945 is a special purpose processor such as, for example, a high throughput MIC processor, network or communications processor, compression engine, graphics processor, GPGPU, or embedded processor, among others. In one embodiment, controller hub 1920 may include an integrated graphics accelerometer.

There are various differences between physical resources 1910, 1915 in terms of a spectrum of metrics including architectural, microarchitectural, thermal, power consumption characteristics, etc. advantages.

In one embodiment, processor 1910 executes instructions that control general types of data processing operations. Embedded within these instructions may be coprocessor instructions. The processor 1910 identifies those coprocessor instructions as being of the type that should be executed by the attached coprocessor 1945 . Accordingly, processor 1910 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1945 over a coprocessor bus or other interconnect. Coprocessor 1945 accepts and executes received coprocessor instructions.

Referring now to FIG. 20 , shown is a block diagram of a first more specific exemplary system 2000 in accordance with one embodiment of the present invention. As shown in FIG. 20 , multiprocessor system 2000 is a point-to-point interconnect system and includes a first processor 2070 and a second processor 2080 coupled via a point-to-point interconnect 2050 . Each of processors 2070 and 2080 may be some version of processor 1800 . In one embodiment of the invention, processors 2070 and 2080 are processors 1910 and 1915, respectively, and coprocessor 2038 is coprocessor 1945. In another embodiment, processors 2070 and 2080 are processor 1910 and coprocessor 1945, respectively.

Processors 2070 and 2080 are shown including integrated memory controller (IMC) units 2072 and 2082, respectively. Processor 2070 also includes point-to-point (P-P) interfaces 2076 and 2078 as part of its bus controller unit; similarly, second processor 2080 includes point-to-point interfaces 2086 and 2088 . Processors 2070 , 2080 may exchange information via P-P interface 2050 using point-to-point (P-P) circuits 2078 , 2088 . As shown in Figure 20, IMCs 2072 and 2082 couple each processor to respective memories, memory 2032 and memory 2034, which may be part of main memory locally attached to the respective processors.

Processors 2070 , 2080 may each exchange information with chipset 2090 via respective P-P interfaces 2052 , 2054 using point-to-point interface circuits 2076 , 2094 , 2086 , 2098 . Chipset 2090 may optionally exchange information with coprocessor 2038 via high performance interface 2039 . In one embodiment, coprocessor 2038 is a special purpose processor such as, for example, a high throughput MIC processor, network or communications processor, compression engine, graphics processor, GPGPU, or embedded processor, among others.

A shared cache (not shown) can be included within either processor or external to both processors but still be connected to these processors via a P-P interconnect so that if a processor is placed in a low power mode, Either processor or both processors' local cache information can be stored in this shared cache.

Chipset 2090 may be coupled to first bus 2016 via interface 2096 . In one embodiment, the first bus 2016 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or other third-generation I/O interconnect bus, but the scope of the present invention is not limited by this limit.

As shown in FIG. 20 , various I/O devices 2014 may be coupled to a first bus 2016 along with a bus bridge 2018 that couples the first bus 2016 to a second bus 2020 . In one embodiment, a processor such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerometer (such as, for example, a graphics accelerometer or a digital signal processor (DSP) unit), a field programmable gate array, or any other One or more additional processors 2015 of processors are coupled to a first bus 2016 . In one embodiment, the second bus 2020 may be a low pin count (LPC) bus. Various devices may be coupled to second bus 2020 including, in one embodiment, keyboard/mouse 2022, communication devices 2027, and storage devices such as disk drives or other mass storage devices, which may include instructions/code and data 2030, for example. Unit 2028. Additionally, audio I/O 2024 may be coupled to second bus 2020 . Note that other architectures are possible. For example, instead of the point-to-point architecture of Figure 20, the system could implement a multidrop bus or other such architecture.

Referring now to FIG. 21 , shown is a block diagram of a second more specific exemplary system 2100 in accordance with one embodiment of the present invention. Like elements in FIGS. 20 and 21 have the same reference numerals, and certain aspects of FIG. 20 are omitted in FIG. 21 to avoid obscuring other aspects of FIG. 21 .

Figure 21 shows that processors 2070, 2080 may include integrated memory and I/O control logic ("CL") 2072 and 2082, respectively. Therefore, the CL2072, 2082 includes an integrated memory controller unit and includes I/O control logic. FIG. 21 not only shows memory 2032 , 2034 coupled to CL 2072 , 2082 , but also illustrates I/O device 2114 also coupled to control logic 2072 , 2082 . Legacy I/O devices 2115 are coupled to chipset 2090 .

Referring now to FIG. 22 , shown is a block diagram of a SoC 2200 in accordance with one embodiment of the present invention. In Fig. 18, similar parts have the same reference numerals. Also, dashed boxes are optional features for more advanced SoCs. In FIG. 22, interconnection unit 2202 is coupled to: application processor 2210, which includes a set of one or more cores 202A-N and shared cache unit 1806; system agent unit 1810; bus controller unit 1816 an integrated memory controller unit 1814; a set or one or more coprocessors 2220, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 2230; a direct memory access (DMA) unit 2232; and a display unit 2240 for coupling to one or more external displays. In one embodiment, coprocessor 2220 includes a special purpose processor such as, for example, a network or communications processor, compression engine, GPGPU, high throughput MIC processor, or embedded processor, among others.

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 as computer programs or program code executing on a programmable system comprising at least one processor, memory system (including volatile and non-volatile memory and/or storage elements) , at least one input device, and at least one output device.

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

The program code can be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system. The program code can also be implemented in assembly or machine language, if desired. In fact, the mechanisms described in this paper are not limited in scope to any particular programming language. In either case, the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, the instructions representing various logic in a processor, which when read by a machine cause the machine to act Logic used to implement the techniques described herein. These representations, referred to as "IP cores," may be stored on a tangible, machine-readable medium and provided to various customers or production facilities for loading into the fabrication machines that actually manufacture the logic or processor.

Such machine-readable storage media may include, but are not limited to, non-transitory, tangible arrangements of articles manufactured or formed by a machine or apparatus, including storage media, such as hard disks; any other type of disk, including floppy disks, optical disks, compact Disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), such as dynamic random access memory (DRAM) and static random access memory Random Access Memory (RAM), Erasable Programmable Read-Only Memory (EPROM), Flash Memory, Electrically Erasable Programmable Read-Only Memory (EEPROM); Phase Change Memory (PCM); Magnetic Card or optical card; or any other type of medium suitable for storing electronic instructions.

Accordingly, embodiments of the invention also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as a hardware description language (HDL), which defines the structures, circuits, devices, processes described herein device and/or system characteristics. These embodiments are also referred to as program products.

Simulation (including binary transformation, code deformation, 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, an instruction converter may transform (eg, using static binary translation, dynamic binary translation including dynamic compilation), warp, emulate, or otherwise convert an instruction into one or more other instructions to be processed by the core. The instruction converter can be implemented in software, hardware, firmware, or a combination thereof. The instruction converter can be on-processor, off-processor, or part-on-processor and part-off-processor.

23 is a block diagram comparing binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction translator, according to an embodiment of the present invention. In the illustrated embodiment, the instruction converter is a software instruction converter, but the instruction converter may alternatively be implemented in software, firmware, hardware, or various combinations thereof. 23 shows that a program in a high-level language 2302 can be compiled using an x86 compiler 2304 to generate x86 binary code 2306 that can be natively executed by a processor 2316 having at least one x86 instruction set core. Processor 2316 having at least one x86 instruction set core means any processor capable of performing substantially the same function as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise processing: 1) an essential portion of the instruction set of an Intel x86 instruction set core, or 2) an object code version of an application or other program directed to run on an Intel processor with at least one x86 instruction set core, in order to obtain a Basically the same result as the x86 instruction set core of the Intel processor. An x86 compiler 2304 represents a compiler for generating x86 binary code 2306 (eg, object code) executable on a processor 2316 having at least one x86 instruction set core, with or without additional linkage processing. Similarly, FIG. 23 shows that a program in a high-level language 2302 can be compiled using an alternative instruction set compiler 2308 to generate a processor 2314 that does not have at least one x86 instruction set core (e.g., with a Sunnyvale, Calif. The replacement instruction set binary code 2310 is natively executed by the MIPS instruction set of MIPS Technologies, Inc. of Sunnyvale, California, and/or by a processor of a core executing the ARM instruction set of ARM Holdings, Inc. of Sunnyvale, California. An instruction converter 2312 is used to convert x86 binary code 2306 into code that can be natively executed by a processor 2314 that does not have an x86 instruction set core. This translated code is unlikely to be identical to the alternative instruction set binary code 2310 because instruction converters capable of doing so are difficult to manufacture; however, the translated code will perform common operations and be composed of instructions from the alternative instruction set. Thus, instruction converter 2312 represents, by emulation, emulation or any other process, software, firmware, hardware or a combination thereof that allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute x86 binary code 2306.

Alternative embodiment

Although the present invention has been described in terms of several embodiments, those skilled in the relevant art will recognize that the invention is not limited to the described embodiments, but that the invention can be modified within the spirit and scope of the appended claims. Invention to modify. The specification should therefore be regarded as illustrative rather than restrictive. For example, although the flowcharts in the figures show a particular sequence of operations for some embodiments of the invention, it is to be understood that the sequence is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations , make certain operations overlap, etc).

Claims (25)

1. A computer-implemented method comprising: An occurrence of a fetch instruction whose format specifies a source operand from a single vector writemask register as its only source operand and a single general purpose register as its destination, wherein the format of the instruction includes the first field, the content of the first field selects the single vector write mask register from a plurality of architectural vector write mask registers, and wherein the format of the instruction includes a second field, the content of the second field selects from multiple selects the single general purpose register among architectural general purpose registers, and wherein the source operand is a write mask comprising a plurality of one bit vector write mask elements, the plurality of one bit vector write mask elements elements correspond to different multi-bit data element locations within the architectural vector register; and storing data in the single general purpose register in response to executing a single occurrence of the instruction such that the content of the single general purpose register is based on whether the plurality of one-bit vector writemask elements in the source operand Both are 0, representing the first or second scalar constant. 2. The method of claim 1, wherein the first and second scalar constants are 1 and 0, respectively. 3. The method of claim 2, wherein storing comprises storing data in the single general purpose register such that when the plurality of bit vector writemask elements are all zeros, the single The contents of the general register represent 1. 4. The method of claim 2, wherein storing comprises storing data in the single general purpose register such that when the plurality of bit vector writemask elements are all zeros, the single The contents of the general-purpose register represent 0. 5. The method of any one of claims 1-4, wherein an opcode of the instruction specifies the size of the source operand. 6. The method of claim 5, wherein the size of the source operand is smaller than the size of the single vector writemask register. 7. The method of claim 6, wherein the source operands are contiguous bits from the single vector writemask register, starting with the least significant bit. 8. The method of claim 1, wherein the instruction is part of an instruction set architecture (ISA), wherein other instructions from the instruction set architecture (ISA) specify vector operations, select destinations, and Select from among the writemasks of the plurality of architectural vector writemask registers, wherein for each of the other instructions, the plurality of one-bit vector writemask elements of the selected writemask control the selected Which data element locations in the destination reflect the result of the instruction's vector operation. 9. The method of claim 1 , wherein the general-purpose registers are configured to store operands for logical operations, arithmetic operations, address calculations, and memory pointers, and wherein the architectural vector registers are configured is a storage vector. 10. The method of claim 1 , wherein there are at least 16 architectural general purpose registers of size at least 64 bits, wherein there are at least 8 architectural vector writemask registers of size at least 32 bits for storing write masks, and There are at least 16 architectural vector registers of size at least 256 bits for storing vectors. 11. The method of claim 1 , wherein there are at least 16 architectural general purpose registers of size at least 64 bits, wherein there are at least 8 architectural vector writemask registers of size at least 64 bits for storing write masks, and There are at least 32 architectural vector registers of size at least 512 bits for storing vectors. 12. The method of claim 1, wherein said performing comprises: performing a logical OR operation on the plurality of bit vector writemask elements; and The first or second scalar constant is generated based on a result of the logical OR operation. 13. The method of claim 12, wherein said generating comprises: Negate the result of the logical OR; The negated value is converted to a 64-bit unsigned integer value to form the first or second scalar constant. 14. The method of claim 12, wherein said generating comprises: The first or second scalar constant is multiplexed based on a control signal formed from the result of the logical OR operation and an indication of which of a plurality of types the instruction is. 15. A processor core, comprising: a hardware decode unit configured to decode occurrences of a set of one or more instructions, wherein each of the occurrences specifies a source operand from a selected one of a plurality of architectural vector writemask registers as its sole source, and designates as its destination a selected one of a plurality of architectural general purpose registers, wherein the set of instructions has a format with a first field whose contents select the plurality of one of the architectural vector write mask registers, and wherein the format has a second field whose contents select one of the plurality of architectural general purpose registers, and wherein each of the source operands is a writemask, the writemask includes a plurality of one-bit vector writemask elements corresponding to different multi-bit data element positions within the architectural vector register; an execution engine unit coupled to the hardware decoding unit and configured to, in response to each of the occurrences: determining whether the plurality of bit-vector writemask elements of the source operand present are all zeros; and Data is caused to be stored in the selected single general purpose register of the occurrence such that the content of the single general purpose register represents either the first or the second scalar constant based on the determination. 16. The processor core of claim 15, wherein the first and second scalar constants are 1 and 0, respectively. 17. The processor core of claim 16 , wherein a first instruction in the set of instructions causes the contents of the selected single general-purpose register to be full in the plurality of one-bit vector writemask elements. 0 means 1. 18. The processor core of claim 17 , wherein a second instruction in the set of instructions causes the contents of the selected single general-purpose register to be full in the plurality of one-bit vector writemask elements. 0 means 0. 19. The processor core of any one of claims 15-18, wherein different instructions in the set of instructions specify different sizes of source operands, and wherein at least one of the sizes is smaller than the Dimensions of the vector write mask register. 20. The processor core of claim 19, wherein the source operands are contiguous bits from a selected single vector writemask register, starting with the least significant bit. 21. The processor core of claim 15, wherein the hardware decode unit is further configured to decode occurrences of other instructions specifying vector operations, select destinations, and from the A selection is made among a write mask of a plurality of architectural vector write mask registers, wherein for each of said other instructions, a plurality of one-bit vector write mask elements of the selected write mask control the selected destination Which data element positions in reflect the result of the vector operation of the instruction. 22. The processor core of claim 15 , wherein the plurality of architectural general purpose registers are configured to store operands for logical operations, arithmetic operations, address calculations, and memory pointers, and wherein The architectural vector registers are configured to store vectors. 23. The processor core of claim 15 , wherein there are at least 16 architectural general purpose registers of size at least 64 bits, wherein there are at least 8 architectural vector writemask registers of size at least 32 bits for storing write masks , and in which there are at least 16 architectural vector registers of size at least 256 bits for storing vectors. 24. The processor core of claim 15 , wherein there are at least 16 architectural general purpose registers having a size of at least 64 bits, wherein there are at least 8 architectural write mask registers having a size of at least 64 bits for storing a write mask, And there are at least 32 architectural vector registers of size at least 512 bits for storing vectors. 25. The processor core according to claim 15, wherein the execution engine unit comprises: a logical OR logical unit configured to logically OR the plurality of bit vector writemask elements; and a multiplexer coupled to a logical OR logic unit and configured to select said first or second scalar constant based on a control signal derived from the result of said logical OR operation and said instruction An indication of which instruction in the set is being executed is formed.