CN105204820B - Instructions and logic for providing generic GF(256) SIMD cryptographic arithmetic functions - Google Patents

Abstract

This application discloses for providing general GF(256) instruction and logic of SIMD encrypted mathematical function.Instruction and logic provide general GF (2⁸) SIMD encrypted mathematical function.Embodiment includes processor, is used to be decoded the instruction of source data operation number invert for SIMD binary system finite field multiplier, specified and irreducible function to calculate inverse element to irreducible function modulus for each of source data operation number element.The result of the instruction is stored in SIMD destination register.Some embodiments are also decoded the instruction for SIMD affine transformation of specified source data operation number, transformation matrix operand and converting vector.Transformation matrix and converting vector are applied to each of source data operation number element.Some embodiments are also decoded the instruction for SIMD binary system finite field multiplier of specified first and second source data operation numbers, so as to by each corresponding element of the first and second source data operation numbers to multiplication, and to irreducible function modulus.

Description

Instructions and logic for providing generic GF(256) SIMD cryptographic arithmetic functions

technical field

The present disclosure relates to the field of processing logic, microprocessors, and associated instruction set architectures that perform logical, mathematical or other functional operations when executed by a processor or other processing logic. More specifically, the present disclosure relates to instructions and logic for providing generic GF(256) SIMD cryptographic arithmetic functions.

Background technique

Cryptography is a tool that relies on algorithms and keys to protect information. The algorithm is a complex mathematical algorithm, and the key is a string of bits. There are two basic types of encryption systems: secret key systems and public key systems. Secret key systems (also known as symmetric systems) have a single key ("secret key") shared by two or more parties. This single key is used to both encrypt and decrypt information.

For example, the Advanced Encryption Standard (AES) (also known as Rijndael) is a block cipher developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, and adopted by the U.S. government as an encryption standard. On November 26, 2001, AES was declared a U.S. FIPS PUB 197 (FIPS 197) by the National Institute of Standards and Technology (NIST).

AES has a fixed block size of 128 bits and a key size of 128 bits, 192 bits, or 256 bits. Key expansion using Rijndael key scheduling transforms keys of size 128, 192, or 256 bits into 128-bit 10-round, 12-round, or 14-round keys. These round keys are used in rounds to process plaintext data as 128-bit blocks (considered as 4x4 byte arrays) and convert them into ciphertext blocks. Typically, for a 128-bit input (16 bytes) to a wheel, each byte is replaced by another according to a lookup table called an S-box. This part of the block cipher is called SubBytes. Next, the row of bytes (treated as a 4x4 array) is rotated left or by a specific offset (i.e., row zero is 0 bytes, row 1 is 1 byte, row 2 is 2 bytes, row 0 three lines of 3 bytes). This part of the block cipher is called ShiftRows. Each column of bytes is then treated as the four coefficients of a polynomial in the finite field GF(256) (also known as the Galois field ²⁸ ) and multiplied by an invertible linear transform. This part of the block cipher is called MixColumns. Finally, the 128-bit block is XORed with the round key to generate a 16-byte ciphertext block, which is called AddRoundKey.

On systems with 32-bit or larger words, it is possible to implement the AES cipher by converting byte substitution, row shifting, and column mixing into a 32-bit table utilizing four 256-entry 32-bit tables of 4096 bytes of memory of. One disadvantage of software implementation is performance. Software runs orders of magnitude slower than dedicated hardware, so it is desirable to have increased performance implemented by hardware/firmware.

Typical direct hardware implementations using lookup memories, truth tables, binary decision diagrams, or 256-input multiplexers are costly in terms of circuit area. An alternative approach using finite fields isomorphic to GF(256) may be area efficient, but may also be slower than a direct hardware implementation.

Modern processors typically include instructions that provide operations that are computationally intensive but provide a high degree of data parallelism, which can be exploited through efficient implementations using various data storage devices such as single-instruction, multiple-data (SIMD) vector registers. Data parallelism. The central processing unit (CPU) can then provide parallel hardware to support the processing vectors. A vector is a data structure that holds multiple contiguous data elements. A vector register of size M (where M is ^2k , eg, 256, 128, 64, 32, . . . 4, or 2) may contain N vector elements of size 0, where N=M/O. For example, a 64-byte vector register can be divided into: (a) 64 vector elements, each holding a data item occupying 1 byte; (b) 32 vector elements, each holding 2 bytes (or a "word") data items; (c) 16 vector elements, each element holding data items occupying 4 bytes (or a "double word"); or (d) 8 vector elements, each element holding data items occupying 4 bytes 8 bytes (or a "quadword") data item. The nature of parallelism in SIMD vector registers lends itself well to processing secure hashing algorithms.

Other similar encryption algorithms may also be of interest. For example, the Rijndael specification itself is specified with various block sizes and key sizes, both of which can be any multiple of 32 bits, with a minimum of 128 bits and a maximum of 256 bits. Another example is SMS4, which is a block cipher used in the wireless local area network WAPI China National Standard (Wired Authentication and Privacy Infrastructure). It also processes plaintext data as 128-bit blocks in GF(256) in rounds (ie, 32), but performs reductions modulo over different polynomials.

To date, options that provide efficient space-time design tradeoffs and potential solutions to such complexity, performance constraints, and other bottlenecks have not been fully explored.

Description of drawings

The present invention is illustrated by way of example and not by way of limitation in the various figures of the accompanying drawings.

Figure 1A is a block diagram of one embodiment of a system that executes instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure IB is a block diagram of another embodiment of a system that executes instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

1C is a block diagram of another embodiment of a system that executes instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 2 is a block diagram of one embodiment of a processor executing instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 3A illustrates a packed data type according to one embodiment.

Figure 3B illustrates a packed data type according to one embodiment.

Figure 3C illustrates a packed data type according to one embodiment.

Figure 3D illustrates an instruction encoding for providing generic GF(256) SIMD encrypted arithmetic functions, according to one embodiment.

Figure 3E illustrates an instruction encoding for providing generic GF(256) SIMD encrypted arithmetic functions according to another embodiment.

Figure 3F illustrates an instruction encoding for providing generic GF(256) SIMD encrypted arithmetic functions according to another embodiment.

3G illustrates an instruction encoding for providing generic GF(256) SIMD encrypted arithmetic functions according to another embodiment.

Figure 3H illustrates an instruction encoding for providing generic GF(256) SIMD encrypted arithmetic functions according to another embodiment.

Figure 4A illustrates elements of one embodiment of a processor microarchitecture for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

Figure 4B illustrates elements of another embodiment of a processor microarchitecture for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

5 is a block diagram of one embodiment of a processor for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

6 is a block diagram of one embodiment of a computer system for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

7 is a block diagram of another embodiment of a computer system for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

8 is a block diagram of another embodiment of a computer system for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

9 is a block diagram of one embodiment of a system-on-a-chip for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

10 is a block diagram of an embodiment of a processor for executing instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

Figure 11 is a block diagram of one embodiment of an IP core development system that provides generic GF(256) SIMD cryptographic arithmetic functionality.

Figure 12 illustrates one embodiment of an architectural simulation system that provides generic GF(256) SIMD cryptographic arithmetic functionality.

Figure 13 illustrates one embodiment of a system for converting instructions that provide generic GF(256) SIMD cryptographic arithmetic functions.

14 shows a flowchart of one embodiment of a process for efficiently implementing the Advanced Encryption Standard (AES) encryption/decryption standard.

Figure 15 shows a flow diagram of one embodiment of a process for efficiently implementing a multiplicative inverse of an AES S-box.

Figure 16A shows a diagram of one embodiment of an apparatus for executing affine map instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. .

Figure 16B shows a diagram of one embodiment of an apparatus for executing an affine inverse instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 16C shows a diagram of an alternative embodiment of an apparatus for executing an inverse affine instruction for computing a multiplicative inverse and then affine transforming the result to provide a generic GF( 256) SIMD encryption arithmetic function.

Figure 17A shows a diagram of one embodiment of an apparatus for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 17B shows a diagram of an alternative embodiment of an apparatus for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 17C shows a diagram of another alternative embodiment of an apparatus for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 18A shows a diagram of one embodiment of an apparatus for executing specific modulus reduction instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 18B shows a diagram of an alternative embodiment of an apparatus for executing specific modulo-reduce instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 18C shows a diagram of another alternative embodiment of an apparatus for executing a specific AES Galois Counter Mode (GCM) modulo-reduce instruction for providing generic GF(2 ¹²⁸ ) SIMD cryptographic arithmetic functions.

Figure 18D shows a diagram of one embodiment of an apparatus for executing a modulo-reduce instruction for providing generic GF( ^2t ) SIMD cryptographic arithmetic functions.

Figure 19A shows a diagram of one embodiment of an apparatus for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 19B shows a diagram of an alternative embodiment of an apparatus for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 20A shows a flowchart of one embodiment of a process for executing an affine map instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 20B shows a flowchart of one embodiment of a process for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 20C shows a flowchart of one embodiment of a process for executing an affine inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions.

Figure 20D shows a flow diagram of one embodiment of a process for executing a binary finite field multiply instruction to provide generic GF(256) SIMD cryptographic arithmetic functions.

Detailed ways

The following description discloses instructions and processing logic for providing general GF(2 ⁿ ) SIMD cryptographic arithmetic functions, in particular, where n may be equal to 2 ^m (eg, GF(2 ⁸ ), GF(2 ¹⁶ ), GF( 2 ³² ), ... GF(2 ¹²⁸ ), etc.). Embodiments include a processor for decoding instructions for SIMD affine transforms specifying source data operands, transform matrix operands, and transform vectors. A transformation matrix is applied to each element in the source data operand, and a transformation vector is applied to each transformed element. The result of this instruction is stored in the SIMD destination register. Some embodiments also decode the instructions for SIMD binary finite field multiplication inversion to compute the inverse in the binary finite field modulo the irreducible polynomial for each element in the source data operand. Some embodiments also decode instructions for SIMD affine transforms and multiplicative inversions (or multiplicative inversions and affine transforms), where a transformation matrix is applied to the source data operation before or after the multiplication inversion operation each element in the number, and a transformation vector is applied to each transformed element. Some embodiments also decode the instructions for SIMD modulo-reduction to compute a particular computation selected from a number of polynomials in a binary finite field for which the modulo-reduction is provided by the instruction (or microinstruction). The reduction modulo by the modulo polynomial p _s . Some embodiments also decode instructions for SIMD binary finite field multiplication specifying first and second source data operands to multiply each corresponding pair of elements of the first and second source data operands, and Modulo an irreducible polynomial.

It will be appreciated that, as described in various embodiments described herein, generic GF(2 ⁿ ) SIMD encrypted arithmetic instructions can be used to provide arithmetic functions in a variety of applications, for example, in secure applications for financial transactions, Privacy, data integrity, authentication, message content authentication and message origin authentication encryption protocols and Internet communications for e-commerce, email, software distribution, data storage, etc.

It will also be appreciated that execution of instructions for at least the following is provided: (1) SIMD affine transform specifying source data operands, transform matrix operands and transform vectors, wherein the transform matrix is applied in the source data operands each data element of , and a transformation vector is applied to each transformed element; (2) SIMD binary finite field multiplication inversion, which is used to compute the inverse in the binary finite field for each element in the source data operands Element modulo irreducible polynomials; (3) SIMD affine transformation and multiplication inversion (or multiplication inversion and affine transformation), which specify source data operands, transformation matrix operands, and transformation vectors, where in the multiplication Before or after the inverse operation, the transformation matrix is applied to each element in the source data operand, and the transformation vector is applied to each transformed element; (4) Modulo reduction, which is used to calculate the binary finite The specific modulo polynomial p _s selected from the multiple polynomials in the field (the modulo reduction is provided by the instruction (or microinstruction) for these specific polynomials) is reduced and modulo; (5) SIMD binary finite field multiplication, It specifies the first and second source data operands and is used to multiply and modulo the irreducible polynomial by pairs of elements corresponding to each of the first and second source data operands; wherein the results of these instructions are Stored in SIMD destination registers; and can provide generic GF(256) and/or other alternative binary finite field SIMD cryptographic arithmetic functions in hardware and/or microcode sequences so as not to require additional circuitry, area, or power An excess or excess of functional units can support significant performance improvements for several important performance-critical applications.

In the following description, numerous specific details are set forth, such as processing logic, processor types, microarchitectural conditions, events, enabling mechanisms, etc., in order to provide a more thorough understanding of embodiments 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. Additionally, some well-known structures, circuits, etc. have not been shown in detail in order to avoid unnecessarily obscuring the various embodiments of the present invention.

Although the following various embodiments are described with reference to a processor, other embodiments are also applicable to other types of integrated circuits and logic devices. Similar techniques and teachings of embodiments of the present invention may be applied to other types of circuits or semiconductor devices that may benefit from higher pipeline throughput and improved performance. The teachings of the various embodiments of the present invention apply to any processor or machine that performs data manipulation. However, the present invention is not limited to processors or machines that perform operations on 512-bit, 256-bit, 128-bit, 64-bit, 32-bit, 16-bit or 8-bit data, and is applicable to any processor and machine that performs data manipulation or management . Furthermore, the following description provides examples, and the accompanying drawings show various examples for illustrative purposes. However, these examples should not be construed in a limiting sense as they are intended only to provide illustrations of the various embodiments of the invention and not to be exhaustive of all possible implementations of the various embodiments of the invention.

While the following examples describe instruction processing and distribution in the context of execution units and logic circuits, other embodiments of the invention may also be accomplished with data and/or instructions stored on machine-readable tangible media, which Data and/or instructions, when executed by a machine, cause the machine to perform functions consistent with at least one embodiment of the present invention. In one embodiment, the functions associated with various embodiments of the invention are embodied in machine-executable instructions. These instructions may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps of the present invention. Embodiments of the present invention may also be provided as a computer program product or software, which may include a machine or computer readable medium having stored thereon instructions that may be used to program a computer (or other electronic device) programmed to perform one or more operations in accordance with various embodiments of the present invention. Alternatively, various steps of various embodiments of the invention may be performed by dedicated hardware components containing fixed function logic for performing the steps, or by any combination of programmed computer components and fixed function hardware components.

Instructions for programming the logic to perform various embodiments of the present invention may be stored in memory (such as DRAM, cache, flash memory, or other storage devices) in the system. Furthermore, the instructions may be distributed via a network or by other computer-readable media. Thus, a computer-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (eg, a computer), but is not limited to: floppy disk, optical disk, compact disk read only memory (CD-ROM), magnetic Optical Disc, Read Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), Magnetic or Optical Cards, Flash Memory, or Tangible machine-readable storage used in transmitting information via the Internet via electrical, optical, acoustic, or other forms of propagated signals (eg, carrier waves, infrared signals, digital signals, etc.). Accordingly, computer-readable media includes any type of tangible machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

Designs go through multiple stages, from creation to simulation to manufacturing. The data representing the design can represent the design in a number of ways. First, hardware can be represented using a hardware description language or another functional description language, as useful in simulation. Additionally, circuit-level models with logic and/or transistor gates may be generated at some stage of the design process. Furthermore, most designs at some stage reach a level of data representing the physical arrangement of the various devices in the hardware model. Using conventional semiconductor fabrication techniques, the data representing the hardware model may be data specifying the presence or absence of various features on different mask layers of the mask used to fabricate the integrated circuit. In any design representation, data may be stored in any form of machine-readable medium. A memory or magnetic or optical storage device, such as a disk, may be a machine-readable medium that stores information transmitted via light or electrical waves, modulated or otherwise generated to convey the information. A new copy is created when the electrical carrier indicating or carrying the code or design is transmitted to the extent that duplication, buffering or retransmission of the electrical signal is effected. Accordingly, a communications provider or network provider may at least temporarily store on a tangible machine-readable medium an article of manufacture embodying the techniques of various embodiments of the present invention (such as information encoded into a carrier wave).

In modern processors, multiple different execution units are used to process and execute various codes and instructions. Not all instructions are created equally, as some instructions complete faster and others may take multiple clock cycles to complete. The faster the throughput of instructions, the better the overall performance of the processor. Therefore, it would be advantageous to have many instructions execute as fast as possible. However, there are certain instructions that have greater complexity and require more in terms of execution time and processor resources. For example, there are floating point instructions, load/store operations, data movement, etc.

As more computer systems are used for Internet, text, and multimedia applications, additional processor support has gradually been introduced. In one embodiment, an instruction set may be associated with one or more computer architectures including: data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I/O).

In one embodiment, an instruction set architecture (ISA) may be implemented by one or more microarchitectures that include processor logic and circuitry for implementing one or more instruction sets. Thus, multiple processors with different microarchitectures may share at least a portion of a common instruction set. E.g, Pentium 4 processor, Core ^™ processors, as well as multiple processors from Advanced Micro Devices, Inc. of Sunnyvale, Calif., execute nearly identical versions of the x86 instruction set (in the updated version with some extensions), but with a different internal design. Similarly, multiple processors designed by other processor development companies, such as ARM Holdings, Inc., MIPS, or their licensors or compatible parties, may share at least a portion of the common instruction set, but may include different processor designs. For example, the same register architecture of an ISA may be implemented in different ways in different microarchitectures using new or well-known techniques, including dedicated physical registers, using register renaming mechanisms (eg, using a register alias table (RAT), reordering One or more dynamically allocated physical registers for the buffer (ROB) and retirement register bank). In one embodiment, a register may include one or more registers, register architecture, register bank, or other set of registers that may or may not be addressable by a software programmer.

In one embodiment, an instruction may include one or more instruction formats. In one embodiment, the instruction format may indicate a number of fields (number of bits, position of bits, etc.) to specify the operation to be performed, the operands of the operation to be performed, and the like. Some instruction formats may be further subdivided by instruction templates (or sub-formats). For example, an instruction template for a given instruction format may be defined as having different subsets of instruction format fields, and/or as having a given field that is interpreted differently. In one embodiment, an instruction is represented using an instruction format (and, if defined, one of the instruction templates given for the instruction format) and specifies or indicates the operation and the operands on which the operation will operate .

Scientific applications, financial applications, general-purpose applications of auto-vectorization, RMS (recognition, mining, and synthesis) applications, and vision and multimedia applications (eg, 2D/3D graphics, image processing, video compression/decompression, speech recognition algorithms, and audio processing) It may be necessary to perform the same operation on a large number of data items. In one embodiment, single instruction multiple data (SIMD) refers to a type of instruction that causes a processor to perform an operation on multiple data elements. SIMD techniques can be used in processors that can logically divide multiple bits in a register into fixed-size or variable-size data elements, each data element representing a separate value. For example, in one embodiment, multiple bits in a 64-bit register may be organized into a source operand containing four separate 16-bit data elements, each data element representing a separate 16-bit value. This data type may be referred to as a packed data type or a vector data type, and the operands of this data type are referred to as packed data operands or vector operands. In one embodiment, the packed data item or vector may be a sequence of packed data elements stored in a single register, and the packed data operand or vector operand may be a SIMD instruction (or "packed data instruction" or "vector instruction" ) of the source or destination operand. In one embodiment, a SIMD instruction specifies that a destination vector operation is to be performed on two source vector operands to generate a destination vector operation of the same or different size, with the same or different number of data elements, and with the same or different order of data elements A single vector operation of numbers (also known as result vector operands).

such as by Core ^™ processors (with instruction sets including x86, MMX ^™ , Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE4.1, SSE4.2 instructions), ARM processors (such as ARM A processor family with an instruction set including vector floating point (VFP) and/or NEON instructions) and SIMD technology employed by MIPS processors such as the Loongson processor family developed by the Institute of Computer Technology (ICT) of the Chinese Academy of Sciences. This class of SIMD technology has brought about dramatic improvements in application performance (Core ^™ and MMX ^™ are either registered trademarks or trademarks of Intel Corporation of Santa Clara, California).

In one embodiment, destination register/data and source register/data are generic terms denoting the source and destination of corresponding data or operations. In some embodiments, they may be implemented by registers, memory, or other storage areas with names or functions different from those depicted. For example, in one embodiment, "DEST1" may be a temporary storage register or other storage area, while "SRC1" and "SRC2" may be first and second source storage registers or other storage areas, and so on. In other embodiments, two or more of the SRC and DEST storage areas may correspond to different data storage elements (eg, SIMD registers) in the same storage area. In one embodiment, one of the source registers may also act as the destination register by, for example, writing back the results of operations performed on the first and second source data to which of the two source registers is the destination register.

1A is a block diagram of an exemplary computer system formed with a processor including an execution unit for executing instructions, according to one embodiment of the present invention. In accordance with the present invention, such as according to the embodiments described herein, system 100 includes a component such as a processor 102 for processing data using an execution unit including logic to execute an algorithm. System 100 represents a system based on a system available from Intel Corporation of Santa Clara, CA, USA III. 4. ^XeonTM , Processing systems of XScale ^(TM) and/or StrongARM ^(TM) microprocessors, although other systems (including PCs with other microprocessors, engineering workstations, set-top boxes, etc.) may also be used. In one embodiment, the sample system 100 may execute a version of the WINDOWS ^(TM) operating system available from Microsoft Corporation of Redmond, Washington, USA, although other operating systems (eg, UNIX and Linux), embedded Software, and/or Graphical User Interface. Accordingly, embodiments of the present invention are not limited to any specific combination of hardware circuitry and software.

Embodiments are not limited to computer systems. Alternative embodiments of the present invention may be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cellular telephones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications may include microcontrollers, digital signal processors (DSPs), systems on chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or may execute one or more of the methods in accordance with at least one embodiment. any other system of instructions.

1A is a block diagram of a computer system 100 formed with a processor 102 including one or more execution units 108 for executing an algorithm to execute at least one instruction in accordance with one embodiment of the present invention. One embodiment may be described in the context of a uniprocessor desktop or server system, although alternative embodiments may be included in a multiprocessor system. System 100 is an example of a "hub" system architecture. Computer system 100 includes a processor 102 for processing data signals. The processor 102 may be a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of multiple instruction sets, or any other A processor device (eg, a digital signal processor). The processor 102 is coupled to a processor bus 110 that may transmit data signals between the processor 102 and other components within the system 100 . Various elements of system 100 perform conventional functions well known in the art.

In one embodiment, the processor 102 includes a first level (L1) internal cache memory 104 . Depending on the architecture, the processor 102 may have a single internal cache or multiple levels of internal caches. Alternatively, in another embodiment, the cache memory may reside external to the processor 102 . Other embodiments may also include combinations of internal and external caches, depending on the particular implementation and requirements. Register bank 106 may store different types of data in various registers, including integer registers, floating point registers, status registers, instruction pointer registers.

Execution unit 108 (including logic for performing integer and floating point operations) also resides in processor 102 . The processor 102 also includes a microcode (ucode) ROM that stores specific macroinstructions. For one embodiment, execution unit 108 includes logic for processing packed instruction set 109 . By including packed instruction set 109 within the instruction set of general-purpose processor 102 and including the associated circuitry for executing those instructions, packed data in general-purpose processor 102 may be used to perform operations used by many multimedia applications. Thus, many multimedia applications can be accelerated and executed more efficiently by utilizing the full width of the processor's data bus for performing operations on packed data. This can eliminate the need to transfer smaller data units across the processor data bus in order to perform one or more operations on one data element at a time.

Alternative embodiments of execution unit 108 may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. System 100 includes memory 120 . Memory 120 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, or other memory device. Memory 120 may store instructions and/or data represented by data signals executable by processor 102 .

System logic chip 116 is coupled to processor bus 110 and memory 120 . The system logic chip 116 in the illustrated embodiment is a memory controller hub (MCH). Processor 102 may communicate with MCH 116 via processor bus 110 . MCH 116 provides a high bandwidth memory path 118 to memory 120 for instruction and data storage, and for storing graphics commands, data and textures. MCH 116 is used to direct and bridge data signals between processor 102 , memory 120 , and other components within system 100 and between processor bus 110 , memory 120 , and system I/O 122 . In some embodiments, system logic chip 116 may provide a graphics port coupled to graphics controller 112 . MCH 116 is coupled to memory 120 via memory interface 118 . Graphics card 112 is coupled to MCH 116 through accelerated graphics port (AGP) interconnect 114 .

System 100 uses dedicated hub interface bus 122 to couple MCH 116 to I/O controller hub (ICH) 130 . ICH 130 provides direct connections to some I/O devices via a local I/O bus. The local I/O bus is a high-speed I/O bus used to connect peripherals to the memory 120 , the chipset, and the processor 102 . Some examples are audio controllers, firmware backbone (flash BIOS) 128, wireless transceivers 126, data storage devices 124, legacy I/O controllers including user input and keyboard interfaces, serial expansion ports such as Universal Serial Bus ( USB)) and the network controller 134. Data storage device 124 may include a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device.

For another embodiment of the system, instructions according to one embodiment may be used with a system on a chip. One embodiment of a system on a chip includes a processor and memory. The memory used for one such system is flash memory. Flash memory can be located on the same die as the processor and other system components. In addition, other logic blocks such as a memory controller or graphics controller may also be located on the system-on-chip.

Figure IB illustrates a data processing system 140 that implements the principles of one embodiment of the present invention. Those skilled in the art will readily appreciate that the various embodiments described herein may be used with alternative processing systems without departing from the scope of the various embodiments of the present invention.

Computer system 140 includes a processing core 159 capable of executing at least one instruction in accordance with one embodiment. For one embodiment, processing core 159 represents a processing unit of any type of architecture including, but not limited to, CISC, RISC, or VLIW type architectures. The processing core 159 may also be adapted to be fabricated in one or more processing technologies, and by representation on a machine-readable medium in sufficient detail, may be adapted to facilitate such fabrication.

Processing core 159 includes execution unit 142 , a set of register files 145 , and decoder 144 . Processing core 159 also includes additional circuitry (not shown) that is not necessary to understand various embodiments of the present invention. The execution unit 142 is used to execute the instructions received by the processing core 159 . In addition to executing typical processor instructions, execution unit 142 may also execute instructions in packed instruction set 143 to perform operations on packed data formats. Packed instruction set 143 includes instructions for performing various embodiments of the present invention, as well as other packed instructions. Execution unit 142 is coupled to register bank 145 through an internal bus. Register file 145 represents a memory area on processing core 159 for storing information including data. As previously mentioned, it will be appreciated that it is not critical that this storage area is used for storing packed data. Execution unit 142 is coupled to decoder 144 . Decoder 144 is used to decode instructions received by processing core 159 into control signals and/or microcode entry points. In response to these control signals and/or microcode entry points, execution unit 142 performs appropriate operations. In one embodiment, a decoder is used to interpret an instruction's opcode, which will indicate what operation should be performed on the corresponding data indicated within the instruction.

Processing core 159 is coupled to bus 141 for communicating with various other system devices, which may include, but are not limited to, for example, synchronous dynamic random access memory (SDRAM) controller 146, static random access memory (SRAM) ) controller 147, burst flash interface 148, personal computer memory card international association (PCMCIA)/compact flash (CF) card controller 149, liquid crystal display (LCD) controller 150, direct memory access (DMA) controller 151 , and an alternate bus master interface 152 . In one embodiment, data processing system 140 may also include I/O bridge 154 for communicating with various I/O devices via I/O bus 153 . Such I/O devices may include, but are not limited to, for example, universal asynchronous receiver/transmitter (UART) 155 , universal serial bus (USB) 156 , Bluetooth wireless UART 157 , and I/O expansion interface 158 .

One embodiment of data processing system 140 provides for mobile communications, network communications, and/or wireless communications, and provides processing core 159 capable of performing SIMD operations including text string comparison operations. The processing core 159 can be programmed with various audio, video, imaging and communication algorithms including discrete transforms such as Walsh-Hadamard transform, Fast Fourier Transform (FFT), Discrete Cosine Transform (DCT) and their corresponding inverses transform); compression/decompression techniques (eg, color space transform, video encoding motion estimation, or video decoding motion compensation); and modulation/demodulation (MODEM) functions (eg, pulse code modulation (PCM)).

Figure 1C illustrates further alternative embodiments of a data processing system capable of executing instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. According to an alternative embodiment, data processing system 160 may include main processor 166 , SIMD co-processor 161 , cache processor 167 , and input/output system 168 . Input/output system 168 may optionally be coupled to wireless interface 169 . SIMD coprocessor 161 is capable of performing operations including instructions according to one embodiment. Processing core 170 may be adapted to be manufactured in one or more processing technologies and, by being represented on a machine-readable medium in sufficient detail, may be adapted to facilitate manufacture of all or part of data processing system 160 including processing core 170 .

For one embodiment, SIMD coprocessor 161 includes execution unit 162 and a set of register files 164 . One embodiment of main processor 166 includes decoder 165 for identifying a plurality of instructions in instruction set 163 including instructions for execution by execution unit 162 according to one embodiment. For an alternative embodiment, SIMD coprocessor 161 also includes at least a portion of decoder 165B for decoding a plurality of instructions in instruction set 163 . Processing core 170 also includes additional circuitry (not shown) that is not necessary to understand embodiments of the present invention.

In operation, main processor 166 executes a stream of data processing instructions that control general types of data processing operations, including interaction with cache memory 167 and input/output system 168 . SIMD coprocessor instructions are embedded into this stream of data processing instructions. The decoder 165 of the main processor 166 recognizes these SIMD coprocessor instructions as the type that should be executed by the attached SIMD coprocessor 161 . Accordingly, the main processor 166 issues these SIMD coprocessor instructions (or control signals representing SIMD coprocessor instructions) on the coprocessor bus 171 from which they are received by any attached SIMD coprocessors to these instructions. In this case, SIMD coprocessor 161 will accept and execute any received SIMD coprocessor instructions for that SIMD coprocessor.

Data may be received via wireless interface 169 for processing by SIMD coprocessor instructions. For one example, a voice communication can be received in the form of a digital signal that can be instructed by a SIMD coprocessor to process the digital signal to regenerate digital audio samples representing the voice communication. For another example, compressed audio and/or video can be received in the form of a digital bitstream that can be processed by SIMD coprocessor instructions to regenerate audio samples and/or motion video frames. For one embodiment of the processing core 170, the main processor 166 and the SIMD coprocessor 161 are integrated into a single processing core 170 that includes an execution unit 162, a set of register banks 164, and a The decoder 165 of the multiple instructions in the instruction set 163 of the multiple instructions of an embodiment.

2 is a block diagram of the microarchitecture of a processor 200 that includes logic for executing instructions in accordance with one embodiment of the present invention. In some embodiments, an instruction according to one embodiment may be implemented as a pair of data types having a byte size, word size, doubleword size, quadword size, etc. and with numerous data types (eg, single and double precision integers and floating point numbers operate on data elements of type). In one embodiment, in-order front end 201 is the portion of processor 200 that fetches instructions to be executed and prepares them for later use in the processor pipeline. Front end 201 may include several units. In one embodiment, instruction prefetcher 226 fetches instructions from memory and feeds the instructions to instruction decoder 228, which then decodes or interprets the instructions. For example, in one embodiment, the decoder decodes received instructions into one or more machine-executable operations known as "microinstructions" or "microoperations" (also known as microops or uops) . In other embodiments, the decoder parses the instruction into opcodes and corresponding data and control fields that can be used by the microarchitecture to perform operations according to an embodiment. In one embodiment, trace cache 230 accepts decoded micro-ops and combines them into a program-ordered sequence or traces in uop queue 234 for execution. When the trace cache 230 encounters complex instructions, the microcode ROM 232 provides the uops needed to complete the operation.

Some instructions are converted into a single micro-op, while other instructions require several micro-ops to complete the complete operation. In one embodiment, if more than four micro-ops are required to complete an instruction, decoder 228 accesses microcode ROM 232 to execute the instruction. For one embodiment, the instruction may be decoded into a small number of micro-ops for processing at the instruction decoder 228 . In another embodiment, instructions may be stored in microcode ROM 232 if multiple micro-ops are required to complete the operation. The trace cache 230 references the entry point programmable logic array (PLA) to determine the correct microinstruction pointer to read the microcode sequence from the microcode ROM 232 to complete one or more instructions according to one embodiment. The machine's front end 201 resumes fetching the micro-ops from the trace cache 230 after the microcode ROM 232 completes the serialization of the micro-ops of the instruction.

The out-of-order execution engine 203 is where instructions are prepared for execution. The out-of-order execution logic has buffers used to smooth and reorder the instruction stream to optimize performance as the instruction stream goes down the pipeline and is scheduled for execution. The allocator logic allocates the machine buffers and resources each micro-op needs for execution. The register renaming logic renames multiple logical registers to multiple entries in the register bank. Before the instruction schedulers (memory scheduler, fast scheduler 202, slow/generic floating point scheduler 204, and simple floating point scheduler 206), the allocator is also two uop queues (one uop queue for memory operations, Another uop queue for non-memory operations) allocates entries for each uop in one of the queues. The uop schedulers 202, 204, 206 determine when uops are ready for execution based on the readiness status of their dependent input register operand sources and the availability of execution resources required by the uops to complete their operations. The fast scheduler 202 in one embodiment may schedule on every half of the master clock cycle, while other schedulers may schedule only once per master processor clock cycle. The scheduler arbitrates the allocation of ports to schedule uops for execution.

In execution block 211 , register sets 208 and 210 are located between schedulers 202 , 204 and 206 and execution units 212 , 214 , 216 , 218 , 220 , 222 and 224 . There are also separate register banks 208, 210 for integer and floating point operations, respectively. Each register bank 208, 210 in one embodiment also includes a bypass network that can bypass just-completed results that have not been written to the register bank or forward those results to new slave uops middle. Integer register set 208 and floating point register set 210 are also capable of passing data to each other. For one embodiment, the integer register set 208 is divided into two separate register sets, one register set for low-order 32-bit data and a second register set for high-order 32-bit data. The floating point register set 210 in one embodiment has entries that are 128 bits wide, since floating point instructions typically have operands from 64 to 128 bits wide.

Execution block 211 includes execution units 212, 214, 216, 218, 220, 222, and 224 in which instructions are actually executed. The block includes register banks 208 and 210 that store integer and floating point data operand values required for microinstruction execution. Processor 200 in one embodiment includes multiple execution units: address generation unit (AGU) 212 , AGU 214 , fast ALU 216 , fast ALU 218 , slow ALU 220 , floating point ALU 222 , and floating point move unit 224 . For one embodiment, floating point execution blocks 222 and 224 perform floating point, MMX, SIMD, SSE, and other operations. The floating-point ALU 222 in one embodiment includes a 64-bit/64-bit floating-point divider for performing division, square root, and remainder microops. For various embodiments of the present invention, floating-point hardware may be utilized to process instructions involving floating-point values. In one embodiment, ALU operations go to high-speed ALU execution units 216 and 218 . Fast ALUs 216 and 218 in one embodiment may perform fast operations with an effective latency of half a clock cycle. For one embodiment, most complex integer operations go to the slow ALU 220 because the slow ALU 220 includes integer execution hardware for long-latency type operations, such as multipliers, shifters, tag logic, and branch processing devices . Memory load/store operations are performed by AGUs 212 and 214 . For one embodiment, integer ALUs 216, 218, and 220 are described in the context of performing integer operations on 64-bit data operands. In alternate embodiments, ALUs 216, 218, and 220 may be implemented to support various data bits including 16, 32, 128, 256, and the like. Similarly, floating point units 222 and 224 may be implemented to support a range of operands with various bit widths. For one embodiment, floating point units 222 and 224 may operate on 128-bit wide packed data operands in conjunction with SIMD and multimedia instructions.

In one embodiment, uop schedulers 202, 204, and 206 dispatch slave operations before the parent load finishes executing. Since uops are speculatively scheduled and executed in processor 200, processor 200 also includes logic for handling memory misses. If a data load misses in the data cache, there will be running slave operations in the pipeline that leave the scheduler with temporarily incorrect data. The replay mechanism tracks and re-executes instructions that use incorrect data. Only dependent operations need to be replayed, while independent operations are allowed to complete. The scheduler and replay mechanism in one embodiment of the processor is also designed to capture instructions that provide general GF(256) SIMD cryptographic arithmetic functions.

The term "register" refers to an on-board processor storage location that is used as part of an instruction to identify operands. In other words, registers can be those available from outside the processor (from a programmer's perspective). However, the registers in the embodiments are not limited to representing a particular type of circuit. Rather, registers in an embodiment can store and provide data and perform the functions described herein. The registers described herein may be implemented by circuitry in the processor using any number of different techniques, eg, dedicated physical registers, dynamically allocated physical registers using register renaming, combinations of dedicated and dynamically allocated physical registers, and the like. In one embodiment, the integer registers store 32-bit integer data. The register bank in one embodiment also contains eight multimedia SIMD registers for packed data. For the following discussion, registers should be understood as data registers designed to hold packed data, such as the 64-bit wide MMX ^™ registers in MMX technology-enabled microprocessors from Intel Corporation, Santa Clara, CA, USA (Also called the 'mm' register in some instances). "These MMX registers (available in integer and floating-point formats) can operate with packed data elements that accompany SIMD and SSE instructions. Similarly, 128 involving SSE2, SSE3, SSE4, or newer techniques (collectively "SSEx") Bit-wide XMM registers can also be used to hold such packed data operands. In one embodiment, when storing packed data and integer data, the registers do not need to distinguish between these two types of data. In one embodiment, integer and floating Point data may be included in the same register bank, or be included in a different register bank. Also, in one embodiment, floating point and integer data may be stored in different registers, or be stored in the same in the register.

In the examples of the following figures, a number of data operands are depicted. Figure 3A illustrates various packed data type representations in a multimedia register according to one embodiment of the present invention. Figure 3A shows the data types of packed bytes 310, packed words 320, and packed double words (dwords) 330 for 128-bit wide operands. The packed byte format 310 of this example is 128 bits long and contains sixteen packed byte data elements. A byte is defined here as 8-bit data. The information for each byte data element is stored as: bits 7 to 0 for byte 0, bits 15 to 8 for byte 1, bits 23 to 16 for byte 2, and finally bits 23 to 16 for byte 15 Stored in bits 120 to 127. Therefore, all available bits are used in this register. This storage configuration increases the storage efficiency of the processor. Also, because sixteen data elements are accessed, an operation can now be performed on sixteen data elements in parallel.

Typically, data elements are separate pieces of data that are stored in a single register or memory location with other data elements of the same length. In packed data sequences involving SSEx techniques, the number of data elements stored in an XMM register is 128 bits divided by the bit length of the individual data elements. Similarly, in packed data sequences involving MMX and SSE techniques, the number of data elements stored in an MMX register is 64 bits divided by the bit length of the individual data elements. Although the data type shown in Figure 3A is 128 bits long, various embodiments of the present invention may also operate on operands of 64 bits wide, 256 bits wide, 512 bits wide, or other sizes. Packed word format 320 in this example is 128 bits long and contains eight packed word data elements. Each packed word contains sixteen bits of information. The packed doubleword format 330 of FIG. 3A is 128 bits long and contains four packed doubleword data elements. Each packed doubleword data element contains thirty-two bits of information. Packed quadwords are 128 bits long and contain two packed quadword data elements.

Figure 3B shows an alternative in-register data storage format. Each packed data may include more than one independent data element. Three packed data formats are shown: packed half data elements 341 , packed single data elements 342 and packed double data elements 343 . One embodiment of packed half data elements 341, packed single data elements 342, and packed double data elements 343 includes fixed point data elements. For alternative embodiments, one or more of packed half data elements 341, packed single data elements 342, and packed double data elements 343 may contain floating point data elements. An alternative embodiment of packed half data element 341 is one hundred and twenty-eight bits long and contains eight 16-bit data elements. An alternative embodiment of packed single data element 342 is one hundred and twenty-eight bits long and contains four 32-bit data elements. One embodiment of packed double data element 343 is one hundred and twenty-eight bits long and contains two 64-bit data elements. It will be appreciated that such packed data formats can be further extended to other register lengths, eg, 96 bits, 160 bits, 192 bits, 224 bits, 256 bits, 512 bits, or longer.

Figure 3C illustrates various signed and unsigned packed data type representations in a multimedia register according to one embodiment of the present invention. Unsigned packed byte representation 344 shows storing unsigned packed bytes in SIMD registers. The information for each byte data element is stored as: bits 7 to 0 for byte 0, bits 15 to 8 for byte 1, bits 23 to 16 for byte 2, and so on, and finally for Byte 15 is stored in bits 120 to 127. Therefore, all available bits are used in this register. This storage arrangement can improve the storage efficiency of the processor. Likewise, because sixteen data elements are accessed, an operation can be performed on sixteen data elements in parallel. Signed packed byte representation 345 shows the storage of signed packed bytes. Note that the eighth bit of each byte data element is the sign indicator. Unsigned packed word representation 346 shows how word 7 to word 0 are stored in SIMD registers. Signed packed word representation 347 is similar to unsigned packed word in-register representation 346. Note that the sixteenth bit of each word data element is the sign indicator. Unsigned packed doubleword representation 348 shows how doubleword data elements are stored. Signed packed doubleword representation 349 is similar to unsigned packed doubleword in-register representation 348. Note that the necessary sign bit is the thirty-second bit of each doubleword data element.

FIG. 3D is a comparison of " 64 and IA-32 Intel Architecture Software Developer's Manual Combined Volumes 2A and 2B: Instruction Set Reference AZ ( 64and IA-32 Intel ArchitectureSoftware Developer's Manual Combined Volume 2A and 2B:Instruction SetReference AZ)", an operation code (opcode) format 360 with 32 or more bits, and register/memory operations corresponding to the type of opcode format described in A depiction of one embodiment of a number addressing mode. In one embodiment, instructions may be encoded by one or more of fields 361 and 362. Up to two operand locations may be identified for each instruction, including multiple to the two source operand identifiers 364 and 365. For one embodiment, the destination operand identifier 366 is the same as the source operand identifier 364, while in other embodiments they are not the same. For alternative embodiments, the destination Operand identifier 366 is the same as source operand identifier 365, while in other embodiments they are not the same. In one embodiment, one of the source operands identified by source operand identifiers 364 and 365 is instructed to The result is overwritten, while in other embodiments, identifier 364 corresponds to the source register element and identifier 365 corresponds to the destination register element. For one embodiment, operand identifiers 364 and 365 may be used to identify 32-bit or 64-bit source and destination operands.

FIG. 3E is a depiction of another alternative operation encoding (opcode) format 370 having forty or more bits. Opcode format 370 corresponds to opcode format 360 and includes optional prefix bytes 378 . Instructions according to one embodiment may be encoded by one or more of fields 378 , 371 and 372 . By source operand identifiers 374 and 375 and by prefix byte 378, up to two operand positions may be identified for each instruction. For one embodiment, prefix bytes 378 may be used to identify 32-bit or 64-bit source and destination operands. For one embodiment, destination operand identifier 376 is the same as source operand identifier 374, while in other embodiments they are not the same. For alternate embodiments, destination operand identifier 376 is the same as source operand identifier 375, while in other embodiments they are not the same. In one embodiment, the instruction operates on one or more of the operands identified by operand identifiers 374 and 375 and overwrites the one identified by operand identifiers 374 and 375 with the result of the instruction or more operands, while in other embodiments the operand identified by identifiers 374 and 375 is written to another data element in another register. Opcode formats 360 and 370 allow register-to-register addressing, memory-to-register addressing, specified in part by MOD fields 363 and 373 and by optional scale-index-base and displacement bytes. Register addressing, memory-to-register addressing, register-to-register addressing, immediate-value-to-register addressing, register-to-memory addressing.

Turning next to FIG. 3F, in some alternative embodiments, 64-bit (or 128-bit, or 256-bit, or 512-bit or more) single-instruction-multiple-data (SIMD) arithmetic operations may be processed via coprocessor data ( CDP) instruction to execute. Opcode (opcode) format 380 depicts one such instruction with CDP opcode fields 382 and 389 . For alternate embodiments, this type of CDP instruction operation may be encoded by one or more of fields 383 , 384 , 387 , and 388 . Up to three operand locations may be identified for each instruction, including up to two source operand identifiers 385 and 390 and one destination operand identifier 386 . One embodiment of a coprocessor can operate on 8-bit, 16-bit, 32-bit and 64-bit values. For one embodiment, the instructions are executed on integer data elements. In some embodiments, the condition field 381 may be used to conditionally execute the instruction. For some embodiments, the source data size may be encoded by field 383 . In some embodiments, zero (Z), negative (N), carry (C), and overflow (V) detection may be performed on the SIMD field. For some instructions, the saturation type may be encoded by field 384.

Turning next to Figure 3G, which depicts a " Advanced Vector Extensions Programming Reference ( Another alternative opcode (opcode) format 397 for providing generic GF(256) SIMD cryptographic arithmetic functions according to another embodiment, corresponding to the opcode format types described in the Advanced Vector Extensions Programming Reference)".

The original x86 instruction set provided 1-byte opcodes with address bytes in various formats (syllable) and immediate operands included in additional bytes, where additional bytes were known from the first "opcode" byte. existence of bytes. In addition, there are certain byte values (called prefixes, since they must be placed before the instruction) that are reserved as modifiers to this opcode. When the original allocation of 256 opcode bytes (including these special prefix values) is exhausted, a single byte is dedicated to escape to the new set of 256 opcodes. Because of the addition of vector instructions (eg SIMD), the need for more opcodes is created even by extension using prefixes, and a "two-byte" opcode map is not sufficient. To do this, a new instruction is added to an additional map that uses two bytes plus an optional prefix as an identifier.

Additionally, to facilitate implementing additional registers in 64-bit mode, an additional prefix (called "REX") may be used between the prefix and the opcode (and any escape bytes necessary to determine that opcode). In one embodiment, the REX has 4 "payload" bits to indicate the use of additional registers in 64-bit mode. In other embodiments, the REX may have fewer or more than 4 bits. The general format of at least one instruction set (generally corresponding to format 360 and/or format 370) is shown generally as follows:

[prefixes][rex]escape[escape2]opcode modrm(etc)

The opcode format 397 corresponds to the opcode format 370 and includes an optional VEX prefix byte 391 (in one embodiment in hexadecimal, in place of most of the other commonly used legacy instruction prefix bytes and escape codes). C4 of the system starts). For example, the following shows an embodiment that uses two fields to encode instructions, which can be used when a second escape code is present in the original instruction, or when extra bits in the REX field (eg, XB and W fields) need to be used this example. In the embodiment shown below, legacy bounces are represented by new bounce values, legacy prefixes are fully compressed as part of a "payload" byte, legacy prefixes are restated and available for future extensions, p. The two-hop code is packed in the "map" field and a future map or feature space is available, and new features are added (eg, increased vector length and additional source register specifiers).

Instructions according to one embodiment may be encoded by one or more of fields 391 and 392 . Combining source opcode identifiers 374 and 375 via field 391, and in conjunction with optional scale-index-base (SIB) identifier 393, optional displacement identifier 394, and optional immediate byte 395, can be used for each entry. Instructions identify up to four operand positions. For one embodiment, the VEX prefix byte 391 may be used to identify 32-bit or 64-bit source and destination operands and/or 128-bit or 256-bit SIMD register or memory operands. For one embodiment, the functionality provided by opcode format 397 may form redundancy with opcode format 370, while in other embodiments they differ. Opcode formats 370 and 397 allow register-to-register addressing, memory-to-register addressing, specified by MOD field 373 and in part by optional (SIB) identifier 393, optional displacement identifier Register addressing, memory-to-register addressing, register-to-register addressing, immediate-value-to-register addressing, register-to-memory addressing.

Turning next to FIG. 3H, which depicts another alternative opcode (opcode) format 398 for providing push-in generic GF (256) SIMD cryptographic arithmetic functionality, according to another embodiment. Opcode format 398 corresponds to opcode formats 370 and 397 and includes the optional EVEX prefix byte 396 (in a example, starts with hexadecimal 62). Instructions according to one embodiment may be encoded by one or more of fields 396 and 392 . Combining source opcode identifiers 374 and 375 via field 396, and combining optional scale-index-base SIB identifier 393, optional displacement identifier 394, and optional immediate byte 395 , can be up to four operand positions and identity masks for each instruction. For one embodiment, EVEX prefix bytes 396 may be used to identify 32-bit or 64-bit source and destination operands and/or 128-bit, 256-bit, or 512-bit SIMD register or memory operands. For one embodiment, the functionality provided by opcode format 398 may form redundancy with opcode formats 370 or 397, while in other embodiments they are different. The opcode format 398 allows register-to-register addressing using masks specified by the MOD field 373 and in part by an optional (SIB) identifier 393, an optional displacement identifier 394, and an optional immediate byte 395 , memory-to-register addressing, memory-to-register addressing, register-to-register addressing, immediate-number-to-register addressing, register-to-memory addressing. The general format of at least one instruction set, which generally corresponds to format 360 and/or format 370, is shown generally as follows:

evex1RXBmmmmmm WvvvLpp evex4opcode modrm[sib][disp][imm]

For one embodiment, instructions encoded according to EVEX format 398 may have additional "payload" bits that are used to provide generic GF(256) SIMD cryptographic arithmetic functions, with additional new features, eg, user configurable Mask registers, or additional operands, or selections from 128-bit, 256-bit or 512-bit vector registers or more registers to be selected, etc.

For example, where VEX format 397 can be used to provide a generic GF(256) SIMD cryptographic arithmetic function with an implicit mask, EVEX format 398 can be used to provide a generic GF(256) SIMD with an explicit user-configurable mask Encrypted arithmetic functions. In addition, EVEX format 398 can be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functions on 128-bit or 256-bit vector registers, where VEX format 397 can be used to provide Generic GF(256) SIMD cryptographic arithmetic functions on (or smaller) vector registers.

Example instructions for providing generic GF(256) SIMD cryptographic arithmetic functions are shown by the following examples:

It will be appreciated that, as described in various embodiments described herein, generic GF(2 ⁿ ) SIMD encrypted arithmetic instructions can be used to provide arithmetic functions in a variety of applications, for example, in secure applications for financial transactions, Privacy, data integrity, authentication, message content authentication and message origin authentication encryption protocols and Internet communications for e-commerce, email, software distribution, data storage, etc.

It will also be understood that execution of instructions for at least the following is provided: (1) a SIMD affine transform specifying a source data operand, a transform matrix operand, and a transform vector, wherein the transform matrix is applied to the source data operand's each data element, and a transformation vector is applied to each transformed element; (2) SIMD binary finite field multiplication inversion, which is used to compute the inverse pair in the binary finite field for each element in the source data operands Irreducible polynomial modulo; (3) SIMD affine transform and multiplicative inverse (or multiplicative inverse and affine transform) specifying source data operands, transform matrix operands, and transform vectors, where before or after the multiply inverse operation , a transformation matrix is applied to each element in the source data operands, and a transformation vector is applied to each transformed element; (4) Modulo reduction, which is used to compute a The specific modulo polynomial p selected from the polynomials (which are provided by the instruction (or microinstruction) to provide modulo reduction for these specific polynomials) is reduced modulo; (5) SIMD binary finite field multiplication, which specifies the first and second Two source data operands, and are used to multiply and modulo the irreducible polynomial by pairs of elements corresponding to each of the first and second source data operands; wherein the results of these instructions are stored in SIMD destination registers and can provide general-purpose GF(256) and/or other alternative binary finite field SIMD cryptographic arithmetic functions in hardware and/or microcode sequences so as not to require excessive or excessive amounts of additional circuitry, area, or power The functional unit can then support significant performance improvements for several important performance-critical applications.

4A is a block diagram illustrating an in-order pipeline and a register renaming stage, an out-of-order issue/execution pipeline in accordance with at least one embodiment of the present invention. 4B is a block diagram illustrating an in-order architecture core and register renaming logic, out-of-order issue/execution logic to be included in a processor in accordance with at least one embodiment of the present invention. The solid-line boxes in Figure 4A show an in-order pipeline, while the dashed-line boxes show a register-renaming, out-of-order issue/execution pipeline. Similarly, the solid-line boxes in Figure 4B show in-order architectural logic, while the dashed-line boxes show register renaming logic and out-of-order issue/execution logic.

In Figure 4A, processor pipeline 400 includes fetch stage 402, length decode stage 404, decode stage 406, allocate stage 408, rename stage 410, schedule (also known as dispatch or issue) stage 412, register read/memory Read stage 414 , execute stage 416 , write back/memory write stage 418 , exception handling stage 422 and commit stage 424 .

In Figure 4B, arrows indicate coupling between two or more units, and the direction of the arrows indicates the direction of data flow between those units. FIG. 4B shows processor core 490 including front end unit 430 coupled to execution engine unit 450 , both of which are coupled to memory unit 470 .

Cores 490 may be reduced instruction set computing (RISC) cores, complex instruction set computing (CISC) cores, very long instruction word (VLIW) cores, or mixed or alternative core types. As yet another option, the cores 490 may be dedicated cores, eg, network or communication cores, compression engines, graphics cores, and the like.

Front end unit 430 includes branch prediction unit 432 coupled to instruction cache unit 434, which is coupled to instruction translation lookaside buffer (TLB) 436, which is coupled to instruction fetch unit 438, The instruction fetch unit is coupled to decode unit 440 . A decode unit or decoder may decode the instruction and generate one or more micro-operations, microcode entry points, micro-instructions that are decoded from, or otherwise reflect, or derived from the original instruction , other commands, or other control signals as output. The decoder can be implemented using a variety of 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. Instruction cache unit 434 is also coupled to a second level (L2) cache unit 476 in memory unit 470 . Decode unit 440 is coupled to rename/distributor unit 452 in execution engine unit 450 .

Execution engine unit 450 includes a rename/distributor unit 452 coupled to a set of retirement unit 454 and one or more scheduler units 456 . Scheduler unit 456 represents any number of different schedulers, including reservation stations, central command windows, and the like. Scheduler unit 456 is coupled to physical register bank unit 458 . Each physical register bank unit 458 represents one or more physical register banks, where different physical register banks store one or more different data types (such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer , vector floating point, etc.), state (such as an instruction pointer which is the address of the next instruction to be executed), and so on. Physical register bank unit 458 is overridden by retirement unit 454 to illustrate the various ways in which register renaming and out-of-order execution can be achieved (eg, using reorder buffers and retirement register banks; using future files, history buffers registers and retirement register banks; using register maps and register pools, etc.). Typically, architectural registers are visible from outside the processor or from the programmer's perspective. These registers are not limited to any known particular circuit type. Various types of registers are suitable so long as they can store and provide the data described herein. Examples of suitable registers include, but are not limited to, dedicated physical registers, dynamically allocated physical registers using register renaming, and combinations of dedicated physical registers and dynamically allocated physical registers, among others. Retirement unit 454 and physical register set unit 458 are coupled to execution cluster 460 . Execution cluster 460 includes a set of one or more execution units 462 and a set of one or more memory access units 464 . Execution unit 462 may perform various operations (eg, shift, add, subtract, multiply) and may perform on various data types (eg, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). 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. Scheduler unit 456, physical register file unit 458, and execution cluster 460 are shown as possibly plural, as some embodiments create multiple separate pipelines (eg, each with their own scheduler unit) for certain data/operation types. , scalar integer pipelines, physical register file units and/or execution clusters, scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipelines, and/or memory access pipelines; and in the case of separate memory access pipelines , some embodiments are implemented such that only the execution clusters of the pipeline have memory access units 464). 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.

The set of memory access units 464 are coupled to memory units 470 including a data TLB unit 472 that is coupled to a cache unit 474 that is coupled to a second level (L2) cache unit 476 . In one exemplary embodiment, memory access unit 464 may include a load unit, a store address unit, and a store data unit, each of which is coupled to data TLB unit 472 in memory unit 470 . L2 cache unit 476 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 400 in the following manner: 1) instruction fetcher 438 performs fetch and length decode stages 402 and 404; 2) decode unit 440 performs decode stage 406; 3) rename/allocator unit 452 performs allocation stage 408 and rename stage 410; 4) scheduler unit 456 performs dispatch stage 412; 5) physical register bank unit 458 and memory unit 470 perform register read/memory read stage 414; execution cluster 460 implements execution stage 416; 6) memory unit 470 and physical register set unit 458 perform write back/memory write stage 418; 7) various units may be involved in exception handling stage 422; and 8) retirement Unit 454 and physical register bank unit 458 perform commit stage 424 .

The core 490 may support one or more instruction sets (eg, the x86 instruction set (with some extensions that add newer versions), the MIPS instruction set from MIPS Technologies, Inc., Sunnyvale, Calif., the ARM, Sunnyvale, Calif. The holding company's ARM instruction set (with optional additional extensions such as NEON).

It should be understood that a core may support multithreaded operations (performing a collection of two or more operations or threads in parallel), and that this multithreading may be accomplished in various ways, including time division multithreading, simultaneous multithreading, and multithreading. Threading (where a single physical core provides a logical core for each of the threads that the physical core is simultaneously multithreading), or a combination thereof (eg, time division fetch and decode followed by simultaneous multithreading (eg, with Hyper-Threading Technology)).

Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. Although the illustrated embodiment of the processor also includes separate instruction and data cache units 434/474 and a shared L2 cache unit 476, alternative embodiments may have a single internal cache for both instruction and data A cache, such as, for example, a first level (L1) internal cache, or multiple levels of internal caches. In some embodiments, the system may include a combination of internal cache and external cache external to the core and/or processor. Alternatively, all caches can be external to the core and/or processor.

5 is a block diagram of a single-core processor and a multi-core processor 500 with an integrated memory controller and graphics device in accordance with various embodiments of the present invention. The solid-line box of FIG. 5 shows a processor 500 having a single core 502A, a system agent 510 , a set of one or more bus controller units 516 , while an optional additional dashed-line box shows an alternative processor 500 , which has a plurality of cores 502A-N, a set of one or more integrated memory controller units 514 located in a system agent unit 510, and integrated graphics logic 508.

The memory hierarchy includes one or more cache levels within the core, a set of one or more shared cache units 506 , and external memory (not shown) coupled to the set of integrated memory controller units 514 . The set of shared cache units 506 may include one or more mid-level caches, such as second-level (L2), third-level (L3), fourth-level (L4) or other level caches, last-level caches (LLC) and/or combinations of the above. Although in one embodiment a ring-based interconnect unit 512 interconnects the integrated graphics logic 508, the set of shared cache units 506, and the system proxy unit 510, alternative embodiments may use any number of well-known techniques to interconnect these units.

In some embodiments, one or more of the cores 502A-N are capable of multi-threaded operations. System agent 510 includes those components that coordinate and operate cores 502A-N. The system agent unit 510 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or may include logic and components required to regulate the power states of cores 502A-N and integrated graphics logic 508 . The display unit is used to drive one or more externally connected displays.

The cores 502A-N may be homogeneous or heterogeneous in terms of architecture and/or instruction set. For example, some of the cores 502A-N may be ordered while others are unordered. As another example, two or more of cores 502A-N can execute the same instruction set, while other cores can execute only a subset of the instruction set or execute different instruction sets.

The processor may be a general purpose processor such as a Core ^™ i3, i5, i7, 2Duo and Quad, Xeon ^™ , Itanium ^™ , XScale ^™ or StrongARM ^™ processors, all available from Obtained from Intel Corporation of Santa Clara, California. Alternatively, the processor may be from another company, such as from ARM Holdings, MIPS, or the like. The processor may be a special purpose processor, eg, a network or communications processor, a compression engine, a graphics processor, a coprocessor, an embedded processor, and the like. The processor may be implemented on one or more chips. Processor 500 may be part of one or more substrates and/or implemented on one or more substrates using any of a variety of process technologies, such as BiCMOS, CMOS, or NMOS.

6-8 are exemplary systems suitable for including processor 500, while FIG. 9 is an exemplary system-on-a-chip (SoC) that may include one or more of 502. FIG. Known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, Other system designs and configurations for video game devices, set-top boxes, microcontrollers, cellular telephones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a variety of systems or electronic devices capable of incorporating the processors and/or other execution logic disclosed herein are generally suitable.

Referring now to FIG. 6, shown is a block diagram of a system 600 according to one embodiment of the present invention. System 600 may include one or more processors 610 and 615 coupled to graphics memory controller hub (GMCH) 620 . The optional nature of the additional processor 615 is represented in FIG. 6 by dashed lines.

Each processor 610 , 615 may be some version of processor 500 . However, it should be noted that integrated graphics logic and integrated memory control units are unlikely to be present in processors 610 and 615 . 6 shows that GMCH 620 may be coupled to memory 640, which may be, for example, dynamic random access memory (DRAM). For at least one embodiment, the DRAM may be associated with a non-volatile cache.

GMCH 620 may be a chipset or part of a chipset. The GMCH 620 may communicate with the processors 610 and 615 and control the interaction between the processors 610 , 615 and the memory 640 . GMCH 620 may also serve as an acceleration bus interface between processors 610 , 615 and other elements in system 600 . For at least one embodiment, GMCH 620 communicates with processors 610 and 615 via a multidrop bus, such as a front side bus (FSB) 695 .

Additionally, the GMCH 620 is coupled to a display 645 (such as a flat panel display). GMCH 620 may include an integrated graphics accelerator. The GMCH 620 is also coupled to an input/output (I/O) controller hub (ICH) 650 , which may be used to couple various peripherals to the system 600 . An external graphics device 660 , which may be a separate graphics device coupled to the ICH 650 , is shown by way of example in the embodiment of FIG. 6 , along with another peripheral device 670 .

Alternatively, additional or different processors may also be present in system 600 . For example, additional processors 615 may include the same additional processors as processor 610, additional processors heterogeneous or asymmetric to processor 610, accelerators (eg, graphics accelerators or digital signal processing (DSP) units), field programmable gate array or any other processor. Various differences may exist between physical resources 610 and 615 in a range of quality metrics including architecture, micro-architecture, thermal and power consumption characteristics. These differences would effectively appear as asymmetries and heterogeneities between processors 610 and 615 . For at least one embodiment, the various processors 610 and 615 may reside in the same die package.

Referring now to FIG. 7, shown is a block diagram of a second system 700 in accordance with an embodiment of the present invention. As shown in FIG. 7 , the multiprocessor system 700 is a point-to-point interconnect system and includes a first processor 770 and a second processor 780 that are coupled via a point-to-point interconnect 750 . Each of processors 770 and 780 may be some version of processor 500 (eg, one or more of processors 610, 615).

Although shown with only two processors 770 and 780, it should be understood that the scope of the present invention is not limited in this regard. In other embodiments, one or more additional processors may be present in a given processor.

Processors 770 and 780 are shown to include integrated memory controller units 772 and 782, respectively. Processor 770 also includes point-to-point (P-P) interfaces 776 and 778 as part of its bus controller unit; similarly, second processor 780 includes P-P interfaces 786 and 788. Processors 770 and 780 may exchange information via P-P interface 750 using point-to-point (P-P) interface circuits 778 and 788 . As shown in Figure 7, IMCs 772 and 782 couple the processors to respective memories, namely memory 732 and memory 734, which may be portions of main memory locally attached to the respective processors.

Processors 770 , 780 may each exchange information with chipset 790 via respective P-P interfaces 752 and 754 using point-to-point interface circuits 776 , 794 , 786 and 798 . Chipset 790 may also exchange information with high-performance graphics circuitry 738 via high-performance graphics interface 739 .

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

Chipset 790 may be coupled to first bus 716 via interface 796 . In one embodiment, the first bus 716 may be a Peripheral Component Interconnect (PCI) bus or a bus such as a PCI Express bus or another third-generation I/O interconnect bus, although the scope of the invention is not limited in this regard .

As shown in FIG. 7 , the various I/O devices 714 may be coupled to the first bus 716 along with a bus bridge 718 that couples the first bus 716 to the second bus 720 . In one embodiment, the second bus 720 may be a low pin count (LPC) bus. Various devices may be coupled to the second bus 720, in one embodiment, these devices include, for example, a keyboard and/or mouse 722, communication devices 727, and other mass storage such as disk drives or other mass storage that may include instructions/code and data 730 A storage unit 728 such as a device. Additionally, audio I/O 724 may be coupled to second bus 720 . Note that other architectures are possible. For example, instead of the point-to-point architecture of Figure 7, the system may implement a multi-drop bus or other such architecture.

Referring now to FIG. 8, shown is a block diagram of a third system 800 in accordance with an embodiment of the present invention. Similar elements in Figures 7 and 8 have been given similar reference numerals, and certain aspects of Figure 7 have been omitted from Figure 8 to avoid obscuring other aspects of Figure 8 .

8 shows that processors 870 and 880 may include integrated memory and I/O control logic ("CL") 872 and 882, respectively. For at least one embodiment, CLs 872 and 882 may include integrated memory controller units such as those described above in connection with FIGS. 5 and 7 . Additionally, the CLs 872, 882 may also include I/O control logic. FIG. 8 shows that not only memory 832 and 834 are coupled to CLs 872 and 882 , but I/O device 814 is also coupled to control logic 872 and 882 . Conventional I/O devices 815 are coupled to chipset 890 .

Referring now to FIG. 9, shown is a block diagram of an SoC 900 in accordance with an embodiment of the present invention. Similar components in Figure 5 have the same reference numerals. Also, the dotted box is an optional feature on more advanced SoCs. In FIG. 9, interconnect unit 902 is coupled to: application processor 910, which includes a set of one or more cores 502A-N and shared cache unit 506; system proxy unit 510; bus controller unit 516; integrated memory Controller unit 514; set of one or more media processors 920, which may include integrated graphics logic 508, image processor 924 for providing still and/or video camera functions, audio processor for providing hardware audio acceleration 926. A video processor 928 for providing video encoding/decoding acceleration, a static random access memory (SRAM) unit 930; a direct memory access (DMA) unit 932; and a display unit 940 for coupling to one or more an external monitor.

10 illustrates a processor, including a central processing unit (CPU) and a graphics processing unit (GPU), that can execute at least one instruction according to one embodiment. In one embodiment, instructions to perform operations in accordance with at least one embodiment may be executed by a CPU. In another embodiment, the instructions may be executed by a GPU. In yet another embodiment, the instructions may be executed by a combination of operations performed by the GPU and the CPU. For example, in one embodiment, instructions according to one embodiment may be received and decoded for execution on a GPU. However, one or more operations in the decoded instructions may be performed by the CPU and the results returned to the GPU for eventual retirement of the instructions. Rather, in some embodiments, the CPU may act as the main processor and the GPU as the co-processor.

In some embodiments, instructions that benefit from a highly parallelized throughput processor may be executed by a GPU, while instructions that benefit from the performance of processors that benefit from a deeply pipelined architecture may be executed by a CPU. For example, graphics, scientific applications, financial applications, and other parallel workloads can benefit from the performance of GPUs and be executed accordingly, while more serialized applications (eg, operating system kernels or application code) are more suitable for CPUs.

In FIG. 10, the processor 1000 includes a CPU 1005, a GPU 1010, an image processor 1015, a video processor 1020, a USB controller 1025, a UART controller 1030, a SPI/SDIO controller 1035, a display device 1040, a high-definition Multimedia Interface (HDMI) Controller 1045, MIPI Controller 1050, Flash Memory Controller 1055, Double Data Rate (DDR) Controller 1060, Security Engine 1065, I2S/I2C ⁽ Integrated Cross ^- Chip Sound/ Cross-Integrated Circuit ) interface 1070. Other logic and circuitry, including more CPUs or GPUs and other peripheral device interface controllers, may be included in the processor of FIG. 10 .

One or more aspects of at least one embodiment may be implemented by representational data stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, causes the representational data to Machines are used to manufacture logic that performs the techniques described herein. Such representations (so-called "IP cores") may be stored on tangible machine-readable media ("tape") and provided to various customers or production facilities for loading into the actual production logic or processor in the manufacturing machine. For example, IP cores such as the Cortex ^™ processor family developed by ARM Holdings and the Loongson IP core developed by the Institute of Computer Technology (ICT) of the Chinese Academy of Sciences may be licensed or sold to various customers or licensees, such as Texas Instruments, Qualcomm, Apple, or Samsung, and implemented in processors produced by these customers or licensees.

Figure 11 shows a block diagram of IP core development according to one embodiment. Storage device 1130 includes simulation software 1120 and/or hardware or software models 1110 . In one embodiment, data representing the IP core design may be provided to storage device 1130 via memory 1140 (eg, hard disk), wired connection (eg, the Internet) 1150 , or wireless connection 1160 . The IP core information generated by the simulation tools and models can then be sent to a production facility where the IP core information can be manufactured by a third party to execute at least one instruction in accordance with at least one embodiment.

In some embodiments, the one or more instructions may correspond to a first type or architecture (eg, x86), and may be translated or emulated on a different type or architecture of processor (eg, ARM). According to one embodiment, instructions may thus be executed on any processor or processor type, including ARM, x86, MIPS, GPU, or other processor types or architectures.

Figure 12 shows how instructions of the first type are emulated by different types of processors, according to one embodiment. In Figure 12, program 1205 contains some instructions that may perform the same or substantially the same function as the instructions according to one embodiment. However, the instructions of program 1205 may be of a different or incompatible type and/or format than processor 1215, which means that instructions of the type in program 1205 cannot be natively executed by processor 1215. However, by means of emulation logic 1210, the instructions of program 1205 are converted into instructions that can be natively executed by processor 1215. In one embodiment, the emulation logic is embodied in hardware. In another embodiment, the emulation logic is embodied in a tangible machine-readable medium containing instructions for converting such instructions in program 1205 into a type that can be executed natively by processor 1215 software. In other embodiments, the emulation logic is a combination of fixed-function or programmable hardware and a program stored on a tangible machine-readable medium. In one embodiment, the processor contains emulation logic, while in other embodiments the emulation logic is external to the processor and provided by a third party. In one embodiment, a processor is capable of loading emulation logic embodied in a tangible machine-readable medium containing software by executing microcode or firmware included in or associated with the processor.

13 is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set in accordance with various embodiments of the present invention. In the illustrated embodiment, the instruction translator is a software instruction translator, but may alternatively be implemented in software, firmware, hardware, or various combinations thereof. 13 shows that x86 compiler 1304 can be used to compile programs utilizing high-level language 1302 to generate x86 binary code 1306 that can be natively executed by processor 1316 having at least one x86 instruction set core. A processor with at least one x86 instruction set core 1316 means any processor capable of performing substantially the same functions as an Intel processor with at least one x86 instruction set core by compatibly executing or otherwise processing: (1 ) an essential part of the instruction set of an Intel x86 instruction set core or (2) is designed to run on an Intel processor with at least one x86 instruction set core to achieve substantially the same results as an Intel processor with at least one x86 instruction set core the object code version of the application or other software. The x86 compiler 1304 represents a compiler that can be used to generate x86 binary code 1306 (eg, object code) capable of processing at least one x86 instruction set core with or without additional linking processing is executed on the device 1316. Similarly, FIG. 13 shows that an alternative instruction set compiler 1308 may be used to compile a program using the high-level language 1302 to generate a program that can be executed by a processor 1314 that does not have at least one x86 instruction set core (eg, with a Sunnyvale California Alternate instruction set binary code 1310 natively executed by processors of MIPS instruction set cores of MIPS Technologies, Inc., and/or processors executing ARM instruction set cores of ARM Holdings, Inc. of Sunnyvale, Calif. The instruction converter 1312 is used to convert x86 binary code 1306 into code that can be natively executed by a processor 1314 that does not have an x86 instruction set core. The transformed code is unlikely to be the same as the alternative instruction set binary code 1310, as it is difficult to manufacture an instruction converter that can accomplish such; however, the transformed code will perform the normal operation and be composed of the instructions in the alternative instruction set. Thus, instruction translator 1312 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 1306.

Figure 14 shows a flowchart of one embodiment of a process 1401 for efficiently implementing the Advanced Encryption Standard (AES) encryption/decryption standard. Process 1401 and other processes disclosed herein are performed by processing blocks, which may include special purpose hardware or software or firmware opcodes executable by a general purpose machine or by a special purpose machine or by a combination of both. In one embodiment, the composite field GF((2 ⁴ ) ² ) and the irreducible polynomials x ⁴ +x ² +x+1 and x ² +2x+0xE can be used for the AES inverse column hybrid transform.

In processing block 1411, an input block of 128 bits comprising 16 byte values is XORed with the round key. In process block 1412, it is determined whether the process is encryption, in which case processing continues from point 1418, or if the process is decryption, in which case processing resumes in process block 1413.

In processing block 1413, a domain conversion circuit is used to separately convert each of the 16 byte values from the corresponding polynomial representation in GF(256) to another corresponding in the composite field GF((2 ⁴ ) ² ) polynomial representation of . For one embodiment of processing block 1413, the polynomial in GF(256) represents [a ₇ ,a ₆ ,a ₅ ,a ₄ ,a ₃ by multiplying each byte value by an 8-bit by 8-bit transformation matrix ,a ₂ ,a ₁ ,a ₀ ] can be transformed into the corresponding polynomial representations in the composite field GF((2 ⁴ ) ² ) [b ₇ ,b ₆ ,b ₅ ,b ₄ ,b ₃ ,b ₂ ,b ₁ ,b ₀ ], which can be achieved by the following series of XORs:

b ₁ =a ₇ ,

At this time, the 16 bytes can be regarded as a 4x4 byte block with four rows and four columns. In processing block 1414, it is determined whether the current round is the last round/special round, in which case no inverse column mixing is performed, otherwise, in processing block 1415, the inverse column mixing circuit is used In computing the inverse column hybrid transform of the 16-byte values in GF((2 ⁴ ) ² ) to obtain the corresponding transformed polynomial representation in GF((2 ⁴ ) ² ). For one embodiment, the inverse column blending transform in GF((2 ⁴ ) ² ) of the 16-byte input value can be performed as follows:

It will be appreciated that by computing the unique terms required to perform the multiplication by the matrix constants in the expression for each result in the first stage, and then summing these unique terms to generate each result, it is possible to obtain a value in GF((2 ⁴ ) ² ) perform such matrix multiplications for [a ₃ , a ₂ , a ₁ , a ₀ , b ₃ , b ₂ , b ₁ , b ₀ ]. For example, the unique items from the nibble [a ₃ ,a ₂ ,a ₁ ,a ₀ ] needed to compute the above matrix multiplication are:

The only items from the nibble [b ₃ ,b ₂ ,b ₁ ,b ₀ ] needed to compute the above matrix multiplication are:

In either case determined in processing block 1414, in processing block 1416, a hard-wired row permutation is performed on the 16-byte values corresponding to the inverse row blending transform. In processing block 1417, a second domain conversion circuit is used to convert each of the corresponding transformed polynomial representations in GF((2 ⁴ ) ² ) and also to apply affine transformations to generate divisions GF((( The third corresponding polynomial representation in a finite field other than 2 ⁴ ) ² ). In one embodiment of process 1401, the new finite field other than GF((2 ⁴ ) ² ) is the composite field GF((2 ² ) ⁴ ). This embodiment is described in more detail below with reference to FIG. 2 . In an alternate embodiment of process 1401, the new finite field is the original field GF (256). These embodiments are described in more detail below with reference to Figures 3a and 3b.

Continuing from point 1418, a multiplication-inversion circuit is used in processing block 1420 to compute for each of the third corresponding polynomial representations of the 16-byte values, respectively, in addition to GF((2 ⁴ ) ² ) The corresponding multiplicative inverse polynomial representation in the new finite field of . In process block 1421, it is determined whether the process is decryption, in which case the round of processing is completed and the result is output in process block 1426, or if the process is encryption, in which case the process is in process Block 1422 resumes.

In processing block 1422, circuitry is used to apply an affine transformation to each of the corresponding multiplicative inverse polynomial representations of the 16 byte values to generate a new finite value at a different one than GF((2 ⁴ ) ² ), respectively The transformed corresponding polynomial representation in the domain. If that new finite field is not the original field GF (256), then in block 1422, another field transform may incorporate circuitry to convert each corresponding transformed polynomial representation back to the original field GF (256). Therefore, the polynomial representation of the remainder of the process 1401 can be assumed to be in the original field GF(256).

In processing block 1423, a hardwired row permutation is performed on the 16-byte values, corresponding to a forward row mix transform. In processing block 1424, it is determined whether the current round is the last round/special round, in which case no column mixing is performed, otherwise, in processing block 1425, the forward column mixing circuit is used The forward column blend transform of the 16-byte values is computed in GF(256) to obtain the corresponding transformed polynomial representation in GF(256). It will be appreciated that since the coefficients in the forward column mixing transform in GF(256) are relatively small, in processing block 1425, no alternative domain representation is used. Finally, the round of process 1401 is completed, and in processing block 1426, the 16-byte result is output.

Figure 15 shows a flowchart of one embodiment of a process 1501 for efficiently implementing the multiplicative inversion of an AES S-box. In one embodiment shown below, the composite field GF((2 ² ) ⁴ ) can be used for the S-box transform in conjunction with the irreducible polynomial x ⁴ +x ³ +x ² +2 .

Continuing from point 1418 of process 1401, at process block 1518, it is determined whether the process is encryption, in which case processing continues at process block 1519. Otherwise, if the process is decryption, the domain conversion has been performed in processing block 1417, and the third corresponding polynomial representation of the 16-byte value is in the composite field GF((2 ² ) ⁴ ). For one embodiment of processing block 1417, an inverse affine transform may be applied by multiplying each byte value by an 8-bit by 8-bit transformation matrix and some XOR (ie, bitwise inversion) with a constant, And the polynomial representation in GF((2 ⁴ ) ² ) [a ₇ ,a ₆ ,a ₅ ,a ₄ ,a ₃ ,a ₂ ,a ₁ ,a ₀ ] can be transformed into the composite field GF((2 ² ) ⁴ ) in the corresponding polynomial representation [b ₇ ,b ₆ ,b ₅ ,b ₄ ,b ₃ ,b ₂ ,b ₁ ,b ₀ ], which can be achieved by the following series of XORs:

In processing block 1519, a domain conversion is required for the encryption process, so a domain conversion circuit is used to convert each of the 16 byte values separately from the corresponding polynomial representation in GF(256) to the composite field GF((( 2 ² ) ⁴ ) corresponding polynomial representation. For one embodiment of processing block 1519, the polynomial in GF(256) represents [a ₇ ,a ₆ ,a ₅ ,a ₄ ,a ₃ by multiplying each byte value by an 8-bit by 8-bit transformation matrix , a ₂ ,a ₁ ,a ₀ ] can be transformed into the corresponding polynomial representations in the composite field GF((2 ² ) ⁴ ) [b ₇ ,b ₆ ,b ₅ ,b ₄ ,b ₃ ,b ₂ ,b ₁ , b ₀ ], which can be achieved by the following series of XORs:

In processing block 1520, an inversion circuit is used to compute the multiplicative inverse variate polynomial representation in GF((2 ² ) ⁴ ) for each polynomial representation of the 16 byte values in GF((2 ² ) ⁴ ), respectively . For one embodiment, the relationship between the input [a,b,c,d] and the multiplicative inverse [A,B,C,D] corresponding to the polynomial representation in the composite field GF((2 ² ) ⁴ ) is as follows:

in, and '·' represent GF(2 ² ) addition and multiplication, respectively.

The solution is: A=Δ ^-1 ·Δ _a , B=Δ ^-1 ·Δ _b , C=Δ ^-1 ·Δ _c , D=Δ ^-1 ·Δ _d , where the determinant Δ is given as:

And the determinants Δ _a , Δ _b , Δ _c and Δ _d are derived from Δ by substituting {0,0,0,1} for the first, second, third and fourth columns of Δ, respectively. Once again it will be understood that unique terms such as a2, b2, a3, ^{3 · b2} , etc. and the unique sum ^of the required terms can be computed in hardware by extending the determinant computation, and then for a particular The terms are summed in combination to generate the necessary results to implement such computations in GF(2 ² ).

In process block 1521, it is determined whether the process is decryption, in which case processing continues in process block 1522. In processing block 1522, another domain conversion circuit is used to separately convert each of the 16 byte values from the corresponding polynomial representation in the composite field GF((2 ² ) ⁴ ) to the corresponding polynomial representation in GF(256) Polynomial representation. For one embodiment of processing block 1522, the polynomial in the composite field GF((2 ² ) ⁴ ) represents [a ₇ , a ₆ , a ₅ by multiplying each byte value by an 8-bit by 8-bit transformation matrix ,a ₄ ,a ₃ ,a ₂ ,a ₁ ,a ₀ ] can be transformed into the corresponding polynomial representations in GF(256) [b ₇ ,b ₆ ,b ₅ ,b ₄ ,b ₃ ,b ₂ ,b ₁ ,b ₀ ], which can be achieved by the following series of XORs:

Otherwise, if the process is encryption, processing continues to process block 1421 in process 1401. As explained with reference to processing block 1422 in process 1401, the circuitry used in processing block 1422 to apply an affine transform to 16 bytes may be combined with the domain conversion circuit of this embodiment to convert the 16 bytes Values are converted from the polynomial representation in GF((2 ² ) ⁴ ) to the corresponding polynomial representation in GF(256). For one embodiment of processing block 1422, by multiplying each byte value by an 8-bit by 8-bit transformation matrix and XORing (ie, bit-wise inversion) with some constant, an affine transformation can be applied, and the composite field GF The polynomial representations in ((2 ² ) ⁴ ) [a ₇ ,a ₆ ,a ₅ ,a ₄ ,a ₃ ,a ₂ ,a ₁ ,a ₀ ] can be converted to the corresponding polynomial representations in GF(256)[ b ₇ ,b ₆ ,b ₅ ,b ₄ ,b ₃ ,b ₂ ,b ₁ ,b ₀ ], which can be achieved by the following series of XORs:

Figure 16A shows a diagram of one embodiment of an apparatus 1601 for executing affine map instructions for affine transformations to provide general GF(256) SIMD cryptographic arithmetic functions. In some embodiments, devices 1601 may be replicated 16 times, each device 1601 comprising a 128-bit block for efficiently implementing a 128-bit block consisting of 16 byte values (each byte having a polynomial representation in GF(256)). The hardware processing block of the affine transformation. In other embodiments of affine map instructions (or microinstructions), element sizes may also be specified, and/or the number of copies of device 1601 may be selected to enable affine to 128-bit blocks or 256-bit blocks or 512-bit blocks, etc. transform. Various embodiments of apparatus 1601 may be part of pipeline 400 (eg, execution stage 416) or part of core 490 (eg, execute affine map instructions for providing generic GF(256) SIMD cryptographic arithmetic functions) unit 462). Various embodiments of apparatus 1601 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for affine transforms in GF(256). In some embodiments, affine map instructions may be implemented by microinstructions (or microops, microops, or uops)—eg, a finite field matrix-vector multiply microinstruction followed by a finite field vector addition (XOR) microinstruction.

For example, various embodiments of apparatus 1601 may be coupled with a SIMD vector register (eg, physical register bank unit 458 ) that includes m adjustable values for storing m variable numbers of variable sized data elements A variable number of variable size data fields. Some embodiments of affine map instructions for providing generic GF(256) SIMD affine transform functions specify source data operand element set 1612, transform matrix 1610 operands, and transform vector 1614 operands. In response to the decoded affine map instruction, one or more execution units (e.g., execution unit 462 ) pass the eight bitwise ANDs (AND) through the GF(256) byte multiplier array in processing block 1602 1627-1620, apply transform matrix 1610 operands to each element 1612 in source data operand set (eg, in 128-bit blocks of 16-byte elements), and via GF(256)-bit addition in processing block 1603 The eight 9-input XORs 1637-1630 of the transformer array apply a transform vector 1614 to perform a SIMD affine transform on each transformed element in the source data operand set. The affine transformed result element 1618 of each element 1612 in the source data operand set of the affine map instruction is stored in a SIMD destination register (eg, in physical register bank unit 458).

Figure 16B shows a diagram of one embodiment of an apparatus 1605 for executing an affine inversion instruction for performing an affine transformation and then computing the multiplicative inverse of the result to provide a generic GF (256) SIMD encrypted arithmetic functions. Various embodiments of apparatus 1605 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, core 490 ) for executing affine inversion instructions for providing generic GF(256) SIMD cryptographic arithmetic functions execution unit 462). Embodiments of apparatus 1605 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for affine transformation and inversion in GF(256) . In some embodiments, affine inversion instructions may be implemented by microinstructions (or microops, microops, or uops)—eg, affine map 1601 microinstructions followed by finite field multiplication inversion microinstructions 1604. In alternative embodiments, affine inversion instructions may be implemented by different uops—eg, finite field matrix-vector multiply uops followed by byte broadcast uops, finite field vector addition (XOR) uops, and finite field vector addition (XOR) uops Field multiplication inversion microinstruction.

Various embodiments of apparatus 1605 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of affine inversion instructions for providing generic GF(256) SIMD affine transform functions and subsequent computation of multiplicative inverses of results specify source data operand element set 1612, transform matrix 1610 operands, transform vector 1614 operations number and an optional first irreducible polynomial. In response to the decoded affine inversion instruction, one or more execution units (eg, execution unit 462 ) perform an AND through eight bitwise AND's through the GF(256) byte multiplier array in processing block 1602. ) 1627-1620, applying the transform matrix 1610 operand to each element 1612 in the source data operand set (eg, in a 128-bit block of 16-byte elements), and via the GF(256) bit in processing block 1603 The eight 9-input XORs 1637-1630 of the adder array apply a transform vector 1614 operand to perform a SIMD affine transform on each transformed element in the source data operand set. It will be appreciated that this point in the calculation may correspond to point 1418 in process 1403 . The finite field multiplicative inverse element 1648 modulo the irreducible polynomial may be computed via the multiplicative inversion unit 1640 from the affine transformed result element 1618 for each element 1612 in the source data operand set. A multiplicative inverse element result element 1648 for each affine transformed result element 1618 of an affine inversion instruction is stored in a SIMD destination register (eg, in physical register bank unit 458).

It will be appreciated that some embodiments of affine inversion instructions may be useful for performing processes such as process 1403 . Other embodiments may be useful for performing processes such as process 1402.

Figure 16C shows a diagram of an alternative embodiment of an apparatus 1606 for executing an inverse affine instruction for computing a multiplicative inverse and then affine transforming the result to provide a generic GF (256) SIMD encrypted arithmetic functions. Various embodiments of apparatus 1606 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, core 490 ) for executing inverse affine instructions for providing generic GF(256) SIMD cryptographic arithmetic functions execution unit 462). Embodiments of apparatus 1606 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for inversion and affine transformation in GF(256) . In some embodiments, an inverse affine instruction may be implemented by a microinstruction (or microop, microop, or uop)—eg, a finite field multiplication inversion microinstruction 1604 followed by an affine map 1601 microinstruction. In alternative embodiments, inverse affine instructions may be implemented by different uops—eg, a finite-field multiplication inversion uops followed by a finite-field matrix-vector multiplication uops and finite-field vector-to-scalar conversions (eg, broadcast and XOR) microinstructions.

Various embodiments of apparatus 1606 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of inverse affine instructions and subsequent affine transform functions for general GF(256) SIMD computations that provide multiplicative inverses specify source data operand element set 1612, transform matrix 1610 operands, transform vector 1614 operations number and an optional first irreducible polynomial. In processing block 1604, in response to the decoded inverse affine instruction, one or more execution units (eg, execution unit 462), via multiply inversion unit 1640, compute a SIMD for each element 1612 in the source data operand set Binary finite field multiplicative inverse element 1616 modulo the irreducible polynomial. The one or more execution units then apply the transform matrix 1610 operands to the source through eight bitwise ANDs 1627-1620 via the GF(256) byte multiplier array in processing block 1602 Each multiplicative inverse element 1616 of elements 1612 in the data operand set (eg, in a 128-bit block of 16-byte elements), and via eight nines of the GF(256)-bit adder array in processing block 1603 XORs 1637-1630 are input to apply transform vector 1614 operands to perform a SIMD affine transform on each transformed inverse element in the source data operand set. The affine transformed result element 1638 of each multiplicative inverse element 1616 of the elements 1612 in the source data operand set of the inverse affine instruction is stored in a SIMD destination register (eg, in physical register bank unit 458 ) ).

Figure 17A shows a diagram of one embodiment of an apparatus 1701 for executing a finite field multiplication inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. In some embodiments, devices 1701 may be replicated 16 times, each device 1701 comprising a 128-bit block for efficiently implementing a 128-bit block consisting of 16 byte values (each byte having a polynomial representation in GF(256)). The hardware processing block of the multiplication and inversion of the AES S-box. In other embodiments of finite field multiply inversion instructions (or microinstructions), the element size may also be specified, and/or the number of copies of the device 1701 may be selected to enable 128-bit blocks or 256-bit blocks or 512-bit blocks Equal to the finite field multiplication inverse. Various embodiments of apparatus 1701 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, execution stage 416 ) for executing finite field multiplication inversion instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1701 may be coupled with a decode stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding the instructions for the multiplication inversion in GF(256). In device 1701, we consider that each byte x is output from point 1418 in process 1401, so device 1701 begins by accessing the source data operand set containing x. Processing blocks 1711-1717 include polynomial exponentiation byte slice generation circuits for computing powers ^x2 , ^x4 , Byte values represented by polynomials in GF( ²⁵⁶ ) for ^x8 , ^x16 , ^x32 , ^x64 , and x128. Processing blocks 1718-1720 and 1728-1730 include multiplier byte slice circuits for dividing byte values in GF(256) corresponding to the powers of the polynomial representations for each of the 16 byte values, respectively Multiply together to generate 16 byte values represented by the polynomial in GF(256), each having multiplicative inverses x ^-1 =x ²⁵⁴ corresponding to their respective byte values x, respectively. These 16 multiplicative inverse metabyte values are then stored (eg, in register bank unit 458) or output to processing block 1421 in process 1401, where an affine transform circuit (eg, 1601) optionally is used in processing block 1422 to apply an affine transformation depending on whether process 1401 is performing encryption or decryption.

Figure 17B shows a diagram of an alternative embodiment of an apparatus 1702 for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. In some embodiments, devices 1702 may be replicated 16 times, each device 1702 comprising a 128-bit block for efficiently implementing a 128-bit block consisting of 16 byte values (each byte having a polynomial representation in GF(256)). The hardware processing block of the multiplication and inversion of the AES S-box. In other embodiments of finite field multiply inversion instructions (or microinstructions), the element size may also be specified, and/or the number of copies of the device 1702 may be selected to enable 128-bit blocks or 256-bit blocks or 512-bit blocks Equal to the finite field multiplication inverse. Various embodiments of apparatus 1702 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, execution stage 416 ) for executing finite field multiplication inversion instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1702 may be coupled with a decode stage (eg, decode 406 ) or a decoder (eg, decode unit 440 ) for decoding the instructions for the multiplication inversion in GF(256). In device 1702, we again consider that each byte x is output from point 1418 in process 1401, so device 1702 begins by accessing the source data operand set containing x. It will be appreciated that point 1418 in process 1401 may represent the output of an affine transformation circuit (eg, 1601 ) or an affine mapping instruction in processing block 1417 . Processing blocks 1721-1727 include polynomial exponentiation byte slice generation circuits for computing powers ^x6 , x24, ^x24 , Byte value represented by a polynomial in GF( ²⁵⁶ ) for ^x96 and x128. Processing blocks 1728-1730 include multiplier byte slice circuits for multiplying together byte values in GF(256) corresponding to powers of polynomial representations for each of the 16 byte values, respectively, in order to generate 16 byte values represented by a polynomial in GF (256), each having multiplicative inverses x ⁻¹ =x ²⁵⁴ corresponding to their respective byte values x, respectively. The 16 multiplicative inverse metabyte values are stored (eg, in register bank unit 458) or output to processing block 1421 in process 1401, where the affine transform circuit (eg, 1601) optionally uses The affine transformation is applied in process block 1422 to depend on whether process 1401 is performing encryption or decoding.

Figure 17C shows a diagram of another alternative embodiment of an apparatus 1703 for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. In some embodiments, devices 1703 may be replicated 16 times, each device 1703 comprising a 128-bit block for efficiently implementing a 128-bit block comprising 16 byte values (each byte having a polynomial representation in GF(256)). A hardware processing block for the finite field multiplication and inversion of . In other embodiments of finite field multiply inversion instructions (or microinstructions), the element size may also be specified, and/or the number of copies of the device 1703 may be selected to achieve a 128-bit block or a 256-bit block or a 512-bit block Equal to the finite field multiplication inverse. Various embodiments of apparatus 1703 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, ) for executing finite-field multiply inversion instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1703 may be coupled with a decode stage (eg, decode 406 ) or a decoder (eg, decode unit 440 ) for decoding the instructions for the multiplication inversion in GF(256).

Various embodiments of apparatus 1703 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of finite field multiplication inversion instructions for providing a generic GF(256) SIMD multiplication inversion function specify a source data element set 1710 and a first irreducible polynomial 1740. In response to the decoded finite field multiplication inversion instruction, one or more execution units (eg, execution units 462 ) compute the SIMD binary finite field multiplication inverse modulo the irreducible polynomial for each element 1710 in the source data operand set . Some embodiments of means 1703 perform a finite field multiplication inversion operation in the composite field GF((2 ⁴ ) ² ). In processing block 1734, each element 1710 in the source data operand set is mapped to a composite field GF((2 ⁴ ) ² ), which outputs 4-bit field elements z _H 1735 and z _L 1736 . For one embodiment, the inverse field element z _L ^-1 1746 is computed as follows: (1) in the composite field, the field elements z _H 1735 and z _L 1736 are added (bitwise XOR 1737); (2) in the composite field In processing block 1739, the outputs of the bitwise XOR 1737 are multiplied and modulo the irreducible polynomial p. In one embodiment, the polynomial p=z ⁴ +z ³ +1, but in alternative embodiments, other 4th degree irreducible polynomials may be used. The computation of the inverse field element z _L ^-1 1746 continues: (3) In processing block 1738, the field element z _H 1735 is squared, multiplied by the hexadecimal value 8, modulo p, in the composite field add its result to the output of processing block 1739 (bitwise XOR 1741); (4) in processing block 1742, compute the inverse of the output of the bitwise XOR 1741; and (5) in processing block 1744, and Field elements z _L 1736 are multiplied and modulo p to generate inverse element field elements z _L ^-1 1746 . For one embodiment, the inverse meta-field element z _H ^-1 1745 is computed as follows: steps (1) through (4) are as described above; and (5) in processing block 1743, the output of processing block 1742 is compared to the field element z _H 1735 is multiplied and modulo p to generate the inverse metafield element z _H ^-1 1745 . Then, in processing block 1747, each pair of 4-bit field elements z _H ^-1 1745 and z _L ^-1 1746 are inverse-mapped from the composite field GF((2 ⁴ ) ² ) to generate the multiplication in GF(256) Inverse meta result element 1750. The multiplication inverse element result element 1750 for each element 1710 in the source data operand set of the finite field multiplication inversion instruction is ultimately stored in a SIMD destination register (eg, in physical register bank unit 458).

Figure 18A shows a diagram of one embodiment of an apparatus 1801 for executing specific modulo-reduce instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. In the presently shown example, the particular modulo polynomial 1811B is p=x8+ ^x4 + ^x3 +x+ ¹ in GF(256). In some embodiments, device 1801 may be replicated 16 times, each device 1801 including a specific modulo normalization for efficiently implementing two 128-bit blocks (or one 256-bit block) comprising 16 two-byte values A hardware processing block that generates a 128-bit block consisting of 16 byte values approximately, each of the resulting 16 byte values having a polynomial representation in GF(256). Various embodiments of apparatus 1801 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, execution stage 416 ) for executing specific modulo-reduce instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1801 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for a particular modulo reduction in GF(256).

Various embodiments of apparatus 1801 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of specific modulo-reduce instructions for providing a generic GF(256) SIMD modulo-reduce function specify a source data operand element set 1810 and a first irreducible polynomial 1811B. In response to the decoded modulo-reduce instruction, one or more execution units (eg, execution units 462) compute a SIMD binary finite field modulo irreducible polynomial reduction modulo for each element 1810 in the source data operand set. Elements 1810 of the source data operand set with two-byte values are input into processing block 1821 as _qH 1828 and _qL 1820. In processing block 1821, some embodiments of apparatus 1801 perform a 12-bit operation that equals:

The resulting element T of processing block 1825 with the partially reduced 12-bit value is input into processing block 1831 as _TH 1838 and _TL 1830. In processing block 1831, some embodiments of apparatus 1801 perform an 8-bit operation in processing block 1835, which is equal to:

It will be appreciated that in an XOR operation, the zero (0) input can be eliminated, thereby further reducing the logic complexity of the device 1801. A particular modulo-reduce result element 1850 for each element 1810 in the source data operand set of a particular modulo-reduce instruction is stored in a SIMD destination register (eg, in physical register bank unit 458).

18B shows a diagram of an alternative embodiment of an apparatus 1802 for executing specific modulo-reduce instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. In the presently shown example, the particular modulo polynomial 1811B is also p=x8+ ^x4 + ^x3 +x+ ¹ in GF(256). It will be appreciated that similar techniques are also applicable to implement specific modulo-reduce instructions (or micro-instructions) for other modulo-reduction polynomials, such as the block cipher SMS4 used in the Wireless LAN WAPI Chinese National Standard (Wired Authentication and Privacy Infrastructure) As used in , f ₅ in GF(256) = x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1. In some embodiments, device 1802 may be replicated 16 times, each device 1802 including a specific modulo normalization for efficiently implementing two 128-bit blocks (or one 256-bit block) comprising 16 two-byte values A hardware processing block that generates a 128-bit block consisting of 16 byte values approximately, each of the resulting 16 byte values having a polynomial representation in GF(256). Various embodiments of apparatus 1802 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, ) for executing specific modulo-reduce instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1802 may be coupled with a decode stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for a particular modulo reduction in GF(256).

Various embodiments of apparatus 1802 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of specific modulo-reduce instructions for providing a generic GF(256) SIMD modulo-reduce function specify a source data operand element set 1810 and a first irreducible polynomial 1811B. In response to the decoded modulo-reduce instruction, one or more execution units (e.g., execution units 462) compute a SIMD binary finite field modulo irreducible polynomial reduction modulo for each element 1810 in the source data operand set. Elements 1810 of the source data operand set with two-byte values are input into processing block 1861 as q[15:8] 1828 and q[7:0] 1820. In processing block 1861, some embodiments of apparatus 1802 perform logical operations in XOR logic gates 1867-1860, which are equal to:

A particular modulo-reduce result element (q mod p) 1850 for each element 1810 in the source data operand set of a particular modulo-reduce instruction is stored in a SIMD destination register (eg, in physical register bank unit 458) .

Figure 18C shows a diagram of another alternative embodiment of an apparatus 1803 for executing specific AES Galois Counter Mode (GCM) modulo-reduce instructions for providing GF( ²¹²⁸ ) SIMD encrypted arithmetic functions. In the presently shown example, the particular modulo polynomial 1887 is p=x128+ ^x7 + ^x2 +x+1 in GF( ²⁵⁶ ). Various embodiments of means 1803 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, execution stage 416 ) for executing specific modulo-reduce instructions for providing GF(2 ¹²⁸ ) SIMD cryptographic arithmetic functions. , execution unit 462). Various embodiments of apparatus 1803 may be coupled with a decode stage (eg, decode 406) or decoder (eg, decode unit 440) for decoding instructions for a particular modulo reduction in GF(2 ¹²⁸ ) .

Embodiments of apparatus 1803 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of specific instructions for providing the AES GCM modulo-reduce function in GF(2 ¹²⁸ ) specify a source data operand element set 1813 and a first irreducible polynomial 1887 . In response to the decoded finite field modulo-reduce instruction, one or more execution units (eg, execution unit 462 ) compute a SIMD finite field reduction modulo an irreducible polynomial for each element 1813 in the source data operand set .

Element 1813 of the source data operand set with a 32-byte value is input into processing block 1871. In processing block 1871, some embodiments of means 1803 perform operations on the non-reflected bits of the reduction polynomial with respect to the non-bit-reflected, which is equal to the bit-reflected as shown below Modulo reduction of the reflected bits of the product of :

(i) [X ₃ , X ₂ , X ₁ , X ₀ ]=q[255:0]<<1;

(ii) A=X ₀ <<63; B=X ₀ <<62; C=X ₀ <<57;

(iv) [E ₁ ,E ₀ ]=[D,X ₀ ]>>1; [F ₁ ,F ₀ ]=[D,X ₀ ]>>2; [G ₁ ,G ₀ ]=[D, X ₀ ]>>7;

Accordingly, equation (i) is implemented by shifter 1870 from element 1813 to generate [X ₃ , X ₂ , X ₁ , X ₀ ] 1872 . Equation (ii) is implemented by shifters 1873-1875. Equation (iii) is implemented by processing block 1876 . Equation (iv) is implemented by shifters 1877-1879. Equation (v) is implemented by processing block 1885 and equation (vi) is implemented by processing block 1880 . A particular modulo-reduce result element (q mod p) 1853 for each element 1813 in the source data operand set of a particular modulo-reduce instruction is stored in a SIMD destination register (eg, in physical register bank unit 458) .

Figure 18D shows a diagram of one embodiment of an apparatus 1804 for executing a modulo-reduce instruction for providing a general binary finite field GF( ^2t ) SIMD cryptographic arithmetic function. In the presently shown example, the modulo reductions may be provided from specific modulo polynomials for which the instructions (or microinstructions) are provided, eg, p ₀ , p ₁ , . . . _pn ) Choose a specific modulo polynomial p _s in . In some embodiments where t=8, the device 1804 may be replicated 16 times, each device 1804 including a method for efficiently implementing two 128-bit blocks (or one 256-bit block) of 16 two-byte values A specific modulo reduction to generate a hardware processing block consisting of 128-bit blocks of 16-byte values, each of the resulting 16-byte values having GF(256) or alternatively some composite field (e.g. , a polynomial representation in GF((2 ⁴ ) ² ) or GF((2 ² ) ⁴ ), etc.). In other embodiments of a modulo-reduce instruction (or microinstruction), the size t may also be specified, and/or the number of copies of the device 1804 may be selected to generate 128-bit blocks or 256-bit blocks or 512-bit blocks, etc. Various embodiments of apparatus 1804 may be part of pipeline 400 (eg, execution stage 416 ) or core 490 for executing modulo-reduce instructions for providing general binary finite field GF(2 ^t ) SIMD cryptographic arithmetic functions part (eg, execution unit 462). Various embodiments of the apparatus 1804 may be used for pairing in a binary finite field GF(2 ^t ) or alternatively in some composite field (eg, GF((2 ^u ) ^v ), where t=u+v) A decode stage (eg, decode 406 ) or decoder (eg, decode unit 440 ) that decodes the instruction performing the modulo reduction in is coupled.

Figure 19A shows a diagram of one embodiment of an apparatus 1901 for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. In some embodiments, the devices 1901 may be replicated 16 times, each device 1901 including an efficient implementation for each including 16 byte values (each byte having a polynomial representation in GF(256)) Hardware processing block for binary finite field multiplication of two 128-bit blocks. In other embodiments of binary finite field multiply instructions (or microinstructions), the element size may also be implemented, and/or the number of copies of the device 1901 may be selected to achieve a 128-bit block or a 256-bit block or a 512-bit block, etc. binary finite field multiplication. Embodiments of apparatus 1901 may be part of pipeline 400 (eg, execution stage 416 ) or part of core 490 (eg, core 490 ) for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. execution unit 462). Various embodiments of apparatus 1901 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for finite field multiplication in GF(256).

Various embodiments of apparatus 1901 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of binary finite field multiply instructions for general GF(256) SIMD computations that provide binary finite field multiply functionality specify two source data operand element sets 1910 and 1920 and a first irreducible polynomial. In processing block 1902, in response to the decoded binary finite field multiply instruction, one or more execution units (eg, execution unit 462) compute a SIMD carry-free 8x8 multiplication to generate a 15-bit product element 1915, and for For each pair of elements 1910 and 1912 in the source data operand set, the reduced product 1918 modulo the selected irreducible polynomial via a modulo-reduction unit 1917 (eg, via selector 1916). The result of the reduction product 1918 of each binary finite field multiplication of pairs 1910 and 1912 of elements in the source data operand set is stored in a SIMD destination register (e.g., in physical register bank location 458).

Figure 19B shows a diagram of an alternative embodiment of an apparatus 1903 for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. In some embodiments, devices 1903 may be replicated 2 times, each device 1903 including a 16-byte value (each byte having a polynomial representation in GF(256)) for efficiently implementing Hardware processing block for binary finite field multiplication of two 128-bit blocks. In other embodiments of binary finite field multiply instructions (or microinstructions), the element size may also be implemented, and/or the number of copies of the device 1903 may be selected to enable 128-bit blocks or 256-bit blocks or 512-bit blocks, etc. binary finite field multiplication. Various embodiments of the apparatus 1903 may be part of the pipeline 400 (eg, execution stage 416 ) or part of the core 490 (eg, execution unit 462). Various embodiments of apparatus 1903 may be coupled with a decoding stage (eg, decode 406) or a decoder (eg, decode unit 440) for decoding instructions for finite field multiplication in GF(256).

Various embodiments of apparatus 1903 may be coupled with a SIMD vector register (eg, physical register bank unit 458) that includes m variable numbers of values for storing m variable numbers of variable size data elements variable size data fields. Some embodiments of binary finite field multiply instructions for general GF(256) SIMD computations that provide binary finite field multiply functionality specify two source data operand sets (eg, 1920 and 1922) and a first irreducible polynomial p. In processing block 1902 of array 1925, in response to the decoded binary finite field multiply instruction, one or more execution units (eg, execution unit 462) compute a SIMD carry-free 8x8 multiplication to generate product element 1915, and for For each pair of elements in the source data operand sets 1920 and 1922, the reduced product 1918 modulo the selected irreducible polynomial via a modulo-reduction unit 1917 (eg, via a selector 1916). The result of the reduced product set 1928 of the SIMD binary finite field multiplication of the source data operand sets 1920 and 1922 is stored in a SIMD destination register (eg, in the physical register bank unit 458).

Figure 20A shows a flowchart of one embodiment of a process 2001 for executing an affine map instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. Process 2001 and other processes disclosed herein are performed by processing blocks, which may include special purpose hardware or software or firmware opcodes executable by a general purpose machine or a special purpose machine or a combination of both.

In processing block 2011, processor affine map instructions for SIMD affine transforms in finite fields are decoded. In processing block 2016, decoding of the affine map instruction optionally generates a plurality of microinstructions, such as the first microinstruction for finite field matrix-vector multiplication 1602 and the first microinstruction for finite field vector addition (or XOR) 1603 The second microinstruction. In process block 2021, the source data operand element set is accessed. In processing block 2031, the transform matrix operand is accessed. In process block 2041, the transform vector operand is accessed. In processing block 2051, a transformation matrix operand is applied to each element in the source data operand set. In processing block 2061, a transform vector operand is applied to each transformed element in the source data operand set. In processing block 2081, a determination is made whether processing of each element in the source data operand set has completed. If not, the SIMD affine transformation repeats the iterations started in process block 2051. Otherwise, in processing block 2091, the result of the SIMD affine transformation is stored in the SIMD destination register.

Figure 20B shows a flow diagram of one embodiment of a process 2002 for executing a finite field multiply inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. In processing block 2012, a processor multiplication inversion instruction for SIMD multiplication inversion in a finite field is decoded. In processing block 2016, decoding of the multiply-inverse instruction optionally generates a plurality of microinstructions, eg, a first microinstruction for multiply-inverse and a modulo-reduction such as one of 1801-1804. The second microinstruction of approx. In process block 2022, the source data operand element set is accessed. In processing block 2032, the irreducible polynomials are optionally explicitly identified. In one embodiment, the irreducible polynomial may be specified as a control value 1B in hexadecimal, for example, in the immediate operand of the instruction to indicate the polynomial ^x8 + ^x4 + in the Galois field GF(256) ^x3 +x+1. In another embodiment, the irreducible polynomial may be specified as a control value FA in hexadecimal to indicate the polynomial x ⁸ +x ⁷ in the Galois field GF(256), for example, in the immediate operand of the instruction +x ⁶ +x ⁵ +x ⁴ +x ² +1 or alternatively indicates another polynomial. In another alternative embodiment, the irreducible polynomial may be specified and/or explicitly identified in the instruction mnemonic. In processing block 2042, a binary finite field multiplicative inverse is computed for each element in the source data operand set, and in processing block 2052, the inverse pair for each element in the source data operand set is optionally rendered inverse About polynomial reduction modulo. In processing block 2082, a determination is made whether processing of each element in the source data operand set has completed. If not, the SIMD finite field multiplication inversion restarts the iteration started in process block 2042. Otherwise, in process block 2092, the result of the SIMD affine transformation is stored in the SIMD destination register.

Figure 20C shows a flowchart of one embodiment of a process 2003 for executing an affine inversion instruction for providing generic GF(256) SIMD cryptographic arithmetic functions. In processing block 2013, processor affine inversion instructions for SIMD affine transformation and inversion in finite fields are decoded. In processing block 2016, decoding of the affine inversion instruction optionally generates a plurality of microinstructions, eg, a first microinstruction for finite field affine map 1601 and a second microinstruction for finite field multiplication inversion 1604. microinstructions; or alternatively, a first microinstruction for finite field matrix-vector multiplication 1601, followed by a second microinstruction for byte broadcasting, a third microinstruction for finite field vector addition (XOR) 1602 instruction and fourth microinstruction for finite field multiplication inversion 1604. In process block 2023, the source data operand element set is accessed. In processing block 2033, the transform matrix operand is accessed. In process block 2043, the conversion vector operand is accessed. In processing block 2053, a transformation matrix operand is applied to each element in the source data operand set. In processing block 2063, a transform vector operand is applied to each transformed element in the source data operand set. In processing block 2073, for each transformed element of the source data operand set, a binary finite field multiplicative inverse is computed. In processing block 2083, a determination is made whether processing of each element in the source data operand set has completed. If not, the SIMD affine transformation and inversion repeat the iterations started in process block 2053. Otherwise, in processing block 2093, the result of the SIMD affine transformation and multiplication inversion is stored in the SIMD destination register.

Figure 20D shows a flow diagram of one embodiment of a process 2004 for executing binary finite field multiply instructions for providing generic GF(256) SIMD cryptographic arithmetic functions. In processing block 2014, a processor multiply instruction for SIMD multiplication in a finite field is decoded. In processing block 2016, decoding of the affine inversion instruction optionally generates a plurality of microinstructions, eg, the first microinstruction for finite field carry-less multiplication 1913 and a microinstruction for one such as one of 1801-1804 The finite field modulo reduction of the second microinstruction of 1917. In process block 2024, a first set of source data operand elements is accessed. In process block 2034, a second set of source data operand elements is accessed. In processing block 2044, the irreducible polynomials are optionally explicitly identified. In one embodiment, the irreducible polynomial may be specified, for example, in the immediate operand of the instruction as a control value 1B in hexadecimal to indicate the polynomial x ⁸ +x ⁴ + in the Galois field GF(256) ^x3 +x+1. In another embodiment, the irreducible polynomial may be specified as a control value FA in hexadecimal to indicate the polynomial x ⁸ +x ⁷ in the Galois field GF(256), for example, in the immediate operand of the instruction +x ⁶ +x ⁵ +x ⁴ +x ² +1. In another alternative embodiment, the irreducible polynomial may be specified and/or explicitly identified in the instruction mnemonic. In process block 2054, a product of pairs of corresponding elements for each of the corresponding elements of the first and second source data operand sets is computed, and in process block 2064, the first and second source data are optionally made The product of each of the corresponding elements in the operand set modulo the irreducible polynomial reduction. In processing block 2084, a determination is made whether processing of each of the corresponding elements in the first and second source data operand sets has completed. If not, the SIMD finite field multiplication repeats the iteration started in process block 2054. Otherwise, in process block 2094, the result of the SIMD finite field multiplication is stored in the SIMD destination register.

It will be appreciated that, while the instructions for executing the instructions for providing general SIMD cryptographic arithmetic functions may be shown above as being iterative, whenever possible, one or more instances of the various processing blocks may and preferably be concurrently and/or are executed in parallel to increase execution performance and throughput.

It will be appreciated that the general purpose GF(256) SIMD encrypted arithmetic instructions can be used to provide general purpose GF(256) SIMD encrypted arithmetic functions in a variety of applications, for example, for secure use in financial transactions, e-commerce, email, software distribution, Encryption protocols and Internet communications for data integrity, authentication, message content authentication, and message origin authentication for data storage, etc.

Accordingly, it will be appreciated that execution of instructions for at least the following: (1) SIMD affine transforms specifying source data operands, transform matrix operands and transform vectors, wherein the transform matrix is applied to the source data operations each data element of the number, and a transformation vector is applied to each transformed element; (2) SIMD binary finite field multiplication inversion, which is used to compute for each element in the source data operand the Inverse modulo an irreducible polynomial; (3) SIMD affine transform and multiplicative inverse (or multiplicative inverse and affine transform) specifying the source data operand, transform matrix operand, and transform vector, where, before the multiply inverse operation or after, a transformation matrix is applied to each element in the source data operands, and a transformation vector is applied to each transformed element; (4) Modulo reduction, which is used to compute the pair from the binary finite field A specific modulo polynomial ps selected from a plurality of polynomials for which modulo reduction is provided by the instruction (or microinstruction) for these specific polynomials is reduced modulo; (5) SIMD binary finite field multiplication, which specifies the first and the second source data operand, and are used to multiply and modulo the irreducible polynomial by pairs of elements corresponding to each of the first and second source data operands; wherein the results of these instructions are stored in the SIMD object and can provide general-purpose GF(256) and/or other alternative binary finite field SIMD cryptographic arithmetic functions in hardware and/or microcode sequences so as not to require excessive or excessive amounts of additional circuitry, area, or power Excessive functional units can support significant performance improvements for several important performance-critical applications.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention can be implemented as a computer program or program code executing on a programmable system including at least one processor, a memory system (including volatile and nonvolatile memory and/or storage element), at least one input device, and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and to generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, 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 may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system. The program code may also be implemented in assembly or machine language, if desired. In fact, the mechanisms described herein are not limited to the scope of any particular programming language. In any case, the language can be a compiled language or an interpreted language.

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

Such machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles of manufacture or formation by machines or equipment, including storage media, such as: hard disks; any other type of disks, 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) such as Access Memory (SRAM), Erasable Programmable Read Only Memory (EPROM), Flash Memory, Electrically Erasable Programmable Read Only Memory (EEPROM); Phase Change Memory (PCM) ; a magnetic or optical card; or any other type of medium suitable for storing electronic instructions.

Accordingly, various embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or containing design data ( For example, Hardware Description Language (HDL)). Such embodiments are also referred to as program products.

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

Accordingly, techniques for executing one or more instructions in accordance with at least one embodiment are disclosed. While certain exemplary embodiments have been described and illustrated in the accompanying drawings, it is to be understood that such embodiments are merely illustrative and not limiting of the broad invention and that the invention is not limited to the particulars shown and described. structures and configurations, as various other modifications will be apparent to those skilled in the art after a study of this disclosure. In a field of technology such as this application, in which development is rapid and further progress is unforeseeable, the disclosed embodiments are easily modifiable in configuration and detail enabled by technological progress, without departing from the scope of the present disclosure. principles and scope of the appended claims.

Claims (31)

1. A processor comprising: a decoding stage for decoding a first instruction for inversion of a single instruction multiple data SIMD binary finite field multiplication, the first instruction specifying a source data operand set and an irreducible polynomial; and One or more execution units, in response to the decoded first instruction: For each element in the source data operand set, computing the binary finite field multiplicative inverse modulo the irreducible polynomial as a SIMD operation; and The result of the first instruction is stored in a SIMD destination register. 2. The processor of claim 1, wherein the first instruction designates the SIMD destination register as a destination operand. 3. The processor of claim 1, wherein the first instruction specifies a SIMD register to hold a plurality of 16-byte elements as the source data operand set. 4. The processor of claim 1, wherein the first instruction specifies a SIMD register to hold a plurality of 32-byte elements as the source data operand set. 5. The processor of claim 1, wherein the first instruction specifies a SIMD register to hold a plurality of 64-byte elements as the source data operand set. 6. The processor of any of claims 1-5, characterized by multiplying each element in the source data operand set to 254 in a Galois field GF( ²⁸ ) power and modulo the irreducible polynomial to perform the computation of the SIMD binary finite field multiplication inversion. 7. The processor of any one of claims 1-5, wherein, in the mnemonic of the first instruction, the irreducible polynomial is designated as 1B to indicate Galois Field GF x ⁸ +x ⁴ +x ³ +x+1 in (2 ⁸ ). 8. The processor of any one of claims 1-5, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a hexadecimal control value 1B to indicate x ⁸ +x ⁴ +x ³ +x+1 in the Galois field GF(2 ⁸ ). 9. The processor of any one of claims 1-5, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a hexadecimal control value F5 to indicate x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1 in the Galois field GF(2 ⁸ ). 10. A device for performing a single instruction multiple data SIMD binary finite field multiplication inversion operation, the device comprising: means for accessing source data operand element sets and irreducible polynomials; means for computing the binary finite field multiplicative inverse modulo the irreducible polynomial for each element in the source data operand element set as a SIMD operation; and Means for storing in a SIMD destination register the result of modulo the irreducible polynomial by the SIMD binary finite field multiplicative inverse. 11. The apparatus of claim 10, wherein in an immediate operand of a first instruction for SIMD binary finite field multiplication inversion, the irreducible polynomial is specified as a control in hexadecimal Value IB to indicate x8+ ^x4 + ^x3 +x+ ¹ in the Galois field GF( ²⁸ ). 12. The apparatus of claim 10, wherein, in the mnemonic of the first instruction of SIMD binary finite field multiplication inversion, the irreducible polynomial is designated 1B to indicate Galois field GF( 2 ⁸ ) in x ⁸ +x ⁴ +x ³ +x+1. 13. The apparatus of claim 10, wherein in the immediate operand of the first instruction of SIMD binary finite field multiplication inversion, the irreducible polynomial is specified as the control value 87 in hexadecimal to indicate x ¹²⁸ +x ⁷ +x ² +x+1 in the Galois field GF(2 ¹²⁸ ). 14. The apparatus of claim 10, wherein in the immediate operand of the first instruction of SIMD binary finite field multiplication inversion, the irreducible polynomial is specified as a control value F5 in hexadecimal to indicate x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1 in the Galois field GF(2 ⁸ ). 15. A processing method, comprising: decoding a first instruction for inversion of single instruction multiple data SIMD binary finite field multiplication, the first instruction specifies a source data operand set and an irreducible polynomial; In response to the decoded first instruction, for each element in the source data operand set, computing a binary finite field multiplicative inverse modulo the irreducible polynomial as a SIMD operation; and The result of the first instruction is stored in a SIMD destination register. 16. The processing method of claim 15, wherein, in the immediate operand of the first instruction, the irreducible polynomial is designated as a control value 1B in hexadecimal to indicate Galois x ⁸ +x ⁴ +x ³ +x+1 in the field GF(2 ⁸ ). 17. The processing method of claim 15, wherein, in the mnemonic of the first instruction, the irreducible polynomial is designated as 1B to indicate that in the Galois field GF( ²⁸ ) x ⁸ +x ⁴ +x ³ +x+1. 18. The processing method of claim 15, wherein, in the immediate operand of the first instruction, the irreducible polynomial is designated as a control value of 87 in hexadecimal to indicate Galois x ¹²⁸ +x ⁷ +x ² +x+1 in the field GF(2 ¹²⁸ ). 19. The processing method of claim 15, wherein in the immediate operand of the first instruction, the irreducible polynomial is designated as a control value F5 in hexadecimal to indicate Galois x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1 in the field GF(2 ⁸ ). 20. A processing system comprising: a memory for storing first instructions for the SIMD secure hash algorithm wheel segment; and processors, including: an instruction fetch stage for fetching the first instruction; a decoding stage for decoding a first instruction for inversion of a single instruction multiple data SIMD binary finite field multiplication, the first instruction specifying a source data operand set and an irreducible polynomial; and One or more execution units, in response to the decoded first instruction: For each element in the source data operand set, computing the binary finite field multiplicative inverse modulo the irreducible polynomial as a SIMD operation; and The result of the first instruction is stored in a SIMD destination register. 21. The processing system of claim 20, wherein in the mnemonic of the first instruction, the irreducible polynomial is designated as 1B to indicate that in the Galois field GF( ²⁸ ) x ⁸ +x ⁴ +x ³ +x+1. 22. The processing system of claim 20, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value IB in hexadecimal to indicate Galois x ⁸ +x ⁴ +x ³ +x+1 in the field GF(2 ⁸ ). 23. The processing system of any one of claims 20-22, wherein the first instruction is further for a SIMD affine transform of each binary finite field multiplicative inverse, and the one or more The execution units are further configured to, in response to the decoded first instruction: By applying a transform matrix operand to the multiplicative inverse of each element in the source data operand set and applying a transform vector operand to each transformed multiplicative inverse of the elements in the source data operand set element to perform a SIMD affine transformation in order to generate the result of the first instruction. 24. The processing system of claim 20, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value of 87 in hexadecimal to indicate Galois x ¹²⁸ +x ⁷ +x ² +x+1 in the field GF(2 ¹²⁸ ). 25. The processing system of claim 20, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value F5 in hexadecimal to indicate Galois x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1 in the field GF(2 ⁸ ). 26. A machine-readable medium comprising a plurality of instructions stored on the machine-readable medium that, when executed, cause a computing device to perform the method of any of claims 15-19 method. 27. A processing device comprising: an apparatus for decoding a first instruction for inversion of a single instruction multiple data SIMD binary finite field multiplication, the first instruction specifying a source data operand set and an irreducible polynomial; means for computing a binary finite field multiplicative inverse modulo the irreducible polynomial for each element in the source data operand set as a SIMD operation in response to the decoded first instruction; and means for storing the result of the first instruction in a SIMD destination register. 28. The processing device of claim 27, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value of 1B in hexadecimal to indicate Galois x ⁸ +x ⁴ +x ³ +x+1 in the field GF(2 ⁸ ). 29. The processing device of claim 27, wherein, in the mnemonic of the first instruction, the irreducible polynomial is designated as 1B to indicate that in the Galois field GF( ²⁸ ) x ⁸ +x ⁴ +x ³ +x+1. 30. The processing device of claim 27, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value of 87 in hexadecimal to indicate Galois x ¹²⁸ +x ⁷ +x ² +x+1 in the field GF(2 ¹²⁸ ). 31. The processing device of claim 27, wherein in an immediate operand of the first instruction, the irreducible polynomial is specified as a control value F5 in hexadecimal to indicate Galois x ⁸ +x ⁷ +x ⁶ +x ⁵ +x ⁴ +x ² +1 in the field GF(2 ⁸ ).